211–220 of 386 posts
Earlier quoted context omitted.
A sign of the times perhaps? It makes sense given the repository, but of course, it does make it challenging to verify the authenticity of the request when, for all we know by looking at the messages, they could be random users.
It does say that they are members of the W3C organization.
I mean, I see what you mean, but to a casual observer that's not very clear.
Earlier quoted context omitted.
> Most of the web quickly moved to XHTML. This simply is not true. The web moved to an XHTML-like dialect of HTML which was still served as text/html and browsers interpreted it as "HTML soup" because actually serving pages as application/xhtml+xml would have broken the majority of the web because browsers would actually validate them and refuse to display a page at all if there was even a single missing close tag.
> This simply is not true. The web moved to an XHTML-like dialect of HTML You're thinking of XHTML 1.1 or XHTML 2. That "XHTML-dialect" that everyone switched to was called "XHTML 1.0", which allowed serving as either content type. If you're choosing to nitpick about the fact that most sites published would not have worked if served as application/xhtml+xml, I'd invite you to do a survey of sites currently being serv…
By the 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, to a first approximation nobody ever did it. Even today XHTML-levels of precision in HTML requires an awful lot of API support and very careful usage; doing it ten years ago was above almost everybody's skill level.
Earlier quoted context omitted.
It definitely needs to be some curation at least. As an example, CSS: Google came up with Flexbox, Microsoft came up with Grid. Now we have two competing layout methods doing pretty much the same. Yet they are conflicting in the sense that define the same flexibility entity by two different means: flexbox uses CSS property (that by itself conflicts with CSS 2.1 box model) and grid uses fr units for defining the same…
Flexbox and Grid coming from different companies isn't really relevant (and, to note, Flexbox comes from Mozilla originally, if I'm not mistaken, it is ultimately based on parts of XUL). They're also not competing: flexbox makes many 1D layouts easier than grid does. They're complementary, not conflicting.
Problem is that flexbox ruins CSS box model that mandates that width CSS property is what defines the width of inner box of the element. Now they have flex-basis that if defined in galaxy far, far away overrides that width by something else.
That above already recognized as a mistake: https://wiki.csswg.org/ideas/mistakes
As of that 1D ...
grid-auto-flow: row | column;
makes flexbox obsolete at great extent.
Earlier 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…
Earlier quoted context omitted.
Why is "creating a rendering engine from scratch" the bar here? A new player could fork Blink or WebKit.
If you fork an existing rendering engine, you're rather implicitly using a WHATWG DOM. In order to use W3C DOM 4.1, you'd either have to modify a WHATWG DOM renderer into a W3C DOM 4.1 renderer -- which is a bit like starting with the emacs source to build a vim clone -- or to build your own. The inertia of forking an existing project pushes you towards the WHATWG implementation, not W3C. That's the point of forking.…
Earlier quoted context omitted.
It definitely needs to be some curation at least. As an example, CSS: Google came up with Flexbox, Microsoft came up with Grid. Now we have two competing layout methods doing pretty much the same. Yet they are conflicting in the sense that define the same flexibility entity by two different means: flexbox uses CSS property (that by itself conflicts with CSS 2.1 box model) and grid uses fr units for defining the same…
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.
For example?
Earlier 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…
You can get an HTML parser off the shelf. A browser vendor (Mozilla) even funded one for non-browser purposes before adopting it for Firefox.
Earlier 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…
> Way back in the day, HTML was implemented as an application of SGML. [citation needed] I'm unaware of basically any implementation of HTML treating it as an application of SGML; the only notable case I'm aware of is the old HTML validator. Tim's original implementation of HTML didn't treat it as SGML.
You're right, I'm not aware of any actual implementation, outside of validators, that treated it as such.
I did actually say a little later that no web browsers actually implemented it as SGML, but the sentence you quote could cause confusion; but it's too late for me to edit now.
Earlier quoted context omitted.
That’s not true – the WHATWG has already deprecated some HTML specs, and older HTML pages already break today. XHTML would have worked the same way – after a few years, you can deprecate the old parsers.
As far as I know, WHATWG have deprecated some elements not widely used (like "isindex", "font"), but the documents using these elements will still be readable even if not exactly as the author intended. Moving to XHTML, on the other hand, would make billions of pages totally inaccessible. There are people who are now dead who have pages on the internet. These pages will never be updated.
Earlier quoted context omitted.
> W3C process then hijacked this While I agree the W3C's insistence on maintaining a parallel spec. is a silly idea they should absolutely abandon, I fail to see how any but the most biased perspective could conclude that they are "hijacking" a process of their own. W3C haven't dropped anything from the WHATWG spec.: that's separate and out of their control. They can drop what they like from their copy, it's their co…
Because there's no point in reconciling the specs if you don't actually reconcile them. If the W3C spec is a snapshot, possibly of a subset, possibly with some editorial but not functional changes, then reconciling the specs is useful; it gives you want the W3C wants to provide, versioned, frozen specifications that can be used as the basis for other specs, for people to claim "full conformance" with a particular ver…
completely agree
> yes, they hijacked the process in the sense that the WHATWG agreed to work together with the W3C, but the W3C never really worked in good faith to resolve differences or provide technical arguments for their changes.
I can't see either party working in good faith. In what way did the WHATWG's "agreement to work together" bear out in terms of a positive contribution to W3C's parallel spec., which we can both agree isn't a great idea but I'm failing to see how the WHATWG is a positive actor here in any way; they've forced W3C into an impossible position through political bullying and somehow W3C are vilified for hijacking something?