HTML 5.2 Recommendation
w3.org
w3.org
(Consider: Apparently, MS-Word docs or PDF prove longer lived than basic HTML documents! Who would have thought of this?)
The comment mentions long-lived MS-Word doc. Which version of those, specifically, has been around the longest so far?
As for MS-Word and HTML: When I finished my thesis in the mid-1990s, I saved it both in the MS-Word version, I used to write it (MS Word 5 for Mac), and HTML (expecting future compatibility). I can still open the Word version, but I may be soon unable to conjure a formatted display of the HTML-version. And I can still display a PDF 1.x...
(Current frame is "self" or "window", parent frame or frameset is "parent", and the top most entry point into the hierarchy "top". Moreover, "self", transcending the window context, is also the only reliable reference to the global object, thus also providing a valid reference to the context of a worker. Specifically, it was for framesets that the notion of hierarchy was introduced, which eventually resulted in the concept of the DOM. Some inconsistencies to this concept of strict parent-child relations were actually introduced by early implementations of the iframe-element, which is, BTW, still a valid HTML element.)
That said, there was a small inconsistency with an early subversion of Netscape 3, regarding, whether the frame source would be relative to any current location of the frame or rather relative to the frameset. (But this was an issue for a rather short period of time, two months or so.) A major difference in styling was the implementation of frame borders, if they would be entirely invisible by just specifying `border="0"` (Netscape and others) or, if they required the two attributes `frameborder="0"` and `framespacing="0"` (MS IE). In practice, next to all sites specified both schemes. And jet another, but minor implementation specific detail was the sizing of framesets: While Netscape Navigator supported, like all other browsers, a size specified in pixels, this was internally translated to percents of the total width. Therefor, depending on rounding to integers, the presentation in the Netscape browser could be off by a pixel or two.
(The latter was, in deed, not unusual behavior at the time, just like MS Word and RTF used to translate any measurements internally to "tips" or twentieths of a point.)
I am super glad for all the hard work put into all this.
The report is saved across six .doc files, due to the size limitation of the 3.5" floppy disks we were using back then.
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?
<span style="color: #000; font-face: Whatever; font-size: 10pt">Blah</span>
<font face="Whatever" size="2" color="#000000">Blah</font>You could use "font-size: small" to get the size="2" behavior.
(Also, "font-family: Whatever", not "font-face: Whatever".)
> <span style="font-size: 10pt">Blah</span>
vs.
> <font size="2">Blah</font>
Which is easier to remember? Which is more obvious at a glance?
Plus, the former is an absolute value where the latter is not, as far as I've been able to tell. I know that first span will always be 10pt font. I have no idea what "2" even means in this context.
It's true that you can just use some CSS to make up for the lost HTML feature, but than again you could also rewrite the HTML part.
Forgive me if I'm wrong, but I'm fairly sure that what the OP is trying to say, is that there are plenty of great websites out there, which were developed a long time ago, and for which there is no maintainer to do any work on it. Thus having HTML elements like this dropped, would make the content in a way lost.
Thinking about it some more, users can probably add plugins to add this css automatically, or some browsers might even keep those features in, but still, there will be users that don't know this, I think, resulting in a bad experience.
I was thinking about something like Stylish or the user stylesheet I've been hearing about in Firefox (for their UI IIRC, but still). Inject some global css on older/missing doctypes, and it's probably less than 200 total declarations to handle every older tag. I'd imagine <font> to be the hardest and/or longest, followed by <blink> and <marquee>.
Would be a small extension.
My other point I think I expressed clearly enough, that the loss of presentational markup is not a loss of content in most cases. If the title is in Times New Roman instead of Arial, most of the time it'll just look worse. Unless the content is meta, the presentation is to make things more pleasant to read.
My primary point is that presentational markup is not required to get value from all but the most meta of old pages.
The content will not be lost. The tags will result in valid elements but the rendering may vary. This has always been a thing to be expected, since legacy elements (pre HTML5) never had uniform rendering and contained quirks.
Should the current/new standard have support for ambiguously rendered quirky elements? Is it even a standard then?
After HTML5 the end result will definitely be the same on most (if not all) layout engines. The standardization as a process requires non-conforming legacy to be dropped.
- 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...
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?
The actual HTML specification which browsers follow is maintained by WHATWG at:
...is found here: https://chromium.googlesource.com/
The reality is that the WHATWG (a) only writes descriptive standards, describing what already exists, usually with pseudocode and prosa instead of ABNF or EBNF (see the URL standard replacement), and (b) only describes something once it’s actually been implemented on larger scale.
On the topic of what standards are supposed to do – prescriptively shape and replace what exists – the WHATWG isn’t useful. WHATWG "standards" are the equivalent of Microsoft Office Open XML, a standards body just taking an existing implementation, defining whatever it does as standard, and doing it so incomplete that the result is useless.
Yes, WHATWG and W3C are doing the best they can do in the current climate (where Google can roll out QUIC and SPDY before even any standard is defined across websites accounting for 6% of global traffic, 65%+ of web browsers, and 85%+ of mobile phones), but this is just misleading. It helps no one to pretend to do standardization work when you don’t actually have any power to decide anything – neither WHATWG nor W3C can actually force, or even ask, Google to change SPDY or QUIC. They’re papertigers.
In Chrome we ensure that all features we ship to the web go through a public standards process. This allows them to be developed by a collaborative community, including other browser vendors and web developers who would use them. It ensures that if we happen to ship a feature sooner than other vendors, there's a specification and a shared test suite (https://github.com/w3c/web-platform-tests) that allow others to quickly follow. Note that a specification is better than requiring them to read the Chromium source, because specifications are at a higher level that doesn't depend on individual browser architecture details.
In the WHATWG we don't only write descriptive standards. But we do ensure that whatever standards we write, are ones browsers are willing to implement. And we ensure that standards accurately describe how browsers operate, even for legacy features, because that is all part of the mission of allowing browsers to compete on an even playing field and build themselves from scratch without having to go through the kind of costly reverse-engineering that Firefox 1.0 did to catch up to IE6. In practice we've found that algorithmic specs are better for this than BNFs, as it's harder to specify error-handling behavior for BNFs while still staying compatible with the web (i.e. while still producing a standard browsers are willing to ship).
And yes, we're not interested in just creating a standard out of thin air, with no vendor collaboration, calling it "standard", and then hoping some magical power would force browsers to implement. It is indeed much more collaborative than that.
But the fact that we require standards to be developed in tandem with implementations doesn't mean that implementations (such as Chrome) just go ahead and do whatever they want, and we at the WHATWG transcribe it into the spec at some lower level of detail. Instead, the public, collaborative standards process helps to extract out all testable and observable aspects of the feature into a codebase-agnostic description others can use, and provides a forum for them to comment on ideas before any final shipping decisions are made. And, per our working mode (https://whatwg.org/working-mode#changes), changes and additions do require multi-implementer support before they're ready to graduate to a WHATWG Living Standard; proposals not yet at that point are said to be in incubation, and are often developed elsewhere (see https://whatwg.org/working-mode#new-proposals) such as the W3C's WICG.
Ehm, basically every major feature Chrome has shipped has been shipped before the standard was even discussed. SPDY shipped long before HTTP/2 was even finalized, and QUIC is doing the same. NaCl shipped in the same way, without any standardization, and to this date, earth.google.com depends on it.
In general, your problem is that you only consider browser developers. In the past, the WHATWG has decided to redefine the URL standard, then shame cURL for not following the standard, without ever involving anyone from the curl project in the discussion. The URL discussion affects everything from Android’s IPC system to curl, from industrial machinery to the web. The WHATWG explicitly declared that the URL spec is designed to completely, and exhaustively, obsolete and deprecate any existing URL or URI spec.
Yet, the only people ever contacted about this, and who were given the ability to take part in the discussion, were representatives from the three large browser vendors.
The URL Standard was designed in the open with input from many different constituencies. The cURL author has chosen not to participate, for reasons of his own, but e.g. Node.js, PHP, Google's GURL (used by Android IPC, I believe), and others are quite involved.
The only participants were all either browsers, affiliated with browsers, or a handful of web serving projects.
Other projects that rely on URLs include everything from KDE to Gnome, Microsoft’s OS to the systems used in your car.
Changing a URL standard and only involving web vendors is basically like changing the A4 paper standard and only talking to the Microsoft Office team, the Google Docs team, and HP’s printer team – while entirely ignoring paper manufacturers, envelope manufacturers, the mail companies around the world that will have to ship the envelopes, fax manufacturers that have to build faxes able to fax the new format, newspapers and magazines that have to replace their paper, newspaper shelf manufacturers that build newspaper shelves for newspaper stores, etc.
Most of the time, it’s easy to only think of the web as browsers and servers, but some of the specs the WHATWG touches go through entire industries, sometimes there are millions of companies that have to be notified months or years beforehand to replace their software, update it, potentially even do a recall, and standardize. Not everything moves as fast as the web.
And this entirely disregards the people that are trying to parse the web with HTML parsing, which everyone loves to ignore. And so many other groups of people and companies.
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.
From what I understand, the WHATWG's policy regarding archival is "well yes the format is constantly changing but we'll try REALLY hard to not make too many breaking changes."
That said, validity changes don’t matter to the browser’s ability to render old pages. Changes to remove support for an element entirely are very rare.
Additionally, WHATWG lost some credibility when they attempted to redefine the DOM and arbitrarily delete some node types. Granted, most of those types are legacy types not in use by anybody in long time, except for the attribute node type. Browser vendors simply ignored this foolishness.
Here is a very simplified description of this problem years after the fact: https://github.com/whatwg/dom/issues/102
It is important to understand the DOM wasn't created for HTML. The DOM, starting with DOM level 2, was created in parallel with XML Schema. This is evident when reading some of the W3C mailing lists and comparing release dates of W3C publications.
Attribute nodes can be independently walked when walking the DOM. By removing attributes as a node type you break this functionality. You can use this little utility I wrote as a proof: https://github.com/prettydiff/getNodesByType/blob/master/get...
Browser vendors are extremely shy about adopting new technology that makes for breaking changes. They will do so, but you need to have an incredibly strong argument. WHATWG's changes to the DOM had no beneficial argument, except perhaps developer convenience for those developers who cannot figure out DOM walking.
The DOM is a pretty solid technology with regard to extensibility, predictability, and sturdiness. If you maintain a large major browser and somebody came to you with breaking changes and a bunch of weak bullshit for justifications what would you do? Also, imagine if you will, that if you ever challenge the people bringing you this pile of shit they will troll the hell out of you in a very visible and immature way.
The response from the browser vendors was to simply say nothing and ignore them like they were never there. I got into an argument about this with the WHATWG on a github issue once, and wish I hadn't. Ignorance is like a black hole that sucks everything in and it never stops to allow rational signals to escape undamaged.
Regardless of issues like this, browsers track WHATWG DOM near exclusively. You can see devs from all of the major browser engines commenting in the issue you linked.
I know from my own conversations with the WHATWG this wasn't something that long time WHATWG members would admit to (or even understand). It was the childishness, perhaps more than anything else, that nobody took them seriously.
> Regardless of issues like this, browsers track WHATWG DOM near exclusively.
I am going to disagree with you there. Perhaps they do now, extremely recently, but historically this is absolutely false.
> You can see devs from all of the major browser engines commenting in the issue you linked.
Yes, everybody participates in the WHATWG. This isn't new. Participation is different than adopting those recommendations back into your software.
Here is what browsers actually implement: https://www.w3.org/DOM/DOMTR and https://www.w3.org/TR/dom41/
It is important to keep in mind that the WHATWG doesn't do a lot of XML work, but the DOM is markup language agnostic. The DOM isn't something created or maintained in an HTML rich vacuum.
The person who ultimately fixed this problem in the DOM Living Standard is Anne Van Kesteren, who was not even remotely new to WHATWG at the time. The person who filed this issue (Philip) is also a WHATWG old timer.
This is about the exact opposite of archival: backwards compatibility. We don’t want to split the web into old web and new web. Having to switch browsers for decade old pages as we encounter them, raising the barrier to entry for that lore of old, effectively sepulchring it from the public.
99% of the web’s users are not going to understand when to switch browsers, how, nor why.
It happens anyways regardless of what people want. The 90s era web doesn't work properly in modern browsers and 90s era browsers don't work with the modern web.
> 99% of the web’s users are not going to understand when to switch browsers, how, nor why.
This also happens naturally. Chrome is the most popular browser and it doesn't come with most operating systems. That is something users must switch to.
Opposed to this, HTML was not intended as presentation layer for fancy web-apps. (There had been better around for this in the Hypertext-world, even then.)
All I want for Christmas is an obvious link in the top of every W3C document showing me what's new.
EDIT: Apparently even that description was too charitable towards the W3C (see gsnedders comments).
But is that actually an improvement over the previous situation? (Serious question.)
No, it means we have two increasingly different documents purportedly defining the same things, and when they do copy patches over they've failed to also copy over other dependent patches too on a number of occasions leaving their spec as defined unimplementable.
Practically speaking, the Web is a consortium of corporate foghorns that also happen to collectively be the majority ad-hoc directors of new media (translation: agendas with finance). Cable and daytime TV was the old media, which of course still exists, and social media has become a juggernaut majority of its own beside that.
So, you'd think the actual grassroots on-the-ground parts of a project that is ostensibly defined to be open and free, would actually be made of extremely smart people with straightforward management and as little bureaucracy as possible. Because, you know, the part where everything hits the ground needs to be well-oiled, have no chinks in the armor, and provide a secure foundation of independence.
And yet we have... chaos, infighting, politics and wars over (literally) nothing. And while all that's happening, corporations are progressively nibbling away at the capabilities we have today (to set up websites, to communicate freely) that we take for granted. One day we'll wake up checkmated by some incredibly well-engineered chess move...
Sighs
If the net neutrality thing is repealed, I will be exactly 0% surprised. It'll just be another EME, really.
It shouldn't be their job to decide how browsers should work, that's the browser makers' decision. (Which happens to be large corporations, for the most part.)
Nevermind the fact that the landscape has changed to the point where that isn't a realistic outcome anymore.
Nevermind the fact that in the instance I'm describing (which was something like WebASM or WebSockets.. it was WebSomething and I can't recall the name), they had submitted their proposals to the standardization groups, with no change on the volume of the noises.
I wish people would decide whether they want browser makers trying New Stuff or they want New Stuff coming from standards bodies only. There are upsides and downsides to either way, but I really don't beleive that BMing browser makers whenever they try New Stuff is even sort of constructive.
This seems to make the most sense because the browser is the end product by which people consume their internet.
It seems to me, they have been and always will be years ahead of the governing bodies that make these part of their "standards" decisions. By the time something finally makes into the spec, we're already onto a dozen new things the browsers are capable of and implementing.
At this point it just feels like the spec is an afterthought, not necessarily keeping up with how fast the industry is changing.
The W3C is for web authors. It presents a more stable recommendation and provides advice (based on research) for authors.
> The W3C is for web authors. It presents a more stable recommendation and provides advice (based on research) for authors.
Web authors usually use MDN instead, because it serves that purpose in a much better way. (Note that despite the name MDN is not Mozilla specific but a cross-browser resource, and that Microsoft and Google recently joined MDN.)
> The WHATWG is for browser vendors. It's in a constant state of flux as new changes get proposed and those proposals get changed through implementation.
The W3C recommendation is no different in that regard, they also describe stuff that's not fully implemented in all browsers yet. But the WHATWG version is more up to date, so you'll notice much earlier that the new feature you want to depend on will be abandoned or changed.
Note for a W3C document to go to Recommendation there must be two interoperable implementations. Of course, that doesn't mean any browser has implemented any of it, just that someone has implemented each part of it.
tl;dr: Ignore w3c's HTML "standards" as they are (often poor) copies of WHATWG's standards.
I my opinion one cannot call something a "standard" that changes every few days.
EDIT: In this sense W3C's HTML 5.x can be considered a rather badly authored (cf. other comments here) standard, while what the WHATWG releases is not something that even measures up to a standard, but it is the daily version of how HTML is supposed to be today.
Just because it changes often doesn't mean things are sloppily accepted, or that experimental ideas are added and later removed.
Indeed, if you want to build something for the web, reading an outdated document that contains bugs browsers have already fixed is not a good idea.
When you do a project contract, you surely want to define the exact standard with respect to which the application is to be developed against, so that one can decide whether the reason for something looking wrong is a browser bug (I can work around it - but it will cost extra money) or indeed a bug in my code that the customer found (i.e. I have to work extra hours for no money because I did bad work).
To be able to decide such questions is a central purpose of existence for standards.
I already argued that there is no WHATWG standard, but only a document that changes every few days. Even without this nitpicking: Which of these thousands of versions is the one on which the browser implementation is based on?
Do you really want to make a requirements document that describes something different at the day you sign it and at the day you deliver?
Wake up.
You can't compare it to browsing on Amazon, because functionality doesn't just go missing and literally break buying things; functionality doesn't just suddenly get added and people rely on the exact font size and copy of a particular header in the men's clothing department to be precisely 2em and "Men’s Clothing," and now that it's changed to 1.5em and "Men's Winter Fashion" a third-party app can't render the header in an appropriate width size nor find the clothes to begin with.
Counterexample: About three months ago I asked on HN why on modern browsers some subtests of Acid3 fail:
> https://news.ycombinator.com/item?id=15256890
I actually got some pretty smart answers, for example:
> https://news.ycombinator.com/item?id=15259428
To quote it for convenience:
"Two changes lead to three failures in Chrome.
The first change is described in the 'note' at https://drafts.csswg.org/selectors-4/#child-index
Chrome is failing a test because the root node claims to be a 'first-child'.
The root node is the first sibling, but since it doesn't have a parent, the selectors 3 spec didn't include it.
The selectors 4 draft does away with the requirement that a 'first-child' have a parent, and chrome's behaviour matches.
The second is discussed here https://github.com/whatwg/dom/issues/319
Roughly, when interpreting qualified names, Chrome is throwing InvalidCharacterErrors when the acid test wants it to throw NamespaceErrors, in situations where you really have both. This leads to two tests failing."
So decide for yourself whether the WHATWG "standard" did breaking changes in the past or not.
The advantage to following the WHATWG specs is that it reflects how browsers work today, not how they worked a few years ago.
So, WHATWG is in constant flux, and W3C has about as much authority as I do. _Thankfully_ in practice WHATWG is "stable enough," but just saying that's what "we" consider a good enough standard for something used in creating all sorts of UIs, from trivial to vitally important, is indicative of a bigger problem.
There exist lots of standards that hardly anybody cares about. So this is clearly not true.
What parts of the standard are stable?
The whole standard is more or less stable. There are some parts of it that describe new technologies that have not yet been implemented everywhere, but at this point those additions are only added after the design itself is pretty stable. Such additions must also have the support of two or more implementers, per our working mode[1].
Why are there no stable snapshots, or versions, of the standard?
In practice, implementations all follow the latest standard anyway, not so-called "finished" snapshots. The problem with following a snapshot is that you end up following something that is known to be wrong. That's obviously not the way to get interoperability!
This has in fact been a real problem at the W3C, where mistakes are found and fixed in the editors' drafts of specifications, but implementers who aren't fully engaged in the process go and implement obsolete snapshots instead, including those bugs. This has resulted in serious differences between browsers.
A standard is something like ISO EN DIN A4. It is defined in cooperation with every stakeholder involved, it is specced, it is tested, and a stable definition is created. Everyone builds against this definition, and it works fine. The standard deprecates everything that existed before, and replaces it.
That is a standard. It’s authoritative, basically immutable, and it is prescriptive.
WHATWG "standards" come after the fact, only consider whatever browsers implement, refuse to ever deprecate anything (unless browsers have already deprecated it), and almost always just are "whatever Google Chrome does". That’s a disgusting abuse of the word standard.
WHATWG "standards" are the equivalent of Microsoft Office Open XML, a standards body just taking an existing implementation, defining whatever it does as standard, and doing it so incomplete that the result is useless.
Yes, WHATWG and W3C are doing the best they can do in the current climate (where Google can roll out QUIC and SPDY before even any standard is defined across websites accounting for 6% of global traffic, 65%+ of web browsers, and 85%+ of mobile phones), but this is just misleading. It helps no one to pretend to do standardization work when you don’t actually have any power to decide anything – neither WHATWG nor W3C can actually force, or even ask, Google to change SPDY or QUIC. They’re papertigers.
It's absolutely a fiction, but at the same time, this at least attempts to be a standard.
The WHATWG version seems more like a reflection of "oh by the way that's the rules our browsers are following this month. Your's truly, the browser vendors."
So far we've done our best to keep a really readable, tidy Git commit log, which should help with understanding changes: https://github.com/whatwg/html/commits/master
If you omit the "Editorial:" or "Meta:" commits, I think it's actually at a similar level of detail as the W3C fork's changes log. (Not completely; scrolling through I do see a number of commits that wouldn't be relevant.) But the W3C fork has only managed to copy-and-paste a small subset of our changes, so indeed, the changes log for the last year of work at the WHATWG will be somewhat daunting compared to the small subset they managed to copy over.
There may be room for someone to compile a higher-level "this week/month/year in the HTML Standard" or similar; before I started working in the WHATWG, that actually used to exist: https://blog.whatwg.org/category/weekly-review (also in very amusing YouTube form: https://www.youtube.com/watch?v=1Bg5BPnmj68). So far we haven't had the bandwidth to restart that, but if you or someone else wants to contribute that sort of thing to the blog or elsewhere, I'd love to help you get started.
I don't think the commit history works. It doesn't give you any indication about which changes are relevant or irrelevant and it doesn't tell anything about the larger efforts taking place.
Actually, I don't think it would even make sense to create an equivalent of the W3C diff, because there are no versions or other structures to organize the changes around - there is just a constant stream of changes. (Which is kind of the point of the living standard concept after all)
Personally I'd tend toward weekly or monthly, although I admit that yearly is more likely to generate HackerNews posts ;)
W3C is supposed to be properly supported everywhere.
“HTML Living Standard — Last Updated 13 December 2017”
https://html.spec.whatwg.org/multipage/
I've been telling students that the W3C develops and maintains the HTML spec. Looks like I'm dead wrong. Oops.
Conversely the W3C specifications are fixed to versions and are occasionally patched with updates. The W3C process is incredibly slow and conservative, which frustrates developers on the bleeding edge. Due to the slow process, thoroughness of that process, and formal versioning most software vendors prefer to implement against the W3C publications as more stable or reliable.
Not sure what you mean. In the lower left there is a working collapse button.
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.
Whether someone should be permitted to do something is a different issue than whether they should actually do it.
If that isn't the world you want to live in, let's get rid of this idea that just because I have no interest in the government stopping you from doing a thing by threatening violence (and that's all a license is - a statement that the following activities are not copyright infringement), I'm totally fine with you doing the thing.
And in the quoted statement they are not saying the W3C should improve their process for forking WHATWG's work. They are saying the W3C shouldn't fork their work at all. So despite their specifically chosen license (with easy to understand layman's summary) are WHATWG against all forking? Or are they simply against the W3C?
"In the case of the WHATWG specifications, the licenses allow broad re-use, so that implementors can copy-and-paste text into their comment blocks, so that tutorial writers can copy-and-paste text into their documentation, so that experiments we haven't considered can spring up without inhibition, and so that, if the WHATWG stops being a good steward (like the W3C stopped being a good steward in the early 2000s), the next group of spec editors doesn't have to start from scratch." (http://lists.w3.org/Archives/Public/www-archive/2014Apr/0034...)
There is a typo in the third paragraph, first sentence, FYI. "Are not" is repeated.
For example, there are derivative specifications ("forks") that are not are not prominently identified as copies of WHATWG standardsAnd Hixie/the WHATWG: "It is critically important (not just here but in life at large) to understand the difference between something being _a right_, and something being _right_." (http://lists.w3.org/Archives/Public/www-archive/2014Apr/0034...)
See the full story here: https://www.reddit.com/r/javascript/comments/5swe9b/what_is_...
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...
It did not win.
There are still use cases for the XML syntax.
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.
If you're writing an embedded renderer, you can always say "This is compliant with the standard as of 14 December 2017." If you're writing an embedded renderer that is being applied to the live web and not just to a fixed set of pages that are also embedded (e.g., you're shipping HTML documentation and a viewer, or a kiosk, or something), you will in fact be out-of-date when the living standard changes. There's no point in saying "I'm compatible with HTML 5.2.0" because the live web isn't targeting 5.2 any more. So you can either acknowledge that, or figure out how to get software updates.
As far as I can tell the only way to author a compatible web page these days is by checking every damn feature of HTML you use against some humongous table like Can I Use? before assuming your audiences' browsers support it.
Compare to versioned specs, where I need simply determine the minimum spec version supported by my target audience (and any exceptions to the spec) and code against that spec.
There is some utility in naming sets of well-supported features...
Bootstrapping a web page through JavaScript polyfills is like autoconf all over again.
(That the W3C is apparently incompetent at associating feature sets with names is a separate issue.)
What you're doing when you say that you assume C99 compliance is you're thinking of the features from C99 that you want to use and relying on that. Admittedly, the generally-unsupported features are very niche. But that means that you potentially have a dozen different ideas of what "we support C99" actually means, and that's before you start asking how reliable an implementation needs to be before it meets the definition of "support." Declaring support for versioned standards is often more problematic than helpful (versioned implementations is a different story).
The real problem with autoconf is that no one removes the unnecessary feature checks and no one audits it to see what's still necessary for the platforms that people intend to support.
Sounds fully supported to me, for all practical purposes.
"Default standard is now GNU11" [2]
What do you know that I don't?
The real issue is that people copy+paste autoconf tests from other projects without thinking about whether they're necessary, or even confirming whether they work for their use case. And because people just copy+paste autoconf tests instead of keeping a browser tab open with the (free) POSIX spec when writing their code, most tests people add are for stuff that no longer needs to be tested for (i.e. all the major Unix platforms support most standard POSIX features by default), and lack the tests for non-standard interfaces they actually use.
But there's no easy way to fix such poor development practices. A good start would be if people just stopped using autoconf, as well as libtool, cmake, maven, etc, unless and until it really became necessary. Follow the KISS principle. Keep your build as simple as possible and regularly test your code on at least one platform other than Linux/glibc, such as FreeBSD or OpenBSD, rather than misplacing your faith in overly wrought tooling.
It works the same way on the web. Don't use the latest + greatest feature if you don't need to. Like with performance optimizations, don't add the burden until there's relevant, empirical evidence that it's worth your while in the particular case. Nobody ever magically achieved high performance or strong portability by adopting over wrought tooling before the problems ever presented themselves. Doing so often ends up with the opposite result.
Going to a third-party website to check to see if something is supported is disgusting.
But since I'm not developing for a single browser (outside of my day job that is) I'm going to use the aggregate site that shows all of them at once.
Ah, hyperbole. I didn't know that humor could be specified.
For the question "is this supported widely enough", caniuse.com + your local traffic stats is in most cases more relevant than inclusion in some spec or not.
I don't recall the reasons for removing <menu>
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.)
See more at https://github.com/whatwg/html/pull/2742
---
For more on removals within the WHATWG process, see:
- https://whatwg.org/faq#removing-bad-ideas
- https://whatwg.org/working-mode#removals
There's also the case of things like marquee, which are not removed, but just marked as obsolete and something that web developers must not use. (Which in practice means that conformance checkers like https://checker.html5.org/ are required to complain about them; it doens't mean there's some godlike web-developer-enforcement committee going around preventing you from writing code that uses marquee.) Their implementation requirements are still in the spec; see e.g. https://html.spec.whatwg.org/multipage/obsolete.html#the-mar... and https://html.spec.whatwg.org/multipage/rendering.html#the-ma.... (Same for frame/frameset, by the way.)
it's a document markup language and shouldn't be used for apps.
there should be a new platform that uses a new engine that's isn't backwards compatible.
It might be possible to do this soon with wasm+canvas, but then you have unused rendering engines (html/css) and it's recreated from the ground up.
And what sort of interactivity? Does backend logic count, or only logic in the browser? If only the latter - why does that matter, but not the former? Does any site that uses javascript qualify, regardless of how little?
Hacker News uses javascript, so is it a "web app" and not a "web site?" Would it suddenly become a webapp if the mods hit their heads and decided in a fever delirium to turn the whole thing into a SPA, despite it having the exact same functionality?
In this model, would YC have to publish the static pages of HN on the "static" web but the forum on the "dynamic" web? But what if they cache the threads? Now they're static as well. And having every web developer divide their attention and work between two platforms based on which part of it is "static" and which part is "dynamic" seems needlessly complex and confusing.
I sympathize with the idea - HTML and javascript are terrible for building applications, but if you want the web to only be static HTML files then your "new" platform is going to contain almost every website in existence, including most of the brochure sites, articles and "legacy stuff." Most web apps are also documents, few are strictly one or the other.
It would make more sense to bifurcate the web along WASM, because that will lead to the distinction between HTML and compiled binaries (which, I know, we've already been there with Flash and Java) both in the browser. But even then, WASM is intended to work within the context of javascript and HTML, not necessarily to stand alone.