You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@cocoon.apache.org by Joerg Heinicke <jo...@gmx.de> on 2007/03/16 21:43:35 UTC
Re: XHTML Serializer block/Ajax: Bug
(moving to dev list)
On 16.03.2007 14:58, Jason Johnston wrote:
>>> Another option might be to wrap the contents of <script> elements
>>> within a CDATA section so the JS could remain unencoded but it would
>>> still result in well-formed XML. I'm not sure how some browsers
>>> would handle the CDATA delimiters so they might have to be commented
>>> out so they're not mistaken for script code:
>>>
>>> <script type="text/javascript">/*<![CDATA[*/
>>> while(0 < 1 && true) alert("oops");
>>> /*]]>*/</script>
>>
>> Actually I don't like it. From an XML POV the above and the current
>> solution are
>> absolutely equal. What we are going to do with such a fix is to fix
>> awkward
>> browser behaviour or even wrong document contents.
>
> I understand what you're saying; it definitely creates uglier content.
> But in terms of fixing browser behavior, we actually already have logic
> in place that does just that by preventing collapsing of <script />
> tags. From an XML point of view <script/> and <script></script> are
> also equal, but we force the latter simply because browsers handle it
> better. I don't see this situation as any different.
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.
Jörg
[1]
http://svn.apache.org/viewvc/cocoon/branches/BRANCH_2_1_X/src/blocks/serializers/java/org/apache/cocoon/components/serializers/XHTMLSerializer.java
Re: XHTML Serializer block/Ajax: Bug
Posted by Joerg Heinicke <jo...@gmx.de>.
Pier Fumagalli <pier <at> betaversion.org> writes:
> > 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.
>
> As the original author of the code, if you don't want to implement
> quirks, then, what's the difference between the "XHTML" serializer and
> the "XML" serializer?
That's exactly what Grek put into question [1]. But I think it's ok to do some
of the specific stuff [2].
> If you don't need quirks, you don't need to support browsers, then
> simply use the XMLSerializer and forget about it, the XHTML and HTML
> do exactly this job of supporting as many browsers as possible, no?
I gave my reasoning at [3]: You address quirks in the XHTMLSerializer which
you'd not need if you were not using it. Furthermore you introduce further
problems by forcing the browser into the quirks mode as it can't understand
XHTML anyway. Delivering standard conform HTML is much more appropriate for
those browsers.
Joerg
[1] http://marc.info/?l=xml-cocoon-dev&m=117407836212241&w=4
[2] http://marc.info/?l=xml-cocoon-dev&m=117408459418886&w=4
[3] http://marc.info/?l=xml-cocoon-dev&m=117422523711377&w=4
Re: XHTML Serializer block/Ajax: Bug
Posted by Pier Fumagalli <pi...@betaversion.org>.
On 3/16/07, Joerg Heinicke <jo...@gmx.de> wrote:
> (moving to dev list)
>
> [...]
> 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.
As the original author of the code, if you don't want to implement
quirks, then, what's the difference between the "XHTML" serializer and
the "XML" serializer?
If you don't need quirks, you don't need to support browsers, then
simply use the XMLSerializer and forget about it, the XHTML and HTML
do exactly this job of supporting as many browsers as possible, no?
Pier
Re: XHTML Serializer block/Ajax: Bug
Posted by Joerg Heinicke <jo...@gmx.de>.
On 17.03.2007 16:43, Jason Johnston wrote:
> If by "the lazy guys" you also mean Cocoon itself. For instance, the
> CForms forms-field-styling.xsl creates all its output in the null
> namespace, which is fine for regular HTML delivery but if for some
> reaason you do want to deliver as XHTML you have to set the proper
> namespace somehow.
A most trivial XSLT can do this.
> To interject a counter-opinion, there is a well-established precendent
> on the Web today for delivering XHTML in ways that are consumable by
> current-day user agents but without sacrificing the well-formedness or
> validity of the XML. True, you have to control certain aspects of the
> serialization to avoid tripping up certain browsers, which can be a bit
> of a pain.
This can be easily reached by using BrowserSelector.
> I think there's a lot of value in having the tool handle these things
> transparently rather than making users figure out workarounds themselves.
That's the point where I don't agree. By delivering XHTML while the
browser can't understand it you force it into the quirks mode - and
that's more or less unpredictable. If you deliver standard conform HTML
instead the browser will behave (probably also more or less) standard
conform.
Just an example, probably everybody who has been working with CSS knows
the box model bug in IE. Since IE6 this one is fixed and you will get
expected behaviour IF you are in standard compliance mode [1].
Otherwise, with the one fits all solution, you have to cope with that
bug [2].
Despite this being just an example which I generalize IMO there is not
lot of value doing such things transparently. Once again problems should
get fixed where they arise. This means using HTMLSerializer here when
necessary and not create one workaround (additional stuff in
XHTMLSerializer) which leads to the next one (e.g. fixing IE box model)
both bloating the code. That's just paradoxical. Documenting it is much
more appropriate.
Regards
Jörg
[1]
http://msdn2.microsoft.com/en-us/library/bb250395.aspx#cssenhancements_topic3
[2]
http://www.456bereastreet.com/archive/200612/internet_explorer_and_the_css_box_model/
Re: XHTML Serializer block/Ajax: Bug
Posted by Joerg Heinicke <jo...@gmx.de>.
On 17.03.2007 16:43, Jason Johnston wrote:
> If by "the lazy guys" you also mean Cocoon itself. For instance, the
> CForms forms-field-styling.xsl creates all its output in the null
> namespace, which is fine for regular HTML delivery but if for some
> reaason you do want to deliver as XHTML you have to set the proper
> namespace somehow.
A most trivial XSLT can do this.
> To interject a counter-opinion, there is a well-established precendent
> on the Web today for delivering XHTML in ways that are consumable by
> current-day user agents but without sacrificing the well-formedness or
> validity of the XML. True, you have to control certain aspects of the
> serialization to avoid tripping up certain browsers, which can be a bit
> of a pain.
This can be easily reached by using BrowserSelector.
> I think there's a lot of value in having the tool handle these things
> transparently rather than making users figure out workarounds themselves.
That's the point where I don't agree. By delivering XHTML while the
browser can't understand it you force it into the quirks mode - and
that's more or less unpredictable. If you deliver standard conform HTML
instead the browser will behave (probably also more or less) standard
conform.
Just an example, probably everybody who has been working with CSS knows
the box model bug in IE. Since IE6 this one is fixed and you will get
expected behaviour IF you are in standard compliance mode [1].
Otherwise, with the one fits all solution, you have to cope with that
bug [2].
Despite this being just an example which I generalize IMO there is not
lot of value doing such things transparently. Once again problems should
get fixed where they arise. This means using HTMLSerializer here when
necessary and not create one workaround (additional stuff in
XHTMLSerializer) which leads to the next one (e.g. fixing IE box model)
both bloating the code. That's just paradoxical. Documenting it is much
more appropriate.
Regards
Jörg
[1]
http://msdn2.microsoft.com/en-us/library/bb250395.aspx#cssenhancements_topic3
[2]
http://www.456bereastreet.com/archive/200612/internet_explorer_and_the_css_box_model/
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@cocoon.apache.org
For additional commands, e-mail: users-help@cocoon.apache.org
Re: XHTML Serializer block/Ajax: Bug
Posted by Jason Johnston <co...@lojjic.net>.
Joerg Heinicke wrote:
> On 16.03.2007 21:52, Grzegorz Kossakowski wrote:
>
>> 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?
>
> If you have a look into the source code [1] you can see that it handles
> (besides the stuff fixing the tag soup) doc type, mime type and has same
> special XHTMLEncoder [2], which adds the HTML 4 entities. So far
> absolutely ok.
>
> It puts every element in no namespace into the XHTML namespace. Still
> acceptable, but abdicable - it's for the lazy guys.
If by "the lazy guys" you also mean Cocoon itself. For instance, the
CForms forms-field-styling.xsl creates all its output in the null
namespace, which is fine for regular HTML delivery but if for some
reaason you do want to deliver as XHTML you have to set the proper
namespace somehow.
> Also the meta tag
> for content type it adds should be abdicable. AFAIR it's also only for
> IE as it stumbles on the XML declaration.
>
> But at the end it should not do more than this.
To interject a counter-opinion, there is a well-established precendent
on the Web today for delivering XHTML in ways that are consumable by
current-day user agents but without sacrificing the well-formedness or
validity of the XML. True, you have to control certain aspects of the
serialization to avoid tripping up certain browsers, which can be a bit
of a pain. But I think the end result is a good one: more documents get
published as true XML but can still be consumed by non-XML user agents.
In fact this compatibility was an important consideration when XHTML
1.0 was created, and there is an entire appendix in the W3C
Recommendation dedicated to the subject [1].
Now, XHTMLSerializer is a tool for publishing XHTML. Adopting a
hard-line attitude and deliberately ignoring those things that can be
(fairly easily) done to make the XHTML consumable by current-day user
agents greatly decreases the usefulness of that tool. I think there's a
lot of value in having the tool handle these things transparently rather
than making users figure out workarounds themselves.
--Jason
[1] http://www.w3.org/TR/xhtml1/#guidelines
Re: XHTML Serializer block/Ajax: Bug
Posted by Joerg Heinicke <jo...@gmx.de>.
On 16.03.2007 21:52, Grzegorz Kossakowski wrote:
> 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?
If you have a look into the source code [1] you can see that it handles
(besides the stuff fixing the tag soup) doc type, mime type and has same
special XHTMLEncoder [2], which adds the HTML 4 entities. So far
absolutely ok.
It puts every element in no namespace into the XHTML namespace. Still
acceptable, but abdicable - it's for the lazy guys. Also the meta tag
for content type it adds should be abdicable. AFAIR it's also only for
IE as it stumbles on the XML declaration.
But at the end it should not do more than this.
Joerg
[1]
http://svn.apache.org/viewvc/cocoon/branches/BRANCH_2_1_X/src/blocks/serializers/java/org/apache/cocoon/components/serializers/XHTMLSerializer.java?revision=433543&view=markup
[2]
http://svn.apache.org/viewvc/cocoon/branches/BRANCH_2_1_X/src/blocks/serializers/java/org/apache/cocoon/components/serializers/encoding/XHTMLEncoder.java?revision=433543&view=markup
Re: XHTML Serializer block/Ajax: Bug
Posted by Grzegorz Kossakowski <gr...@tuffmail.com>.
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