W3C home > Mailing lists > Public > public-rdf-in-xhtml-tf@w3.org > April 2007

Re: HREF attribute in elements other than A and LINK

From: Mark Birbeck <mark.birbeck@x-port.net>
Date: Tue, 17 Apr 2007 00:35:31 +0100
Message-ID: <640dd5060704161635mefb8e56ydecb45dcd6981928@mail.gmail.com>
To: RDFa <public-rdf-in-xhtml-tf@w3.org>

Hi Ivan,

I think that the reason there was some suggestion that having @href on
an element should immediately mean that it was a 'navigable link', is
because that's what it _seems_ to mean in HTML and that's what it
_definitely_ means in XHTML 2. So based on this, it felt to some that
if we were going to have @hrefs that _weren't_ navigable, we had
somehow introduced an inconsistency.

However, as with all of these things, acceptance is largely based on
creating mental models that everyone feels comfortable with, so the
question is whether we can come up with a 'new' mental model that
describes _both_ the old stuff and the new.

One way to do that would be to say that in HTML, what was going on was
that @href was describing a *relationship* between one document and
another, with @rel/@rev specifying the nature of that relationship.
The presence of either an anchor tag (<a>) or an image map area
(<area>) could further augment the use of that relationship, and allow
the connection to the 'other document' to become _navigable_.

This seems to me a reasonable way of 'interpreting' HTML, although of
course it's not something you'll find in the specification for 4.01.
The argument is simply that, since not all uses of @href result in
navigable links--<link> and <base> both use @href without necessarily
giving navigable links--then we can already say that there is no
reason to assume that allowing @href everywhere would introduce
confusion, were links to be non-navigable.

(And of course the converse is true; there are certain values of @rel
that will use @href in other ways, such as as a URL from which to
retrieve stylesheets, and even as another kind of navigable link that
is outside the main document, such as 'next', 'previous', and so on.
In other words, @href on its own doesn't tell you enough to know how
to handle the URL, merely that there is one.)

So, we can see that it's quite easy to create a model of HTML where
@href has a dual purpose; the first is to be part of a definition of a
relationship with another document, and the second is to define a
'parameter' to some functionality--the URL to navigate to on <a>, the
stylesheet to load with <link>, and so on.

Now...XHTML 2 does of course go further, and say that any element with
@href on is a navigable link. Although that's another 'mental model'
that seems right from a semantic point of view (you don't tend to
write a document that contains 'links', you tend to write documents
that contain paragraphs, headings, sections, notes, etc.), I don't
think that should influence our current discussion.

The reason I say that is that we're trying to build 'mental models'
that both work within the confines of current technology, and allow us
to provide a 'bridge' to the future. As you point out Ivan, current
browsers are already programmed to ignore attributes they don't
understand, so allowing @href everywhere is readily achievable.

And although it's not at all difficult to add code to parsers like
Ben's bookmarklet, that will make all @hrefs clickable, I'm not
convinced that this is the concern of RDFa, and we can leave that
'mental model' for XHTML 2 to sort out when the time comes.

Regards,

Mark


On 16/04/07, Ivan Herman <ivan@w3.org> wrote:
>
>
> Ben Adida wrote:
> > 1) should we define the RDFa module to allow for HREF on any element?
> >
>
> I would like to see strong RDFa use cases for this need.
>
> My trick on my home page was to use
>
> <a href="blabla" rev="..." style="display:none"> </a>
>
> which covered most of my needs:-) It is a bit ugly, but it works... (in
> case one wants to add some RDF links here and there...)
>
> > 2) if so, should we ask XHTML1.1+RDFa-compliant agents to make these
> > elements clickable.
> >
>
> I would not expect that to happen, let us be realistic. In view of the
> current mood around HTML and HTML agents, the maximum we can expect is
> that the HTML group would define a way to add attributes to the current
> HTML elements that would not require any change on the HTML agents' core
> behaviour (ignoring unknown attributes is already part of this
> behaviour, I would expect). Anything more than that will simply not
> happen in the coming years.
>
> On the other hand... you are right that 1) without 2) sounds bad. I
> guess this is an argument against 1), too
>
> > A related issue is whether the XHTML1.1 RDFa module should allow LINK
> > and META inside the body, where XHTML1.1 does not.
> >
>
> Again, from a 'political' point of view, I think it is better not to go
> there. HTML browsers might be much more prepared to accept (and ignore)
> new attributes; I would expect much more push back on a change in the
> content model.
>
> > Let's discuss!
> >
>
> You mean: let the tempest begin!:-)
>
> Ivan
>
> > -Ben
> >
>
> --
>
> Ivan Herman, W3C Semantic Web Activity Lead
> URL: http://www.w3.org/People/Ivan/
> PGP Key: http://www.cwi.nl/%7Eivan/AboutMe/pgpkey.html
> FOAF: http://www.ivan-herman.net/foaf.rdf
>
>


-- 
  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, 16 April 2007 23:35:35 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Tuesday, 8 January 2008 14:15:04 GMT