Re: still too early for XHTML :-((

At 01:31 PM 4/9/2003 +0200, you wrote:
> On Út, 2003-04-08 at 16:30, Jacob
> Kjome wrote:
> > When I say that it should be <script><script> and you
> say "but <script
> > /> is XHTML compatible" we are arguing two different
> things.
>
> I know what you mean (and meant).
>
> > 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.
>
> OK, but my point was whether to include a special hack for the
> SCRIPT
> tag or if to use the David C.'s patch that enable </tag>
> everywhere. The
> former is definitely a hack while the latter is more clear but turns
> off
> one advantage of XHTML over HTML - a shorter code (shorter of the
> closing tags).
>
> Anyway, I have decided to continue with XHTML (after I realized 
> that
> Enhydra still strips the ID off the SPAN tags in HTML mode), 
> applied
> David's patch and am happy. The <script></script> works
> perfectly!

In order to prove it is a hack, please point out another case where this
would be affected?  The tags that were defined as empty in HTML such
as <br>, <hr>, etc shouldn't be written as
<br></br> or anything like that.  <br /> is just
fine.  All the ones where the end tag is optional such as most of
the table tags and others should have an end tag written for it anyway
and HTML browsers understand that just fine.  I was writing end tags
for these well before XML ever became the big thing.  All the rest
of the elements have in HTML4 have their end tags required.  So,
again, point out which other element this affects.  It is only a
"hack" to do <script></script> in the sense that
you feel you shouldn't have to.  However, since XHTML1.0 is the
XML'ization of HTML4.01, all HTML4.01 rules apply except those that
changed because of XML rules and <script /> is not one of those
changed rules.  <script></script> is the right thing to
do and it is *not* a hack.  Doing <script /> breaks the rules
set by HTML4.01 so doing anything other than
<script></script> is just wrong even though <script />
is valid XML syntax.  XHTML1.0 obeys more specific rules than
generic XML.

Here are all the HTML4.01 elements.  Point out another element which
might be at issue.  I can't think of one.
http://www.w3.org/TR/html401/index/elements.html

> > > 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?
>
> this wasn't about doctype. Enhydra didn't allow me to include
> "ID" to
> <TITLE>. Latest XHTML 1.0 allows that. I submitted a patch for the
> DTD.
> It's in the Enhydra 5.1.

Why would you want to do that?  By definition, there is only one
title element in the entire page. 
document.getTitle()/document.setTitle() or the more generic
document.getElementsByTagName("title") and grabbing the single
node in the NodeList should suffice. 

> >
> oo.setOmitDocType(false);
> > oo.setPublicId("-//W3C//DTD HTML 4.01
> Transitional//EN");
> >
> oo.setSystemId("http://www.w3.org/TR/html401/loose.dtd");
>
> I don't do anything like that.
>
> I did two things: first, all my HTML files do contain the XHTML
> header
> (so that validator.w3.org can validate them) and second, I added 
> the
> following line to my options.xmlc:
>
> -domfactory org.enhydra.xml.xhtml.HTMLDomFactory
>
> Thanks to that the doctype is "text/html" (so browsers can
> handle that).

Ok, I've never actually compiled my markup as XHTML.  So you are
saying that without doing anything on your own, you get a doctype set at
the top of your page upon output?  All my mockups are valid HTML4.01
and have the doctype declaring them as such at the top of each
page.  However, upon XMLC compilation, the doctype is not stored and
I have to add it back in at runtime using the OutputOptions object. 
So, you are saying that your dynamic output has the XHTML1.0 doctype
there by default?  And, you must have mistyped because
"text/html" is obviously a "content type", not a
"doctype".  Actually, I hope that "text/html"
being set as the content type can be easily overridden to be one of
"text/xml", "application/xml", or, ideally,
"application/xml+xhtml".  In Mozilla, for instance, if you
send the content type "text/html", the HTML parser is
used.  If you send one of the xml content types, then the XML parser
is used.  It makes a big difference.  Behaviors change
significantly.  For instance, I think Mozilla recognizes, <form
id="blah"> when using the XML parser rather than <form
name="blah"> with the HTML parser.  This is quite
important if you are trying to use valid XHTML where the "name"
attribute has been deprecated in XHTML1.0 and removed from XHTML1.1 in
favor of "id".

> > > 3) setting
> of boolean attributes does not work
> > 
> > Yep, definitely need this patched!  Did you provide this
> patch
>
> no, I haven't patched this. I added a workaround to my application
> code
> for now (using setAttribute(attr, attr)). Would be happy if 
> somebody
> fixed it.

Yes, hopefully soon!

> > Maybe provide a
> .zip file with all gathered patches included? 
>
> google can find all the patches I posted. Also David's patch was at
> the
> top of google's list.
>
> > > 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;
>
> any idea what to patch in XMLC? Right now I use David's patch to
> keep
> the single quotes untranslated...

Not completely sure, otherwise I'd do it.  If someone can point out
where this is done, I'll make the change and commit it.

> > > 6)
> URLRewriter does not work
> > 
> > What was the issue with this one?  I don't remember.
>
> URLRewriter is not called since the XHTML page is instanceof
> XMLObject.
> I posted a longish thread (replying to myself most of the time)
> about
> all that one or two weeks ago.

I think you mean "is *not* an instance of XMLObject",
right?  Yeah, I wonder why not?  I'll have to re-read your
message about that.

Jake

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