Re: [css3-hyperlinks] inclusion of Clink in next WD

On Tuesday, March 9, 2004, 5:37:24 PM, George wrote:



GC> On Mon, 8 Mar 2004, Boris Zbarsky wrote:
>> 
>> > This, as opposed to XLink, which is heavily complicated 
>> People keep saying this.... but the XLink equivalent of "make this node a link
>> to X" is very very simple, in fact.
GC> Yes, but there is one important psychological factor, even if simple
GC> xlinks
GC> are really simple webmaster encounters new not too simple language Xlink
GC> (more precisely even three new languages XLink, Xpointer, XPath). Note
GC> also that even simple Xlinks are not really so simple, for instance if you
GC> need to make link that points to some part of standalone XML doc you
GC> can't use id and need to use XPath.

I assume you refer to the "dude, where's my IDs" problem?

It is of course possible to point into XML (XHTML, SMIL, MathML, SVG,
VoiceXML, etc if one knows where the IDS are by reading or cacheing
the DTD or schema or by defining them in an internal DTD subset, and in
practice there is a lot of linking to elements by ID in XML.

The ID issue (for linking, CSS, and DOM) is orthogonal to which
language is used to detect where the links are, of course.

GC>  So Xlink in my opinion will not be
GC> used by webmasters (as for instance they don't use HyTime linking
GC> language).

HyTime is a red herring in this context.

GC> However apart of convenience, main advantage of CSS linking extensions is
GC> better flexibility. Consider for instance markup
GC> <element url="http://sample.com/sample.png">PNG Image</element>
GC> You can display it as link to png image using CSS hyperlink extensions,
GC> you can without changing markup display image itself using CSS generated
GC> content and finally you can display just url to image or content of
GC> element again using generated content. Can you achieve it with XLink?
GC> No, Xlink is dumb language that lacks flexibility and is not extensible.

XLink is a markup language, so clearly changing a link requires
changing the markup. Of course, sometimes you want to link things you
don't have write access to or don't want to change, as you say; that
is why XLink also includes out of line links. Which have the same
problem as your CSS Clink example - it requires fetching and
understanding a external file to discover where the links are.

So Webmasters typically do not use out of likne linking like HyTime,
XLink external links, CLink, or Hlink and prefer to use simple,
direct, search-engine-freindly direct markup (such as XLink inline
simple links, or functional equivalents like the links in SMIL or the
assorted link forms in HTML).


GC> Another issue that I mentioned previously on this list is that CSS linking
GC> extensions are invaluable in default style sheets for XML based languages
GC> that have they own linking mechanism (XHTML, DocBook, TEI and many
GC> others).

Which is fine as long as clients are the only things that process
links. Since most people find most of their content by search engines,
then links need to be trivially discoverable by search engines.

GC> Here Xlink simply can't effectively replace CSS linking
GC> extensions (please don'to suggest me to use HLink + XLink + XPointer +
GC> XPath for things that can be done in much more simple and elegant way).

I believe it was yourself that made this suggestion, no one else is
suggesting it, so you can simply stop, to get your wish here ;-)

GC> Thus I vote for CSS hyperlinks that provide more convenient, more
GC> flexible and more aesthetical linking mechanism then that we currently
GC> have. I use it for several years in Opera and I would like to see this
GC> functionality it CSS3.






-- 
 Chris Lilley                    mailto:chris@w3.org
 Chair, W3C SVG Working Group
 Member, W3C Technical Architecture Group

Received on Tuesday, 9 March 2004 06:19:28 UTC