[XML-DEV Mailing List Archive Home] [By Thread] [By Date] [Recent Entries] [Reply To This Message] RE: linking, 80/20
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
|
PURCHASE STYLUS STUDIO ONLINE TODAY!Purchasing Stylus Studio from our online shop is Easy, Secure and Value Priced! Download The World's Best XML IDE!Accelerate XML development with our award-winning XML IDE - Download a free trial today! Subscribe in XML format
|