Re: Is not better using role="copyright" or <link rel="copyright"> element?

Hi Rene,

> Exactly. Completely agree. I do prefere role attribute over
> predefined classnames (this should be pretty clear from one of
> my recently sent message [1]).
>
> But my question was: Why, in the particular case of copyright,
> would you prefere a role attribute instead of a new element
> <copyright>?

The problem is that anyone could say the same thing for their favoured element.

In the discussions about XHTML 2 the same issue reared its head time
and again. People would propose adding new elements that met some
requirement from their own particular sphere of interest, and then
others from a different sphere of interest would say 'that element is
unnecessary...but this element is crucial'. :) Worse, we'd sometimes
find that the same word being proposed for a new element had different
meanings in different contexts. So in the end we decided that we had
to take a different approach.

We took the view that given that the standards process is so slow (by
its nature), and given that different interest groups would always be
wanting to add their own terms and vocabularies, why not concentrate
on the extension mechanism, rather than the extensions themselves? In
other words, once we had ensured that XHTML 2 provided the necessary
structural constructs (paragraphs, sections, headings, separators and
so on), we then spent the rest of the time ensuring that we had
sufficient mechanisms to give those constructs semantics.

Now, when we talk about semantics, there is a subtlty that is often
missed, which is that sometimes you want to add semantics about a
document's structure, and sometimes you want to add semantics about
the _content_ of the document. For example, you might want to indicate
that some area of a document is the primary navigation area, or the
footer, or a sidebar, etc. But you might also want to indicate that
some content is FOAF data, or RSS information, or Dublin Core, or an
iCal event, etc. In XHTML 2 the former requirement is largely met by
@role, whilst the latter is met by RDFa.



@ROLE

XHTML 2 includes some predefined @role values, so we can say:

  <div role="main">
    ...
  </div>

and a voice browser could hop straight to the main content. Or we could say:

  <div role="navigation">
    ...
  </div>

and a browser could render the navigation area in a separate panel
that can be controlled independently of the main conten.

And since values in @role can be namespace qualified, groups can
create their own taxonomies. For example, the mobile industry might
have a set of values that a news organisation will add to its news, so
that the phone companies know what they can strip out when sending
information to a small screen.

  <div role="xyz:summary">
    ...
  </div>

(This is not a contrived example; most mobile operators have their own
'languages' that extend HTML, which they require organisations to use
when marking up their news for consumption on mobile portals.
Unfortunately, this makes their content 'non-standard'.)



RDFa

RDFa is much more to do with the content, allowing you to say things
about the relationships between 'this' document and some other one, or
to qualify items in the document.



LICENSE EXAMPLE

Returning therefore to the copyright example, I would say that there
are two things that might need to be marked up. The first is that you
might have an external license that your document is linked to; this
relationship should be established using @rel="license". This gives
the connection some semantics, and the connection can also be
processed 'by machines'. To mark this up you could put it in the head
of the document:

  <head>
    <link rel="license" href="http://creativecommons.org/licenses/by/2.5/" />
  </head>

or you could put it inline:

  <a rel="license"
href="http://creativecommons.org/licenses/by/2.5/">Attribution</a>

We now have something that search engines could process, and it could
even be used by browsers, in some special way. (Some browsers, like
Opera, will show 'special' links like 'next' and 'previous' in an area
above the main document.)

The second thing you might want to mark up is the actual area that
contains the licensing information. This could use @role, and as with
the mobile phone examples mentioned earlier, having a 'marker' to
indicate the purpose of some mark-up would allow the area to be
processed differently. For example, on a mobile device, an area might
be removed from a page, but made available via an additional
navigation request by the user.

Putting all of this together, we might have something like this:

  <div role="contentinfo">
    Licensed under Creative Commons
    <a rel="license"
href="http://creativecommons.org/licenses/by/2.5/">Attribution</a>
  </div>

or this:

  Thanks for visiting my page. Feel free to use anything you find here, since it
  is licensed under
  <span role="contentinfo">
    <a rel="license" href="http://creativecommons.org/licenses/by/2.5/">
      Creative Commons Attribution
    </a>
  </span>.

or this:

  <ul role="contentinfo">
    <li>Written by Mark Birbeck</li>
    <li>
      Licensed under
      <a rel="license" href="http://creativecommons.org/licenses/by/2.5/">
        Creative Commons Attribution
      </a>
    </li>
  </ul>

In other words, the semantics of the _purpose_ of the element (in this
case, that it contains 'content information') is distinct from the
semantics of an element's _structure_ (a paragraph, an unordered list,
etc.)



HOOKS RATHER THAN NEW ELEMENTS

So my main point is that _in general_ it is better to add semantic
'hooks' rather than trying to keep adding new elements. Of course
there is no point in being religious about this, and when taken
individually you can always argue that some particular element 'x'
should be added to one or more of the HTML family of languages. And
since this is to some extent an art, you can also convincingly argue
that the list of 'structural' elements (like div, span and ul) should
be extended to include the 'strutcural' element 'copyright'.

But once you start to look at the 'big picture' and take on board the
many requirements of the many communities that use HTML and co. for
many different things, the case for each new element becomes less and
less convincing. And so, at some point we have to accept that adding
sufficient new elements to satisfy everyone is never going to happen,
and at that point the extension mechanism starts to become more
important than the actual extensions.



BEYOND XHTML 2

Note that both @role and RDFa have been created as separate modules
that are independent of XHTML 2, and support for @role can be found in
recent versions of Firefox as an accessibility hook.

The @role attribute is defined here (which includes a DTD):

  <http://www.w3.org/TR/xhtml-role/>

I blogged about 'Using the role attribute to extend XHTML' here:

  <http://internet-apps.blogspot.com/2006/08/using-role-attribute-to-extend-xhtml.html>

I also wrote on the @role spec itself, in 'The XHTML role attribute:
small and perfectly formed':

  <http://internet-apps.blogspot.com/2006/07/xhtml-role-attribute-small-and.html>


A draft of the RDFa modules is here:

  <http://www.w3.org/MarkUp/2007/ED-xhtml-rdfa-20070405/>

Links to other specs (syntax, use cases and primer), example mark-up
and demos, and code for processing RDFa both in the browser and on the
server, are all available from the RDFa communit site:

  <http://rdfa.info/>



CONCLUSION

It seems to me that regardless of whether HTML 5 adds new elements or
not, it should at least support the extension hooks for @role and
RDFa.

Regards,

Mark

-- 
  Mark Birbeck, formsPlayer

  mark.birbeck@x-port.net | +44 (0) 20 7689 9232
  http://www.formsPlayer.com | http://internet-apps.blogspot.com

  standards. innovation.

Received on Monday, 7 May 2007 11:59:11 UTC