[
Lists Home |
Date Index |
Thread Index
]
Arjun Ray wrote:
> > "href" on any element is a straight-up loser.
> I agree.
>
> The basic problem with href and src is that they are not
> *links* at all. They are locators, with a conflated
> actuation semantic ('href' implying "replace", 'src'
> implying "embed".)
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".
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):
http://www.w3.org/TR/xhtml2/mod-object.html
> We may also note that bog-standard HTML *already* has one
> form of multiway linkage: the <MAP> element. It so happens
> to be usable presently with only one element type, <img>,
> but it still qualifies as a reasonable basis for
> generalization, because the <MAP> element expresses the
> insight that multiway linking needs independent structured
> description. So, if href and src are to be retained for
> their locator+actuation function, it makes sense to have a
> container element to aggregate them, and to attach the
> aggregate to other elements by normal intra-document
> reference mechanisms.
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?
/Jelks
|
