Re: still too early for XHTML :-((

At 08:55 PM 4/9/2003 +0200, you wrote:
> On St, 2003-04-09 at 15:29, Jacob
> Kjome wrote:
> > In order to prove it is a hack
>
> It's not real hack but it is a browser specific workaround. 
> Remember
> when I suggested to add an empty space before "/>" in order
> to make it
> more browser compatible? And Mark D. said that it's not necessary,
> that
> I can as well go for real HTML if I have problems with XHTML in
> browsers..

Sure, but that ignores the fact of what XHTML1.0 is.  It it a
transitional language to bring the HTML4 spec into the world of
XML.  The workarounds such as adding a space before
"/>" and <script></script> are valid things to
do since we make the decision to write XHTML compliant pages to gain the
benefits of XML, but no browser is XHTML1.0 compliant yet (Mozilla maybe,
but it wasn't the original goal).  We forsee XHTML browser
compliance and want to be there already when it happens.

You could make a better argument by stating that XHTML1.1 shouldn't use
any hacks or workarounds.  The XHTML library in XMLC is useless if
it generates web pages that don't work in most browsers.  So, be
lenient for XHTML1.0 and be strict for XHTML1.1.

> > 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. 
>
> right. 

You miss my point.  Just be because you feel it is a hack doesn't
make it one.  I've already explained why it isn't 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.
>
> Sounds like you consider XHTML 1.0 buggy as IMHO it allows the
> <script/>
> syntax.

Only in the sense that HTML4 probably should declare the end tag as
"Optional" rather than "Required".  Beyond that,
it isn't a bug.  It is part of the HTML4 spec of which XHTML1.0 is
merely the XML'ized version of, therefore needs to enforce all the rules
that HTML4 enforces.  Only if </script> were
"Optional" could the <script /> syntax be considered
correct.

> I personally don't
> care. As you might have read in latest message from
> me, I patched enhydra in order to get <script></script> and
> nothing else
> as I simply have to support IE and I want to feed it with XHTML. And
> my
> tests confirmed that this is the way to go - everything seems to work
> OK
> in both IE and Mozilla (Opera 7.03 is another story).

Opera7 doesn't support XHTML?  How so?  What behavior do you
see?

> All I want to achieve
> is to be able to use *unmodified* Enhydra releases
> so my main aim is to get all my patches accepted by the 
> Enhydra/XMLC
> maintainers. If you all are happy with the <script></script>
> specific
> support and will add it to XMLC CVS ASAP then I am more than happy.

me too.

> > > this wasn't
> about doctype. Enhydra didn't allow me to include "ID"
> > > to <TITLE>. Latest XHTML 1.0 allows that.
>
> > Why would you want to do that?
>
> Got HTML files from our designer and the XMLC couldn't compile it.
> He
> told me his files are 100% OK and really - the validator agreed. So
> I
> had to fix the compiler, that's obvious.

No, it isn't obvious.  I still don't understand what you mean. 
You are saying that your templates won't compile unless you put an id
attribute on the <title> element?  Or are you saying that the
java code counts on a method like getElementMyTitle() based on <title
id="MyTitle"> existing in the markup?  I have lots of
HTML templates that don't have an ID on the title element.  Why
would one be required?

> > 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?
>
> yes. But I can't swear that this doctype is generated by enhydra -
> it
> might as well be leftover from the original html file. In the XHTML
> mode
> the XMLC preserves the original layout. It is very unusual - compared
> to
> the one longish line (the HTML output from XMLC/Enhydra).

I highly doubt that it preserves the original markup.  More likely
is that it is doing pretty printing or something.  I would
definitely like to find out if compiling XHTML preserves the doctype or
not.  David?  Richard? Mark?  Any confirmation on
that?  Compiling standard HTML templates certainly doesn't preserved
the doctype.

> > mistyped because
> "text/html" is obviously a "content type"
>
> that's the thing in the header of the data stream. When it was
> "text/xml" browsers didn't work (_javascript_ couldn't handle
> forms etc).
> The first few lines of my dynamically generated pages are as
> follows:

Well, yes.   This makes sense for browsers that don't support
XML or XHTML.  Mozilla mostly does but then you have to live by the
XML parser which probably doesn't understand <form
name="">, rather <form id="">....and
such.

Jake