[
Lists Home |
Date Index |
Thread Index
]
Tim Bray wrote:
>...
> Dammit, I'm still uncomfortable with moving this information from a
> self-descriptive form in the instance to another resource, and I'm
> uncomfortable with the notion that "font-family" is at a similar
> semantic level to "hyperlink". More thought required. -Tim
It's clearly not the case that "hyperlink" is presentation, because
Google and link checkers need to follow hyperlinks but they don't care
about presentation. Therefore, if we say that CSS is strictly about
presentation/behaviour then clearly CSS is not the right place.
"font-family" and "this is a hyperlink" are not in the same category.
Hacking the font-family in a device-specific manner makes sense.
Claiming something is a link only contextually seems weird. Either it is
an element that asserts a relationship or it isn't.
That all said, CSS is the appropriate place to add the styling
information that does vary in a device- and client-specific manner. In
other words all of the "actuate=" stuff.
On the other hand:
Having the "definition" of link for a vocabulary be described
out-of-line is tried and true and was done long before there was CSS.
HTML's "src" and "href" were declared to be links in the HTML spec. Same
for Docbook's equivalents. The problem is that discovering these link
specifications at runtime was impossible, because they were not in a
machine-readable form. So Google is an example of an application that
breaks when it sees new XML vocabularies with opaque linking types.
The solution that preserves the syntactic goodness of HTML and Docbook
is to move the link specification for a vocabuulary into a machine
readable form. Then the question becomes how to link to it: but this is
no more complicated than nor difficult than linking to a schema. We
could use RDDL or a special attribute or processing instruction. And of
course use CSS to say how it renders and behaves in browser user agents.
Paul Prescod
|
