5 ms·
I thought that WhatWG were actually the ones developing HTML5?
by staz 10y ago
I thought that WhatWG were actually the ones developing HTML5?
- kuschku 10y agoWhatWG is just rubberstamping "whatever Chrome implements" (sometimes with feedback from Firefox) as HTML5. The actual development is entirely controlled by the browser vendors, causing pain for everyone trying to parse HTML programmatically.
- andybak 10y agoBecause everything went so well when the W3C was left to their own devices...
- kuschku 10y agoCertainly better than bullying cURL into accepting their idiotic URL specification. Especially considering what they want would rather be specified as a parser for generating URLs from user input, and not to simply demand every tool interacting with URLs to be able to parse malformed URLs.
- jcranmer 10y agoWHATWG didn't bully cURL into URL, people complaining that cURL didn't match browsers did that. The WHATWG made a decision long ago that its standards would be descriptive (describe how people parse it), not prescriptive (describe how people should write it). Anyone who attempted to write a web browser would have had to reverse-engineer how other browsers treated crap, because it was the only way to get websites to work. If you think the definition of URL was stupid, you should see what they had to do to support document.all: define a new concept in JS to represent the notion of "this looks and acts like undefined but you can actually use it as an object."
- kuschku 10y agoAnd a descriptive standard is entirely useless. The entire point of a standard is that implementors agree on a design definition, then implement it, and it stays consistent, forever. If you look at standards that work and fail, you’ll quickly notice a pattern. Prescriptive are Metric, the A-series of paper, the entire SI system, most open standards, etc. Descriptive are the imperial / US standard, Letter paper, Microsoft "Open" XML, etc. And before you complain that prescriptive standards are useless because you can never change legacy systems: Several countries have prescriptive language design, with legal authorities how the language has to be used, and they manage to deal with centuries of legacy data.
- jcranmer 10y agoThe email RFCs are prescriptive, and totally useless. I actually have evidence, for example, that RFC 2047 is more often violated than not, and I wonder if message/global will ever see usage as a Content-Type. Prescriptive attempts at tackling memory models in languages have generally failed. Also, your delineation of prescriptive/descriptive is laughable. The imperial standard, letter paper, and OOXML are all prescriptive standards (albeit OOXML is a very badly written one). Prescriptive language standards aren't necessarily well-applied--ask how many people follow the 1996 German spelling reform, or how many use «le hashtag» instead of the "official" «le mot-dièse» (hint: look at the name of the Wikipedia page is). OOXML did poorly not because it was descriptive but because it wasn't precise. It was an XML rendering of internal Office file formats, and its description of terms were no better than internal documentation. Something like the TNEF format is much closer to a descriptive document, since it spends a lot of time discussing the differences between Outlook 2007, Outlook 2010, and Outlook 2013 at various steps.
- gsnedders 10y ago> Especially considering what they want would rather be specified as a parser for generating URLs from user input, and not to simply demand every tool interacting with URLs to be able to parse malformed URLs. The goal of the URL standard isn't to generate URLs from user input (for example, the browser address bar is out-of-scope), but instead define how <a href="foo"> in HTML (or, rather, more generally, {http://www.w3.org/1999/xhtml}a@href http://www.w3.org/1999/xhtml}a@href from the DOM), url("foo") in CSS, Location: foo in HTTP, and similar get parsed. There are large parts of this that the web relies on undefined error handling around this, which makes it worth standardising somewhere (as browsers cannot practically drop it, and most web content is targeted primarily at browsers, hence if you want to be compatible with the web you need to be compatible with browsers). I'll also point out that the WHATWG scarcely exists: as a venue there's almost no formal organisation or high-level plan, it largely working on some shared values, and as a result there's a fair bit of variety between different groups of people working on different specifications where some take those values to further extremes than others.
- kuschku 10y ago> The goal of the URL standard isn't to generate URLs from user input […], but instead define how <a href="foo"> in HTML Ehm, that’s exactly user input. If it were machine input, there would be a normalized definition, and you’d use that internally. And you wouldn’t define a URL spec this way, but you’d define a strict URL spec that browsers and all tools should use, and a legacy tool for converting URLs. Then any tool that doesn’t directly deal with user input can always be sure the URL they get will strictly follow the standard, and only the first tool in the pipeline has to deal with malformed input (which this is)
- gsnedders 10y ago> Ehm, that’s exactly user input. If it were machine input, there would be a normalized definition, and you’d use that internally. That depends on the definition of "user"; most things I'm used to refer only to the current user of the device as the user, and everything else as untrusted input. The problem with having a formal definition of the strict subset is that you end up with bugs (often security critical) in almost every implementation because of some case where the conversion produces something not in the strict subset. That's something that's happened with way too many formats.
- deleted 10y ago[deleted]