- From: Robert Koberg <rob@koberg.com>
- Date: Thu, 23 Oct 2003 11:48:09 -0700
- To: "'Ian Hickson'" <ian@hixie.ch>
- Cc: <www-style@w3.org>
> -----Original Message----- > From: Ian Hickson [mailto:ian@hixie.ch] <yep/> > >> 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 that. > > > >> 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 :) Best, -Rob > > -- > Ian Hickson )\._.,--....,'``. fL > U+1047E /, _.. \ _\ ;`._ ,. > http://index.hixie.ch/ `._.-(,_..'--(,_..'`-.;.'
Received on Thursday, 23 October 2003 14:53:50 UTC