> Finally, I'd like to conclude with this reductio ad absurdum of the XHTML2
> approach. If assigning behavior and semantics to attributes is so much
> better, why not just have a single <elt> element:
>
> <elt role="paragraph">My cat is really cute: <elt src="mycat.jpeg">picture of
> my cat</elt>. Check out <elt href="story.html">this <elt
> role="emphasis">hilarious</elt> story about her</elt>.</elt>
this is a valid approach. the next step is to factor out <elt> and simplify the
syntax, preferably reusing JSON or the Relax-NG compact syntax. then it would
be more readable than either suggestion here.
i also think its important that userdefined elements can inherit from other
elements via the normal ECMAscript prototype idioms, so that one can eg,
<time>.property("dc:date").prototype = <span>, we'll always have semantic
ambiguity and shoehorning of semantics into classnames and other attributes
until theres the equivalent of the stylesheet providing referencable URIs
describing any element - unless we want to stick to the boring world where
theres only the elements that enough people could agree upon.
styling all the 'time' elements in the stylesheet is cake.. easier than
deconstructing a microformat, or having to resort to crazy attribute matching
xpath/regex..
fwiw, ive started doing this using HPricot serverside and JQuery clientside
since i found microformats too limiting and both them and RDFa too verbose
(they use attributes quite a bit instead of elements), i started writing
webpages in pico and will do what it takes for that to continue in the day and
age where i want semantic disambiguity/lossless-encoding for the elements.
> I find the HTML approach much more readable and more semantically clear:
>
> <p>My cat is really cute: <img src="mycat.jpg" alt="picture of my cat">.
> Check out <a href="story.html">this <em>hilarious</em> story about
> her</a>.</p>
>
> Regards,
> Maciej
>
