Re: Polyglot markup and authors

Maciej Stachowiak wrote:
> 
> > 
> > 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.
> 

What I meant by "stylesheet" in the quoted paragraph, was CSS.  You'll
note on my demo, that the CSS is applied before the XSLT transformation
begins; it's referenced from the transformation input, not the output.
(Actually, it's referenced from both, but that's because the output is
intended to be polyglot -- this isn't strictly necessary.)

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

If I'm writing XSLT for the browser, then it's written in a way which
doesn't reorder the output, to retain stream processing.  IIRC, Michael
Kay's XSLT 2 browser plugin can work this way, if the author takes the
necessary steps.  The only reason I can figure why libxslt works like
this using CLI pipes, but not in Opera, is an implementation bug.

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

I'm hardly the only developer who gets pushback against browser-resident
XSLT; just look at almost any stackoverflow or xsl-list thread where
such problems are discussed.  This thread has been the subject of three
off-list discussions I'm having with other developers who feel as I do,
that there's an anti-XML faction out there trying to kill it off in the
browser.

On-list, I'm with Norm -- fatalistic concerning XML's future.  I don't
think we're all suffering a shared paranoid delusion.

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

That's putting words in my mouth; Anne brought up mobile, not me.  I
specifically mentioned desktop vs. server CPUs.  Many sites use conneg
to treat mobile as a completely separate problem, so there's an
assumption being made about my comments which doesn't actually apply.

What I did say about mobile, is that XSLT can save bandwidth by not
sending template cruft over the wire for every request, and that this
may be an acceptable tradeoff vs. performance depending on use case.

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

Assuming there is such a performance hit, which depends on the use-
case, and may not be valid tomorrow given the performance of upcoming
mobile CPUs.  Or if we ever see XSLT 2 support, or XSLT otherwise get
treated seriously by more browser vendors than Microsoft (although IE's
failure to support application/xhtml+xml for so long did more to stunt
browser XSLT uptake than anything else).

I develop for the long haul, not what works best today.  Tricky, but I
did have a client who kept their website I did online from 1995-2011,
unchanged, until a re-branding.  Changes to XSLT invocation keep me on
my toes maintenance-wise, but the only threat to my personal-standard
templates for converting Atom -> XHTML (etc.) is political; otherwise
my XSLT code should continue to be valid for a long time to come.

-Eric

Received on Tuesday, 19 February 2013 17:11:33 UTC