Re: HREF attribute in elements other than A and LINK

Ivan,

I don't think we should start by anticipating problems that have not
even been raised. If we did that we definitely would never have even
started RDFa, given its rocky ride. :)

Of course, if problems arise we have to discuss them, debate them, and
if they raise important points, we certainly have to look again at
what we're doing. But I'm not with you, that an anchor with
'display:none' is 'good enough', so let's leave it at that.

My point about starting with a 'mental model' is only to suggest that
we look at how something fits with existing HTML, and existing
practice. The idea was simply that if we're happy with the model we
can look at how we explain it to other people. (It's actually how
nearly everything in RDFa has been designed, just not always
explicitly.)

By taking this approach, it means we've not just been throwing in
attributes and giving them a meaning which may not harmonise with
HTML, but instead we've been trying to come up with a design that
builds as much as possible on current attribute meaning.

So in this context--of trying to retain as much consistency as
possible, even when we need something new--I don't think we do
anything terribly radical by allowing @href to appear on elements that
are non-clickable, since it is already used in that way in HTML. And
conversely, I've not found anything that points to the fact that
currently authors see @href as the real substance of navigable links,
rather than 'a'. (And certainly nothing in HTML 5 to indicate that.)

Regards,

Mark

On 17/04/07, Ivan Herman <ivan@w3.org> wrote:
> Mark,
>
> with all due respect: I have the impression that this is a different
> (albeit interesting!) discussion. The issue at hand for me is how to
> achieve acceptance of RDFa in the current HTML 'climate', with the
> current view of HTML. I do not think we can have any influence on the
> 'mental model' on HTML at the moment, if I look at the discussions
> around HTML4 and HTML5. And *that* is what we are up against at the
> moment in terms of acceptance. And hence my general approach: try to get
> something that is most easily swallowable, so to say. Unless it is
> *absolutely necessary* for our goals in RDFa, I would avoid unnecessary
> discussions, and both questions asked by Ben (usage of href everywhere,
> and the usage of meta/link in the body) would lead to those.
>
>
> Ivan
>
> Mark Birbeck wrote:
> >
> > 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
> >>
> >>
> >
> >
>
> --
>
> 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 Tuesday, 17 April 2007 09:57:13 UTC