[whatwg] Attributes vs. Elements

[carmen]

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