[
Lists Home |
Date Index |
Thread Index
]
Hi Uche,
> Behavioral aspects of linking should certainly have a mechanism for
> override in the instance. I believe this is the job for CSS. I am
> also not convinced that there should be no mechanism for expressing
> linking semantics in the instance document.
Yes; I've been being naive. In many ways, linking is a lot like
presentation in terms of how it can be applied at both a global level
and a local level. At a global level there can be a general linking
semantic and behaviour for a particular element such as "all <a>
elements point to a page that should be shown on user request". At a
local level there can be a requirement to override this general
semantic or behaviour, such as "this particular <a> element is
pointing to the home page".
Like presentation, at least for a presentation-oriented language like
XHTML, those semantics/behaviours at the *global* level are *built-in*
to the language. You really don't want to have to specify, in every
XHTML document (or referenced CSS stylesheet), that a <p> element is a
block element. Likewise, you really don't want to have to specify, in
every XHTML document (or referenced
whatever-you-use-to-specify-linking), that an <a> element is a link
that is activated by the user clicking on it.
This is really what I was trying to get at by the "put it in the
schema" suggestion. If you have something that is built-in to a
language as a default, then it doesn't make sense to repeat that in
every single instance document. I believe that the proper place for
these defaults is in the schema (I'm using 'schema' in a very general
sense meaning "the place where you describe and specify the structure
and semantics of your markup language"). XLink does this, for example,
by having fixed and defaulted attributes specified in the DTD. It
appeared to me that, on the contrary, HLink was advocating repeating
the same link specification in every instance document.
But you're absolutely right that you need to have a local mechanism as
well. Importantly, though, it should be at the level of individual
elements. HLink, from what I can see, defines things at the level of
all-elements-of-the-same-name. It seems to me that something along the
lines of CSS selectors or XSLT patterns would work well here, enabling
you to target elements depending on their name, their class or
individual elements by their ID. XLink manages this, of course, by
allowing you to override the default XLink attributes on particular
element instances.
> In particular, I do not think extended links should be ditched, and
> I think that extended links would require some semantic notation in
> the instance.
>
> People always say they don't "get" extended links and then go right
> on to reinvent them. Right now, HTML authors build extended links
> using rickety prefabs of simple links and Javascripting. Even the
> HTML WG has sorta reinvented them in the new navigation links
> thingie (and possibly in other places). I think that almost any
> declarative approach to extended links would be easier for Web
> designers than figuring out what combination of iffy HTML and
> specialized scripting can be made to somewhat work in the variety of
> browsers.
Just because it will help me visualise this, can you describe an
example of where what should be an extended link is used in an HTML
page?
My only, random, thoughts are that (a) perhaps you can implicitly
understand that a link is an extended link by seeing that the simple
links are all attributes/children of the same element, (b) if you're
right, you do need something more than CSS, and HLink isn't there yet,
(c) if we have to have a new mechanism here that works in a similar
way to CSS isn't it time we started unifying the way individual
documents can point to related resources so that applications don't
have to know about 15 different ways to get information about a
document, and (d) if we could rely on a transformation layer and XLink
comprehension we wouldn't have to make up a new language for
describing links.
Cheers,
Jeni
---
Jeni Tennison
http://www.jenitennison.com/
|
