RE: CSS 4?

> -----Original Message-----
> From: Ian Hickson []
> >> 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).

OK, good explanation. Google is the biggest blind user out there and all

> >> 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?

Yes, perfectly.

> >> 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).

I was thinking about having to maintain /code/ for different browsers. But
yes, I understand what you are saying. 

I keep hoping that contentEditable will get added to the (X)HTML spec(s).
But when I asked about it I was told that it is up to the UAs to implement
such a thing (yes, I know about Mozile)

> >>> 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. 

Apache FOP is pretty limited, but there are some other ones (renderX) out
there that can do quite a bit more.

> 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.

:) me too. We have an ASP based CMS and I totally refuse to use (generate)
it mainly because of the processing power required. For our print friendly
pages we just present a stripped down HTML version of a page/folder/site.
BTW, (if we are in control) we only output valid HTML, CSS and are 508
compliant :)


> --
> Ian Hickson                                      )\._.,--....,'``.    fL
> U+1047E                                         /,   _.. \   _\  ;`._ ,.
>                         `._.-(,_..'--(,_..'`-.;.'

Received on Thursday, 23 October 2003 14:53:50 UTC