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
>[email protected]
>http://www.enhydra.org/mailman/listinfo.cgi/xmlc