Hm – I'm not too happy to see most of the original HTML-elements marked "not conforming" and "must not be used", thus preparing for browsers to eventually drop the support. There are still lots of web-sites and valuable information stored and archived in this format. Back in the day, it was thought that basic HTML was a format to last. Who is going to update these documents in order to make them conforming to future browsers? Or are we just dropping a decade of documentation? Is it worth it?
(Consider: Apparently, MS-Word docs or PDF prove longer lived than basic HTML documents! Who would have thought of this?)
I don't really know what process the W3C fork of our work uses for removal, if any, but you can learn more about how features get removed in the (WHATWG) HTML Standard per our working mode:
In short, I think it's important to distinguish between conformance and removal from browsers. Removal from browsers is a big deal and, as per those links, is only done when it's not going to break the web, or when the benefits are very high (e.g. security issues). Removal from being conformant just reflects the evolution of best practices. See also https://github.com/whatwg/html/blob/master/FAQ.md#how-are-de...
<blink> is no longer supported by browsers, but with a few css declarations it works just fine.
Removing support for presentational markup does not mean a loss of information. Browsers will still render tags they don't recognize, and re-applying the styling of those tags is often trivial. (I mention <blink> because it's one of the more difficult, but not terribly so)
As the web evolved, our needs changed. Do we still need the <font> tag?
> Back in the day, it was thought that basic HTML was a format to last.
HTML was never intended to be archival. Archival assumes a long term relationship between format and user-agent, but those two things evolve independently.
> Who is going to update these documents in order to make them conforming to future browsers?
You don't update legacy documents stored in an archive. You find a conforming user-agent (appropriately old browser version) to consume them in their intended state.
> Is it worth it?
Yes, HTML is a versioned format. Improvements to the format are welcomed and necessary.
What's wrong with W3C again? Are we on the same train we were with the ill-fated XHTML 1 strict and XHTML 2.
Anyway what's going on anyway with Google+Microsoft+Apple+W3C, why is there such a big push to HTTPS and HTTP/2, and declaring old HTTP/0.9 and HTTP/1 and HTTPS/1 and HTML5.0 as legacy!? And why is Mail still sent in plain text completely insecure, and no adoption hype to support SMIME/etc? It is beyond fishy. Or is it just pure greed, no one cares about non-walled-garden-open-web (aka everything has to live in LinkedIn/FB/AppStore/PWA) and there is no money in mail?
WHATWG needs to add a <w3c-please-stop-plagiarising-the-whatwg-html-standard /> tag then gate some useful functionality behind it to see if W3C will dare include it
I really wish we'd "simplify" the HTML spec. The "pave the cow paths" approach to allow non-closed tags and mix of various syntaxes has lead to an explosion of complexity. That has regressed into terrible performance and memory hungry parsers.
I wish WHATWG would properly version their work. I don't like the idea of a "living standard" because it leads to checking for individual functionality and feature detection, rather than being able to say, "This is fully HTML 5.x.x compliant."
Regardless of the state of W3C, if I built an embedded renderer based on their specs, I could at least say, "this renderer is based on <http-ref> and link to the recommended spec version. Whereas if I did that with the living standard href, I'd be out of date any time they decided to rename an attribute.
This specification should be read like all other specifications. First, it should be read cover-to-cover, multiple times. Then, it should be read backwards at least once. Then it should be read by picking random sections from the contents list and following all the cross-references.
Ah, hyperbole. I didn't know that humor could be specified.
What's the point of removing features such as "menu" from HTML standard? If there are browsers supporting it and webpages using it, would Mozilla (or Google or Microsoft) actually remove those features just because newest standard said so? I mean: marquee was deprecated long ago, yet browsers still render it correctly.
<marquee> has never been part of any HTML standard, ever. It is listed as an obsolete feature in the HTML5 standard for the point of making it obsolete (a weird reason) but not mentioned anywhere else since time began.
<isindex> got removed from browsers, which I personally find kind of sad because that's what I learned in 1995 and I've written a web page that uses it. But it's weird and does nothing that a normal form couldn't do, so the browsers seem to want to deprecate it.
Whether or not to remove a web platform feature from a browser basically comes down to how many people are using it vs. what is the maintenance cost. I suspect that browsers continue to support <marquee> so they can continue to render all those great webpages from the late 1990s properly.
I can't speak for the spec authors, but IMHO, tags should be deprecated and eventually removed when they are deemed to be useless, especially when their functions and/or semantics are covered by another tag, and especially when their use is harmful (or rather, more harmful than beneficial).
In my (very personal) opinion, an HTML tag or attribute, and more generally a feature of any design/development framework, should be considered possibly harmful if it:
- presents possible security problems; for examples, consider some of the points listed here: https://html5sec.org/
- promotes poor usability or accessibility; e.g. interactive tooltips with links or controls in them, for example, are quite difficult to make accessible, and I wouldn't want an HTML <tooltip> tag without a lot of discussion about accessibility
- promotes anti-patterns; e.g., at this point I think <marquee>-style scrolling informational text is an anti-pattern in a web context, since it can the text much harder to read, especially on small screens
Of course, none of these concerns should lead to immediate removal of a thing as soon as they're pointed out, but they should be discussed and considered. It's a cost-benefit analysis: what does this feature actually buy us that isn't easily achievable with other features, what problems is it causing and how severe are they, and are the benefits worth the problems?
As for <menu>, my guess, though I haven't been able to find the actual discussion, is that it was removed because its semantics are somewhat in conflict with <nav>, and probably its most common use was custom context (aka "right-click") menus, which bring a lot of accessibility problems with them. I don't know that I agree with the decision to remove it altogether, since I think its use to semantically identify and group web application controls is very valuable and not covered by any other tags (though I'd love to be corrected), but I do think that context menus, which to me seems like the most common use for the <menu> tag, are a very problematic design element. Again, it's a balance; is it worth the problems it causes? I guess the authors decided it wasn't.
(Just to reiterate, I don't know why <menu> was removed, I'm just guessing. If anyone can find any of the discussions about <menu> and the problems with it, I'd love to read more.)
[+] [-] masswerk|8 years ago|reply
(Consider: Apparently, MS-Word docs or PDF prove longer lived than basic HTML documents! Who would have thought of this?)
[+] [-] domenicd|8 years ago|reply
- https://whatwg.org/working-mode#removals
- https://whatwg.org/faq#removing-bad-ideas
In short, I think it's important to distinguish between conformance and removal from browsers. Removal from browsers is a big deal and, as per those links, is only done when it's not going to break the web, or when the benefits are very high (e.g. security issues). Removal from being conformant just reflects the evolution of best practices. See also https://github.com/whatwg/html/blob/master/FAQ.md#how-are-de...
[+] [-] reificator|8 years ago|reply
Removing support for presentational markup does not mean a loss of information. Browsers will still render tags they don't recognize, and re-applying the styling of those tags is often trivial. (I mention <blink> because it's one of the more difficult, but not terribly so)
As the web evolved, our needs changed. Do we still need the <font> tag?
[+] [-] vorpalhex|8 years ago|reply
[+] [-] austincheney|8 years ago|reply
HTML was never intended to be archival. Archival assumes a long term relationship between format and user-agent, but those two things evolve independently.
> Who is going to update these documents in order to make them conforming to future browsers?
You don't update legacy documents stored in an archive. You find a conforming user-agent (appropriately old browser version) to consume them in their intended state.
> Is it worth it?
Yes, HTML is a versioned format. Improvements to the format are welcomed and necessary.
[+] [-] jraut|8 years ago|reply
The comment mentions long-lived MS-Word doc. Which version of those, specifically, has been around the longest so far?
[+] [-] Bahamut|8 years ago|reply
[+] [-] frik|8 years ago|reply
Anyway what's going on anyway with Google+Microsoft+Apple+W3C, why is there such a big push to HTTPS and HTTP/2, and declaring old HTTP/0.9 and HTTP/1 and HTTPS/1 and HTML5.0 as legacy!? And why is Mail still sent in plain text completely insecure, and no adoption hype to support SMIME/etc? It is beyond fishy. Or is it just pure greed, no one cares about non-walled-garden-open-web (aka everything has to live in LinkedIn/FB/AppStore/PWA) and there is no money in mail?
[+] [-] taspeotis|8 years ago|reply
[+] [-] rwmj|8 years ago|reply
[+] [-] planxty|8 years ago|reply
All I want for Christmas is an obvious link in the top of every W3C document showing me what's new.
[+] [-] igravious|8 years ago|reply
[+] [-] TazeTSchnitzel|8 years ago|reply
[+] [-] kryptiskt|8 years ago|reply
[+] [-] ChrisSD|8 years ago|reply
See https://creativecommons.org/licenses/by/4.0/
> You are free to:
> Share — copy and redistribute the material in any medium or format
> Adapt — remix, transform, and build upon the material for any purpose, even commercially.
[+] [-] dmitriid|8 years ago|reply
See the full story here: https://www.reddit.com/r/javascript/comments/5swe9b/what_is_...
[+] [-] bringtheaction|8 years ago|reply
[+] [-] currysausage|8 years ago|reply
The W3C regularly publishes forks [1] of the WHATWG HTML Living Standard. They have good SEO, but not much relevance.
[1] http://lists.w3.org/Archives/Public/www-archive/2014Apr/0034...
[+] [-] unknown|8 years ago|reply
[deleted]
[+] [-] dragonwriter|8 years ago|reply
[+] [-] toxicFork|8 years ago|reply
[+] [-] exabrial|8 years ago|reply
[+] [-] andrewmcwatters|8 years ago|reply
Regardless of the state of W3C, if I built an embedded renderer based on their specs, I could at least say, "this renderer is based on <http-ref> and link to the recommended spec version. Whereas if I did that with the living standard href, I'd be out of date any time they decided to rename an attribute.
[+] [-] _nalply|8 years ago|reply
Ah, hyperbole. I didn't know that humor could be specified.
[+] [-] philipwhiuk|8 years ago|reply
[+] [-] zaarn|8 years ago|reply
[0]: https://www.w3.org/TR/html52/changes.html#changes
[+] [-] tobyhinloopen|8 years ago|reply
[+] [-] magnat|8 years ago|reply
[+] [-] sureaboutthis|8 years ago|reply
I don't recall the reasons for removing <menu>
[+] [-] geofft|8 years ago|reply
[+] [-] rlanday|8 years ago|reply
[+] [-] kenbellows|8 years ago|reply
In my (very personal) opinion, an HTML tag or attribute, and more generally a feature of any design/development framework, should be considered possibly harmful if it:
- presents possible security problems; for examples, consider some of the points listed here: https://html5sec.org/
- promotes poor usability or accessibility; e.g. interactive tooltips with links or controls in them, for example, are quite difficult to make accessible, and I wouldn't want an HTML <tooltip> tag without a lot of discussion about accessibility
- promotes anti-patterns; e.g., at this point I think <marquee>-style scrolling informational text is an anti-pattern in a web context, since it can the text much harder to read, especially on small screens
Of course, none of these concerns should lead to immediate removal of a thing as soon as they're pointed out, but they should be discussed and considered. It's a cost-benefit analysis: what does this feature actually buy us that isn't easily achievable with other features, what problems is it causing and how severe are they, and are the benefits worth the problems?
As for <menu>, my guess, though I haven't been able to find the actual discussion, is that it was removed because its semantics are somewhat in conflict with <nav>, and probably its most common use was custom context (aka "right-click") menus, which bring a lot of accessibility problems with them. I don't know that I agree with the decision to remove it altogether, since I think its use to semantically identify and group web application controls is very valuable and not covered by any other tags (though I'd love to be corrected), but I do think that context menus, which to me seems like the most common use for the <menu> tag, are a very problematic design element. Again, it's a balance; is it worth the problems it causes? I guess the authors decided it wasn't.
(Just to reiterate, I don't know why <menu> was removed, I'm just guessing. If anyone can find any of the discussions about <menu> and the problems with it, I'd love to read more.)
[+] [-] unknown|8 years ago|reply
[deleted]
[+] [-] yuhong|8 years ago|reply
[+] [-] tebruno99|8 years ago|reply
[+] [-] jlebrech|8 years ago|reply
it's a document markup language and shouldn't be used for apps.
[+] [-] eberkund|8 years ago|reply
[+] [-] SimeVidas|8 years ago|reply
[+] [-] jrochkind1|8 years ago|reply