Tantek lives in the real world. He has essentially defined XHTML to imply text/html in the beginning of his slides. Unfortunately I can not point directly to any of his slides, which would be my point of critic. I have some other bits as well. He probably wants to style the ins and del elements with display:block before making them inline as that is the default style in most browsers (display:inline is). He might also want to style them differently after that. There are some problems in browsers with regard to propagation of text-decoration.
The table example he is using is confusing. He should at least add the tbody element so scripters will not have any problems. In browsers parsing text/html tables will always result in having a tbody element node. The element is implicitly there, just the start and end tags are missing. (The same happens with a lot of my current source code by the way. That is why I can style the body element for example.)
His conversation piece is kind of valid though the HTML 4.01 specification states that they can also be used for conversations. Perhaps it should get an errata. Fortunately Ian and Tantek agree on this on so it is consistently defined in HTML 5. Great. The rest seemed ok to me, anyone else any nitpicks?
I don't see why he replaces the P element for a DIV in the example for the ADDRESS element (frame #8).
I don't see why he replaces the
Pelement for aDIVin the example for theADDRESSelement (frame #8).
Because P cannot contain ADDRESS.
The table example he is using is confusing. He should at least add the tbody element so scripters will not have any problems. In browsers parsing text/html tables will always result in having a tbody element node. The element is implicitly there, just the start and end tags are missing. (The same happens with a lot of my current source code by the way. That is why I can style the body element for example.)
It is because of the SGML Declaration (OMITTAG YES). This isn't the case for XHTML.
It is the case for the kind of XHTML Tantek is describing and all the XHTML found on the web. It is also a relevant issue is when people switch to a real XML MIME type it will break their sites. There you go with being forward compatible and all that.
http://tantek.com/presentations/2005/09/elements-of-xhtml/#slide3
The link above can link to the slide 3 directly. Hope help.
It is the case for the kind of XHTML Tantek is describing and all the XHTML found on the web. It is also a relevant issue is when people switch to a real XML MIME type it will break their sites. There you go with being forward compatible and all that.
You're right, with the text/html Media Type XHTML is treated like invalid HTML.
Tantek takes the following example...
<p>
Please contact
webmaster at example dot com
if you have any problems with this site.
</p>...and transforms it into this:
<div>
Please contact
<address class="email">webmaster at example dot com</address>
if you have any problems with this site.
</div>I disagree with this markup. For one, <div> is less semantic than <p>. Also, the example for <address> is being used inline when it's a block element. I would suggest that, based on the example in the HTML 4.01 spec, the entire paragraph should be converted into an <address> and the specific email address should receive additional markup/semantics:
<address>
Please contact
<a href="../People/Webmaster/">webmaster at example dot com</a>
if you have any problems with this site.
</address>Some good reading here. I would have to agree to Matthew Raymonds comment on the usage of the address-element. Using it inline with a div-element appears a bit odd to me.
I really think it should be:
<address>Please contact
webmaster at example dot com
if you find any problems with this site.</address>The address problem is a good example of the difference between structural semantics like headers and paragraphs, and higher level semantics, and that these two types of semantics are orthogonal.
An address should be marked up like f.e. <p role="address">, or with pre or span.
It's believe questionable if ADDRESS should have been exclusively block-level.
Exactly Robert!
Also, your source is quite amusing Anne... ..I'm loving it, but it does show that... ...the whole 'implied elements' thing is quite rediculous. Tbody can bite my shiny metal ass for instance..
PS. In the name of usability, please, p-l-e-a-s-e make the comment box give p-tags on the house. It's really a pain in the ass.
Basically the slides are fine, except - you mentioned it - the table example, the - your audience mentioned it - address example, which is at least "controversial", and in general, the "suboptimal" formatting.
Besides, there apparently seems to be some curious behaviour visiting the slides with Gecko UAs, since the slides' text color is in almost unreadable grey, unless you go back a slide, when it becomes black. (I neither don't have time nor motivation now to have a closer look at it.)
The suggestion to add explicit <tbody> for a consistent HTML/XHTML DOM is a good one. That's a definite improvement upon the example I gave.
The point about <address> and "block" vs. "inline" elements is an interesting one. I used to think that there was some actual semantic difference between "block" and "inline" elements as defined in HTML4, but I've decided there is insufficient evidence for this at best. If anything, those labels (which have more to do with nesting rules) have very little to do with whether the elements themselves are used with block or inline presentation, except for their default presentation, which is of course meant to be overridden by the author or user with CSS.
And those nesting rules are actually far more hurtful than helpful. For example such distinctions prevent the placement of lists inside paragraphs, which I've seen actual semantic examples of in the "real" (i.e. print) word. In addition such nesting rules force you (as a language designer) to often create two versions of the same element, e.g. <q> and <blockquote>, which is quite silly. Their semantics are the same. Same problem with XHTML2.0 <blockcode> (which I helped come up with while I was on the HTML WG, mea culpa) vs. <code>. This unnecessary duplication of elements bloats the language without any obvious benefit.
Thus I posit the right thing to do is to ignore any preconceived supposedly semantic notions of inline-ness vs. block-ness and simply use elements for their meaning independent of that inline vs. block axis. Hence the inline use of <address>.
N.B. How ironic. When previewing I got the message: "You need to use block level elements in order to post a comment". Yeah, that's what I'm talking about. That's lame. Why is it important to use block level elements in order to post a comment? Who does that benefit if anyone at all?