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

Just because something changes often doesn't mean it is unstable. Do you ever shop at amazon.com? I do, and I find it pretty stable.

Just because it changes often doesn't mean things are sloppily accepted, or that experimental ideas are added and later removed.

Indeed, if you want to build something for the web, reading an outdated document that contains bugs browsers have already fixed is not a good idea.




> Just because something changes often doesn't mean it is unstable.

When you do a project contract, you surely want to define the exact standard with respect to which the application is to be developed against, so that one can decide whether the reason for something looking wrong is a browser bug (I can work around it - but it will cost extra money) or indeed a bug in my code that the customer found (i.e. I have to work extra hours for no money because I did bad work).

To be able to decide such questions is a central purpose of existence for standards.


When I do a project I want to be able to code against the standards from which browsers were developed; that is the WHATWG standard.


> When I do a project I want to be able to code against the standards from which browsers were developed; that is the WHATWG standard.

I already argued that there is no WHATWG standard, but only a document that changes every few days. Even without this nitpicking: Which of these thousands of versions is the one on which the browser implementation is based on?


This one: https://html.spec.whatwg.org/multipage/ . Contrary to some people's perception here, everything that goes into this is implemented by at least 2 browsers.


Again, which one? The one from November 14, 2017, the one from December 14, 2017 or the one from January 14, 2018?

Do you really want to make a requirements document that describes something different at the day you sign it and at the day you deliver?


Sorry, but you can't print that page and use that forever. I understand that you wish that you could, but you can't. I live in the real world, so rather than reading a snapshot and hoping it stays that way forever, I just read the up-to-date version since that's what is implemented by browsers, not the PDF I saved 3 months ago.


It is a strong liability in a project contract if the standard with respect to which you implement the code changes under your feet.


Given that the browsers with respect to which you implement the code change under your feet every 6 weeks, I think it's better the standard keeps pace with them than having it give a misleading impression of what you're developing against.


I hope we can agree HTML is used for text content first and foremost. A format that changes all the time at the whim of an ad company is basically useless for long-term preservation of legal documents, or documents in education, etc. Do you think having the latest web app fad is more important? Especially when the format has been around for 25 years now. "Innovation" on the Web is only happening so that Google can keep an edge in search tech, and for similar reasons.

Wake up.


This just speaks from lack of experience: that's exactly what it means in the world of software. Do you not understand what specification means? "Specific" is even in the word.

You can't compare it to browsing on Amazon, because functionality doesn't just go missing and literally break buying things; functionality doesn't just suddenly get added and people rely on the exact font size and copy of a particular header in the men's clothing department to be precisely 2em and "Men’s Clothing," and now that it's changed to 1.5em and "Men's Winter Fashion" a third-party app can't render the header in an appropriate width size nor find the clothes to begin with.


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 W25 batch! Applications are open till Nov 12.

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

Search: