Re: new XSLT output methods, was: several messages

Julian Reschke <julian.reschke@gmx.de>, 2008-09-04 11:49 +0200:

> My question remains: is it a good idea to make it harder to
> generate HTML5 than it needs to be?

Of course not. But you can't simply consider the criterion of
"good idea to make it harder to generate HTML5 than it needs to
be" in isolation. The thoughts that Henri has been posting
recently (and for some time before, actually) about not wasting
people's time seem relevant here. Or in general (and however you
care to word it or see it), the idea that we all should be making
a good-faith attempt at trying to objectively consider what the
net costs to everybody are for what ends up in the spec, including
doing that for things that are a high priority (for whatever
reasons) to each of use personally.

In this case, it seems like we have real a cost of complicating
the spec (and making things not-insignificantly more complicated
and confusing for authors who need to figure out how best to try
to conform to the spec) by adding an additional/ optional form of
the doctype -- we don't get it for free in terms of what it costs
in peoples' time...

...and we need to take that and weigh it against the cost of it
being more difficult (but that said, not impossible) for authors
using XSLT in their toolchains to generate conformant HTML5 output.

As somebody who has made a lot of use of XSLT and who sees real
value in XSLT, I personally would like for it to be as easy as
possible to generate HTML5 output from XSLT engines. But I would
like to try to make sure that doesn't bias me away from really
trying to consider in good faith what the net costs to everybody
would be.

Anyway, as Henri has alluded to in some of his messages, it's very
hard to anybody to be able to legitimately assert that they have
made a completely objective judgment about the costs of some of
the choices around issues that have been under discussion[1].

Given that, in cases where people involved in the discussions
consistently and repeatedly keep insisting that their own
evaluation/assessment/conclusion of the costs is the only
right/logical/reasonable one -- without even acknowledging that
it just may not be totally clear-cut (as much as they might like
to be), well.. that especially doesn't help a whole lot in trying
to move the discussion toward a productive resolution.

And no, I don't intend to say that's what you're doing in this
case, but just in general that it's a problem in a good number of
the contentious discussions on public-html.

  --Mike

[1] For example, having a rationale, not-unnecessarily complicated
spec, free from cruft and junk that should not have been in the
language in the first place and maybe would not have been if as
much thought and discussion about it had taken place as has been
for the issues we've been discussing...

  vs.

...making certain "legacy" markup non-conforming even for cases of
markup that while it may be bad from a markup purity point of
view, is something relatively common in existing content, that
don't cause any unexpected behavior in browsers, and that may be
something that many or most of the authors using already know it
not best-practice markup but that they have chosen to use in spite
of that -- maybe for good reasons -- and that it may likely be a
waste of their time to have a conformance checker warn them about

  --Mike

-- 
Michael(tm) Smith
http://people.w3.org/mike/

Received on Thursday, 4 September 2008 11:30:07 UTC