This issue is not styling, but transformation. If the model of linking is to take a document with links and make a derived document 'without' links, then sure, there is a problem adresssing that derived document or linking to it. After all, it doesn't have a URL. But that is a general problem with in-place transformation - anonymous generated resources.
But for styling links, there is no particular problem. For example, Opera has some CSS extensions that let it do styling of XLinks, and of links in WAP content, and in Open eBook. SVG rendererd regularly style XLinks in SVG content.
i disagree with the opinion that xlink styling is not a problem. opera's css extensions are interesting, and xsl-fo also has some (rather weak) support for styling links. but: if you think of the linking model of xlink, you will see that many complex links (such as multi-ended links or transclusions and the whole issue of how to style titles and roles) have no well-defined representation. i think that this is one of the reasons why xlink support generally is so weak. implementors must solve many problems that are not part of xlink (and rightly so), but which should be specified in additional specs making it clear how complex xlinks should be styled. currently, even if browsers were supporting xlink, they would display them in very different (and proprietary, as indicated by opera's css extensions) ways.
Previous Message
Up
