Joerg Heinicke napisaĆ(a):
(moving to dev list)
To be honest I'm quite intolerant in this regard: I would even remove
this code. It's an all or nothing decision - where you probably can't
reach all.
What's actually happening? People want to use XHTML because it's cool,
in or state of the art, but they have to support browsers that don't
handle XHTML correctly or they break it themselves by not providing
the XHTML correctly and forcing the browsers into the quirks mode.
Then we get 20 bug reports for 10 issues in special cases because not
all quirks have been addressed yet. And we complicate our code base
more and more. Just have a look at XHTMLSerializer commits [1]:
special tags handling, omit-xml-declaration and now the
not-to-be-escaped characters. And what for at the end? That something
formerly known as XHTML can be understood by the browsers in quirks
mode and gets parsed as tag soup again.
But why not staying with HTML then??? Why is the XHTMLSerializer be
used in those cases? IMO we should NOT implement any special case
handling in XHTMLSerializer but tell the people to use the
HTMLSerializer.
I agree with you, Joerg, on all you said.
Moreover, I wonder why we need special XHTMLSerializer? As XHTML is only
XML with special namespace and tag set why we don't use just normal xml
serializer and configure proper mime type? Do I miss something important?
--
Grzegorz Kossakowski