Re: Are there W3C definitions of presentation and content?

On Friday 23 September 2005 15:18, Rijk van Geijtenbeek wrote:

> It is a bit of a 'if you have a hammer...' argument, but using CSS
> for linking is an easy way to implement support for these type of
> documents in any CSS supporting browser. I guess DOM+EcmaScript could
> also be used. In both cases, the author will have to include the
> style (or script) in the document, or the user would have to use a
> user stylesheet (or userscript).
> Ideally, such documents should not be used directly in the browser,
> but transformed server-side to normal HTML+CSS.

That is indeed the point ("If you have a hammer, everything looks like a 
nail"): CSS would be quite convenient as a language to add links, 
logos, navigation bars, access control, checksums, time stamps, 
copyrights, annotations, etc. to a document, but it would be bad for 
the semantic Web, because the document and the CSS would no longer be 
separable. It's better to keep things modular: content in one place, 
style in another, and certain other things in yet other places.

That doesn't mean that the requirement of readability-by-machines should 
take priority over usability. But I think we can have modularity *and* 
usability. The answer to how to display other XML-based formats than 
XHTML could be as follows:

  - First of all, only use standard formats on the Web. There is more to
    semantics than how a document looks and whether the hyperlinks work.
    If you need graphics, use SVG; if you need multimedia, use SMIL, if
    you need text, use HTML; if you need privacy statements, use P3P;
    etc. Don't invent new formats unless you really have to or unless
    you are sure that everybody who receives your file understands it.

    DocBook and TEI are nice enough formats, but they are currently not
    Web formats. They could become so, of course, if IANA gives them
    a MIME type and browsers start recognizing them.

  - If you have to use a non-standard format, it may be possible to
    distribute one of more XSLT transformations with it, that transform
    it to something that *is* standard and that is usable on the user's
    platform. (The transformation may have to be done on the server or
    in a proxy, depending on the client platform.)

There are various efforts to define generic solutions for hyperlinks and 
transclusions, because those kinds of links are rather essential to the 
Web. So far, none of them is very successful:

  - XLink[2]: The idea here is that everybody who designs a new
    XML-based format that contains links uses the same attributes. Any
    browser that sees such an attribute would know that it contains a
    URL and the element is a link.

    But XLink has some problems: not everybody wants to use those names
    and XLink only allows one link per element. Thus XHTML, for example,
    has chosen not to use XLink. Also, XLink requires support for XML

    (Another, rather subtle problem is that an XLink attribute in an
    XSLT file is *not* a link, even if it looks like one. That may be a
    design problem in XSLT, rather than in XLink.)

  - HLink[3]: The HTML working group has developed an XML-based format
    that can be used to declare what elements and what attributes in a
    given file are links. Somehow a document should link (maybe
    indirectly) to such an HLink file and then a browser that knows
    HLink will know how to find the links in that document.

  - CSS3[4] will have support for transclusions ("replaced elements" as
    they are called in CSS). Thus, as long as the software understands
    CSS, it will be able to recognize those links that indicate external
    content to be inserted into the document. Basically, the syntax will
    be 'FOO {content: attr(SRC, url)}' to indicate that the FOO element
    is replaced by whatever the SRC attribute points to, when
    interpreted as a URL.

But the current thinking is still that CSS3 should not be used to 
indicate what elements are to be displayed as hyperlinks. It will 
probably have ways to modify *how* hyperlinks are displayed (in the 
same window, in a separate window, inline...). But those properties 
will only apply to elements that match ':link' or ':visited' and CSS 
itself will not define which elements do so.

Maybe we'll eventually have to add something like Opera's CLink[1] to 
CSS, but I hope it won't be necessary.


  Bert Bos                                ( W 3 C )                               W3C/ERCIM                             2004 Rt des Lucioles / BP 93
  +33 (0)4 92 38 76 92            06902 Sophia Antipolis Cedex, France

Received on Friday, 23 September 2005 16:02:17 UTC