Re: ISSUE-54 (html5-doctype-vs-xslt): XSLT 1.0 can not generate HTML5 documents [HTML 5 spec]

This also kinda relates to the: "Are new void elements really a good 
idea?" issue

I see Ian has already updated the spec to reflect the feedback received 
on this issue, and although I would think it would have been better to 
just have the one doctype for HTML5, I admire Ian for working so hard to 
try and accommodate everyone's needs. I do however just want to express 
some concerns I have surrounding matters of backwards compatibility with 
existing tools and software.


Jirka Kosek wrote:
> Julian Reschke wrote:
>   
>> Ian Hickson wrote:
>>     
>>> ...
>>> Based on the above feedback, I've allowed "XSLT-generated" as a string
>>> in the DOCTYPE.
>>> ...
>>>       
>> I think Mike's proposal to allow the empty string instead got more
>> positive feedback.
>>     

>
> This was also my understanding.
>
>   Jirka
>   

Perhaps it did receive some positive feedback on public-html, but 
public-html is not the only means for Ian to receive feedback. Several 
people on irc have expressed there concern over the multiple doctype 
proposal. There was actually a lot of negative feedback given to Ian 
regarding the idea of adding another doctype to the spec. Myself and 
several others asked Ian to not add another doctype at all to the HTML5 
spec, so I think people should be glad that Ian has tried his best to 
accommodate everyone here.


Julian Reschke wrote:
>
> ...
> I just checked my last project where I needed to produce HTML from 
> Java -- turns out that it falls into the same category, as it uses 
> javax.xml.transform just for the purpose of serializing to HTML. Note 
> that this is *not* XSLT, just usage of a standard JDK method to 
> produce HTML.
>
> So, which standard libraries do people use on other platforms (such as 
> .NET), and can *those* produce the HTML5 header?
>
> BR, Julian

I think that's totally irrelevant. It's one thing to make a special case 
for a W3C standard (XSLT), but if you're suggesting we go changing the 
spec to suit various web frameworks I think that's going too far. If we 
go down that path we'd be making exceptions for every web framework that 
pops up over the next 5 years, this would compromise the quality of the 
spec and we might never get it finished.


link: http://lists.w3.org/Archives/Public/public-html/2008Aug/0951.html
> Philip Taylor wrote:
> > Julian Reschke wrote:
> >>
> >> The "<tagname />" syntax is not allowed in HTML4, and thus existing 
> >> libraries that have been designed to produce HTML4 will not use it.
>   

Your argument seems to be that people should be able to produce HTML5 
with HTML4 tools, I totally disagree with that. HTML5 should not just be 
considered simply as HTML4++, it's a whole new language, it doesn't just 
update HTML4, it replaces HTML4, therefore it doesn't need to be a 
"HTML4 lookalike" or be backwards compatible with HTML4 tools.

If the text/html version of the spec wasn't called HTML5, would people 
still think it should be producible with HTML4 tools? The spec is called 
HTML5, the text/html version of the spec could have been called 
anything. So what if we had decided to not even call it HTML at all? 
Instead we could have called it "WebML", we could have discovered that 
we could just use something like {- webml -} at the top of the documents 
to trigger standards mode instead of a doctype. Would it then still need 
to be producible with existing tools? Or what if we, the HTML WG, had 
decided to have the text/html serialisation as close as possible to the 
XHTML version of the spec and use the <tag-name/> syntax for void 
elements; would that idea be stopped solely because existing libraries 
had not been designed to produce such a syntax? I don't think reasons 
like this should be allowed to effect the design of a new markup language. 

> >>
> >> [snipo]
> > 
> > Allowing both syntaxes means there are more opportunities for authors to 
> > get confused, and makes the language a bit more complex.
> > ...
>
> Agreed. It's always good if there's are fewer ways to do the same thing...

Yes, I totally agree ;)

I'm glad that Ian didn't add the <!DOCTYPE html PUBLIC ""> idea to the 
spec. That would have effectively said to the public: "Hey, we have two 
doctypes for HTML, a short one, and a long one, you can use whatever one 
you want". This would have lead to a lot of confusion as there would be 
a choice of two doctypes for HTML for ever. We've had that problem 
before [1] and this was one of the main reasons a single, short, easy to 
spell doctype was chosen for HTML5. With having one doctype, plus a 
special one that's just for legacy XSLT generators, it reduces this 
confusion, and after all, "it's always good if there are fewer ways to 
do the same thing"  ;)

Lots of software needs to be updated for (X)HTML5
    - No browsers support HTML5 completely
    - Expression web, CS3, the FCKeditor, TinyMCE don't support HTML5 
yet, they will all need to be updated along with many other tools, 
libraries and frameworks.

So I think having a special doctype for XSLT is a disappointment, but I 
guess it's a necessary evil as they say.


Regards
Dean Edridge

Received on Tuesday, 2 September 2008 17:51:49 UTC