6 ms·

> 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, tabl

> 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.
  - eridius 7y ago
    One of the interesting things you could do with XHTML was ditch the HTML entirely and write an XML document expressing the semantic content, and then couple that with an XSLT stylesheet to convert it into XHTML for display. This way the exact same resource could be read by machines to get the semantic content, and then read by browsers and transformed into the display content. I'm not sure if anyone ever actually used this seriously though. Definitely very "ivory tower" design. But in the abstract it's a cool idea.
    - spiralx 7y ago
      I wrote an XSLT stylesheet that could turn an XHTML document into a display of its own source, complete with indenting, code folding and syntax highlighting. I was quite pleased with that :) When I worked at the BMJ all of our content was stored as XML and rendered to the browser using XSLT, although this was done on the back-end and the resulting XHTML embedded in our various Spring applications. This sort of thing is probably the most common use of XHTML today...
dragonwriter 7y ago
> 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 That was a major focus of HTML5, as well, which was more successful at enabling that (arguably, it was more of the focus of HTML5, Which didn't try to impose major syntactic change as well, even though it also supported an XML form.) > On a side note, now that the web development industry seems to have collectively given up any ambitions for semantically sound documents Semantic soundness in the strict sense has always been something of a niche concern, not something hat was a general web dev industy goal and then abandoned. > it's strange that the criticism against table-based layouts prevails. Table-based layout remains an accessibility problem, which is a more practical issue than abstract concern for semantic soundness (though related).
- boomlinde 7y ago
  > That was a major focus of HTML5, as well, which was more successful at enabling that (arguably, it was more of the focus of HTML5, Which didn't try to impose major syntactic change as well, even though it also supported an XML form.) I agree. Don't confuse my interpretation of the point of XHTML with some sort of endorsement. For the record, I think XHTML is an unnecessarily complex standard that results in more work for little added value. I do recognize, though, that the point of XHTML is unrelated to its success to that end. Comparing HTML5 to XHTML is also a bit of a no-brainer. There are 14 years between their introductions, and HTML5 obviously had a history of lessons learned from XHTML to take into account. > Semantic soundness in the strict sense has always been something of a niche concern, not something hat was a general web dev industy goal and then abandoned. What is the strict sense of semantic soundness? I'd agree that few people care about semantic soundness even in a general sense. I frequently see documents where the presentation seems prioritized over content. But the ambition did exist at some point, and was more of a mainstream concern in, say, 2005 than it seems to be now, and the idea of a more semantic web was peddled by big names like Tim Berners-Lee. > Table-based layout remains an accessibility problem, which is a more practical issue than abstract concern for semantic soundness (though related). I'd say that they are strictly related. You improve accessibility primarily by improving the semantic representation of documents. I don't see semantic soundness as an "abstract concern" for this reason. The most useful screen readers unfortunately seem to rely on some level of guesswork to make verbal sense of documents that rely on spatiality to communicate element relationships.
amyjess 7y ago
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 both transitional and strict forms. The real problem is that HTML is a massive pain in the ass to parse. You can close tags out of order, some tags can't even be closed (<hr>), some tags can optionally be closed (<p>), nothing is case-sensitive, and because of how flexible SGML is, you need a DTD to properly parse any SGML implementation (fun fact: SGML allows for a bunch of different markup styles, but the HTML DTD explicitly disallows most of them). XHTML sought to eliminate all that by mapping HTML onto XML, which was much easier to parse.
- boomlinde 7y ago
  > 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.
- spiralx 7y ago
  Could you have unquoted attributes in transitional?
  - amyjess 7y ago
    Ah, I just checked, and no you can't. So I guess that's a third difference. Thanks for the correction! Another correction I noticed when looking that up: I meant to say XHTML 1.0 Transitional, not 1.1. 1.1 was Strict-only.
    - 7y ago
goto11 7y ago
XHTML documents have exactly the same semantics as HTML. Neither is more semantically sound than the other. XHTML just defined a slightly different syntax which was XML compatible. This was useful if you were using XML tools, but it didn't affect semantics at all.
- WorldMaker 7y ago
  XHTML 2.0 was very different from HTML semantically. Some of its tags (ARTICLE, SECTION, MENU, etc) wound up smashed into HTML5 later and became semantically meaningless again, but XHTML 2.0 tried to be more semantically sound than HTML and is a large part of how W3C lost the war to HTML5, because semantics are hard and most of the browsers didn't care about semantics.
  - goto11 7y ago
    Why to you consider the XHTML 2.0 elements more "semantically sound" than the equivalent HTML5 elements?
    - WorldMaker 7y ago
      A reason XHTML 2.0 got so bogged down in committee and never actually finished a standard was that the attempt was made to define semantically what an ARTICLE would be, how SECTIONS work, what things a browser or semantic web crawler could infer/summarize build from such things. For instance, one group of the committee argued you couldn't have SECTIONs outside of an ARTICLE; that an ARTICLE consisted of zero or more SECTIONs (and maybe SECTIONs could be nested inside of each other). Folks argued for SECTIONs to have concepts of names that could be listed in auto-generated Tables of Contents. HTML5 mostly just defines ARTICLE and SECTION as optional block-level content elements, with no other real importance. This leaves them as merely fancier synonyms for DIV. Semantics is almost entirely left to ARIA, and while HTML5 has come back around to ARTICLE tag should imply, for instance, ARIA role="article", there's still a bunch of interesting reasons that people concerned with ARIA semantics continue to write "redundant" things like <ARTICLE aria-role="article"...

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.
- eridius 7y ago
  One of the interesting things you could do with XHTML was ditch the HTML entirely and write an XML document expressing the semantic content, and then couple that with an XSLT stylesheet to convert it into XHTML for display. This way the exact same resource could be read by machines to get the semantic content, and then read by browsers and transformed into the display content. I'm not sure if anyone ever actually used this seriously though. Definitely very "ivory tower" design. But in the abstract it's a cool idea.
  - spiralx 7y ago
    I wrote an XSLT stylesheet that could turn an XHTML document into a display of its own source, complete with indenting, code folding and syntax highlighting. I was quite pleased with that :) When I worked at the BMJ all of our content was stored as XML and rendered to the browser using XSLT, although this was done on the back-end and the resulting XHTML embedded in our various Spring applications. This sort of thing is probably the most common use of XHTML today...

dragonwriter 7y ago

> 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 That was a major focus of HTML5, as well, which was more successful at enabling that (arguably, it was more of the focus of HTML5, Which didn't try to impose major syntactic change as well, even though it also supported an XML form.) > On a side note, now that the web development industry seems to have collectively given up any ambitions for semantically sound documents Semantic soundness in the strict sense has always been something of a niche concern, not something hat was a general web dev industy goal and then abandoned. > it's strange that the criticism against table-based layouts prevails. Table-based layout remains an accessibility problem, which is a more practical issue than abstract concern for semantic soundness (though related).

boomlinde 7y ago
> That was a major focus of HTML5, as well, which was more successful at enabling that (arguably, it was more of the focus of HTML5, Which didn't try to impose major syntactic change as well, even though it also supported an XML form.) I agree. Don't confuse my interpretation of the point of XHTML with some sort of endorsement. For the record, I think XHTML is an unnecessarily complex standard that results in more work for little added value. I do recognize, though, that the point of XHTML is unrelated to its success to that end. Comparing HTML5 to XHTML is also a bit of a no-brainer. There are 14 years between their introductions, and HTML5 obviously had a history of lessons learned from XHTML to take into account. > Semantic soundness in the strict sense has always been something of a niche concern, not something hat was a general web dev industy goal and then abandoned. What is the strict sense of semantic soundness? I'd agree that few people care about semantic soundness even in a general sense. I frequently see documents where the presentation seems prioritized over content. But the ambition did exist at some point, and was more of a mainstream concern in, say, 2005 than it seems to be now, and the idea of a more semantic web was peddled by big names like Tim Berners-Lee. > Table-based layout remains an accessibility problem, which is a more practical issue than abstract concern for semantic soundness (though related). I'd say that they are strictly related. You improve accessibility primarily by improving the semantic representation of documents. I don't see semantic soundness as an "abstract concern" for this reason. The most useful screen readers unfortunately seem to rely on some level of guesswork to make verbal sense of documents that rely on spatiality to communicate element relationships.

amyjess 7y ago

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 both transitional and strict forms. The real problem is that HTML is a massive pain in the ass to parse. You can close tags out of order, some tags can't even be closed (<hr>), some tags can optionally be closed (<p>), nothing is case-sensitive, and because of how flexible SGML is, you need a DTD to properly parse any SGML implementation (fun fact: SGML allows for a bunch of different markup styles, but the HTML DTD explicitly disallows most of them). XHTML sought to eliminate all that by mapping HTML onto XML, which was much easier to parse.

boomlinde 7y ago
> 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.
spiralx 7y ago
Could you have unquoted attributes in transitional?
- amyjess 7y ago
  Ah, I just checked, and no you can't. So I guess that's a third difference. Thanks for the correction! Another correction I noticed when looking that up: I meant to say XHTML 1.0 Transitional, not 1.1. 1.1 was Strict-only.
  - 7y ago

goto11 7y ago

XHTML documents have exactly the same semantics as HTML. Neither is more semantically sound than the other. XHTML just defined a slightly different syntax which was XML compatible. This was useful if you were using XML tools, but it didn't affect semantics at all.

WorldMaker 7y ago
XHTML 2.0 was very different from HTML semantically. Some of its tags (ARTICLE, SECTION, MENU, etc) wound up smashed into HTML5 later and became semantically meaningless again, but XHTML 2.0 tried to be more semantically sound than HTML and is a large part of how W3C lost the war to HTML5, because semantics are hard and most of the browsers didn't care about semantics.
- goto11 7y ago
  Why to you consider the XHTML 2.0 elements more "semantically sound" than the equivalent HTML5 elements?
  - WorldMaker 7y ago
    A reason XHTML 2.0 got so bogged down in committee and never actually finished a standard was that the attempt was made to define semantically what an ARTICLE would be, how SECTIONS work, what things a browser or semantic web crawler could infer/summarize build from such things. For instance, one group of the committee argued you couldn't have SECTIONs outside of an ARTICLE; that an ARTICLE consisted of zero or more SECTIONs (and maybe SECTIONs could be nested inside of each other). Folks argued for SECTIONs to have concepts of names that could be listed in auto-generated Tables of Contents. HTML5 mostly just defines ARTICLE and SECTION as optional block-level content elements, with no other real importance. This leaves them as merely fancier synonyms for DIV. Semantics is almost entirely left to ARIA, and while HTML5 has come back around to ARTICLE tag should imply, for instance, ARIA role="article", there's still a bunch of interesting reasons that people concerned with ARIA semantics continue to write "redundant" things like <ARTICLE aria-role="article"...