RE: CSS 4?

On Thu, 23 Oct 2003, Robert Koberg wrote:
>>>
>>> With CSS, how would you take this XML element:
>>>    <link idref="a1234"/>
>>> And style it into:
>>>    <a style="internalLink" href="../folder/page.html">page</a>
>>
>> That question is meaningless. You are adding semantics, not styling.
>
> I would say it is absurd, not meaningless (if it had no meaning, how can you
> answer it?).

Granted.


> I put in to point out that CSS cannot handle the situation.

Of course, CSS wasn't designed to. :-) (Although, as I mentioned, it is
getting to the point where CSS, in addition with technologies like HTCs or
XBL, can actually do it. Much of Mozilla's XML-based user interface uses
XBL in exactly this way, for instance.)


> What actually happens (in our case, which I did not feel was necessary to
> show the absurdity) is that the @idref is used in an XSL transformation to
> lookup a node in a hierarchical site representation and determines the
> document relative path. This way all internal links can be guaranteed to be
> valid. Also, the page name and link inner text can be retrieved from a name
> attribute or generated from a child label element. Since, the XSL matches on
> the link, and it is known that this element means internal link then it can
> provide the class (I miswrote style...) attribute with the correct class
> name. This is all done on the server.

That is exactly the right use of XSLT. Server-side transformation from a
proprietary language designed for maintainability into a standard language
designed for accessibility.

That problem space is not in any way coincident with CSS's problem space.
It is also quite separate from XSL (as in XSL-proper, that is to say, XSLT
used to transform standard semantic data to XSL:FO typically on the
client side). I do not think Tantek was talking about this use of XSLT at
all in his e-mail(s).


>> If the <link> element above is in a proprietary language, then it
>> shouldn't be sent over the wire anyway, it should be transformed on the
>> server side.
>
> Why shouldn't you send proprietary XML and transform it client-side into
> (X)HTML?

At the very basic level, because there is no guarentee that the client
supports XSLT or has XSLT enabled. For example, search engines, Lynx,
Opera -- none of those UAs have XSLT support. And with the number and
range of UAs increasing daily (printers now have XHTML support, mobile
phones have Web support, etc) you can't rely on the client having anything
other than built-in knowledge of the standard semantics (in this context,
that would typically be HTML/XHTML, but it could also include MathML or
XForms depending on the target audience).


>> If the <link> element is in a fictional but well-known standard namespace,
>> then it would already have the linking semantics, and so it would already
>> match the :link and :visited pseudo-classes as appropriate.
>
> I don't understand this.

fictional but well-known standard namespace: A language that the UA has
built-in knowledge about. Examples of well known standard namespaces would
be XHTML or MathML.

having linking semantics: The UA knows that the element is a link just
like it knows that in HTML, the <a> element is a link, and in XLink, the
<foo xlink:type="simple"> element is a link.

the :link and :visited pseudo-classes: the mechanisms in CSS to style
elements that the UA knows are links.

Does that explain the sentence?


>> In the extreme case, however, it would be possible to do something like:
>>
>>    link { binding: url(internalLinks.xml#link); }
>>
>> ...where internalLinks.xml is a BECSS binding that defines how elements
>> should be turned into links. (BECSS is still in development, though. At
>> the moment, you would use -moz-binding or behavior depending on whether
>> you were targetting Mozilla or WinIE.)
>
> This seems to be going back to the bad-old-days.

Which part, BECSS, or the proprietary experimental binding technologies I
mentioned? The latter are what are driving the former. Generally inovation
in the market is required before specifications can be drawn up -- you
can't draw up good solid specs without implementation experience and
feedback from the users (in this case, the authors that use HTCs and XBL).


>>> Or, using CSS, turn the things above (or anything) into a PDF?
>>
>> There are several CSS-to-PDF systems available.
>
> In a very limited way.

The current CSS-to-PDF systems are very advanced, easily as advanced as
the XSL:FO-to-PDF systems in my limited experience. Of course, why you
would want to take perfectly accessible XHTML+CSS and turn it into
device-dependent, non-user-configurable PDF is beyond me.

-- 
Ian Hickson                                      )\._.,--....,'``.    fL
U+1047E                                         /,   _.. \   _\  ;`._ ,.
http://index.hixie.ch/                         `._.-(,_..'--(,_..'`-.;.'

Received on Thursday, 23 October 2003 14:16:18 UTC