xsl-list
[Top] [All Lists]

Re: [xsl] Modern web site design with XML and XSLT

2010-01-05 17:10:55
David Carlisle wrote:

I didn't suggest otherwise.  I'm pointing out that your lack of XML
Prolog is causing Opera to choose utf-8.  It's a repeatable problem,
and it is solvable (except doing so will put IE 6 into quirks mode).

that is not a problem so it needs no solution.
If it was a problem 9for exaple if teh files were in latin 1 so utf 8
was incorrect it can be solved by specifying the correct encoding in
the http headers.


OK.


But I'm looking at two browsers with the same font settings, on the
same system, with the same fonts available.  The only other
explanation for the box relates to parsing.

there are all sorts of things that browsers, especially ie6 may get
wrong, but they can all read ascii files. the files you are refering
to are ascii, so clearly your explanation can not be the only one as
it does not apply here.


You're right, I forgot the "IE sux" alternative...


It's an example of browsers using content-sniffing to override the
server-defined media type.  As RFC 3023 explains, text/xml is for:

absolutely not, it is processing text/xml (or equivaently here if you
prefer, application/xml) as specified. 


They are not equivalent, text/xml specifies no processing (I want the
user to see the raw XML document, similarly as with text/plain), while
application/xml specifically expects processing of XML PIs -- XSLT, CSS
or otherwise.  The default encoding for text/xml is ASCII, as with all
'text' types, while the default encoding for application/xml is
Unicode, as with all 'application' types.


Using application/xhtml+xml for content using the xml-stylesheet pi is
not strictly wrong but is a suboptimal choice of mime type as the main
point of application/xhtml+xml is that it asks for html rendering of
teh supplied content, but if using xml-stylesheet the served document
is never rendered, what is rendered is the generated result dccument.


Sure it is.  I've been using XHTML 1.1 with CSS PIs for longer than
I've been using XSLT.  Adding a XSLT PI to my existing documents didn't
change anything, the rendering is application/xhtml+xml both before
and, critically, after transformation.  I only use match='/' to
manipulate (add or remove or alter) CSS _and_ XSLT PIs.  I can also use
Javascript to manipulate XML PIs -- user clicks button, new XSLT PI is
added, representation is transformed immediately.

I match='html/body' to perform client-side inclusion via transformation
of external Atom content, my client-side XSLT doesn't overwrite
<html>.  That the rendering is styled the same both before and after,
in addition to not overwriting <html>, is why it works smoothly without
any artifacts like a flash of unstyled content.

The critical difference is that application/xhtml+xml is asking for XML
parsing of transformation output into the DOM (formedness matters),
whereas other types are asking for HTML rendering (formedness doesn't
matter).  Since I intend the browser context to always be XML, I don't
have to worry about quirks mode vs. standards mode, which is only
relevant if the browser context is HTML.


The corollary is, can your XSLT output apply CSS stylesheets by
adding XML PIs, or do you have to use <link/> tags?

since i'm generating xhtml it;s more natural to use link elements
since that's what they are there for. I haven't checked the status of
css via teh xml-stylesheet pi recently, but it's not really of any
concern, it would be more of a concern if the stylesheets were
generating some non xml vocabulary that was to be styled by css, but
I don't know of anyone who does that.


The only possible use of the xml-stylesheet PI currently, is for CSS
intended to style XHTML.  I use it that way and don't have any problems
with it.  Since I'm generating XHTML that's meant to be displayed using
the browser's XML mode, and my styling is not meant to change with the
transformation, I use CSS PIs because XML PIs are always active in the
browser context when using application/xhtml+xml.  It works very well,
using user-perceived performance as the basis for that determination.

-Eric

--~------------------------------------------------------------------
XSL-List info and archive:  http://www.mulberrytech.com/xsl/xsl-list
To unsubscribe, go to: http://lists.mulberrytech.com/xsl-list/
or e-mail: <mailto:xsl-list-unsubscribe(_at_)lists(_dot_)mulberrytech(_dot_)com>
--~--