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

121–130 of 188 posts

Re: HTML 5.2 Recommendation

#121

Post by kuschku »

duskwuff wrote: post #107
frik wrote: post #104

Earlier quoted context omitted.

What's wrong with W3C again? Are we on the same train we were with the ill-fated XHTML 1 strict and XHTML 2. Anyway what's going on anyway with Google+Microsoft+Apple+W3C, why is there such a big push to HTTPS and HTTP/2, and declaring old HTTP/0.9 and HTTP/1 and HTTPS/1 and HTML5.0 as legacy!? And why is Mail still sent in plain text completely insecure, and no adoption hype to support SMIME/etc? It is beyond fishy.…

This W3C recommendation is essentially meaningless. The W3C's "HTML 5.x" specifications have never been considered normative by browsers. The actual HTML specification which browsers follow is maintained by WHATWG at: https://html.spec.whatwg.org/multipage/

> 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 are supposed to do – prescriptively shape and replace what exists – the WHATWG isn’t useful. WHATWG "standards" are the equivalent of Microsoft Office Open XML, a standards body just taking an existing implementation, defining whatever it does as standard, and doing it so incomplete that the result is useless.

Yes, WHATWG and W3C are doing the best they can do in the current climate (where Google can roll out QUIC and SPDY before even any standard is defined across websites accounting for 6% of global traffic, 65%+ of web browsers, and 85%+ of mobile phones), but this is just misleading. It helps no one to pretend to do standardization work when you don’t actually have any power to decide anything – neither WHATWG nor W3C can actually force, or even ask, Google to change SPDY or QUIC. They’re papertigers.

Re: HTML 5.2 Recommendation

#122

Post by austincheney »

rwmj wrote: post #6
taspeotis wrote: post #3

https://www.w3.org/TR/html52/changes.html#changes

For those who have not been paying attention for a decade, what's the relationship between this revision and WHATWG?

The WHATWG specs contain a lot of innovation, but change more rapidly. In many cases WHATWG specs are living documents that gradually evolve and adapt to changes in real time.

Conversely the W3C specifications are fixed to versions and are occasionally patched with updates. The W3C process is incredibly slow and conservative, which frustrates developers on the bleeding edge. Due to the slow process, thoroughness of that process, and formal versioning most software vendors prefer to implement against the W3C publications as more stable or reliable.

Re: HTML 5.2 Recommendation

#123

Post by [deleted] »

collinmanderson wrote: post #90
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.

I think of it like WHATWG is the git master branch of the "html" standard, and W3C regularly packages a modified (changing things they disagree with) version of it and "release" it with a version number (HTML 5.x), going through alpha, beta, etc. By the time it's finalized, it's out of date.

[deleted]

Re: HTML 5.2 Recommendation

#124

Post by xg15 »

stupidcar wrote: post #13
rwmj wrote: post #6

Earlier quoted context omitted.

For those who have not been paying attention for a decade, what's the relationship between this revision and WHATWG?

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."

Re: HTML 5.2 Recommendation

#125

Post by kuschku »

dmitriid wrote: post #11
rwmj wrote: post #6

Earlier quoted context omitted.

For those who have not been paying attention for a decade, what's the relationship between this revision and WHATWG?

Full story here: https://www.reddit.com/r/javascript/comments/5swe9b/what_is_... tl;dr: Ignore w3c's HTML "standards" as they are (often poor) copies of WHATWG's standards.

WHATWG standards don’t even deserve that name.

A standard is something like ISO EN DIN A4. It is defined in cooperation with every stakeholder involved, it is specced, it is tested, and a stable definition is created. Everyone builds against this definition, and it works fine. The standard deprecates everything that existed before, and replaces it.

That is a standard. It’s authoritative, basically immutable, and it is prescriptive.

WHATWG "standards" come after the fact, only consider whatever browsers implement, refuse to ever deprecate anything (unless browsers have already deprecated it), and almost always just are "whatever Google Chrome does". That’s a disgusting abuse of the word standard.

WHATWG "standards" are the equivalent of Microsoft Office Open XML, a standards body just taking an existing implementation, defining whatever it does as standard, and doing it so incomplete that the result is useless.

Yes, WHATWG and W3C are doing the best they can do in the current climate (where Google can roll out QUIC and SPDY before even any standard is defined across websites accounting for 6% of global traffic, 65%+ of web browsers, and 85%+ of mobile phones), but this is just misleading. It helps no one to pretend to do standardization work when you don’t actually have any power to decide anything – neither WHATWG nor W3C can actually force, or even ask, Google to change SPDY or QUIC. They’re papertigers.

Re: HTML 5.2 Recommendation

#126

Post by taco_emoji »

ocdtrekkie wrote: post #110
reificator wrote: post #91

Earlier quoted context omitted.

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 unapologetically still use the font tag, because most of the time I have no desire to bother with CSS.

Even inline?

    Blah
vs.

    Blah

Re: HTML 5.2 Recommendation

#127

Post by xg15 »

Touche wrote: post #76
wolfgke wrote: post #73

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. 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?

Re: HTML 5.2 Recommendation

#128

Post by xg15 »

austincheney wrote: post #120
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…

> Back in the day, it was thought that basic HTML was a format to last. HTML was never intended to be archival. Archival assumes a long term relationship between format and user-agent, but those two things evolve independently. > Who is going to update these documents in order to make them conforming to future browsers? You don't update legacy documents stored in an archive. You find a conforming user-agent (appropri…

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 not make too many breaking changes."

Re: HTML 5.2 Recommendation

#129

Post by austincheney »

xg15 wrote: post #128
austincheney wrote: post #120

Earlier quoted context omitted.

> Back in the day, it was thought that basic HTML was a format to last. HTML was never intended to be archival. Archival assumes a long term relationship between format and user-agent, but those two things evolve independently. > Who is going to update these documents in order to make them conforming to future browsers? You don't update legacy documents stored in an archive. You find a conforming user-agent (appropri…

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.

Re: HTML 5.2 Recommendation

#130

Post by domenicd »

kuschku wrote: post #121
duskwuff wrote: post #107

Earlier quoted context omitted.

This W3C recommendation is essentially meaningless. The W3C's "HTML 5.x" specifications have never been considered normative by browsers. The actual HTML specification which browsers follow is maintained by WHATWG at: https://html.spec.whatwg.org/multipage/

> 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 specification and a shared test suite (https://github.com/w3c/web-platform-tests) that allow others to quickly follow. Note that a specification is better than requiring them to read the Chromium source, because specifications are at a higher level that doesn't depend on individual browser architecture details.

In the WHATWG we don't only write descriptive standards. But we do ensure that whatever standards we write, are ones browsers are willing to implement. And we ensure that standards accurately describe how browsers operate, even for legacy features, because that is all part of the mission of allowing browsers to compete on an even playing field and build themselves from scratch without having to go through the kind of costly reverse-engineering that Firefox 1.0 did to catch up to IE6. In practice we've found that algorithmic specs are better for this than BNFs, as it's harder to specify error-handling behavior for BNFs while still staying compatible with the web (i.e. while still producing a standard browsers are willing to ship).

And yes, we're not interested in just creating a standard out of thin air, with no vendor collaboration, calling it "standard", and then hoping some magical power would force browsers to implement. It is indeed much more collaborative than that.

But the fact that we require standards to be developed in tandem with implementations doesn't mean that implementations (such as Chrome) just go ahead and do whatever they want, and we at the WHATWG transcribe it into the spec at some lower level of detail. Instead, the public, collaborative standards process helps to extract out all testable and observable aspects of the feature into a codebase-agnostic description others can use, and provides a forum for them to comment on ideas before any final shipping decisions are made. And, per our working mode (https://whatwg.org/working-mode#changes), changes and additions do require multi-implementer support before they're ready to graduate to a WHATWG Living Standard; proposals not yet at that point are said to be in incubation, and are often developed elsewhere (see https://whatwg.org/working-mode#new-proposals) such as the W3C's WICG.

Post reply on HN