The "Obsolete" label is rendered in a seemingly random place

[Krinkle]

Important info

• URL to affected spec:https://w3c.github.io/navigation-timing/#dom-performancetiming-redirectend
• ReSpec version: 26.8.12
• I did a "hard refresh", but it's still busted.

Description of problem

What happened?

The "Obsolete" label is rendered in a seemingly random place. Making it appear to be about a specific property further down a long list when in actuality it is applies to the whole section.

Expected behavior

Maybe somewhere toward the top of the section, or perhaps more clearly separated from the content.

Relatedly, I found this word is difficult to read due to its low color contast (light shade of text, on an almost equally light-shaded background(. Increasing this contrast would be good too, if the label is useful to keep around.

[marcoscaceres]

Thanks @Krinkle for reporting. Transferred issue to the navigation timing repo, at it's actually CSS that is directly in the spec that is causing this issue:

navigation-timing/index.html

Lines 9 to 15 in 606cf02

	#obsolete {
	background-position: right;
	background-repeat: repeat-y;
	background-color: rgba(251, 233, 233, 0.5);
	padding: 0 1em;
	background-image: url("data:image/svg+xml;utf8,<svg xmlns='http://www.w3.org/2000/svg' version='1.1' height='300px' width='125px'><text x='0' y='100' fill='red' font-size='15' fill-opacity='0.20'>Obsolete<\/text><\/svg>")
	}

[noamr]

Thanks @Krinkle for reporting. Transferred issue to the navigation timing repo, at it's actually CSS that is directly in the spec that is causing this issue:

navigation-timing/index.html

Lines 9 to 15 in 606cf02

	#obsolete {
	background-position: right;
	background-repeat: repeat-y;
	background-color: rgba(251, 233, 233, 0.5);
	padding: 0 1em;
	background-image: url("data:image/svg+xml;utf8,<svg xmlns='http://www.w3.org/2000/svg' version='1.1' height='300px' width='125px'><text x='0' y='100' fill='red' font-size='15' fill-opacity='0.20'>Obsolete<\/text><\/svg>")
	}

Is there a standard way to emphasize that a whole section is obsolete?

[marcoscaceres]

So, it's quite odd to have "obsolete" section in a standard (as then why is it in the standard?). If the things are shipping in browsers, and there are no intentions to remove them, then we unmark them as obsolete.

For actual obsolete things, we have two options:

• Move them to https://compat.spec.whatwg.org (where, say, things ship, but they are only there for compat reasons)
• Remove them entirely and let MDN keep a record that they are obsolete.

Example from MDN, using <blink> tag:

[marcoscaceres]

Put differently: we should make a working group + implementer decisions about what "obsolete" means here and decide what to do.

@yoavweiss, maybe something to for the group to discuss during TPAC?

[noamr]

I believe it's time to remove those "obsolete" things from the spec, and defer to old versions. But if there are differing views about this, we should discuss of course :)

[npm1]

I guess the question is whether it will ever be possible to remove the 'obsolete' APIs right? I think last time we checked, the usage was extremely high and hence it didn't seem feasible.

[noamr]

Ah it's deprecated but still available, I misunderstood.

If it's available in older versions of the spec, I suggest to refer to the old version from the new one and mention that it's still available but deprecated, but without including all that obsolete detail in the new specs.

[marcoscaceres]

@noamr wrote:

If it's available in older versions of the spec, I suggest to refer to the old version from the new one and mention that it's still available but deprecated, but without including all that obsolete detail in the new specs.

You are not wrong, but "it's complicated" because of a bunch of institutional W3C/community things.

Consider: We could remove the attributes from this document and point to the following old document, where they were originally specified:

• https://www.w3.org/TR/navigation-timing/ (unversioned)

But, generally, at the W3C, and even in this group(!), the spec shortname should point to the latest version.

For example, Page Visibility "2":

• https://www.w3.org/TR/page-visibility/ (Page Visibility 2)
• https://www.w3.org/TR/page-visibility-2/ (Page Visibility 2)

Yep...I could go on... and you'd be right in saying, "this is madness!", and it is.

My recommendation for the working group would be to get rid of versioning and just take over /navigation-timing/ and not mark things as "obsolete". As @npm1 said, we can't ever unship them. What we can do is suggest better alternatives in the spec.

Practically speaking, we should formally "Supersede" (per the W3C process) the 2012 document that currently sits at /navigation-timing/ (as there is no reason anyone should be looking at that document), and just plan the "living standard" version (i.e., this one we are working on) of navigation-timing there... and get rid of the "obsolete" label in the process.

[noamr]

Gotcha, lots of TIL here for me. Not sure what this process entails, will defer to @yoavweiss.

[yoavweiss]

I think there are multiple issue packed into this:

• The current CSS styles should be fixed
• "Obsolete" may not be the accurate term for what we're trying to convey - we want to document the APIs and their processing, but discourage developers from using them. Maybe we should add a note to that effect instead of the "obsolete" label?
• We need to move the unversioned /TR/ link to point to the latest spec iteration, rather than to the 2012 doc.

[noamr]

• "Obsolete" may not be the accurate term for what we're trying to convey - we want to document the APIs and their processing, but discourage developers from using them. Maybe we should add a note to that effect instead of the "obsolete" label?

Isn't that the exact definition of "deprecated"?

[yoavweiss]

In browsers, "deprecated" is something we're hoping to be able to remove one day. I suspect this is not the case here. At the same time, I see this is the language MDN uses here, so maybe we should adopt it as well in the spec.

So, from my perspective, I'm cool with aligning with MDN's language and call this "deprecated".