Re: Polyglot markup and authors

(to be clear, this is all with chair hat off)

On Feb 17, 2013, at 9:08 PM, Eric J. Bowman <eric@bisonsystems.net> wrote:

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

Yes, the XSLT stylesheet and anything else needed for the transformation itself is fetched before the transformation. You don't get FOUC because you don't get any incremental rendering before the XSLT transform. But anything referenced from the transform output will not be fetched until after the transform.


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

I don't know of any XSLT implementation that works like you describe. It's not clear to me how it's even possible, because XSLT can arbitrarily reorder the output relative to the input. But certainly no one should assume in-browser XSLT works this way today.

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

No one is suggesting dropping support for XSLT or XHTML. Not sure what you're arguing with.

But I will bet you that if you actually measure the speed of client-side XSLT vs. serving the transform output to the client for a mobile site, the latter will be faster. You claimed that client-side XSLT could make mobile sites faster, and I think that is bad advice. If you find it more pleasant as a way to develop and you can live with the perf hit, that is of course up to you.

Regards,
Maciej

Received on Monday, 18 February 2013 20:46:22 UTC