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

Dean Edridge wrote:
> ...
> 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.
> ...

What does that have to do with the decision *which* additional doctype 
to add? Just because the editor doesn't like the direction itself, he 
somehow gets the right to choose an extra-ugly one (which happens to be 
misleading)?

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

The point I was trying to make (and apparently failed to) was that there 
are frameworks that re-use the XSLT serializer framework, even in cases 
where there's no XSLT run at all.

So the requirement to allow a doc type is only indirectly related to XSLT.

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

I disagree with that. But even if I did agree, that still leaves the 
issue of whether it should be possible to create HTML6 documents with 
HTML5 tools (which is the same issue, after all).

> 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 

Yes.

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

If *that* serialization could be produced with existing XML serializers, 
that would be great.

>> >>
>> >> [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"  ;)

Well, we have two now, no matter how you call it.

The "special" one is not only for XSLT, as I have demonstrated in 
<http://lists.w3.org/Archives/Public/public-html/2008Sep/0043.html>.

Thus, the name is misleading. For instance, can I use it, even though 
I'm not using XSLT?

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

The doctype is only one aspect of a bigger problem. Losing the SGML 
heritage in HTML may reflect reality, and make things simpler, but it 
also means that nobody can't predict anymore how new elements need to be 
serialized. That is a problem, and it applies both to HTML4 tools trying 
to produce HTML5 output, and HTML5 tools trying to produce tomorrow's HTML.

BR, Julian

Received on Tuesday, 2 September 2008 18:04:17 UTC