Re: still too early for XHTML :-((

See comments below...

At 11:08 PM 4/7/2003 +0200, you wrote:
> On Po, 2003-04-07 at 19:37, Jacob
> Kjome wrote:
> > So, can anyone confirm that if an XHTMLScriptElement is added to
> the
> > XHTML DOM that it is written as <script></script>
> instead of <script
>
> I can confirm that it's written out as <script /> and while it is
> a
> problem for browsers with closed source code it is not a real 'bug'
> since W3C allows that.
>
> > If it is writing it as <script /> then we will have a major
> browser
> > incompatibility. 
>
> yes, both IE 5-6 and Opera 7 choke on that and stop rendering the
> page.
>
> > It should definitely be written as
> <script></script>.
>
> But the <script /> is XHTML compatible. XMLC does that to all tags
> when
> generating XHTML. Perhaps the David Corbin's patch with 
> configurable
> behaviour will help but then the question is why to bother with
> producing XHTML 1.0 when the output is basically equal to HTML 
> 4.01.

When I say that it should be <script><script> and you say
"but <script /> is XHTML compatible" we are arguing two
different things.  I agree, <script /> is legal XML syntax and
there is nothing in the XHTML1.0 spec that I can see that explicitly says
it can't be used this way.  However, the HTML4.01 spec, of which
XHTML1.0 is an XML'ized version, declares that <script> tags are
required to have an </script> end tag.  Other than having to
follow various XML rules, the only real change between HTML4 and XHTML1.0
are that the Empty elements in HTML4 need to have " />"
added to them and there is no more attribute minimization.  So, yes,
XHTML1.0 *is* HTML4.01 with XML rules applied.  The benefit of this
is all the benefits you get from XML.  Of course the XHTML1.1 spec
goes further and allows for a lot more flexibility such as inventing your
own elements with your own behaviors.  XHTML1.0 was a stepping stone
meant to get people using XML syntax while still proving for backward
compatibility with HTML.  And that is the key "backward
compatibility".  If <script></script> and
<script /> are both legal XHTML, but the latter is not backward
compatible with browsers that only understand HTML, then we should be
using <script></script>.   We have everything to
gain and nothing to lose.  Where is the harm?  This one's a
no-brainer.

> Let me list all the
> XHTML problems I encountered so far, IIRC:
>
> 1) document type incorrect, _javascript_ didn't work
> 2) too old DTD for XHTML in XMLC

Is this an XMLC issue or an Enhydra framework issue?  How do you set
the doctype?  i set mine like this...

first, grab a reference to the default output options of the document and
then do...

oo.setOmitDocType(false);
oo.setPublicId("-//W3C//DTD HTML 4.01 Transitional//EN");
oo.setSystemId("http://www.w3.org/TR/html401/loose.dtd");

Then I pass the output options object to the dom writer.

XMLC doesn't do this automatically, so how could you get the
wrong doctype when you set it yourself?...which is why I think this is an
Enhydra issue, not an XMLC issue.  Maybe you can help me
understand?

> 3) setting of boolean attributes
> does not work

Yep, definitely need this patched!  Did you provide this patch (and
others) to David or Richard?  I could also apply them, but I'd feel
much more comfortable having one of them do it.  Maybe provide a
.zip file with all gathered patches included? and send to the list on
this thread.

> 4) single quotes are
> converted to &apos; (IE doesn't understand)

Like I said in my email last night, the fix for this is to use
&#39; instead of &apos; since the latter only
appeared in XML 1.0 and not HTML.  I tested the following and it
worked perfectly in both Mozilla and IE6...

<a href="" 
world!&#39;);">Hello World</a>

Again, since both entities are perfectly compatible with
XHTML, but only &#39; works with browsers that only understand HTML,
we should use the backward compatible one.  Again, we have
everything to gain and nothing to lose by doing this.

See:
http://www.w3.org/TR/xhtml1/#C_16

> 5) <script /> is not
> understood by IE/Opera

Already addressed this above.  We should definitely use
<script></script>.

> 6) URLRewriter does
> not work

What was the issue with this one?  I don't remember.

> I reported all
> problems and submitted patch for 1 and 2 and suggested
> solutions for 3 and 6. David C. submitted patch for 4 and 5.
>
> Even if the 3 got fixed (not that hard) the 6 is still a serious
> issue.
>
> Also note that XMLC with patch 5 basically produces HTML 4.01 code,
> since the only visible difference between HTML and XHTML is the
> short
> form of <TAG />. So after disabling the short form of closing tag
> the
> question is why to bother with XHTML at all.

http://www.w3.org/TR/xhtml1/#why

And that is just for XHTML1.0.  XHTML1.1 is even more flexible,
although less backward compatble and should only be used when you know
your audience are using browsers which are XHTML compatible.  Most
are not.  Mozilla mostly is, but even it has a few issues with
strict XHTML (when served with the application/xml+xhtml or text/xml
content types).

> Petr


Jake

> _______________________________________________
> XMLC mailing list
> XMLC@xxxxxxxxxxx
> http://www.enhydra.org/mailman/listinfo.cgi/xmlc