[
Lists Home |
Date Index |
Thread Index
]
"Jelks Cabaniss" <jelks@jelks.nu> wrote:
| Arjun Ray wrote:
|> The basic problem with href and src is that they are not *links* at
|> all. They are locators,
| Are you saying that "elements besides <a> can have (replace) links" is a
| bad idea, i.e. <quote href="...">? Or that it's a bad idea for certain
| elements (head, title, body)? Or that the proposed implementation does
| not indicate a means of differentiating between "replace" and "embed".
None of these, actually. Just that href/src attributes don't scale to
multiway links. The really bad idea I see coming sometimes is things like
href_1, href_2... It has just the right touch of "sufficient ingenuity"
to punt on the real problem.
| Note, AFAICT there is no 'src' attribute any more in XHTML 2; 'img' is
| now 'object', whose semantic apparently is always "embed" (with the
| 'data' attribute):
Well, yes. 'href' meaning "replace" and 'src' meaning embed were
circumstantial kludges, after all. That semantic could just as well as
have been associated with the element type, with a generic name for a
locative attribute (the way that Xlink has that, for example). That's the
essential structure of simple links (or HyTime c-links) anyway. The point
however, is that contextual aggregation of locators is necessary to any
kind of multiway linking - and the essence of the *linking* semantic is in
the aggregator, not the locators.
| If there had been a container element to aggregate <a> like map-usemap,
| it would be a lot more complex -- at least for authoring -- than a
| simple <a href="..."> with an (understood) semantic of "replace", don't
| you think?
Yes. But I see no reason why the complex (or the obscure!) should be just
as easy as the simple case to "use". Most of the time, simple links will
suffice. When you need something more, it should be there too, but there
is always a price for complexity.
Can you think of anything *simpler* than the <MAP> construct for what it
does?
|
