- From: Eric J. Bowman <eric@bisonsystems.net>
- Date: Sun, 17 Feb 2013 22:08:57 -0700
- To: Maciej Stachowiak <mjs@apple.com>
- Cc: Anne van Kesteren <annevk@annevk.nl>, Michael Smith (tm) <mike@w3.org>, public-html WG <public-html@w3.org>, "www-tag@w3.org List" <www-tag@w3.org>
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
Received on Monday, 18 February 2013 05:09:22 UTC