Re: ISSUE-54: doctype-legacy-compat

On Jan 16, 2009, at 14:14, Sam Ruby wrote:
> Jirka Kosek <jirka@kosek.cz> wrote on 01/09/2009 04:53:21 AM:
> >
> > Sam Ruby wrote:
> >
> > > The suggestion was made that the name of this doctype be changed  
> from
> > > xslt-compat to legacy-compat.  Expressing support for this idea  
> were
> > > hsivonen, DanC, anne, gsnedders, smedero, and myself.  (Note: I  
> believe
> > > that Julian was also OK with this idea too, but didn't manage to  
> scribe
> > > that)
> > >
> > > Any objections?
> >
> > I'm fine with this change. It's good that XSLT and other "legacy"
> > content producer are satisfied. Let's move on something more  
> interesting ;-)
>
> There are two problems preventing moving on.
>
> First, we have an editor who did not participate in yesterday's  
> call, nor in the call the week before it, has chosen to Warnock[1]  
> this thread,
>
You only asked for objections, though.
> Second, Chris Wilson has indicated[4] that he is not happy with  
> legacy-compat, and at that point we no longer have consensus.
>
I agree with the point Chris made about the ambiguity of what legacy  
the compatibility is about. That is, authors might think that "legacy- 
compat" means compatibility with legacy consumers rather than legacy  
producers.

This is a reason why "XSLT-compat" is better. It's clear that it's  
there for compatibility with a pre-existing W3C spec.
> From a technical perspective, here is my understanding of the  
> problem.  The following string is the smallest and simplest string  
> that will trigger standards compatibility mode in all browsers  
> (there was some confusion over this, but that was resolved[5]) and  
> can be produced by all known tools.
>
> <!DOCTYPE html "">
>
> If the goal was to promote a single DOCTYPE, this would be it.
>
As Lachlan pointed out, I think you (and others) saying <!DOCTYPE html  
""> instead of saying <!DOCTYPE html PUBLIC ""> should be taken as  
evidence of these strings being too long and weird to be memorized  
correctly.

In the rest of this email, I'll assume you meant <!DOCTYPE html PUBLIC  
"">.
> One possible objection is that the above DOCTYPE contains three  
> unnecessary characters, and by promoting a least common denominator  
> approach, we are penalizing everybody in order to accommodate a  
> relative few.
>
Indeed.
> One solution to that is to make those three characters optional.   
> Optional quotes are not without precedent within HTML, but some want  
> to go further and make the string pejorative[6] in order to  
> discourage its use.
>
Making the string obviously unattractive is necessary, because  
otherwise we'd be responsible of wasting huge amounts of human time  
(over time over many people in aggregate) as people would debate  
whether to use <!DOCTYPE html> or <!DOCTYPE html PUBLIC "">. After  
all, the latter has more magic cruft in it, so surely that cruft has  
some desirable meaning.
> The current editor's draft follows[7] the pejorative approach,  
> singling out XSLT in a way that may be inappropriate[8].  The only  
> alternative proposed which does not single out any specific tool,  
> namely "legacy-compat", may be confusing[9].
>
We could say "legacy-generator-compat".
> Going forward, I would appreciate it if everybody with an opinion on  
> the subject would weigh in on which of the following options they  
> could live with:
>
As I said on the telecon last week, this is a bikeshed.

I think applying the "can live with" criterion to bikesheds is bad,  
because it leads to a race to the bottom as far as language design  
aesthetics go. The problem with "can live with" is that people have  
been taught that the more reasonable person gives up on bikesheds  
first. Of course, reasonable people know that they are able to deal  
with any *one* bad spec outcome--i.e. strictly speaking can "live"  
with any *one* bad choice. But if one always gives up soon on things  
like this, the outcome is bad committee design.

Hence, I'm going to comment on what I'm OK with and what I strongly  
oppose instead of answering on the "can live with" terms.
> 1) Single DOCTYPE, with a null quoted string
>
I take it that you mean <!DOCTYPE html PUBLIC "">.

I am strongly opposed to this for various reasons:

  * As demonstrated by yourself, <!DOCTYPE html PUBLIC ""> is too hard  
to memorize. <!DOCTYPE html> is memorizable. If we require a doctype  
that needs to be looked up, copied and pasted, we waste a lot of  
humanity's time on the aggregate.

  * Not having <!DOCTYPE html> as a conforming doctype would be a  
serious PR blunder now that HTML5 has been advertised for a couple of  
years as having a sane an memorizable doctype.

  * Compared to <!DOCTYPE html>, <!DOCTYPE html PUBLIC ""> is  
distinctly inferior aesthetically.
> 2) DOCTYPE with an optional null quoted string
>
I take it that you mean making both <!DOCTYPE html> and <!DOCTYPE html  
PUBLIC ""> conforming.

I am opposed to this, because we'd be responsible for wasting a lot of  
humanity's time on the aggregate since people would spend time.
  1) People would waste time wondering which one of <!DOCTYPE html>  
and <!DOCTYPE html PUBLIC ""> they should use.
  2) One group of people coming up with wild bogus rationalizations  
about the significance of PUBLIC "" in order to appear as gurus and  
another group of actual gurus refuting the bogus rationalizations.
> 3) Two DOCTYPES: one "preferred" with no quoted string, and one  
> "pejorative" with the value "legacy-compat".
>
I think we need the longer doctype to have a string that makes it  
undesirable and that pre-empts bogus rationalizations.

However, due to the reason Chris mentioned "legacy-compat" may not be  
sufficiently resilient against bogus rationalizations and not  
sufficiently undesirable. "legacy-generator-compat" would likely be  
better.
> 4) Two DOCTYPES: one with no quoted string, and one with a value of  
> "XSLT-compat" that should not be used unless the document is  
> generated from XSLT.
>
I'd be fine with the undesirable string being "XSLT-compat" if the  
spec allowed it to be used by any legacy generators even if they had  
nothing to do with XSLT. After all, presumably for users of non-XSLT  
generators "XSLT-compat" would be appropriately undesirable.

-- 
Henri Sivonen
hsivonen@iki.fi
http://hsivonen.iki.fi/

Received on Friday, 16 January 2009 13:55:45 UTC