Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

HTML 5.2 Recommendation

w3.org

Post reply on HN
Print view View original

71–80 of 188 posts

Re: HTML 5.2 Recommendation

#71

Post by Touche »

wolfgke wrote: post #49
Touche wrote: post #45

Earlier quoted context omitted.

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 w…

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.

Re: HTML 5.2 Recommendation

#72

Post by eberkund »

wolfgke wrote: post #67
LaGrange wrote: post #59

Earlier quoted context omitted.

It's not enough to be stable to be a standard, you also need authority that enforces it. Either because people "respect you" (whatever that means), or because there's a central authority forcing them to implement the standard, people actually implement it. If they don't, then it's not much of a standard. So, WHATWG is in constant flux, and W3C has about as much authority as I do. _Thankfully_ in practice WHATWG is "s…

> It's not enough to be stable to be a standard, you also need authority that enforces it. There exist lots of standards that hardly anybody cares about. So this is clearly not true.

That was his point...

Re: HTML 5.2 Recommendation

#73

Post by wolfgke »

Touche wrote: post #71
wolfgke wrote: post #49

Earlier quoted context omitted.

> 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 w…

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?

Re: HTML 5.2 Recommendation

#74

Post by wolfgke »

Touche wrote: post #70
andrewmcwatters wrote: post #50

Earlier quoted context omitted.

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 i…

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.

Re: HTML 5.2 Recommendation

#75

Post by colanderman »

tptacek wrote: post #61
colanderman wrote: post #56

Earlier quoted context omitted.

How does one perform feature detection in a static HTML page? As far as I can tell the only way to author a compatible web page these days is by checking every damn feature of HTML you use against some humongous table like Can I Use? before assuming your audiences' browsers support it. Compare to versioned specs, where I need simply determine the minimum spec version supported by my target audience (and any exception…

By using conditional includes and fallback CSS.

Unless "conditional includes" are some new feature of HTML5 that my Google-fu isn't turning up, that kind of negates the whole "static HTML" thing.

Bootstrapping a web page through JavaScript polyfills is like autoconf all over again.

Re: HTML 5.2 Recommendation

#76

Post by Touche »

wolfgke wrote: post #73
Touche wrote: post #71

Earlier quoted context omitted.

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.

Re: HTML 5.2 Recommendation

#77

Post by Touche »

wolfgke wrote: post #74
Touche wrote: post #70

Earlier quoted context omitted.

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…

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.

Re: HTML 5.2 Recommendation

#78

Post by tptacek »

colanderman wrote: post #75
tptacek wrote: post #61

Earlier quoted context omitted.

By using conditional includes and fallback CSS.

Unless "conditional includes" are some new feature of HTML5 that my Google-fu isn't turning up, that kind of negates the whole "static HTML" thing. Bootstrapping a web page through JavaScript polyfills is like autoconf all over again.

The problem with autoconf is that it detects every conceivable Unix featuring going all the way back to the 1980s, not that feature detection is itself that problematic.

Re: HTML 5.2 Recommendation

#79

Post by masswerk »

jraut wrote: post #66
masswerk wrote: post #60

Hm – I'm not too happy to see most of the original HTML-elements marked "not conforming" and "must not be used", thus preparing for browsers to eventually drop the support. There are still lots of web-sites and valuable information stored and archived in this format. Back in the day, it was thought that basic HTML was a format to last. Who is going to update these documents in order to make them conforming to future…

Dropping the support does not make the elements non-functional. Instead, they are presented differently. Formats and notations do undergo changes. The comment mentions long-lived MS-Word doc. Which version of those, specifically, has been around the longest so far?

I'm really afraid that this is preparing the final drop of browser support. (We've seen similar in http, where many of the http/1.1 (1997) features, like multipart-http, for-headers, etc. aren't supported by any client for years by now.)

As for MS-Word and HTML: When I finished my thesis in the mid-1990s, I saved it both in the MS-Word version, I used to write it (MS Word 5 for Mac), and HTML (expecting future compatibility). I can still open the Word version, but I may be soon unable to conjure a formatted display of the HTML-version. And I can still display a PDF 1.x...

Post reply on HN