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

W3C and the WHATWG sign agreement to collaborate on single version of HTML, DOM

w3.org

Post reply on HN
Print view View original

151–160 of 287 posts

Re: W3C and the WHATWG sign agreement to collaborate on single version of HTML, DOM

#151

Post by boomlinde »

amyjess wrote: post #122
boomlinde wrote: post #48

Earlier quoted context omitted.

> These are the same people who created XHTML, an ivory tower idea nobody was waiting for... who didn't support the most popular layout method at the time, tables, in their new styling language CSS. You certainly could lay out pages using tables in XHTML, but the point of the standard in the first place was to enable semantically sound documents for the sake of interoperability and to facilitate separation of concern…

I honestly don't think either was the purpose. XHTML existed to make parsing easier. The only things you couldn't do in XHTML 1.1 Transitional that you could do in HTML were having unclosed tags and using uppercase in tag names. That's it. Now yeah, the strict version tried to force you into semantically sound documents... but that was completely orthogonal to XHTML vs. HTML. Both XHTML and HTML were available in bot…

> I honestly don't think either was the purpose. XHTML existed to make parsing easier.

That being the only goal would have resulted in a much simpler standard. Extension modules for example is completely orthogonal to that goal. I think that the standards themselves do a good job of describing what motivates them.

> The only things you couldn't do in XHTML 1.1 that you could do in HTML were having unclosed tags and using uppercase in tag names. That's it.

That's true, but ignores the opposite question—what you could do in XHTML that you could not in HTML.

Re: W3C and the WHATWG sign agreement to collaborate on single version of HTML, DOM

#152

Post by kijin »

ChrisSD wrote: post #9

I still maintain that the "living standard" is an oxymoron. It's a collaborative browser dev document. Don't get me wrong, that's great. However for everyone else an unversioned document, any part of which can change at any moment, is not what's usually thought of as a standard.

I don't mind a changing standard as long as two people can agree on exactly which version of the standard they're talking about and actually use that version.

I should be able to build my web app against an LTS version of the standard and expect it to behave identically in all future versions of all major browsers, until the EOL date of said version, no matter what changes they make in future versions. I want this for the same reason I want either CentOS or Ubuntu LTS, not Arch, on my production boxes.

Unfortunately, the whole HTML 5.1/5.2/5.3 business never quite caught on, and browsers don't support anything but the latest snapshot of whatever it is that they call a standard.

Re: W3C and the WHATWG sign agreement to collaborate on single version of HTML, DOM

#153

Post by rimliu »

ChrisSD wrote: post #116
vorpalhex wrote: post #103

Earlier quoted context omitted.

Hopefully those aren't in contrast to each other. You can have a living document that gets consistent updates AND still has meaningful versions, much like a lot of well developed software. The goal is for the time between HTML versions to not be a decade, but instead for consistent, incremental improvements without browsers trailing behind for years. At the same time, these should (hopefully) not be breaking changes.

Sure. IMHO one solution might be to have a HTML standard specification that is stable, which can then be built on. Extensions can be proposed so long as they don't break the standard. This would allow new elements and attributes to be introduced before they are themselves fully stable, as they are now. Breaking changes would require bumping the spec to a new major version and should happen only rarely.

We have HTML standards that ar stable. 4.01 e.g. The problem is that no browser ever implemented all of it, and even implemented parts were done differently.

Re: W3C and the WHATWG sign agreement to collaborate on single version of HTML, DOM

#154

Post by rimliu »

jrochkind1 wrote: post #61

On the one hand, good. On the other, it seems like just complete capitulation by the W3C; WHATWG makes all the real decisions still, W3C now performs important administrative services for free, turning the "living standard" into an actual usable standard, without actually having any meaningful power over the results. WHATWG gets to do the part that matters without having to do the hard part, W3C does the hard part fo…

The browser vendors always had control. W3C could put anything they want into the standards, it does not matter if nobody implements it.

Re: W3C and the WHATWG sign agreement to collaborate on single version of HTML, DOM

#155

Post by jerf »

sureaboutthis wrote: post #133
ChrisSD wrote: post #66

Earlier quoted context omitted.

IIRC, the main objection was that error handling was an all or nothing affair. Whereas most HTML on the web is (or was) broken to a greater or lesser degree. There was also the objection that stricter parsing made it harder for hobbyists. In these days of Typescript, where web devs seem to like having stricter rules, it could play better. But that ship has already sailed.

I never understood that either except, as you said, for the hobbyist's sake. A lot of XHTML was generated from XML and, if one is using XML, chances are programming is involved in the transformation to XHTML. But programming has strict rules itself and will also fail if not adhered to so I never understood the complaint of "draconian" error checking in XML/XHTML.

As the scale of a program increases, the probability that someone will do something wrong increases polynomially. Consequently, as web sites got larger and larger, the probability that some component would break the XML goes up quickly. This is a difficult pattern to deal with, pushing up the skill floor required, and as HTML5 shows, it isn't even all that necessary.

There was also similar exposure from the data side; as the amount of data you handled increased, the odds that some data would tickle some code path that you didn't even know could blow up went up. You write your news front page in XHTML, and everything seems fine for six months, until someone finally includes an ampersand in their headline, and your entire front page crashes for two hours (not in any way monitoring will pick up, either, so you're getting customer reports), and it takes you hours to discover that someone was passing through the headline (and just the headline!) unencoded.

The problem isn't XHTML's rigidity per se; personally I'm inclined more in that direction myself. The problem is when you have a ton of sloppy systems working together (MySQL, old HTML generation code, plugins from third parties your don't control, open source written by people whose belief in their understanding of HTML exceeds their actual understanding, decade-old internal databases with poor validations and unknown provenance, and so on and so on indefinitely), and then trying to suddenly, at the last minute, couple that big sloppy pile of technology to a strict technology at the last second. That sudden mismatch there at the end was a huge problem.

One of the reasons I tend to prefer being as strict as possible is that in general, starting with existing strict-tech and adding sloppy-tech to it is no big deal; the sloppy tech doesn't complain that it only gets a subset of possible data it will accept. And if you need to couple to strict-tech, you still can. But if you start with a sloppy-tech system and for some reason need to couple it to a strict-tech system... prepare for some long nights and blown deadlines. So, professionally, the correct default is to choose strict-tech whenever possible. But XHTML forced that at almost the worst possible place.

Re: W3C and the WHATWG sign agreement to collaborate on single version of HTML, DOM

#156

Post by danarmak »

kevingadd wrote: post #121
danarmak wrote: post #91

Earlier quoted context omitted.

If I complain to Mozilla that they deviate from the W3C spec in some respect, will they treat that as a bug, or will they more likely say "no-one implements this, so no website uses this, so we have no reason to be the first to implement this because we don't think this is part of the spec is really important"?

Depends on the deviance. If it's 'this was changed in the whatwg spec' the answer will probably be 'the next w3c spec will document this change, for now here's '. If the deviance breaks production apps sometimes Mozilla will roll it back, it's happened before. In other cases they'll treat it as a bug and fix it.

Thanks, that's encouraging to hear!

Although I still worry about the case where fixing the deviance would break production apps. Potentially break them, since people won't complain until you release the breaking browser version. That's what's usually kept browsers from hewing to standards.

Re: W3C and the WHATWG sign agreement to collaborate on single version of HTML, DOM

#157

Post by danShumway »

giancarlostoro wrote: post #80
userbinator wrote: post #52

Earlier quoted context omitted.

This obsession with "living" and constant change seems to be mostly confined to the web --- instead of settling on a spec and then leaving it alone and "doing what you can with what you have", those working on this stuff seem more inclined with continuing to make browsers change. I suspect at least part of the reason is to build a high barrier to entry and preserve the monopoly, keeping out competitors, given who the…

> I suspect at least part of the reason is to build a high barrier to entry and preserve the monopoly, keeping out competitors, given who the people in these groups work for. A lot of what happens in someone like Chrome implements something not yet standardized, then it gets standardized in a different way, or Mozilla implements something and Chrome implements it differently from the standard, perhaps to try and reac…

> A lot of what happens in someone like Chrome implements something not yet standardized, then it gets standardized in a different way

This. The Chrome team is hopelessly optimistic when making assumptions about how standards evolve. See Web Bluetooth which was heavily advertised to developers before other browser eventually chimed in and said, "yeah, we're not doing that."

Still turned on by default in modern Chrome without a flag, probably because the Chrome team is still assuming that eventually the API will be standardized to Chrome's specification.

Re: W3C and the WHATWG sign agreement to collaborate on single version of HTML, DOM

#158

Post by jasonhansel »

cotelletta wrote: post #26
Multicomp wrote: post #4

Extremely condensed version: W3C is giving up publishing future HTML and DOM standards. They will focus on writing 'recommendations' for the WHATWG's living standards. Versioned vs living HTML discussions aside, I personally admit some mild sadness that the original group responsible for maintaining Sir TBL's work on HTML has been forced to give up.

These are the same people who created XHTML, an ivory tower idea nobody was waiting for... who didn't support the most popular layout method at the time, tables, in their new styling language CSS. W3C became irrelevant because they kept thinking they could just tell the entire web what to do, that they'd make enormous technical investments to satisfy the W3C's latest fashions. I interacted with them once, over their…

I think what really hurt the W3C was its obsession with "semantic web" features (RDF, XHTML 2, etc.) that nobody wanted and few people used.

Re: W3C and the WHATWG sign agreement to collaborate on single version of HTML, DOM

#159

Post by ezoe »

ChrisSD wrote: post #9

I still maintain that the "living standard" is an oxymoron. It's a collaborative browser dev document. Don't get me wrong, that's great. However for everyone else an unversioned document, any part of which can change at any moment, is not what's usually thought of as a standard.

Attempt of versioning the HTML was failed miserably in the past. I prefer living document than outdated standard.

Re: W3C and the WHATWG sign agreement to collaborate on single version of HTML, DOM

#160

Post by lstamour »

lucideer wrote: post #144
Ajedi32 wrote: post #129

Earlier quoted context omitted.

> My personal opinion on this is to stop feeding the monopoly and refuse to use anything other than basic HTML for static content sites. That's not going to work for one simple reason: despite HN's obsession with plain HTML/CSS, these new standards _are_ actually useful. They're being created with the express purpose of solving practical problems that developers, site operators, and users are experiencing in the real…

> these new standards _are_ actually useful I don't necessarily disagree, but it would help your case if you includes some examples in your comment (if only to build a discussion upon).

You have to take the mindset that "giant bundles of JavaScript" aren't how we want to build the web but to begin to ship more and more of the web baked into browsers instead. And that even "static HTML" requires accessibility improvements and adaptations to new device types. For example, split screen phones, where you've a mobile device that starts at one size, but then can open up to a larger size. Tiny watch apps, new camera APIs, Responsive @media queries, better support for print media, less onscroll jank through the use of IntersectionObserver, new authentication APIs to support Windows Hello, advancements to link tags for prefetching resources and DNS, CORS security enhancements, discussion about proprietary browser implementations of features so they're not proprietary, using origin trials (Chrome) or the Develop menu (Safari) or preferences (Firefox) to encourage web developers to try new features on their sites and report back on how they work (origin trials make this trivial), non-vendors building new features for the web such as Intel and Facebook, and ... well, it's hard to summarize how many advancements there have been in web standards since HTML5 became a thing. I'd also point to a useful parallel in how ECMAScript versions their spec, it's in a constantly evolving state also as new proposals move between stages. To me, this reflects how standards bodies now can use git much more easily and effectively as a versioning mechanism and how they've learned to try and use the best of open source instead of locking up versions behind paywalls and private interest groups. Literally anyone can contribute to these specifications, see https://www.youtube.com/watch?v=y1TEPQz02iU
Post reply on HN