Hacker News new | past | comments | ask | show | jobs | submit login

Nothing you said here is true of the WHATWG standard. It doesn't make breaking changes and it is specific.



> Nothing you said here is true of the WHATWG standard. It doesn't make breaking changes and it is specific.

Counterexample: About three months ago I asked on HN why on modern browsers some subtests of Acid3 fail:

> https://news.ycombinator.com/item?id=15256890

I actually got some pretty smart answers, for example:

> https://news.ycombinator.com/item?id=15259428

To quote it for convenience:

"Two changes lead to three failures in Chrome.

The first change is described in the 'note' at https://drafts.csswg.org/selectors-4/#child-index

Chrome is failing a test because the root node claims to be a 'first-child'.

The root node is the first sibling, but since it doesn't have a parent, the selectors 3 spec didn't include it.

The selectors 4 draft does away with the requirement that a 'first-child' have a parent, and chrome's behaviour matches.

The second is discussed here https://github.com/whatwg/dom/issues/319

Roughly, when interpreting qualified names, Chrome is throwing InvalidCharacterErrors when the acid test wants it to throw NamespaceErrors, in situations where you really have both. This leads to two tests failing."

So decide for yourself whether the WHATWG "standard" did breaking changes in the past or not.


The csswg is a W3C working group. It's true that there are sometimes breaking changes if usage is low enough. This is true of the W3C specs as much as it is of the WHATWG specs.

The advantage to following the WHATWG specs is that it reflects how browsers work today, not how they worked a few years ago.




Consider applying for YC's Spring batch! Applications are open till Feb 11.

Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: