Jesus Christ this is becoming a hot mess.
Microsoft, Google, Mozilla, and Apple Object to W3C Fork of DOM Spec
341–350 of 386 posts
Re: Microsoft, Google, Mozilla, and Apple Object to W3C Fork of DOM Spec
#342Earlier quoted context omitted.
That sounds horrible.
But it worked.
I am not sure if this is still the case today, but I remember that not too long after the new orthography / grammar rules were passed, two major news publishers announced that they would return to the old rules.
Also, my sister is a linguist, and I can trigger her going on a long rant just by mentioning the Rechtschreibreform. ;-)
(Personally, I think some of the new orthography rules are much simpler and consistent, so I use them. The rest I basically ignore, unless a spellchecker nags me about it.)
Re: Microsoft, Google, Mozilla, and Apple Object to W3C Fork of DOM Spec
#343Earlier quoted context omitted.
the formal complaints of all browser people seem to support the WHATWG
The browser people are the WHATWG. There are no other stakeholders in that.
Not only are there non-browser-maker WHATWG stakeholders, there are non-browser-maker formal objectors to the W3C DOM move to CR endorsing the same view as the four browser makers (Bloomberg and Disruptive Innovations; I've never heard of the latter previously, AFAIK.)
Re: Microsoft, Google, Mozilla, and Apple Object to W3C Fork of DOM Spec
#344Earlier quoted context omitted.
Way back in the day, HTML was implemented as an application of SGML. SGML was a quite complex markup format, that had lots of features that were kind of complex to implement, and so web browsers didn't actually implement all of SGML, just that which was necessary for HTML and the HTML found in the wild. However, the HTML found in the wild was frequently invalid, so browsers had to implement some clever rules to do so…
> Inspired by the clever algorithm the WebKit developers had come up with for parsing invalid content, What was the clever algorithm?
Re: Microsoft, Google, Mozilla, and Apple Object to W3C Fork of DOM Spec
#345Earlier quoted context omitted.
I think you're downplaying the shit show that was XHTML. It was the epitome of standards people chasing the ideal of a perfect platonic ideal of a standard at the cost of actual usability. E.G. a single parse error in an XHTML document and it doesn't render at all. That all by itself was a deal breaker for many people.
That’s great if you’re either an existing browser vendor, using a browser, or developing a broken website. But if you actually try to write a new browser from scratch, or a tool to scrape websites, you’ll learn to love XHTML, and hate HTML5. The same that applies with human languages applies here as well. Writing a vocaloid for japanese is a high school programming class project. Writing a TTS for english takes thous…
> Writing a vocaloid for japanese is a high school programming class project. Writing a TTS for english takes thousands of Google developers years.
It didn't take "thousands of Google developers years" to teach a computer English spelling rules. Indeed, even a programming class assignment could do that: you can cover most cases by just looking the pronunciations up in a dictionary. (The number of quirks and inconsistencies makes English spelling quite hard for humans to memorize, but computers are rather good at lookup tables.)
Even if you consider the actual Vocaloid software, which was developed by a team at a large corporation, there are two factors differentiating it from English TTS that make the latter much harder:
1. Japanese has much simpler phonetics than English, with a smaller set of phonemes and (somewhat oversimplifying) only using open syllables. So it's easier to consume and produce, for both computers and humans, but at the cost of being a less efficient encoding: Japanese tends to require a lot more syllables than English to express the same concept, and there are a lot of homophones.
2. Vocaloid sounds robotic. It's gotten a bit less so over time, but it still doesn't come close to passing as human. If you're okay with robotic, English TTS software has existed for a long time, starting many decades before Google was founded. The hard part, the part that requires neural networks and massive computational power and Google and still has yet to be perfected, is making it sound human.
By the way, although vocaloid software would be given phonetic input, normal Japanese writing uses kanji (i.e. Chinese characters), most of which have multiple unrelated possible pronunciations. Determining which pronunciation applies to each character in a given piece of text is nontrivial, and sometimes even depends on context or meaning.
Re: Microsoft, Google, Mozilla, and Apple Object to W3C Fork of DOM Spec
#346Earlier quoted context omitted.
I use both flexbox and grid layout together. They are not comepting, merely completing each other. Grid can do things Flexbox can't do. Flexbox can do things Grid can't do.
"Flexbox can do things Grid can't do" For example?
flex-wrap. flexbox is one-dimensional, so it can "wrap" items that don't fit to the next line. The wrapped items don't have to line up with vertical grid lines, like they would in a grid, and they can be stretched or centred to fit across the full width of the parent.
Re: Microsoft, Google, Mozilla, and Apple Object to W3C Fork of DOM Spec
#347Earlier quoted context omitted.
And yet, forcing people to implement opengraph tags, forcing people to drop flash, forcing people to use HTTPS, forcing people to drop Symantec certs, forcing people to drop SHA1 certs – so often the actors behind the WHATWG have managed to get website authors to change what they use. Hell, Google has AMP, which is far more intrusive than XHTML ever was, and yet, they’ve managed to get every major website to implemen…
There' s a Big difference between "every major website" and "the Web". "every major website" means 100 companies with skilled developer who can and will react to changes in browsers quickly. "The web" consists of millions of websites maintained by individuals and small organisations who have no resources to update the way their web pages are coded every year. It contains HTML generated 10, 20, soon 30 years ago. It c…
There's also a federal procurement picture: big governments making big purchases aren't fans of incompatibilities and standardised solutions.
For a company like MS losing access to "the web" could keep a lot of people from becoming VPs...
Re: Microsoft, Google, Mozilla, and Apple Object to W3C Fork of DOM Spec
#348Earlier quoted context omitted.
> by lucideer's quirky definition Which also happens to be the definition the w3c xhtml 1.0 spec. You can choose to think that's quirky, please don't attribute it to me. > definition that most of us are using, which is that XHTML is complaint XHTML that could be rendered without error in browser's XHTML modes Which, again, is the definition used in the later w3c xhtml 1.1 & 2 specs, the former which wasn't widely use…
You're taking about the ease of validation. Everyone else is talked about the ease of writing.
Oh, you mean like AMP, which now every major site supports, and which is even stricter than XHTML?
Re: Microsoft, Google, Mozilla, and Apple Object to W3C Fork of DOM Spec
#349Earlier quoted context omitted.
> not all related to browser making, quite understandably was never fully on board with the new WHATWG HTML spec efforts. That's the other thing that pisses me off about the WHATWG, is how much they shit all over XML and other interoperability technologies. E.g. their URL standard (because, why not fuck the IETF as well) basically ignores anything non-HTTP for specious reasons.
The only reason there is a URL standard in the WHATWG is that the IETF URL RFC didn't define error handling and this led to interop problems. So there was a need for a URL standard that _would_ define error handling. The IETF refused to produce one (basically said "fuck you, we don't care about your use cases or interop problems" with slightly more polite wording), so the WHATWG ended up doing it... I'm not saying th…
The first line of the WHATWG URL spec says that it deprecates and replaces all IETF URL standards.
Re: Microsoft, Google, Mozilla, and Apple Object to W3C Fork of DOM Spec
#350Earlier quoted context omitted.
I agree with everything you said. What rubs me the wrong way about the WHATWG is that they give the perception (and it may be just that) that they are trying not just to serve as that forum for browser makers, but also as the standard reference for web developers (which is the role the W3C HTML specs, save XHTML 2, have historically served), and doing a poor job of the latter.
Exactly what is the purpose of a standard reference for web developers that fails to track the documented behavior of browsers?
Great, so if I build a website based purely on the WHATWG specs, it will work in all browsers, correctly?
No, it won't.
I can take the A4 paper spec and build a printer that takes that paper, and I know paper will comply with it. And the other way around.
You can't build a website just from WHATWG specs, and you can't, excluding the parts about backwards compatible parsing, easily build a new browser from scratch either.
A standard is an a-priori written document that describes the entire API surface, so that people on both sides can develop based on the standard without having to verify with actual implementations.
The WHATWG documents are useless for this purpose.