Re: HREF attribute in elements other than A and LINK

Mark,

You're right, we all come at this problem with pre-conceived ideas about
what is aesthetically pleasing, what is technically correct, and what we
expect the world to accept. I agree with some of your points.

That said, I think there's a key question that you and I probably
disagree on: should the XHTML1.1+RDFa module validate a document with
HREF on a DIV? I think the answer is "no."

One quick point: the above answer does *not* imply that we can't have
REL on other elements. REL on other elements has a clear and important
use: allowing bnodes and layered data, which is crucial for about half
of our use cases. It also has very little downside: there's no hidden
metadata that people might complain about, it's really just about
layering the triples that are already rendered in HTML on the page. So I
don't agree that we should bundle those issues together. I'm pretty sure
Ivan wasn't arguing against REL everywhere.

> In this post I propose taking a 'profile' approach to RDFa, so that we
> don't use valuable features form RDFa when dealing with situations or
> languages that may not be able to support them.

I agree with this, modulo the definition of 'profile'. In other words,
as I said on the call last week, I think RDFa should be a set of
attributes (ABOUT, PROPERTY, REL, REV, CONTENT, DATATYPE) that modify
the *existing* host language. I think of HREF as being part of the host
language. Its original meaning is clickability for HTML. REL and REV,
though they were already defined in the host language, were always about
semantics, almost always invisible to the user.

So, in XHTML1.1, RDFa qualifies HREFs wherever they can be found, i.e. A
and LINK. In XHTML2, RDFa also qualifies HREFs wherever they can be
found, which is everywhere. That's what I would see as a "profile" of RDFa.

I simply see adding HREF on other elements as *not part of the RDFa
scope*. We're messing with the host language!

[...]

> (I do also think it's a shame that in these discussions people always
> assume the worst, i.e., that we can't convince people in a genuine
> discussion that some change is worth making.)

That's not a fair qualification of what's going on. The question is
cost/benefit. There is going to be a cost to this change, and Ivan and I
are particularly worried about the perception cost. But even if the cost
were low, what's the benefit? Given that these HREFs will not be
clickable in today's browsers, what is the use case you want that we
can't easily do some other way? If we're waiting for a browser upgrade,
why not say "you can get a whole lot more features if you do XHTML2! And
then RDFa is vastly more powerful, too!"

I don't see any significant benefit, thus I see a terrible cost/benefit
ratio to this change to XHTML1.1.

[..]

> I haven't yet seen one, other than just a general notion of preventing
> @href on 'extra' elements. So to be more specific, if we have to go
> this route, should @href be prevented from appearing on all additional
> elements only in HTML+RDFa, or in XHTML+RDFa as well? What about RDFa
> more generally?

The proposal is that we define which attributes are the RDFa modifiers.
REL, REV, PROPERTY, CONTENT, DATATYPE. Then we point out host language
attributes that are modified by RDFa attributes: HREF, and to some
degree ID. (Then there are syntactic sugars like CLASS and ROLE.) Then,
we say that RDFa modifiers can be applied anywhere, but we respect the
host language's constraints regarding its existing elements that have
clear uses that are primarily *not* RDFa.

> Also, since the arguments for not allowing @href apply also to @rel
> and @rev, then only allowing @href/@rel/@rev on clickable link
> elements ('a' and 'area') means we lose bnode support, so again, we
> need to decide whether we lose bnode support in RDFa more generally,
> or just in the HTML use of RDFa.

No, I think that's not part of the issue. HREF and REL play very
different roles, as per my partitioning above. As far as the host
language is concerned, placing REL on a DIV is very similar to placing
REL on an anchor. However, Placing HREF on a DIV is *completely*
different than placing HREF on an anchor, from the point of view of the
host language which defines clickability.

[...]

> But then for author usage we say 'this is how RDFa is used in
> HTML...this is how it is used in XHTML 1.x...this is how it is used in
> XHTML 2'. That way, we have the flexibility to deal with the 'social'
> issues that might arise in any community (and they may be different
> again when producing SVG/RDFa), but we still only need one parsing
> model (the one in RDFa-Full).

I think it has to be more than author usage. The spec and validator have
to reflect this. Again, our approach should be to change things
minimally: why add HREF everywhere? That is a *big* change. We can't
make the change and say "well, I don't see a problem," we have to
affirmatively justify it.

> This means, for example, that if we also say that nested meta and link
> are unworkable (or undesirable) in HTML+RDFa, it doesn't make any
> difference to an RDFa parser that is presented with an HTML document,
> since their absence means nothing.

I suppose the parser can be the same no matter what the validator says.
But I think the XHTML1.1+RDFa parser should not allow HREF everywhere.

[...]

> My view remains that we should support @href everywhere, for the
> reasons I've said. But I think we'll lose valuable time if we simply
> polarise the discussion to being for or against that view. Instead we
> need to ensure that whilst the broader discussion continues on the
> authoring and 'social' points, we're also looking at what exactly the
> consequences are (the loss of bnode support, for example) and whether
> such changes should affect RDFa 'as such' or just the use of RDFa with
> HTML. Losing features from RDFa more broadly, just to handle issues
> that are specific to HTML, seems like using a hammer to crack a nut,
> but adopting a 'profile' approach appears to give us a greater degree
> of flexibility.

The argument you're making here is confusing. I don't think anyone was
proposing that we remove HREF from all elements in XHTML2. Just that we
shouldn't use RDFa as a vehicle for changing a fundamental property of
the host language, e.g. that XHTML1.1 should remain essentially XHTML1.1
with modifiers when RDFa is mixed in.

-Ben

Received on Wednesday, 18 April 2007 12:34:28 UTC