W3C and the WHATWG sign agreement to collaborate on single version of HTML, DOM
w3.org
w3.org
Around 2004 W3C abandoned organizational effort on HTML in favor of things like XHTML2, XEvents, semantic web, etc. The WHATWG was formed in reaction to that, rewriting HTML completely from its W3C HTML 4.0 version for example to make it better for web applications and to specify things in more detail.
Since the formation of WHATWG, W3C HTML specs became copy-pastes (often not even correct copy-pastes) in an effort to satisfy paying member companies (https://github.com/w3c/charter-html/issues/14#issuecomment-1...).
You can see everything WHATWG maintains here: https://platform.html5.org/ (they are the green question mark)
The W3C still maintains a good chunk web standards though, such as CSS, Wasm, web security, etc.
The whatwg HTML spec defines exactly how html is parsed, and exactly how every element interacts the scripting environment. Just defining the grammar is not sufficient.
Historically for instance something like
<bold>foo<italic>bar</bold>baz</italic>
Produced a different DOM tree in different browsers. WHATWG specified what should actually happen. IIRC IE managed to produce a DOM graph rather than a tree in the above example.
What you claimed is absolutely wrong.
Please note that it defines the DOM interfaces for all of the core elements, and more or less every DOM API, including all elements, as well as most programmatic types - even things like the XHR objects. They used to all be in a single giant "HTML living standard" document, and have in the relatively recent past been split into separate spec docs (many of which reference the original "living standard").
None of this is either confusing or a mystery. It’s all out there in the open and the people who maintain these documents respond to email. I typically avoid talking about the DOM online because many developers aren’t aware of what it is and are less aware of its history and sometimes people get sensitive about it.
Essential the w3c went “incorrect” html isn’t valid so we don’t need to specify it, even though all browsers support that “incorrect” content. Instead they said “everyone should just use xhtml as that makes sure the syntax is correct”.
Unfortunately they again failed to address the real world:
* xhtml is necessarily slower to display because you cannot do anything until you’ve got a full document (otherwise it will definitely fail to validate)
* because IE didn’t display xhtml it was published with the html mime type, so browsers that did support xhtml still had to parse it as html
* as a byproduct of the last one, invalid xml got added to documents which would then cause the browsers that did try to treat it as html to appear broken
* xml is also incredibly hard to actually get right - take RSS that was ostensibly XML from the outset. Even that has to be parsed as html because of the amount of broken xml.
By going all in on XML the w3c essentially went all in on a technology that people didn’t actually use or want.
But browsers did actually need an accurate specification that matched the real world, and that’s what became HTML5 through the hard work of people from apple, Firefox, (eventually) google, Microsoft, and opera - the w3c was not really involved. The end result is that in the modern DOM you are far less likely to need per-browser hacks than you once did.
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.
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.
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.
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.
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 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.
W3C is giving up publishing future HTML and DOM standards. They will focus on writing 'recommendations' for the WHATWG's living standards.
Versioned vs living HTML discussions aside, I personally admit some mild sadness that the original group responsible for maintaining Sir TBL's work on HTML has been forced to give up.
W3C became irrelevant because they kept thinking they could just tell the entire web what to do, that they'd make enormous technical investments to satisfy the W3C's latest fashions.
I interacted with them once, over their seamless iframe proposal. I had to point out that the two biggest uses of iframes at the time, i.e. Twitter embeds and Facebook apps, could not make use of it, despite being a perfect fit. They just hadn't considered that.
I can do tables just fine in XHTML. And luckily, tables have become redundant as layout technique, since CSS would do that, already then.
The nice thing with X(HT)ML is, that you can place queries against any document, natively.
To this day, changing a site's entire design without touching its markup is a mirage. It only works in contrived scenarios with extremely artificial restrictions, and nobody does it in the real world. CSS Zen Garden was demoscene.
You don't come from print design by any chance?
With flexbox, for example, you can change order of appearance contrary to the code order in the markup. It's not a mirage. Anyone who's used a browser's reader mode, or distilled view (as Brave calls it), knows the usefulness of applying different styles to a fixed markup.
Separation of presentation is possible.
Indeed now we've moved to responsive design and the number of devices and UA has exploded the separation of design and data is coming in to its own -- but instead pixel-perfection is still being chased with a billion @media declarations.
You've not been doing that whole web design thing for very long, by any chance? Those of us who have been around for a while do remember the inadequate layouting capabilities of CSS of bygone eras. While I was on the semantic markup side of the debate at the time, it's not as if the pragmatists that just went with the table for convenience's sake did so for no reason at all...
There's a clear body of web design/dev people that think it's just a visual display medium, and a lot of those seem to come from print design.
The web for me has always been primarily a medium for information transfer, visual design is nice but not at the expense of semantic markup; table markup for visual layout is entirely unnecessary (and was terrible for accessibility).
People went with table layout because marketing people demanded pixel matched presentation and/or they didn't care to make sure their content was machine readable. The same views lead to IE only and give us websites that don't bother with semantic blocks now, or that don't work without JavaScript when that js is just being used for presentational flair.
For another, wishing for a certain amount of control over the layout seems like an entirely reasonable demand to me (eg you should not need to jump through hoops just to place something in the center of the viewport).
Lastly, if we're being honest, how much has semantic markup improved the web experience in practice, and how much did layout tables hurt us? When I used to do web design, I was a good citizen, avoiding layout table and arguing for semantic markup. But nowadays, I'm far more forgiving, though I still think there's some value in it insofar as proper markup can improve the screen reader experience.
Aren't you talking past each other? The issue is that with initial versions of CSS, replicating the powerful layout possibilities of tabular markup was not possible. Developers generally built layouts using "float" instead, and had trouble replicating some of the standard table features like keeping columns the same height.
Only with full CSS 2.1 implementation in IE8 did this state of affairs change, at that point you could apply rules like "display: table" to DIVs and get the same layout possibilities without using tables.
Flexbox, on the other hand, is actually an improvement (are are Grid Layout and Template Layout Modules). But it didn't come until after CSS 2.1.
I never really understood why people had such difficulty with this. I was able to execute table-less layouts while still supporting IE5 on Mac.
> To this day, changing a site's entire design without touching its markup is a mirage.
That's only because HTML authoring is dead. No one writes HTML well these days. Just look at tools like Elementor. How many nested divs do you need to add a faux button to a website? It's ridiculous.
Write well-structured, semantic HTML being mindful of a separation of concerns, and flipping between stylesheets is a piece of cake.
I keep hearing about this mythical beast, and yet I have never seen one beyond the simplest of text-only blogs.
HTML was created to be used for documents. It was coopted to be used for apps. They really should have come up with a different language for apps.
I lost a lot of hair trying to make a simple 3 column layout where the middle column would scale to the width of the window and could consist of multiple DIVs in a vertical row, all of the same width. AKA "baby's first blog" layout. Something that should have been one of the design cases for CSS.
I cannot. They no longer exist. This was 14 years ago. I left web development shortly afterwards.
For your example, horizontal alignment was easy. One container div with a width of 99.9% and a left/right margin of auto. Inside you place three divs (columns) with a width of 33.3% and float left. Add another div at the end to clear the float.
Vertical alignment required a "hack."
http://www.greywyvern.com/code/min-height-hack
And to be clear, I never called it "elegant." I simply suggested it was possible.
Should CSS have been better? Sure. But, by that measure, it still sucks today.
It took well over a decade to get CSS to play nicely with layouts. It's disingenuous to present CSS as the obvious solution to a problem while criticising table usage to implement grid layouts, as this line of argument entirely ignores the recent history of the web.
Foolishness aside it is important to understand the DOM came out of work from the XML Schema spec and for many years updates to those two documents were always released together.
The W3C isn’t irrelevant as there is more to the web than just HTML just like Oasis isn’t irrelevant for schematic design and business integration. This talk of irrelevance is a hard argument to make for many frontend developers who cant tell the difference between the standard DOM and Reacts VDOM.
In the end, we finally have CSS grid now ( https://css-tricks.com/snippets/css/complete-guide-grid ) which do what we were trying to achieve back in the day with tables. We had to wait until 2016 to have a type of layout which is considered standard in most GUI toolkit ...
Which got released in 2009, but took another year to overtake IE6+7 in market share. This means `display:table` was of limited usefulness for nearly a decade after its introduction...
In practice I was using display table in some designs in the mid 00's but also using conditional stylesheets to hack an IE layout. This was not a particularly good solution but it "worked".
DOM v3 Document.load() https://www.w3.org/TR/DOM-Level-3-LS/load-save.html was the candidate for client side document loading long before most people even knew what W3C is
That spec seems to be mostly related to Java and it seems to me that it hardly considers how ECMAScript could use it i.e. someone had an idea, but couldn't translate that into a useful feature...
You certainly could lay out pages using tables in XHTML, but the point of the standard in the first place was to enable semantically sound documents for the sake of interoperability and to facilitate separation of concerns. So maybe if you authored XHTML documents that was already an important consideration to you.
On a side note, now that the web development industry seems to have collectively given up any ambitions for semantically sound documents it's strange that the criticism against table-based layouts prevails.
Documents built on the principle that their structure should relate to the meaning of their content rather than its presentation are what I consider "semantically sound". By negative example, an HTML document filled with div pyramids just to apply layout information, and obtuse class and id names are not what I consider semantically sound. However clumsy it was in practice, XHTML and CSS sought to address this by making the markup extensible and moving style information out of the document.
> I never saw any indication that XHTML brought significant practical semantic information or standardization over what HTML5 can do.
Obviously HTML5 had the advantage of hindsight and the perspective to learn from some of the mistakes of XHTML while adopting some of its more useful qualities. I should also note that I'm discussing the point of XHTML, not trying to tell anyone that it was particularly successful to that end. Don't confuse the two.
I'm not sure if anyone ever actually used this seriously though. Definitely very "ivory tower" design. But in the abstract it's a cool idea.
When I worked at the BMJ all of our content was stored as XML and rendered to the browser using XSLT, although this was done on the back-end and the resulting XHTML embedded in our various Spring applications. This sort of thing is probably the most common use of XHTML today...
That was a major focus of HTML5, as well, which was more successful at enabling that (arguably, it was more of the focus of HTML5, Which didn't try to impose major syntactic change as well, even though it also supported an XML form.)
> On a side note, now that the web development industry seems to have collectively given up any ambitions for semantically sound documents
Semantic soundness in the strict sense has always been something of a niche concern, not something hat was a general web dev industy goal and then abandoned.
> it's strange that the criticism against table-based layouts prevails.
Table-based layout remains an accessibility problem, which is a more practical issue than abstract concern for semantic soundness (though related).
I agree. Don't confuse my interpretation of the point of XHTML with some sort of endorsement. For the record, I think XHTML is an unnecessarily complex standard that results in more work for little added value. I do recognize, though, that the point of XHTML is unrelated to its success to that end.
Comparing HTML5 to XHTML is also a bit of a no-brainer. There are 14 years between their introductions, and HTML5 obviously had a history of lessons learned from XHTML to take into account.
> Semantic soundness in the strict sense has always been something of a niche concern, not something hat was a general web dev industy goal and then abandoned.
What is the strict sense of semantic soundness? I'd agree that few people care about semantic soundness even in a general sense. I frequently see documents where the presentation seems prioritized over content. But the ambition did exist at some point, and was more of a mainstream concern in, say, 2005 than it seems to be now, and the idea of a more semantic web was peddled by big names like Tim Berners-Lee.
> Table-based layout remains an accessibility problem, which is a more practical issue than abstract concern for semantic soundness (though related).
I'd say that they are strictly related. You improve accessibility primarily by improving the semantic representation of documents. I don't see semantic soundness as an "abstract concern" for this reason. The most useful screen readers unfortunately seem to rely on some level of guesswork to make verbal sense of documents that rely on spatiality to communicate element relationships.
The only things you couldn't do in XHTML 1.1 Transitional that you could do in HTML were having unclosed tags and using uppercase in tag names. That's it.
Now yeah, the strict version tried to force you into semantically sound documents... but that was completely orthogonal to XHTML vs. HTML. Both XHTML and HTML were available in both transitional and strict forms.
The real problem is that HTML is a massive pain in the ass to parse. You can close tags out of order, some tags can't even be closed (<hr>), some tags can optionally be closed (<p>), nothing is case-sensitive, and because of how flexible SGML is, you need a DTD to properly parse any SGML implementation (fun fact: SGML allows for a bunch of different markup styles, but the HTML DTD explicitly disallows most of them). XHTML sought to eliminate all that by mapping HTML onto XML, which was much easier to parse.
That being the only goal would have resulted in a much simpler standard. Extension modules for example is completely orthogonal to that goal. I think that the standards themselves do a good job of describing what motivates them.
> The only things you couldn't do in XHTML 1.1 that you could do in HTML were having unclosed tags and using uppercase in tag names. That's it.
That's true, but ignores the opposite question—what you could do in XHTML that you could not in HTML.
Another correction I noticed when looking that up: I meant to say XHTML 1.0 Transitional, not 1.1. 1.1 was Strict-only.
<button disabled="disabled">...</button>
<button disabled>...</button>
Even SGML has problems with expressing an attribute like that from what I remember reading of someone's attempt to specify HTML 5 using an SGML DTD.
XHTML just defined a slightly different syntax which was XML compatible. This was useful if you were using XML tools, but it didn't affect semantics at all.
HTML5 mostly just defines ARTICLE and SECTION as optional block-level content elements, with no other real importance. This leaves them as merely fancier synonyms for DIV. Semantics is almost entirely left to ARIA, and while HTML5 has come back around to ARTICLE tag should imply, for instance, ARIA role="article", there's still a bunch of interesting reasons that people concerned with ARIA semantics continue to write "redundant" things like <ARTICLE aria-role="article"...
Tables were NEVER a layout method and it was only used for that because CSS was deficient at the time.
Okay.
I never understood what people had against XHTML. The more common theme seems to be "XML... eww" and nothing else. Can anybody help me understand?
In these days of Typescript, where web devs seem to like having stricter rules, it could play better. But that ship has already sailed.
In most cases, if your code has some syntax error, the author of the code sees the syntax error; in the web case, if your code has some syntax error, the user sees the syntax error. That's the dramatic difference.
The other reality is unlike program code, there's vastly more often user content intermixed in (X)HTML and it's rare for people to implement sanitisation correctly (do you handle U+0000? U+FFFF? U+1FFFF? most people outputting XHTML historically haven't, even if they get the security critical stuff (like "<") right).
Good writers of markup will always check with those before they ship it. In the case of user supplied markup, that's still an issue today with HTML.
The reality ten years ago, when a number of prominent XML advocates were using XHTML (and actually using it as such, serving it as such), almost all of their sites had user input means where the input was sanitized well enough for HTML to be secure (and not have any markup injection), but not for XML well-formedness (they got all the markup injection risks in XML, but not all the other WF requirements). If the very people who claim XML is easy can't get it right, can everyone else?
I, too, served my web pages as "real" xhtml 10 years ago and loved it :)
There was also similar exposure from the data side; as the amount of data you handled increased, the odds that some data would tickle some code path that you didn't even know could blow up went up. You write your news front page in XHTML, and everything seems fine for six months, until someone finally includes an ampersand in their headline, and your entire front page crashes for two hours (not in any way monitoring will pick up, either, so you're getting customer reports), and it takes you hours to discover that someone was passing through the headline (and just the headline!) unencoded.
The problem isn't XHTML's rigidity per se; personally I'm inclined more in that direction myself. The problem is when you have a ton of sloppy systems working together (MySQL, old HTML generation code, plugins from third parties your don't control, open source written by people whose belief in their understanding of HTML exceeds their actual understanding, decade-old internal databases with poor validations and unknown provenance, and so on and so on indefinitely), and then trying to suddenly, at the last minute, couple that big sloppy pile of technology to a strict technology at the last second. That sudden mismatch there at the end was a huge problem.
One of the reasons I tend to prefer being as strict as possible is that in general, starting with existing strict-tech and adding sloppy-tech to it is no big deal; the sloppy tech doesn't complain that it only gets a subset of possible data it will accept. And if you need to couple to strict-tech, you still can. But if you start with a sloppy-tech system and for some reason need to couple it to a strict-tech system... prepare for some long nights and blown deadlines. So, professionally, the correct default is to choose strict-tech whenever possible. But XHTML forced that at almost the worst possible place.
Or you import a small Javascript library from 1999 that generates its own innerHTML for a few elements, but does it with HTML. Oops.
Or you built a new CMS with shiny XHTML markup, but before you had the CMS your org just hand-wrote pages which you now need to parse and import into the CMS.
These were all very real considerations in the 2002-2004 period; I've dealt with all of them. Backwards compatibility is often the most important feature you can offer, because it directly affects the value the end user gets out of the product. Sites that were concerned with "doing it right" in that time period largely failed, while sites that "did it fast" in a hacky, XSS-prone way are now worth hundreds of billions of dollars.
We did get a handful of different names for a div though, so that's nice, maybe.
> The Extensible Markup Language (XML) is a subset of SGML that is completely described in this document. Its goal is to enable generic SGML to be served, received, and processed on the Web in the way that is now possible with HTML. XML has been designed for ease of implementation and for interoperability with both SGML and HTML.
Basically, XML's purpose was to make parsing rules for web documents generic and DTD-less, in particular to support new vocabularies (eg. SVG and MathML) in addition to HTML/XHTML. The XML namespace spec back then was another pillar for advancing that goal.
HTML5 then simply imported SVG and MathML into HTML as external vocabulary, without a need for namespaces or other modularization meta-technique.
That XML has failed on the web (and was succesful only in enterprise and publishing) shouldn't make fans of structured documents on the web bitter, though: SGML is exactly as capable as XML to describe the syntax of markup documents (with tag inference, a feature recently being discussed for re-inclusion into XML under the term invisible markup), and even can parse markdown and other Wiki syntaxes, can do HTML-aware, injection-free macro expansion, and a whole lot of other things waiting to be discovered by XML fans.
XHTML continued the spirit of HTML 4 strict, getting rid of presentational elements and replacing them with 'sematic' ones. Eventually, you were also supposed to combine it with RDF to embed machine-readable metadata into your documents (cf https://www.w3.org/2003/03/rdf-in-xml.html and https://en.wikipedia.org/wiki/XHTML%2BRDFa ).
But it undoubtedly makes development harder. Web Developer 101: Section 1: This 20 page list of categories and their strict formal definitions.
Hence the “ivory tower” comment upthread.
The browser is a communication channel between a publisher and a reader. They may want different things...
But the "semantic, well-formed, machine-readable web" idea is, in theory, a demand that the channel imposes on both parties. It's not something the publisher wants. It's not something the reader wants. Nobody cares what the channel wants; demanding extra information that isn't relevant to what any party to an actual transaction is trying to accomplish is always going to be doomed.
Readers care about positional information at a fairly minor level. Publishers care about it a lot. And hey, positional information has robust, if annoying, implementations.
For a reaction from a browser developer, see https://dbaron.org/log/20090707-ex-html
But getting everyone else to start over as well was always going to be an uphill struggle even if it was truly the best thing ever.
Yes, it was a requirement that XHTML 2.0 documents be served as application/xhtml+xml (which IE didn't support at the time), but that was really a non-issue (with so much renamed and moved around v. HTML 4.01 and its XML reformulations (XHTML 1.0, XHTML 1.1) because there was no graceful fallback story.
The bigger problem was that it required content to be served as application/xhtml+xml, and gave the same element and attribute names, in the same namespace, different semantics to what XHTML 1.0/XHTML5 gave them, with different implementation requirements (and it being impossible to satisfy both).
AFAIK this essentially got resolved by XHTML 2.0 being abandoned (in 2009, years after HTML 5 had moved to being jointly developed with the W3C).
That's quite a misunderstanding of the past. Your proposition is only technically correct: CSS1 (Dec 1996) did not have table display properties, but they were added in CSS2 (Mar 1998). They were available early enough to matter.
The reason why many Web authors did not design with these properties is not the fault of the W3C, but rather because of the typical Microsoft sabotage. In the early 2000s, I personally did not give a shit about IE - my standard compliant CSS rendered fine in other popular browsers.
RDF, JSON-LD, "semantic web", piles and piles of garbage. And all written by the same group of 10 people who have never written a web app by themselves.
On the other, it seems like just complete capitulation by the W3C; WHATWG makes all the real decisions still, W3C now performs important administrative services for free, turning the "living standard" into an actual usable standard, without actually having any meaningful power over the results. WHATWG gets to do the part that matters without having to do the hard part, W3C does the hard part for them without any control over what matters.
On the other other hand, sometimes when the battle is already lost, formal capitulation is all that's left.
The browser vendors took control of the web standards process from any body that might represent/balance multiple constituencies/interests, and that's just how it is now.
It's not a capitulation, it's a way to exert influence in a world that respects rough consensus and running code more than formal processes and authority. Under the agreement, W3C has the power to ratify (or not) changes to HTML/DOM that align with the needs of its broad community for accessibility, internationalization, privacy, security, etc. The agreement provides a way for experts in those "horizontal" areas to participate more effectively in WHATWG to get improvements made upstream, rather than downstream in what amounted to a fork.
And yes, W3C provides the service of providing vetted snapshots of the Living Standards into more formal standards that governments and other standards bodies can reference and ratify. That's adding real value for some constituencies.
Seems to me W3C will straight up be acting as administrative staff for WHATWG, providing free labor to do the "hard parts" of providing a useful standard, without much decision-making ability.
Without much decision-making ability is indeed the status quo. Now they're providing some free labor too. But it's certainly less pointless than what they were doing before, so.
W3C has no authority to change browser behavior, no. But they CAN influence browser behavior by providing expert assistance to promote W3C's traditional values (accessibility, internationalization, privacy, etc.) in WHATWG.
We'll have to see if W3C's ratification or not has an impact on the larger web ecosystem, but it would probably get key customers' (and regulators) attention if W3C refused to ratify changes to HTML, DOM, etc. on accesibility or privacy grounds. Browser developers may respect W3C's supposed authority to set standards, but they definitely do respect the opinions of customers and authority of regulators.
I've had a very pleasant experience contributing to things like `fetch` and negative experiences contributing to some other things - essentially it's a "people problem" more than a technology problem.
Coming in to try and fix problems or propose improvements for existing stuff like canvas or XHR or whatever is another matter entirely, as you've probably noticed. Thanks for helping make fetch good!
I'd love to see more groups like the WHATWG specifically for this reason.
WHATWG seems to have found a way to manage the noise of allowing essentially anyone in to comment and contribute.
However, all W3C specs are developed in the open, nowadays on github, and feedback from anyone anywhere is taken seriously. Don't like something about css? go here: https://github.com/w3c/csswg-drafts/issues. Something wrong with SVG? https://github.com/w3c/svgwg/issues. An issue with the Payment Handler API? https://w3c.github.io/payment-handler/. Dislike the way W3C itself works? That's here: https://github.com/w3c/w3process
Yes, the W3C is a membership based organization, and if you want to vote for instance on who gets to be on its Advisory Board, or have a say in the Charter of Working Groups, you need to be a member, and pay.
For the WHATWG, you don't get to vote on who's on the Steering Group, and you don't get a say on what new Workstreams are started / changed / stopped, even if you did want to pay. That's up to Google, Apple, Microsoft and Mozilla. Sure anybody can suggest stuff (but that's true at the W3C too), but they decide, and there's no way into that club.
Not to claim that W3C is perfect. Plenty of improvements are needed. But claiming that small business or individuals cannot participate just isn't true.
And the W3C had stalled progress so much in the 00s and 10s, that it deservedly got sidelined.
One belongs to the backend to decide, the other is for HTTP/S-level specs and Javascript, none of which are or should be W3C's concern.
You have more of a voice in the W3C than any other standards body (you can comment on the github issues, or join as an invited expert etc). The W3C was created by Tim Berners-Lee, if anyone should have a vote on how web standards are run, then the creator of the web should be one of the contenders for it.
>And the W3C had stalled progress so much in the 00s and 10s
Not the 10s, just the early part of 00s, due to the xhtml vs html5 thing.
That's… not any different to the WHATWG. You can comment on GitHub issues there just fine too. (And you can't just join as an invited expert for the W3C, but even being an invited expert means relatively little in most groups.)
> The W3C was created by Tim Berners-Lee, if anyone should have a vote on how web standards are run, then the creator of the web should be one of the contenders for it.
Tim is scarcely involved in the W3C nowadays, and hasn't been for a long time. The fact he's in theory the Director (but in practice almost everything is done by W3C staff in the Director's name) means very, very little.
That's an appeal to an authority who isn't even present.
Yes, but (and you can disagree with me here) the W3C has much better international participation and say in standards. I know you can just file github comments, but none of the world has any real way to oppose any development that the whatwg makers have proposed. There doesn't seem to be any consensus forming or way to really oppose any development apart from filing a github issue. All the editors are pretty much from one company, which feels like handing over control of the web to that one company essentially.
Which company are you referring to? Per https://github.com/whatwg/sg/blob/master/Workstreams.md, I see
- 3 independent (Dom Farolino, Robert Kowalski, G. P. Hemsley)
- 2 Mozilla (Mike Taylor, Anne van Kesteren)
- 2 Google (Domenic Denicola, Philip Jägenstedt)
- 1 CloudFlare (Terrin Stock)
- 1 Bocoup (Simon Pieters)
Still seems a pretty small group to control something so important, but I hope they keep improving and adding more people there from other companies and countries.
On the one hand, browser manufacturers now "have won" and can do what they like. On the other hand, the W3C always was kind of a toothless tiger, hoping that everybody would do as they say.
Difficult situation, not sure if this will "help the web".
Not really, it was, and still is, a neutral ground for people to discuss and build consensus on what technical standards should be on the web. CSS, ARIA, WCAG and many other stuff are working in the W3C pretty well.
There are fewer compatible browsers than at any time in the past 20 years.
The compatibility problem has been solved by drowning browser maintainers in complexity and convincing them to give up. All the small browsers lack the manpower to implement the rapidly churning spec. This leaves the Google-funded Firefox and the Google-funded Chromium in the space.
Compatibility has been solved by reducing the web to a monoculture, with a puppet competitor to avoid monopoly issues.
Firstly, much of the complexity is an emergent property of interaction between a spec and reality: the engineering choices developers make when implementing a spec.
Pixel examples: (a) mitering of borders, (b) sizing four 25% width divs within a 99px div.
Pick just about any old spec, then look at the corner cases where developers have discovered different browsers act differently ("bugs"). The programming differences are often emergent and are not covered by the spec.
Developers create web pages that depend on the differences in a browser: that is a hard reality.
Secondly: Chrome mostly works better, follows specifications faster, and it is marketed better. Firefox has a significant budget, but it tools around with a bunch of shit that doesn't make their browser better. My interactions with Mozilla trying to get real bugs fixed have been poor. Safari and Microsoft were worse. Chrome cares about bugs, and fixes them in my experience.
Ah, clearly that makes it easier for third parties to maintain browsers. Or, wait, no -- that's yet another way to push players that don't have hundreds of millions per year worth of funding.
> Chrome mostly works better, follows specifications faster, and it is marketed better.
That's largely because of the way the specs are developed: They rubber stamp Chrome features.
I also don't like how Firefox, Safari and Edge have failed to compete with it, especially because I don't like that Google slurps so much private information. I wish Opera could have continued to compete as I loved the underdog for years.
If it were just a problem of marketing, I could be upset. However technically the Chrome team is just totally obliterating competitors by just being technically so much more competent and also providing features. Features that developers and consumers want: as a web developer I see Chrome kill the other browsers on metrics I care about such as bugs fixes, adding features that are relevant to my development, development tools, etc; As a Chrome user, Chrome mostly trounces the other browsers on security, speed, etc (Safari does win on some metrics on closed iOS and macOS).
Mozilla, Apple, and Microsoft are not poorly funded - they are just being beaten for what are mostly technical reasons (relatively slower, unreliability, wasting time on low-value features).
On topic: Chrome implements many standards it didn't create far better than the other browsers. Browse through the list at https://wpt.fyi/results and see that Chrome has better scores for IndexedDB (I think created by Firefox); better scores for offscreen-canvas and orientation-sensor (I think created by Apple).
A great example: Firebug which was created outside[1] of Mozilla and fantastic at the time. Good developer tools draw in plenty of developers, and help make sure they test everything on your browser. Chrome Dev tools overtook it in every way I cared about: reliability, features, inbuilt F12, remote debugging, async stack, etc. Now developers use Chrome because this massive feature is so much better, and why blame the developers for using the tool that makes their job the easiest?
PS: I didn't downvote you - someone else must have disliked the way you answered.
[1] https://hacks.mozilla.org/2017/10/saying-goodbye-to-firebug/
No, it's a perfectly rational set of business decisions. I'd make the same ones if I was in charge of maximizing Google's control of the web platform.
> Mozilla, Apple, and Microsoft are not poorly funded
Correct. Apple and Microsoft just can't make a business case for burning huge mountains of cash to dominate the web, so they let Google have that pie. Again, a rational business decision.
So we end up with what is largely a monoculture, with fewer compatible web browsers than any time in the past 20 years, because is willing or able to put in the resources to keep up with the incredible complexity required by the modern web.
One way of looking at it is who has final say what ends up in the documents. That seems to be what you're discussing.
In the W3C, that's the Director, Tim Berners-Lee. Except, as pointed out elsewhere in this thread, he has delegated all his decision-making powers to W3C staff. So ultimately it is the W3C CEO and the folks he hires.
In the WHATWG, that's the browser vendors (i.e., the WHATWG Steering Group). I find the WHATWG model to make more sense, as I think what ends up in specs should match what the implementers plan to do; that makes for a more useful spec ecosystem for everyone. When you diverge too far from that model, you get circa-20004 W3C, i.e. XHTML 2, XForms, XEvents, etc.
A different way of looking at it is who contributes to the discussion and development of features. In the W3C, that's paying member companies (https://www.w3.org/Consortium/fees, $2.25-$77k/year in the US). Although anyone can comment on GitHub, to contribute ideas that get incorporated into the specification, you need to be a W3C member, for IPR reasons. (Or invited expert, but that has its own problems; see https://medium.com/@tobie/w3c-doesnt-help-its-invited-expert...) In the WHATWG, anyone can contribute; the IPR concerns are taken care of by signing an agreement, somewhat like an open-source project CLA, but that agreement does not require paying membership fees.
Overall, I think the WHATWG structure, of being open to input from all (instead of pay-to-play), with the spec tracking what browsers intend to implement (instead of tracking what W3C staff deems good), is a pretty great model for standardization.
Thats not entirely fair. The WHATWG is also pay-to-play in a way - the browser makers have disproportionally higher power, even more so than the w3c model where there is at least some form of consensus forming among a group of people with more international representation. Now technically anyone in the world can open a github issue (w3c also does it though now), but thats about what anyone can do to oppose something in the spec that the browser makers have their hearts set on.
The WHATWG is open to input from all, but only things browsers are willing to ship get into the specs. So yes, that's more power. No disputing that. But I would rather not have specs full of unimplemnted fiction, even if that fiction has consensus among paying member companies.
The W3C is not open to input from all. If you open a GitHub issue contributing an idea, but do not pay member fees, they cannot incorporate your idea into the spec, because of Intellectual Property Rights concerns. There is no way in the W3C to say "I sign over my IPR rights" without also paying thousands of dollars per year.
Or, as you mention up-thread, get invited into the group by the chairs and with consent of the W3C staff. Which… is an opaque process, and totally non-obvious to an outsider.
This is not true: https://www.w3.org/2019/Process-20190301/#contributor-licens...
WHATWG fails to realize that they cannot represent the browser vendors left (Google and Google-financed Mozilla) having a desire for ever more webapp contamination, and web users and authors at the same time who want a stable content media format.
Also, I have to say your comment doesn't sound very promising wrt the future WHATWG/W3C relations being anounced.
And then there is patent exclusion ( What? )
Anyway I don't see anything new to developers. Apart from the politics and two parties bury the hatchet.
For the same reason you put any value in, e.g., ISO or ANSI. Because others recognize them as the standard organization and put value in what they recommend.
Google, from what I found around, cites nothing, not even WHATWG.
Webkit cites MDN (which cites w3c) as a source.
If there is an inconsistency between what the standards say and what the browsers have done, the browsers will more than likely trump the standards. In all practical senses the standards are descriptive, not prescriptive.
Although I still worry about the case where fixing the deviance would break production apps. Potentially break them, since people won't complain until you release the breaking browser version. That's what's usually kept browsers from hewing to standards.
Also, for the full details, here is a direct link to the agreement: https://www.w3.org/2019/04/WHATWG-W3C-MOU.html
> WHATWG maintains the HTML and DOM Living Standards
Which is understandable, since all of the main implementers of HTML are active in WHATWG, not so much W3C.
What will be the concrete impact of this agreement?
Per the Memorandum of Understanding at https://www.w3.org/2019/04/WHATWG-W3C-MOU.html#transition, after the W3C first marks a WHATWG Review Draft as a W3C Recommendation, all the forks will be marked as "Superceded" with redirects to the WHATWG originals.
Note also the W3C specs weren't really redacted versions of the WHATWG spec, especially in later years: they were pretty much complete forks and moving changes between them non-trivial.
Will it mean anything if one of them becomes a W3C Recommendation?
If the W3C sends a draft back with requests for corrections, will anyone from WHATWG actually be motivated to make those corrections?
Or is this more of a "pick any commit you like and we can declare it the 'review draft' if that makes you happy" kind of thing?
Also, by this agreement, does the W3C have any avenues to influence HTML/DOM design work that exceed those of an average volunteer an the WHATWG mailing list?
However, it is indeed sad that the HTML spec is now controlled by browser makers only, and the editors are mostly from just one company.