W3C home > Mailing lists > Public > public-html-comments@w3.org > August 2008

Suggested additions: global href and semantic attributes

From: Eduard Pascual <herenvardo@gmail.com>
Date: Sun, 24 Aug 2008 20:05:45 +0100
Message-ID: <6ea53250808241205u522d709y2ee81b90c37246c6@mail.gmail.com>
To: public-html-comments@w3.org

Global href (and related) attributes:
The restriction of which elements can be hyperlinks in a document is
an inherited limitation from earlier versions which has no reason to
be kept.
On the practical sense, content authors may end up saving lots of
typing when converting common idioms like <li><a
href="/">home</a></li> into cleaner <li href="/">home</li>, or <a
href="pict.jpg"><img src="thumbnail.jpg"></a> into <img
src="thumbnail.jpg" href="pict.jpg">. But beyond that, from a
conceptual point of view, these idioms are describing a wrong
structure due to the shortcommings of the markup language: on the
first example, the link is described as the content of the list item,
but the author intention is normally to define the link as the item
itself; on the second example, the relationship is reversed, having
the image being represented as the content of the link but the image
is itended to be the link.
Obviously, elements that get a href attribute don't get their context
or content model altered at all (ie: giving the href attribute doesn't
grant it the flexible content model of an <a> element); and the <a>
element is still appropriate for those links whose context is (mainly)
text, or a region of the document that is not represented by one of
the elements on it (although a <span> could be used in many cases,
it's worth to keep the <a> with its extra flexibility).
>From the browser perspective, while this might not work on current
browsers, it shouldn't be hard to implement in new versions, and the
appropriate behavior can be easily emulated via scripting if legacy
browsers need to be supported, as long as the the attributes are
exposed to scripts.


A role/purpose/meaning or similar semantics anotative attribute
I'm not sure if the folks on the XHTML2 group had this (subtle) idea
in mind when they added it to their spec, but IMHO the best conceptual
benefit this would provide, rather than allowing to **add** semantics
to a document, would be to allow **separating** these semantics from
the structure. This has the basic practical benefit that the structure
won't need to be forced to achieve semantics. For example (the use of
"role" in these examples is just for the examples' sake, there might
be a more appropriate name for such attribute), it is perfectly
possible to have a short paragraph that deserves to be an aside, but
doesn't deserve to define its own section (or sub-section), which
could be marked up as <p role="aside">. Another example would be a
secondary navigation (maybe a list of vaguely related external
references) which could be marked with something like <ul role="aside
navigation">.
Furthermore, this would allow cleaning up the content model at several
levels: <nav> and <aside> could be replaced with something like
<whatever role="navigation"> and <whatever role="aside"> (having to
deal with only <section> as a sectioning element would, in addition,
give UAs a better time when figuring out the structure of the
document; especially if we notice the subtle "overlap-prevention" this
feature provides: compare <aside><nav></aside></nav> vs. <section
role="aside"><section role="navigation></section></section>). And yet
one more example: <dl> could become a "double list", so the <dialog>
would go away, and we'd have <dt role="definition"> or <dt
role="glosary"> and <dt role="dialog">... but suddenly we open the
door to many interesting usages, such as <figure><dl
role="score"><dt>Player 1</dt><dd>150</dd><dt>Player
2</dt><dd>165</dd></dl><legend>Player 2 wins!</legend><figure> or <dl
role="armament"><dt>Left wing</dt><dd>Laser</dd><dd>Chicken
launcher</dd><dt>Right wing</dt><dd>Laser</dd><dd>Shrink
Ray</dd></dl>.
To top it up, this would also provide a solution to the issue I posted
under the subject "The Web, the Noob, and the Soup": when using markup
like <span role="ship name"> or <span role="keyword"> there is no room
for the "presentational temptation" the <i> or <b> tags would provoke.

I won't say whether binding this attribute to RDF, like the XHTML2
group did, is a good idea or not because, simply put, I don't really
know what RDF is (I have read some of the specs about it and the only
things I've been able to figure out from there is that it has to do
with semantics, and with an abstract syntax). Honestly, I think that a
list of values included in the specification (like is being done with
the links' rel attribute) or an extensible open list on the wiki (as
done with the meta's name) could be good approaches to this.
In summary, my main point is that I really feel that separating
semantics from structure would be as good as it was to separate
presentation from semantics/structure in the first place.


Regards,
Eduard Pascual,
Software and Web developer
Received on Sunday, 24 August 2008 19:06:26 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Wednesday, 1 June 2011 00:13:59 GMT