Maciej Stachowiak wrote:
>
> Client-side XSLT would prevent starting the loads of any auxiliary
> resources (images, stylesheets, scripts) until the main resource load
> is complete so that the XSLT transformation can be performed.
>
When using an XML PI to load stylesheets, the stylesheet is fetched
prior to the XSLT transformation. If what you say were true, I'd have
a FOUC problem on my hands, which I don't. The only real problem my
demo has, is browser vendors constantly changing the rules for engaging
XSLT (used to work in both Chrome and IE9).
Images and scripts not loading until the transformation completes,
sounds like a bug that needs fixing, not a reason to _not_ use XSLT.
Transformation output *should* be rendered incrementally, just as if it
were coming over the wire -- XSLT via PI is just a stream transducer,
any implementation which fails in this regard is simply broken.
>
> For anyone looking to make high-performance mobile sites, I would
> strongly recommend using text/html and strongly recommend against
> client-side XSLT.
>
Stating that any one solution is categorically better than another for
all use cases, sounds like ill-considered advice to me. Nothing I
haven't heard before from starry-eyed Flash developers, tho.
A given tradeoff may be acceptable for one use case, but not the next.
As a developer, I appreciate having more than one approach which works
for the Web, particularly if it means I have the *option* of sticking
with functional, declarative code (particularly for mobile). Forcing
me to accept any tradeoff for all use cases, would be a disservice to
my clients.
The difference between us, is I am neither advocating XSLT as panacea,
nor am I trying to do away with other approaches. What I am advocating,
is that the publisher (w3c) of various standards also continue to
publish interoperability guidelines between said standards, because
that's how they get used in the real world, like it or not.
http://blogs.msdn.com/b/ie/archive/2010/11/01/xhtml-in-ie9.aspx
Seeing as how these guidelines already exist, and are referred to by
the vendor with the largest share of the browser market, and really
costs nothing to publish and maintain, dropping polyglot seems like more
trouble than it's worth -- for the sake of what? Fantasies about a
monoculture Web?
While this may be advantageous to the likes of Google, Apple, etc. it
seems like a step backwards to those of us out here who believe in
letting *content publishers* continue to decide which way the Web should
evolve instead of having a pre-ordained future dictated to us. Impeding
this natural course of affairs by *eliminating* publisher choice between
viable alternatives should not be the business of even a "reformed" TAG,
it's anti-Web.
-Eric