Jake,
Yes, it's the tag splitting that's causing trouble, not the clear
attribute. Opening the following file in Firefox and IE will clearly
display which browser is a #&$#ing piece of @#&$.
---
<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Transitional//EN"
"
http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd";>
<html xmlns="
http://www.w3.org/1999/xhtml";>
<head>
<title>Test</title>
</head>
<body>
<table>
<tr>
<td>
One<br/>Two<br/>Three
</td>
<td>
One<br clear="none"/>Two<br clear="none"/>Three
</td>
<td>
One<br></br>Two<br></br>Three
</td>
</tr>
</table>
</body>
</html>
---
God, I hate IE. If you could make that setXHTMLCompatiblity() change
and either do a release or email me the built jar, that would be great.
Cheers,
Erik
On Apr 16, 2007, at 9:14 PM, Jacob Kjome wrote:
Yep, you found the cause, even if you didn't understand it.
<!ATTLIST %br.qname;
clear ( left | all | right | none ) 'none'
That defines the default value for the "clear" attribute to be
"none". The
parser sees this and fills it in. There's not a whole lot to do here.
Technically, the parser is absolutely correct and following the DTDs
instructions perfectly.
Oh, and I just remembered why it is printing out <br ...></br>
instead of <br
/>. This is a result of the options.setXHTMLCompatiblity(true).
This option
is meant for tags such as SCRIPT and STYLE. Some browsers don't
deal with
<script/> and <style/> very well, and accept <script></script>,
<style></style>
much better, even if there is no content inside those tags. But BR
probably
shouldn't be treated the same way since its content model is always
empty.
I'll have a look at the code tonight.
Can you do a test to see if <br clear="none" /> has the same browser
compatibility issues as <br clear="none"></br>? If it doesn't,
then the fix is
to not include BR in the tags to apply the XHTML compatibility flag
to. Oh,
also check that <br clear="none" /> and <br /> exhibit the same
behavior. I'd
like to the leave the DTD alone.
Jake
Quoting Erik Rasmussen <rasmussenerik@xxxxxxxxx>:
On Apr 16, 2007, at 6:21 PM, Jacob Kjome wrote:
I don't have time to check ATM, because I'm at work.
It's a shame that you selfless OSS heroes have to have day jobs too.
However, can you look at
the DTD? Does it have default values defined for these
attributes? If so, the
parser is probably filling those in automagically.
I don't speak DTD very fluently, but the relevant lines of xhtml.jar/
org/enhydra/xml/xhtml/dtd/w3/1.1/xhtml11-flat.dtd seem to be:
---
<!-- br: forced line break ............................. -->
<!ENTITY % br.element "INCLUDE" >
<![%br.element;[
<!ENTITY % br.content "EMPTY" >
<!ENTITY % br.qname "br" >
<!ELEMENT %br.qname; %br.content; >
<!-- end of br.element -->]]>
<!ENTITY % br.attlist "INCLUDE" >
<![%br.attlist;[
<!ATTLIST %br.qname;
%Core.attrib;
<!-- end of br.attlist -->]]>
---
Sure looks like there isn't anything about a "clear" attribute
there. Perhaps I'm looking in the wrong place?
Not sure what could be done
about that other than changing the DTD (which is feasible, since
XMLC contains
its own local copies of the DTD, but care would need to be taken
for any change
to a published DTD)
The "clear" attribute is deprecated in the HTML4 spec. It wasn't
deprecated in HTML3.2.
or having the user delete the attribute (which would be
annoying, I admit).
Indeed.
As far as outputing <br ...></br> instead of <br .../>, that's
probably
something I can control in the serializer code. I'll try to look
into it
tonight. There's no reason it should be output with the former
format as BR's
content model is empty, at least as far as I am aware.
The XHTML spec says, "Use the minimized tag syntax for empty
elements, e.g. <br />, as the alternative syntax <br></br> allowed by
XML gives uncertain results in many existing user agents."
Oooh! I just found this:
---
<!ATTLIST %br.qname;
clear ( left | all | right | none ) 'none'
---
on this page: http://www.w3.org/TR/xhtml-modularization/
dtd_module_defs.html
I'm not familiar enough with XML and DTDs to know if the XHTML
Modularization 1.1 DTD applies to XMLC and this particular problem.
Did my research help at all? I can't say that it cleared things up
any for me. :-(
Thanks for your promptness,
Erik
--
You receive this message as a subscriber of the xmlc@xxxxxxxxxxxxx
mailing list.
To unsubscribe: mailto:xmlc-unsubscribe@xxxxxxxxxxxxx
For general help: mailto:sympa@xxxxxxxxxxxxx?subject=help
ObjectWeb mailing lists service home page: http://www.objectweb.org/
wws
--
You receive this message as a subscriber of the xmlc@xxxxxxxxxxxxx mailing list.
To unsubscribe:
mailto:xmlc-unsubscribe@xxxxxxxxxxxxx
For general help:
mailto:sympa@xxxxxxxxxxxxx?subject=help
ObjectWeb mailing lists service home page:
http://www.objectweb.org/wws
| 