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

131–140 of 188 posts

Re: HTML 5.2 Recommendation

#131

Post by domenicd »

xg15 wrote: post #124
stupidcar wrote: post #13

Earlier quoted context omitted.

The W3C version is a sporadically updated, bad-faith fork of the WHATWG version, created to maintain the fiction that it "owns" HTML, which it deems necessary to maintain the organisation's standing (and funding) in the eyes of other organisations and governments.

And yet, we don't get things like that changes page from the WHATWG version. (Unless you want to dig through the whole commit history) It's absolutely a fiction, but at the same time, this at least attempts to be a standard. The WHATWG version seems more like a reflection of "oh by the way that's the rules our browsers are following this month. Your's truly, the browser vendors."

> And yet, we don't get things like that changes page from the WHATWG version. (Unless you want to dig through the whole commit history)

So far we've done our best to keep a really readable, tidy Git commit log, which should help with understanding changes: https://github.com/whatwg/html/commits/master

If you omit the "Editorial:" or "Meta:" commits, I think it's actually at a similar level of detail as the W3C fork's changes log. (Not completely; scrolling through I do see a number of commits that wouldn't be relevant.) But the W3C fork has only managed to copy-and-paste a small subset of our changes, so indeed, the changes log for the last year of work at the WHATWG will be somewhat daunting compared to the small subset they managed to copy over.

There may be room for someone to compile a higher-level "this week/month/year in the HTML Standard" or similar; before I started working in the WHATWG, that actually used to exist: https://blog.whatwg.org/category/weekly-review (also in very amusing YouTube form: https://www.youtube.com/watch?v=1Bg5BPnmj68). So far we haven't had the bandwidth to restart that, but if you or someone else wants to contribute that sort of thing to the blog or elsewhere, I'd love to help you get started.

Re: HTML 5.2 Recommendation

#132

Post by kuschku »

domenicd wrote: post #130
kuschku wrote: post #121

Earlier quoted context omitted.

> The actual HTML specification which browsers follow ...is found here: https://chromium.googlesource.com/ The reality is that the WHATWG (a) only writes descriptive standards, describing what already exists, usually with pseudocode and prosa instead of ABNF or EBNF (see the URL standard replacement), and (b) only describes something once it’s actually been implemented on larger scale. On the topic of what standards…

I work for Chrome, as an editor of the HTML Standard. So let me give you my perspective on this. In Chrome we ensure that all features we ship to the web go through a public standards process. This allows them to be developed by a collaborative community, including other browser vendors and web developers who would use them. It ensures that if we happen to ship a feature sooner than other vendors, there's a specifica…

> In Chrome we ensure that all features we ship to the web go through a public standards process.

Ehm, basically every major feature Chrome has shipped has been shipped before the standard was even discussed. SPDY shipped long before HTTP/2 was even finalized, and QUIC is doing the same. NaCl shipped in the same way, without any standardization, and to this date, earth.google.com depends on it.

In general, your problem is that you only consider browser developers. In the past, the WHATWG has decided to redefine the URL standard, then shame cURL for not following the standard, without ever involving anyone from the curl project in the discussion. The URL discussion affects everything from Android’s IPC system to curl, from industrial machinery to the web. The WHATWG explicitly declared that the URL spec is designed to completely, and exhaustively, obsolete and deprecate any existing URL or URI spec.

Yet, the only people ever contacted about this, and who were given the ability to take part in the discussion, were representatives from the three large browser vendors.

Re: HTML 5.2 Recommendation

#133

Post by domenicd »

kuschku wrote: post #132
domenicd wrote: post #130

Earlier quoted context omitted.

I work for Chrome, as an editor of the HTML Standard. So let me give you my perspective on this. In Chrome we ensure that all features we ship to the web go through a public standards process. This allows them to be developed by a collaborative community, including other browser vendors and web developers who would use them. It ensures that if we happen to ship a feature sooner than other vendors, there's a specifica…

> In Chrome we ensure that all features we ship to the web go through a public standards process. Ehm, basically every major feature Chrome has shipped has been shipped before the standard was even discussed. SPDY shipped long before HTTP/2 was even finalized, and QUIC is doing the same. NaCl shipped in the same way, without any standardization, and to this date, earth.google.com depends on it. In general, your probl…

Those are fair counterexamples. Perhaps I should be distinguishing between the Blink team and the rest of the Chrome team. I realize that distinction isn't very important to an outsider, but at least realize that that there's a large portion of the Chrome team that cares very much about the web evolving through an open standards process.

The URL Standard was designed in the open with input from many different constituencies. The cURL author has chosen not to participate, for reasons of his own, but e.g. Node.js, PHP, Google's GURL (used by Android IPC, I believe), and others are quite involved.

Re: HTML 5.2 Recommendation

#134

Post by om2 »

austincheney wrote: post #129
xg15 wrote: post #128

Earlier quoted context omitted.

Except, as described later in this thread, WHATWG HTML, the spec that is actually implemented is decidedly not versioned and changes from day to day. It's likewise discouraged from keeping old user-agents. (See e.g. chrome's and firefox' aggressive update and support policies.) From what I understand, the WHATWG's policy regarding archival is "well yes the format is constantly changing but we'll try REALLY hard to no…

To my knowledge the WHATWG specs are the backbone of the W3C specs, but nobody follows the WHATWG specs. Browser vendors prefer to follow the W3C specs precisely because they are versioned and perform against a slower and extremely thorough review process.

That’s not right. Browser implement the WHATWG specs.

That said, validity changes don’t matter to the browser’s ability to render old pages. Changes to remove support for an element entirely are very rare.

Re: HTML 5.2 Recommendation

#135

Post by mastax »

austincheney wrote: post #129
xg15 wrote: post #128

Earlier quoted context omitted.

Except, as described later in this thread, WHATWG HTML, the spec that is actually implemented is decidedly not versioned and changes from day to day. It's likewise discouraged from keeping old user-agents. (See e.g. chrome's and firefox' aggressive update and support policies.) From what I understand, the WHATWG's policy regarding archival is "well yes the format is constantly changing but we'll try REALLY hard to no…

To my knowledge the WHATWG specs are the backbone of the W3C specs, but nobody follows the WHATWG specs. Browser vendors prefer to follow the W3C specs precisely because they are versioned and perform against a slower and extremely thorough review process.

This is not (uncontroversially) true. See the long discussion below or on any other W3C post on HN.

Re: HTML 5.2 Recommendation

#136

Post by kuschku »

domenicd wrote: post #133
kuschku wrote: post #132

Earlier quoted context omitted.

> In Chrome we ensure that all features we ship to the web go through a public standards process. Ehm, basically every major feature Chrome has shipped has been shipped before the standard was even discussed. SPDY shipped long before HTTP/2 was even finalized, and QUIC is doing the same. NaCl shipped in the same way, without any standardization, and to this date, earth.google.com depends on it. In general, your probl…

Those are fair counterexamples. Perhaps I should be distinguishing between the Blink team and the rest of the Chrome team. I realize that distinction isn't very important to an outsider, but at least realize that that there's a large portion of the Chrome team that cares very much about the web evolving through an open standards process. The URL Standard was designed in the open with input from many different constit…

The URL Standard didn’t even consider contacting any industrial vendor that relies on them - e.g. SIEMENS. There’s entire industries out there that use these standards, and rely on them to be stable.

The only participants were all either browsers, affiliated with browsers, or a handful of web serving projects.

Other projects that rely on URLs include everything from KDE to Gnome, Microsoft’s OS to the systems used in your car.

Changing a URL standard and only involving web vendors is basically like changing the A4 paper standard and only talking to the Microsoft Office team, the Google Docs team, and HP’s printer team – while entirely ignoring paper manufacturers, envelope manufacturers, the mail companies around the world that will have to ship the envelopes, fax manufacturers that have to build faxes able to fax the new format, newspapers and magazines that have to replace their paper, newspaper shelf manufacturers that build newspaper shelves for newspaper stores, etc.

Most of the time, it’s easy to only think of the web as browsers and servers, but some of the specs the WHATWG touches go through entire industries, sometimes there are millions of companies that have to be notified months or years beforehand to replace their software, update it, potentially even do a recall, and standardize. Not everything moves as fast as the web.

And this entirely disregards the people that are trying to parse the web with HTML parsing, which everyone loves to ignore. And so many other groups of people and companies.

Re: HTML 5.2 Recommendation

#137

Post by austincheney »

mastax wrote: post #135
austincheney wrote: post #129

Earlier quoted context omitted.

To my knowledge the WHATWG specs are the backbone of the W3C specs, but nobody follows the WHATWG specs. Browser vendors prefer to follow the W3C specs precisely because they are versioned and perform against a slower and extremely thorough review process.

This is not (uncontroversially) true. See the long discussion below or on any other W3C post on HN.

I don't need to see a comment thread here to understand the process. I have been following this for 20 years, long before there was a WHATWG.

Additionally, WHATWG lost some credibility when they attempted to redefine the DOM and arbitrarily delete some node types. Granted, most of those types are legacy types not in use by anybody in long time, except for the attribute node type. Browser vendors simply ignored this foolishness.

Re: HTML 5.2 Recommendation

#138

Post by int_19h »

collinmanderson wrote: post #96
exikyut wrote: post #46

Earlier quoted context omitted.

I know the current manglement isn't explicitly malicious, but this is an atrocious state of affairs. Practically speaking, the Web is a consortium of corporate foghorns that also happen to collectively be the majority ad-hoc directors of new media (translation: agendas with finance). Cable and daytime TV was the old media, which of course still exists, and social media has become a juggernaut majority of its own besi…

At this point both W3C and WHATWG are not where innovation on the web is (or should be) happening. It's up to the individual browser makers to innovate. W3C and WHATWG's job should be to document any consensus among browser makers. It shouldn't be their job to decide how browsers should work, that's the browser makers' decision. (Which happens to be large corporations, for the most part.)

This is exactly how we got IE market dominance back in the day.

Re: HTML 5.2 Recommendation

#139

Post by Touche »

xg15 wrote: post #127
Touche wrote: post #76

Earlier quoted context omitted.

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.

Re: HTML 5.2 Recommendation

#140

Post by orph4nus »

reificator wrote: post #91
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…

is no longer supported by browsers, but with a few css declarations it works just fine. Removing support for presentational markup does not mean a loss of information. Browsers will still render tags they don't recognize, and re-applying the styling of those tags is often trivial. (I mention because it's one of the more difficult, but not terribly so) As the web evolved, our needs changed. Do we still need the tag?

I think you're missing the OP's point though.

It's true that you can just use some CSS to make up for the lost HTML feature, but than again you could also rewrite the HTML part.

Forgive me if I'm wrong, but I'm fairly sure that what the OP is trying to say, is that there are plenty of great websites out there, which were developed a long time ago, and for which there is no maintainer to do any work on it. Thus having HTML elements like this dropped, would make the content in a way lost.

Thinking about it some more, users can probably add plugins to add this css automatically, or some browsers might even keep those features in, but still, there will be users that don't know this, I think, resulting in a bad experience.

Post reply on HN