I suspect at least part of the reason is to build a high barrier to entry and preserve the monopoly, keeping out competitors, given who the people in these groups work for.
My personal opinion on this is to stop feeding the monopoly and refuse to use anything other than basic HTML for static content sites.
Now the browser is pretty limited, sandbox and all that, so companies making bank with it want to widen what they can do with it, again, and again, until the browser becomes an OS under their control, and the user machine just a terminal to access it.
That is far too grand a motive. The reality is that the average web developer has a shelf life of about 5 years or is primarily focused elsewhere, such as Java or C#. That said consider the people who do this work with 100% focus. These people are typically not the same developers who are performing graduate level statistical analysis, building artificial intelligence, or resolving quantum computing. The hiring expectations for front-end developers in the corporate world tend to skew much lower, and the historical average salaries for these positions reflect that. Taking this into account I suspect the real reason for the constant churn is that many of these developers want things to be easier everything else be damned.
It's not good enough to for me to be an arrogant techno-mage looking down on those stupid commoners from my technical tower, I must now also shit on all the other lower developers I have judged to be not as smart as me, some other class of developer.
Fuck off.
Maybe self reflection or hubris is the issue?
I’m blown away by the sheer complexity that has evolved in frontend code. Developers there have such a broad toolset and arcane knowledge about how you really need to combine two CSS traits on surrounding containers to get the positioning you want.
Unfortunately, in our industry, most engineers think the layer above theirs is a trivial composition of parts
As an example consider this recent comment that was upvoted 11 times and some of the responses to it: https://news.ycombinator.com/item?id=20021708
How much of that complexity was necessary? How much of it was chosen to boost someone's CV?
If a job listing for a front-end developer is expecting applicants to know PHP beyond a "writing templates" level, it's either a poorly-written job listing or its creator has unrealistic expectations of its applicants - sadly, neither case is very uncommon in this industry.
At any rate, someone calling themselves a full-stack developer isn't implying they can do embedded, as that sort of stuff is pretty far afield of web development.
99% of it is self-inflicted though. You didn't need react/redux/sagas/uber popular framework 7.5 to do your job, but you and your coworkers thought "This is the cool new toy that facebook made!!!! Let's use it!!!" When 90% of web sites are reinventing a wheel made in 1994, there's no reason to actually do most of this junk
See the framework fallacy https://news.ycombinator.com/item?id=20014888
And none of that complexity is essential to the task, which by itself is a testament of the quality of the “web platform”.
A lot of what happens in someone like Chrome implements something not yet standardized, then it gets standardized in a different way, or Mozilla implements something and Chrome implements it differently from the standard, perhaps to try and reach the same goal without a care for the yet to be finalized standard.
Of course Embrade, Extend, Extinguish is something I think of mostly in regards to Google, but I rather not think they're completely and utterly sinister in their goals. Some parts of Google are bad, just like some parts of Microsoft (sadly) are bad.
Go is a good example of the good parts of Google. Sure the core team works for Google, but they make all the decisions, not Google.
VS Code is another good example in regards to Microsoft, and soon enough GitHub (which I suspect is implementing a lot of ideas they couldn't afford to work on prior to the acquisition).
If the core team works for Google then Google is making all the decisions.
A company is the people working there making the decisions. A company can't make decisions without the people there doing so.
If you are making a web app (like my company does) that needs to print to a label printer how should we do that besides switching to a native app that all of our clients need to install and maintain? WebUSB gives us an option of doing it in a seamless and maintainable way.
So rather than just doing what works and shipping a native app, you instead rely on a feature that's currently in draft status, and works in one browser.. unless Google disable it again, like they did last year?
Sounds like a winning strategy my man.
Edit: to answer your original question > So you're against the standards entirely?
Yes. Literally the only reason either exists, is because without them Google's theory of "everything can be in a browser" falls flat on it's face, and when things are in a browser Google has a good chance of controlling the conversation (the same way Microsoft controlled the conversation in the 90s and early 2000's with Windows).
Both specs have glaring security issues that they themselves point out, but then provide no actual solution or work around for. They may as well start each one with "this could lead to compromise of your device.. life's a lottery, be lucky!"
This means that decision-making is less consistent or deterministic than many people pretend. Things happen because someone advocated for it and other people gave in. The outcomes of internal political decision-making are not necessarily predictable. Speaking of "Google" making a decision is usually misleading.
This. The Chrome team is hopelessly optimistic when making assumptions about how standards evolve. See Web Bluetooth which was heavily advertised to developers before other browser eventually chimed in and said, "yeah, we're not doing that."
Still turned on by default in modern Chrome without a flag, probably because the Chrome team is still assuming that eventually the API will be standardized to Chrome's specification.
That's not going to work for one simple reason: despite HN's obsession with plain HTML/CSS, these new standards _are_ actually useful. They're being created with the express purpose of solving practical problems that developers, site operators, and users are experiencing in the real world. Those stakeholders aren't going to just ignore a practical solution to their problem over some esoteric concerns about "feeding the monopoly".
I share your concerns about the proliferation of web standards making it difficult for browser vendors to compete, but if the only alternative you can offer is stagnation I think it's completely unsurprising that your concerns go unheeded.
I don't necessarily disagree, but it would help your case if you includes some examples in your comment (if only to build a discussion upon).
"giant bundles of JavaScript" weren't how we shipped the web before the HTML5 process began. The solution to "we're loading too much overengineered bloated redundant logic over HTTP" isn't "lets bundle all of that logic", it's "stop overengineering simple webpages".
> even "static HTML" requires accessibility improvements and adaptations to new device types
Accessibility standards predate and are still external to HTML5, and have actual fixed specs. They're relatively simple to implement from a parser perspective, and individual tools implementing functionality on top of that are ancillary to mainstream browsers. The only exception here is support for things like MSAA, etc. and that's also completely separate to HTML5 et al.
You go on to list a bunch of CSS stuff (again, some pre-dating HTML5, none coming from WHATWG), proprietary browser settings (not a part of any spec, living or static).
> better support for print media
Now this would be great to see. However this is something we definitely have not gotten since the advent of HTML5. What are you referring to here?
CORS pre-dates HTML5 (was later subsumed into HTML5), but the newer auth APIs you mention are nice; I'll give you that.
Things like IntersectionObserver however are one perfect example of extra feature-creep in HTML5, building hacks on top of an ecosystem overrun with overengineering. You should not need IntersectionObserver to get basic, usable performant scrolling. If you feel you do, you've overengineered your webapp: try actually addressing your performance bottlenecks.
https://github.com/whatwg/html/commits
Let’s see, right off the top we’ve inputmode attr which helps support different keyboards on plain input text controls, we’ve enterkeyhint which lets you pick from a list of options for the enter key on virtual keyboards - both of these changes improve the usability and accessibility of the keyboard on newer touch screen devices. Form-associated custom elements let you create your own HTML elements that can participate in forms (the goal of custom elements is to help you build your own custom LEGO pieces instead of relying on the basic blocks the HTML spec includes — one could think of this as an eventual replacement of JSX components with HTML-based ones), autocomplete=one-time-code (thanks, iOS!), more granular control over file downloads, updating the spec to match reality (what browsers actually implemented for compatibility vs what was written in advance), srcset for retina (which reminds me, lazy loading images as a simple img tag attribute), WeakMap/WeakSet to help reduce memory leaks from stale DOM node references, requestAnimationFrame and other enhancements to the page lifecycle, CSP headers and related HTML attribute changes, and well, the list doesn’t end. ;-) For accessibility there’s the inert attribute that prevents focus to child content which is great if you need more flexibility than the dialog element provides by default but don’t want to get into setting tabindex manually or controlling all focus with JS, etc.
WeakMap is ECMA. CSP was W3C and implemented by Firefox 4 years before HTML5 was released as a spec.
There's good stuff in the HTML5 (there would want to be in a spec. that size!), but it's remarkable how many of the cited examples are nothing to do with it.
Re. specific examples mentioned:
CSP is still evolving today and HTML has to keep up -- https://github.com/whatwg/html/search?o=desc&q=CSP&s=author-...
With WeakRef, things still need to stay up-to-date: https://github.com/whatwg/html/pull/4571
I would say it's remarkable how many standards on the web apparently don't have anything to do with HTML.
> I would say it's remarkable how many standards on the web apparently don't have anything to do with HTML.
I took the thrust of the original comment I responded to above to be giving WHATWG and general living/rolling-spec. process credit for increasing the pace of useful/practical/needed web innovations. I was pointing out that many of the cited examples of useful innovations were created either before WHATWG existed, or at least outside of WHATWG process, and that the majority (admittedly not all) of what the WHATWG has actually contributed has been superfluous cruft. That's the intent of my separating "this is part of HTML5, this isn't". Obviously many things are/can be subsumed into HTML5 as that's where they belong taxonomically, but I'm focusing on inception and what benefit living-standard process brings.
[0] https://developer.mozilla.org/en-US/docs/Web/API/Web_Authent...
(it might be a bit lost in the hierarchy of the thread by now, but the original comment was about the WHATWG taking over and monopolising the normal considered and democratic standardisation process of the W3C with their HTML5 "living" spec.)
Not a criticism, by the way, sometimes that's just the right fit.
And for anyone who needs some bona fide examples of new standards and updates that are useful from the WHATWG specifications, well how about:
New semantic elements like header, footer, section, article, nav, aside, main, etc. These are far better for making logically structured pages than a ton of divs with class names would be.
The various new input types and attributes. Now you can have input fields which validate email addresses and phone numbers, present the right keyboard for the type of input you want, do various other validation checks or even provide things like a nifty date picker without JavaScript.
Picture and srcset too. No more having to load giant images on mobile devices or have blurry ones on devices with retina support, you can choose which image displays on which type of device.
The preload attribute and what not. Being able to load content the user will likely need in the background is helpful.
The built in video and audio elements, obviously. Again, object was a terrible solution for this, which was unsemantic, was awkward to use and struggled in certain browsers. These elements don't.
The canvas tag and things you can do with it.
And this will be a controversial one, but... most of the old elements that were made official by 'paving the cowpaths' were nice to see added too. The whole fiasco involving embed/object in the old days and how supporting multiple browsers meant invalid HTML was a bit of a farce really, especially as neither were particularly 'semantic' to begin with. Seeing them both made official and better alternatives provided just puts a lifelong issue at rest.
But most of the things mentioned do work in more browsers than not, and you can use them without worrying the site will break in almost all cases. The new semantic elements will never have issues (unless you're trying to target IE8 or below), the validation works fine in pretty much all modern browsers (as do simple styles for it) and support for the picture element and srcset are pretty good too.
The likelihood of anyone using the Blackberry browser or IE mobile is small enough to ignore.
The Electronic Frontier Foundation resigned from the W3C for a reason.
That isn't very logical. New specs like Grid are introduced because they're insanely useful; not because browser vendors just want to make the spec more complex and hard to implement.
I don't see what is so oxymoronic about this? Just because a consensus has been reached doesn't mean that consensus must be immutable.
Just because the process of standardisation in some technical domains has tended to use versioned documents doesn't mean that such an approach is fundamental to standardisation.
A standard is set in stone as a fixed target for implementers.
No fixed target? No standard.
And no, an unversioned document that changes arbitrarily is not a standard.
To put it differently, a standard is a goal. If the goalpost is arbitrarily kept on the move then there is no goal.
Is that a descriptive or normative statement?
These are the first sentences of Yuri Rubinski's foreword to The SGML Handbook outlining the purpose of markup languages (from 1990):
> The next five years will see a revolution in computing. Users will no longer have to work at every computer task as if they had no need to share data with all their other computer tasks, they will not need to act as if the computer is simply a replacement for paper, nor will they have to appease computers or software programs that seem to be at war with one another.
Held up to that goal, HTML has utterly failed. And there's just no justification for attempting to complicate HTML, leading only further away from that goal, and by intent never coming to an end for a task that isn't terribly complicated, and increasing the scope without any sense of mental discipline, and without considering the scarce resources available, thereby creating a browser monoculture.
- Virtually none of these changes are breaking, by design. If you prefer the web of 1998, then as a web developer by and large you can pretend that's still the world we live in.
- HTML itself has actually been a very small fraction of the "HTML5" (a silly marketing term) rapid iteration over the past decade. CSS has grown dramatically in power, and JS is hardly even the same language (which is good, because it was barely a real programming language at the beginning). But HTML itself is not dramatically different; most of what it's gotten are a handful of native replacements for things people had been implementing in JavaScript on a regular basis.
Pretend if you want, your stuff will probably break eventually. If it's simple enough it won't break and then you can go on with your life - that's certainly the goal of browser developers.
At the moment you start using the DOM or other JS APIs exposed by browsers the odds of your stuff breaking in the next decade go up, especially if you're using things that aren't like 5-year-old parts of the spec. The shelf life of most JS-heavy webapps is like 2 years in my experience.
This can still be a significant number, of course...
can you share an example of a breaking change to HTML that a browser has intentionally shipped in the last year?
The "HTML spec" includes a lot of APIs and processing model details that need tweaking as new constraints come up. A good example is that a lot of APIs that involve cross-window access need changes to their specifications in a process-per-origin world; the old spec text assumes everything can always be done synchronously, but that's not actually possible in that world as far as I can tell.
This, and fixing security bugs in the spec that get found from time to time are far from "no good reasons"!
None of the recent HTML spec changes would have affected "wellformedness" of an existing document in the markup sense. They're mostly about fixing spec bugs (in that the spec doesn't match what web sites expect!) in complicated areas like security, navigation, etc.
HTML doesn't cease to be based on SGML by mere declaration, or even by brittling it to the point it can't be parsed by any known formal standard. That's more a political stance, as in American isn't English or some such.
WHATWG's formulation of HTML has deliberately distanced itself from SGML out of ignorance and a desire to not being accountable or formally verifiable (aka move fast and break things) against established, rich theoretical foundations of markup languages. And it shows: already in a paper I published two years ago [1], I show flaws in HTML as described by WHATWG, some of which have since been fixed ([3]). Not only is the concept of "transparent markup" flawed and underspecified, it also has since be used in the definition of the content model for the dl element, and as an unintended consequence also the div element (cf [2]), flaws that could be easily avoided by just using SGML for the grammar WHATWG is attempting to describe when SGML has been around for ages.
It's also not entirely true that WHATWG HTML can parse all legacy docs. For example, the keygen element has been removed, and while not a terrible loss as such ;), since keygen is a void element (an element with declared content EMPTY in SGML parlance), its presence in a legacy document (eg without an end-element tag) will make HTML5 parsers fail hard ([4]). It's also completely unclear which version of HTML is being validated by eg. W3C's nu or another validator. Heck, even the spec text for WHATWG HTML itself reads
> This file is NOT HTML, it's a proprietary language that is then post-processed into HTML
when a large portion of the spec text portrays HTML in the role of an authoring language.
So tell me why, as an author, I should follow WHATWG's vision for HTML? As you say yourself, WHATWG hasn't advanced HTML the markup language at all, and has rather prevented the evolution of declarative UI features, to the effect of making JavaScript essential for all but the most basic documents.
[1]: http://archive.xmlprague.cz/2017/files/xmlprague-2017-procee...
[2]: https://github.com/w3c/html/issues/1116
[3]: https://github.com/whatwg/html/commit/6e305c457e42276bf275b8...
[4]: Edit: this affects differences introduced in HTML 5.2 vs HTML 5.1, not some distant archaic HTML 4 version
I don't think that's a fair characterization at all. Ian Hickson was pretty intimately familiar with the SGML formulation of HTML.
What led to that being dropped was that no browsers implemented it in practice and that trying to implement it as written in the HTML 4 standard actively broke web pages (which had been written against browsers, not against the spec). Firefox tried going down that route for a while; I should know, because I implemented some parts of that and reviewed the code for the implementations of other parts. We eventually had to remove them, because of compat problems with websites. Comment parsing was a perennial favorite there.
> For example, the keygen element has been removed
That is a good point, yes. Arguably it should have been left in as a void element with no behavior to avoid parsing issues of the sort you describe...
> So tell me why, as an author, I should follow WHATWG's vision for HTML?
Honestly, because that's the thing browsers will implement. That's the only reason.
That's what we did, actually :). Parsing behavior was unchanged. Ctrl+F "keygen" in https://html.spec.whatwg.org/multipage/parsing.html.
Please don't tell me SGML comments were the problem - SGML commenting syntax is straightforward, eg. anything in double-hyphens within a markup declaration is treated as a comment, and there can be multiple comments in a markup declaration (unlike XML). The only problem I see is that there is an interaction with an ancient form of JavaScript comment taking the form of double-hyphens, presumably to make JavaScript commenting uniform with HTML syntax. Now the rules for terminating the content of a script element are dangerously bogus in ancient HTML, but HTML5 has done nothing to fix the situation.
In any case, WHATWG has driven almost all web browsers out of existence already; appealing to what "browser vendors" (Google) actually do is not the solution, but part of the problem, obviously.
[1]: https://www.webdesignerdepot.com/2013/the-harsh-truth-about-...
I'm not saying it didn't spec various things that didn't match browsers (some just because, some because it tried to reverse-engineer browsers and failed). Well do I know it did; we're still sorting some of those things out. The only defense there is that unlike previous web specs it actually tried to specify this stuff (like navigation!) instead of just saying "yeah, do whatever".
The element name thing was actually needed for compat with how browsers parsed HTML in practice. The ID thing largely affects well-formedness, but was also informed by common practices, and the mismatch with CSS in large part was probably somewhat unavoidable due to differences in reserved chars. For example, there's really no reason, within the context of HTML, to not allow "foo.bar" as an ID, and people were definitely using IDs of this form all over, whereas in CSS you'd need to jump through the "#foo\.bar" hoop to use it in a selector.
SGML comments were definitely _a_ big problem (I'm not sure why you decided to describe them as "the" problem). This sort of markup:
<!-- This is comment -- This is just in a markup decl -->
This is still comment, because the '>' is inside the comment the third double-dashes started, yes?
> presumably to make JavaScript commenting uniform with HTML syntax
No, that was there to enable hiding of <script> tag contents from browsers that didn't know about <script> at all. So you would write:
<script>
<!--
// Your script here
-->
</script>
> In any case, WHATWG has driven almost all web browsers out of existence already
I'm not sure the problem here is "WHATWG" per se. I'm pretty sure that if WHATWG had never existed the results would have been pretty similar...
That's good, because these aren't the reasons the HTML standard is changed, and to claim they are is absurd.
HTML may have had its origins in SGML, but it has long, long since grown past beyond those origins to become the web platform. Like any other non-dead software platform, it is undergoes a process of refinement and enhancement, not for reasons of "job security" or "Webkit dominance", but to provide additional functionality to allow more and better software to be build with of it, and to remain competitive with other software platforms.
You, and a large constituency of Hacker News commenters along with you, may utterly loathe the web platform. You may wish the web had evolved along entirely different lines, remaining a simple system for server hypertext documents. But the fact is, it didn't, and to act as if that the global development ecosystem that relies on the web platform doesn't exist is ridiculous.
The web has "evolved" from a medium for simple self-publishing into a medium of mass surveillance and manipulation, big media, privacy-invading ads, uncalled-for browser monopoly, information oligopoly, and arbitrary crap code being sent to you in ridiculous quantities, not only draining your batteries and showing no respect for planet earth wrt energy efficiency, but also actively putting you in danger through fishing, xss and whatnot, and making your future ability to even read your legal, personal, study, business, or banking documents dependent on a needlessly over-complicated technology stack that no-one has the ability to influence in meaningful ways except Google, an ad company.
What it has not evolved into is a medium for long-term preservation of digital information, information autonomy, for simple ecommerce transactions and payments for everyone (as a merchant), for letting content producers thrive with quality content, or one that fosters free speech and diversity.
It has "evolved" by being captured to serve the interests of very few players, and fails the criteria of not having to appease computers or software programs that seem to be at war with one another.
The idea of versioned standards is only really important if you have to worry about things changing out from under you that could break your existing work.
I should be able to build my web app against an LTS version of the standard and expect it to behave identically in all future versions of all major browsers, until the EOL date of said version, no matter what changes they make in future versions. I want this for the same reason I want either CentOS or Ubuntu LTS, not Arch, on my production boxes.
Unfortunately, the whole HTML 5.1/5.2/5.3 business never quite caught on, and browsers don't support anything but the latest snapshot of whatever it is that they call a standard.
Because that was an artifact created by W3C by taking snapshots of the WHATWG HTML5 standard and making arbitrary changes to portions they didn't agree with. Since the WHATWG standard was already considered normative by most browser makers, the influence of the W3C's "standards" work here was essentially nil.
That's already true of HTML5. Breaking changes in standardized features almost never happen. HTML5 actually goes further than what you suggest: they aim to never have breaking changes.
The goal is for the time between HTML versions to not be a decade, but instead for consistent, incremental improvements without browsers trailing behind for years. At the same time, these should (hopefully) not be breaking changes.
No browser will ever implement the current spec because it's shifting sand. A smaller but stabilised spec that can be extended is much better for everybody who isn't a major browser vendor.
It's only for very recently implemented features that you should need to look in bugzilla.
caniuse.com is amazing but let‘s not kid ourselves what it covers. It‘s about feature availability. Some feature might have 1000s of normative behaviors specifics but their being condensed down to there/not there.
At the time the behavior worked right in Firefox and Edge but now that Chrome is going to ignore the spec I suspect the other vendors might too. (For reference, it was an issue related to the lifetime of javascript objects for frames that have been unloaded or navigated)
This sort of thing will never appear in a compatibility matrix. You find out when it breaks your code.