12 ms·

Extremely condensed version: W3C is giving up publishing future HTML and DOM standards. They will focus on writing 'recommendations' for the WHATWG's living st

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.

cotelletta 7y ago
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 seamless iframe proposal. I had to point out that the two biggest uses of iframes at the time, i.e. Twitter embeds and Facebook apps, could not make use of it, despite being a perfect fit. They just hadn't considered that.
- zmix 7y ago
  > who didn't support the most popular layout method at the time, tables I can do tables just fine in XHTML. And luckily, tables have become redundant as layout technique, since CSS would do that, already then. The nice thing with X(HT)ML is, that you can place queries against any document, natively.
  - cotelletta 7y ago
    Did you miss the 5-10 years during which every CSS designer tortured themselves replicating tables with floats? Google 'pure css page footer' to see the wreckage. CSS tables took years to be supported, and even then, only brought back what people had been irrationally told to stay away from. It took another 5 years for flex box to become usable, adding something actually new. To this day, changing a site's entire design without touching its markup is a mirage. It only works in contrived scenarios with extremely artificial restrictions, and nobody does it in the real world. CSS Zen Garden was demoscene.
    - cygx 7y ago
      Personally, I was fine with ditching tables, but stuff like differing box models, unequal CSS support, quirks modes, etc did make for a rather painful cross-browser development experience: Making things work out correctly (or at least gracefully degrade) in multipe IE versions, Mozilla, Opera, ... could be a challenge.
    - pbhjpbhj 7y ago
      Tabular markup for non-tabulated data is not rational & semantic markup is certainly not irrational. You don't come from print design by any chance? With flexbox, for example, you can change order of appearance contrary to the code order in the markup. It's not a mirage. Anyone who's used a browser's reader mode, or distilled view (as Brave calls it), knows the usefulness of applying different styles to a fixed markup. Separation of presentation is possible. Indeed now we've moved to responsive design and the number of devices and UA has exploded the separation of design and data is coming in to its own -- but instead pixel-perfection is still being chased with a billion @media declarations.
      - cygx 7y ago
        You don't come from print design by any chance? You've not been doing that whole web design thing for very long, by any chance? Those of us who have been around for a while do remember the inadequate layouting capabilities of CSS of bygone eras. While I was on the semantic markup side of the debate at the time, it's not as if the pragmatists that just went with the table for convenience's sake did so for no reason at all...
        pbhjpbhj 7y ago
        I started web design for lynx browser, back when using pine for email was hot, then moved on to Mosaic and NN. There's a clear body of web design/dev people that think it's just a visual display medium, and a lot of those seem to come from print design. The web for me has always been primarily a medium for information transfer, visual design is nice but not at the expense of semantic markup; table markup for visual layout is entirely unnecessary (and was terrible for accessibility). People went with table layout because marketing people demanded pixel matched presentation and/or they didn't care to make sure their content was machine readable. The same views lead to IE only and give us websites that don't bother with semantic blocks now, or that don't work without JavaScript when that js is just being used for presentational flair.
  - geezerjay 7y ago
    > And luckily, tables have become redundant as layout technique, since CSS would do that, already then. It took well over a decade to get CSS to play nicely with layouts. It's disingenuous to present CSS as the obvious solution to a problem while criticising table usage to implement grid layouts, as this line of argument entirely ignores the recent history of the web.
- austincheney 7y ago
  ? Tables for layout? Seriously? Foolishness aside it is important to understand the DOM came out of work from the XML Schema spec and for many years updates to those two documents were always released together. The W3C isn’t irrelevant as there is more to the web than just HTML just like Oasis isn’t irrelevant for schematic design and business integration. This talk of irrelevance is a hard argument to make for many frontend developers who cant tell the difference between the standard DOM and Reacts VDOM.
  - maeln 7y ago
    Yes tables. There is a reason why people where abusing table for layout even though all hated it. In the end, we finally have CSS grid now ( https://css-tricks.com/snippets/css/complete-guide-grid https://css-tricks.com/snippets/css/complete-guide-grid ) which do what we were trying to achieve back in the day with tables. We had to wait until 2016 to have a type of layout which is considered standard in most GUI toolkit ...
    - ChrisSD 7y ago
      `display: table` has been around since around 2001/02, for exactly that reason. However IE didn't support it until IE8.
      - cygx 7y ago
        However IE didn't support it until IE8. Which got released in 2009, but took another year to overtake IE6+7 in market share. This means `display:table` was of limited usefulness for nearly a decade after its introduction...
        ChrisSD 7y ago
        Sure but that's a different issue. It's not the fault of the standard if a major browser doesn't implement it. In practice I was using display table in some designs in the mid 00's but also using conditional stylesheets to hack an IE layout. This was not a particularly good solution but it "worked".
- baybal2 7y ago
  > seamless iframe proposal. DOM v3 Document.load() https://www.w3.org/TR/DOM-Level-3-LS/load-save.html https://www.w3.org/TR/DOM-Level-3-LS/load-save.html was the candidate for client side document loading long before most people even knew what W3C is
  - robocat 7y ago
    Perhaps that is a great example of why the W3C failed?
  - robocat 7y ago
    From what I can see, your example of "DOM v3 Document.load()" is a great example of why the W3C failed to convince browsers to implement their proposals. That spec seems to be mostly related to Java and it seems to me that it hardly considers how ECMAScript could use it i.e. someone had an idea, but couldn't translate that into a useful feature...
- boomlinde 7y ago
  > 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 concerns. So maybe if you authored XHTML documents that was already an important consideration to you. On a side note, now that the web development industry seems to have collectively given up any ambitions for semantically sound documents it's strange that the criticism against table-based layouts prevails.
  - protonfish 7y ago
    After writing XHTML for several years (giving it a full-faith attempt) I never understood the point. You keep repeating "semantically sound" but I can't fathom what that means in your context. I never saw any indication that XHTML brought significant practical semantic information or standardization over what HTML5 can do. It did add significant gratuitous verbosity that made XHTML documents much harder to read and edit.
    - boomlinde 7y ago
      > You keep repeating "semantically sound" but I can't fathom what that means in your context. Documents built on the principle that their structure should relate to the meaning of their content rather than its presentation are what I consider "semantically sound". By negative example, an HTML document filled with div pyramids just to apply layout information, and obtuse class and id names are not what I consider semantically sound. However clumsy it was in practice, XHTML and CSS sought to address this by making the markup extensible and moving style information out of the document. > I never saw any indication that XHTML brought significant practical semantic information or standardization over what HTML5 can do. Obviously HTML5 had the advantage of hindsight and the perspective to learn from some of the mistakes of XHTML while adopting some of its more useful qualities. I should also note that I'm discussing the point of XHTML, not trying to tell anyone that it was particularly successful to that end. Don't confuse the two.
- sureaboutthis 7y ago
  > didn't support the most popular layout method at the time, tables Tables were NEVER a layout method and it was only used for that because CSS was deficient at the time.
  - deadbunny 7y ago
    > Tables were NEVER a layout method except for the decade or so they were Okay.
- klez 7y ago
  > These are the same people who created XHTML, an ivory tower idea nobody was waiting for I never understood what people had against XHTML. The more common theme seems to be "XML... eww" and nothing else. Can anybody help me understand?
  - ChrisSD 7y ago
    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.
    - sureaboutthis 7y ago
      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.
      - gsnedders 7y ago
        > 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. In most cases, if your code has some syntax error, the author of the code sees the syntax error; in the web case, if your code has some syntax error, the user sees the syntax error. That's the dramatic difference. The other reality is unlike program code, there's vastly more often user content intermixed in (X)HTML and it's rare for people to implement sanitisation correctly (do you handle U+0000? U+FFFF? U+1FFFF? most people outputting XHTML historically haven't, even if they get the security critical stuff (like "<") right).
        sureaboutthis 7y ago
- bmn__ 7y ago
  > who didn't support the most popular layout method at the time, tables, in their new styling language CSS. That's quite a misunderstanding of the past. Your proposition is only technically correct: CSS1 (Dec 1996) did not have table display properties, but they were added in CSS2 (Mar 1998). They were available early enough to matter. The reason why many Web authors did not design with these properties is not the fault of the W3C, but rather because of the typical Microsoft sabotage. In the early 2000s, I personally did not give a shit about IE - my standard compliant CSS rendered fine in other popular browsers.
  - antod 7y ago
    Thank you - saved me typing it. CSS support for table display predated XHTML 1.0 by nearly 2 years, and worked in XHTML with non IE browsers.
- fiatjaf 7y ago
  Exactly. And the same people who keep producing tons and tons of specs no one uses -- and even if anyone wants to use they're so complex it doesn't make any sense. RDF, JSON-LD, "semantic web", piles and piles of garbage. And all written by the same group of 10 people who have never written a web app by themselves.
- jasonhansel 7y ago
  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.
_bxg1 7y ago
It is a sad day, but for a long time now W3C has been a figurehead and nothing more. It was like Japan's modern-day emperor. It carried no weight to actually contradict the WHATWG's version of things. So it's simply acknowledging that fact.

cotelletta 7y ago

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 seamless iframe proposal. I had to point out that the two biggest uses of iframes at the time, i.e. Twitter embeds and Facebook apps, could not make use of it, despite being a perfect fit. They just hadn't considered that.

zmix 7y ago
> who didn't support the most popular layout method at the time, tables I can do tables just fine in XHTML. And luckily, tables have become redundant as layout technique, since CSS would do that, already then. The nice thing with X(HT)ML is, that you can place queries against any document, natively.
- cotelletta 7y ago
  Did you miss the 5-10 years during which every CSS designer tortured themselves replicating tables with floats? Google 'pure css page footer' to see the wreckage. CSS tables took years to be supported, and even then, only brought back what people had been irrationally told to stay away from. It took another 5 years for flex box to become usable, adding something actually new. To this day, changing a site's entire design without touching its markup is a mirage. It only works in contrived scenarios with extremely artificial restrictions, and nobody does it in the real world. CSS Zen Garden was demoscene.
  - cygx 7y ago
    Personally, I was fine with ditching tables, but stuff like differing box models, unequal CSS support, quirks modes, etc did make for a rather painful cross-browser development experience: Making things work out correctly (or at least gracefully degrade) in multipe IE versions, Mozilla, Opera, ... could be a challenge.
  - pbhjpbhj 7y ago
    Tabular markup for non-tabulated data is not rational & semantic markup is certainly not irrational. You don't come from print design by any chance? With flexbox, for example, you can change order of appearance contrary to the code order in the markup. It's not a mirage. Anyone who's used a browser's reader mode, or distilled view (as Brave calls it), knows the usefulness of applying different styles to a fixed markup. Separation of presentation is possible. Indeed now we've moved to responsive design and the number of devices and UA has exploded the separation of design and data is coming in to its own -- but instead pixel-perfection is still being chased with a billion @media declarations.
    - cygx 7y ago
      You don't come from print design by any chance? You've not been doing that whole web design thing for very long, by any chance? Those of us who have been around for a while do remember the inadequate layouting capabilities of CSS of bygone eras. While I was on the semantic markup side of the debate at the time, it's not as if the pragmatists that just went with the table for convenience's sake did so for no reason at all...
      - pbhjpbhj 7y ago
        I started web design for lynx browser, back when using pine for email was hot, then moved on to Mosaic and NN. There's a clear body of web design/dev people that think it's just a visual display medium, and a lot of those seem to come from print design. The web for me has always been primarily a medium for information transfer, visual design is nice but not at the expense of semantic markup; table markup for visual layout is entirely unnecessary (and was terrible for accessibility). People went with table layout because marketing people demanded pixel matched presentation and/or they didn't care to make sure their content was machine readable. The same views lead to IE only and give us websites that don't bother with semantic blocks now, or that don't work without JavaScript when that js is just being used for presentational flair.
- geezerjay 7y ago
  > And luckily, tables have become redundant as layout technique, since CSS would do that, already then. It took well over a decade to get CSS to play nicely with layouts. It's disingenuous to present CSS as the obvious solution to a problem while criticising table usage to implement grid layouts, as this line of argument entirely ignores the recent history of the web.
austincheney 7y ago
? Tables for layout? Seriously? Foolishness aside it is important to understand the DOM came out of work from the XML Schema spec and for many years updates to those two documents were always released together. The W3C isn’t irrelevant as there is more to the web than just HTML just like Oasis isn’t irrelevant for schematic design and business integration. This talk of irrelevance is a hard argument to make for many frontend developers who cant tell the difference between the standard DOM and Reacts VDOM.
- maeln 7y ago
  Yes tables. There is a reason why people where abusing table for layout even though all hated it. In the end, we finally have CSS grid now ( https://css-tricks.com/snippets/css/complete-guide-grid https://css-tricks.com/snippets/css/complete-guide-grid ) which do what we were trying to achieve back in the day with tables. We had to wait until 2016 to have a type of layout which is considered standard in most GUI toolkit ...
  - ChrisSD 7y ago
    `display: table` has been around since around 2001/02, for exactly that reason. However IE didn't support it until IE8.
    - cygx 7y ago
      However IE didn't support it until IE8. Which got released in 2009, but took another year to overtake IE6+7 in market share. This means `display:table` was of limited usefulness for nearly a decade after its introduction...
      - ChrisSD 7y ago
        Sure but that's a different issue. It's not the fault of the standard if a major browser doesn't implement it. In practice I was using display table in some designs in the mid 00's but also using conditional stylesheets to hack an IE layout. This was not a particularly good solution but it "worked".
baybal2 7y ago
> seamless iframe proposal. DOM v3 Document.load() https://www.w3.org/TR/DOM-Level-3-LS/load-save.html https://www.w3.org/TR/DOM-Level-3-LS/load-save.html was the candidate for client side document loading long before most people even knew what W3C is
- robocat 7y ago
  Perhaps that is a great example of why the W3C failed?
- robocat 7y ago
  From what I can see, your example of "DOM v3 Document.load()" is a great example of why the W3C failed to convince browsers to implement their proposals. That spec seems to be mostly related to Java and it seems to me that it hardly considers how ECMAScript could use it i.e. someone had an idea, but couldn't translate that into a useful feature...
boomlinde 7y ago
> 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 concerns. So maybe if you authored XHTML documents that was already an important consideration to you. On a side note, now that the web development industry seems to have collectively given up any ambitions for semantically sound documents it's strange that the criticism against table-based layouts prevails.
- protonfish 7y ago
  After writing XHTML for several years (giving it a full-faith attempt) I never understood the point. You keep repeating "semantically sound" but I can't fathom what that means in your context. I never saw any indication that XHTML brought significant practical semantic information or standardization over what HTML5 can do. It did add significant gratuitous verbosity that made XHTML documents much harder to read and edit.
  - boomlinde 7y ago
    > You keep repeating "semantically sound" but I can't fathom what that means in your context. Documents built on the principle that their structure should relate to the meaning of their content rather than its presentation are what I consider "semantically sound". By negative example, an HTML document filled with div pyramids just to apply layout information, and obtuse class and id names are not what I consider semantically sound. However clumsy it was in practice, XHTML and CSS sought to address this by making the markup extensible and moving style information out of the document. > I never saw any indication that XHTML brought significant practical semantic information or standardization over what HTML5 can do. Obviously HTML5 had the advantage of hindsight and the perspective to learn from some of the mistakes of XHTML while adopting some of its more useful qualities. I should also note that I'm discussing the point of XHTML, not trying to tell anyone that it was particularly successful to that end. Don't confuse the two.
sureaboutthis 7y ago
> didn't support the most popular layout method at the time, tables Tables were NEVER a layout method and it was only used for that because CSS was deficient at the time.
- deadbunny 7y ago
  > Tables were NEVER a layout method except for the decade or so they were Okay.
klez 7y ago
> These are the same people who created XHTML, an ivory tower idea nobody was waiting for I never understood what people had against XHTML. The more common theme seems to be "XML... eww" and nothing else. Can anybody help me understand?
- ChrisSD 7y ago
  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.
  - sureaboutthis 7y ago
    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.
    - gsnedders 7y ago
      > 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. In most cases, if your code has some syntax error, the author of the code sees the syntax error; in the web case, if your code has some syntax error, the user sees the syntax error. That's the dramatic difference. The other reality is unlike program code, there's vastly more often user content intermixed in (X)HTML and it's rare for people to implement sanitisation correctly (do you handle U+0000? U+FFFF? U+1FFFF? most people outputting XHTML historically haven't, even if they get the security critical stuff (like "<") right).
      - sureaboutthis 7y ago
bmn__ 7y ago
> who didn't support the most popular layout method at the time, tables, in their new styling language CSS. That's quite a misunderstanding of the past. Your proposition is only technically correct: CSS1 (Dec 1996) did not have table display properties, but they were added in CSS2 (Mar 1998). They were available early enough to matter. The reason why many Web authors did not design with these properties is not the fault of the W3C, but rather because of the typical Microsoft sabotage. In the early 2000s, I personally did not give a shit about IE - my standard compliant CSS rendered fine in other popular browsers.
- antod 7y ago
  Thank you - saved me typing it. CSS support for table display predated XHTML 1.0 by nearly 2 years, and worked in XHTML with non IE browsers.
fiatjaf 7y ago
Exactly. And the same people who keep producing tons and tons of specs no one uses -- and even if anyone wants to use they're so complex it doesn't make any sense. RDF, JSON-LD, "semantic web", piles and piles of garbage. And all written by the same group of 10 people who have never written a web app by themselves.
jasonhansel 7y ago
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.

_bxg1 7y ago

It is a sad day, but for a long time now W3C has been a figurehead and nothing more. It was like Japan's modern-day emperor. It carried no weight to actually contradict the WHATWG's version of things. So it's simply acknowledging that fact.