Comment by domenicd | Hacker News Reader

Comment by domenicd | Hacker News Reader

Parent Full thread

Hi there, one of the WHATWG HTML editors here.

> Meanwhile, W3C HTML5 has defined releases that are thoroughly scrutinized, reviewed, and debated in endless committee meetings.

While this was true in the past, these days it's not really the case. They mostly just copy and paste our work without scrutinizing it, and usually without understanding it (as can be seen by the bugs they introduce during the copy-and-paste process). There aren't really any technical deliberations or committee meetings, and they don't follow a well-defined process; the most recent fork (from which HTML 5.1 is based) was actually done without the knowledge of the membership, and broke several aspects of W3C process while doing so.

Why do they do this? Well, it seems to be largely an issue of institutional face-saving. See e.g. https://github.com/w3c/charter-html/issues/14#issuecomment-1...: "When the HTML WG co-chairs and Team presented our proposed After HTML5 plan to the W3C Advisory Board earlier this year, we received a clear message that it was not appropriate to delegate or assign the maintenance of a W3C Recommendation outside the organization." In other words, since they started copying and pasting back in the day with HTML 5.0, they can't stop now.

Meanwhile there's actually a lot of interesting deliberation between web developers and browser vendors over in the WHATWG HTML Standard's bug tracker. https://github.com/whatwg/html/pulse might give a reasonable overview. Compare to https://github.com/w3c/html/pulse.

Some relevant corroborating links:

- https://annevankesteren.nl/2016/01/film-at-11 when this all started

- https://wiki.whatwg.org/wiki/Fork_tracking monitoring the ongoing copy-and-paste-induced confusion

- https://github.com/w3c/html/issues/364 wherein they monitor our tree for things to copy and paste over

- https://github.com/w3c/html/commit/19fcaf241f4417b2078bc26bf... example commit of them copying and pasting our work en masse (Spot the bugs introduced! It's a fun game!)

So, when will the WHATWG finally fix the HTML standards?

Get rid of all the backwards compatibility shit, and actually create strict, and simple standards, with no unexpected behaviour, that only parse valid documents, and where anyone can write an implementation?

Because that’s the definition of a standard.

That’s what a standard is supposed to be.

Standards, from paper standards to screws to fucking cucumber regulations are supposed to be more strict than what came before them, so anyone can easily accept only one type, and know it will work.

The WHATWG "standards" don’t fulfil the definition of standard in the least.

They are a strict superset of everything all implementers accept, making it a larger and more complicated mess with every single iteration.

So when will the WHATWG, as you say it’s now the legitimate standards body, do what it, as standards body is supposed to do, and deprecate currently used behaviour to replace it with stricter, simpler, standard behaviour?

Yes, that will break the web, but yes, it will also improve it.

Because it would not be useful to any real web browsers.

That’s not any justification – you standardize things so other people can easier work with them, create competing browsers, libraries, etc, and so more innovation happens.

If you just document what already exists for the benefit of existing implementors, great, you just got Microsoft Office Open XML.

That, and nothing more, is everything that can result from such a mindset.

"Don't break the web" is a hard constraint. Any solution you propose that violates this constraint is unacceptable.

There is nothing you can do to change this.

Your comments are getting downvoted to hell and back because you either don't understand or are unwilling to accept this constraint.

> "Don't break the web" is a hard constraint. Any solution you propose that violates this constraint is unacceptable.

What would you rather happen with mangled input like opening tags with no ending tag? Should the browser always try a best effort and never die with errors? Perhaps we can afford to break some things even though we can't afford a clean break?

I think you'd agree that the perfect is the enemy of the good. I'd argue that perfect backward compatibility is the enemy of good backward compatibility as well. Thoughts?

I'm unwilling to accept this is a hard constraint. It can't be that a later version should accept all inputs accepted by an earlier version. We should carve out exceptions based on what's actively used and inform the developer that what they're using is bad code. Eventually, some day if it becomes rare, we can discontinue support.

Reply on news.ycombinator.com