3 ms·

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

by Touche 9y ago

wolfgke 9y ago
> 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 https://news.ycombinator.com/item?id=15256890 I actually got some pretty smart answers, for example: > https://news.ycombinator.com/item?id=15259428 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 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 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.
- Touche 9y ago
  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.

3 ms·

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

by Touche 9y ago

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

wolfgke 9y ago
> 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 https://news.ycombinator.com/item?id=15256890 I actually got some pretty smart answers, for example: > https://news.ycombinator.com/item?id=15259428 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 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 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.
- Touche 9y ago
  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.