Tags:
create new tag
view all tags

Bug: Mozilla doesn't style some XHTML tags

I've been experimenting with using CSS with TWiki again, and ran into the interesting situation that Mozilla-0.9.9 won't style (at least) <p /> tags. It might be having troubles with all the psuedo omitted end tag elements, but i'm not sure. It does style other tags such as headings, tables and list items, but not those.

Test case

Add a CSS link to twiki.templ. Create a stylesheet with a p element style. Works on IE 6.0, but not Mozilla 0.9.9

Environment

TWiki version: Beta 4/14/2002
TWiki plugins: n/a
Server OS: Win 2k
Web server: apache 1.3.23
Perl version: ActiveState
Client OS: Win 2k
Web Browser: Mozilla & IE

-- DavidLeBlanc - 20 Apr 2002

Follow up

By the way, it's Mozilla 0.9.9, not 0.99...

This looks like a Mozilla bug, see if it's already reported at http://bugzilla.mozilla.org. The attached HTML passes the W3C's validation as HTML 4.0, and the XHTML validation only causes a problem on non-Paragraph elements. However, this is fairly unusual HTML, which may explain why Mozilla's HTML editor deletes it and why the HTML 4.01 spec's examples always have a separate closing <P> tag.

It would be best to avoid this construct - just close the <P> tag separately and it should work.

This is not a TWiki bug, but it would be good to support CSS in templates anyway, since it is silently ignored by browsers that don't support it (as far as I can tell). Some sort of %STYLESHEET% variable would be a good start.

-- RichardDonkin - 21 Apr 2002

Perhaps you've overlooked that Twiki itself now generates <p /> tags in lieu of figuring out where paragraphs end. TWiki's former behavior was to omit p end tags altogether (which, in fact, is what it really still does).

If TWiki's objective is to be a cross-platform tool then Mohamed needs to come to the mountain, not blame the mountain for not coming to Mohamed. In other words, please make TWiki do the right thing (balance open/close tags for elements with content and thus work on both IE and Mozilla!)

I agree about the %STYLESHEET% variable, and I think it should be settable at the user, web and site levels with appropriate overrides as desired. IMO it's important to support user level setting to facilitate supporting people with disabilities.

Not trying to irritate anyone by setting this bug back to active, just don't know if rejected bugs with new comments get noticed.

-- DavidLeBlanc - 22 Apr 2002

I actually went and read the XHTML-1.0-Transitional spec and DTD, and found that TWiki's use of <p /> for non-empty paragraphs is possibly in error. Referring to http://www.w3.org/TR/xhtml1, Section 4.3 says:

4.3 For non-empty elements, end tags are required
In SGML-based HTML 4 certain elements were permitted to omit the end tag; with 
the elements that followed implying closure. This omission is not
permitted in XML-based XHTML. All elements other than those declared in the DTD
as EMPTY must have an end tag.
CORRECT: terminated elements

<p>here is a paragraph.</p><p>here is another paragraph.</p>

INCORRECT: unterminated elements

<p>here is a paragraph.<p>here is another paragraph.

It does allow for some content containing elements (those whose content model is "EMPTY" to use the <tag /> syntax, but to me it reads as though this isn't preferred.

Paragraphs, per the DTD, don't have an EMPTY content model. (Confusingly, Appendix C-3 suggests that p elements containing no content use the <p /> syntax, however there is no language in the balance of the document supporting the use of such a construct at all, and Section 4.3 specifies open/close tags.)

-- DavidLeBlanc - 22 Apr 2002

Good point, wasn't aware that TWiki was generating this. The text of the spec quoted seems to say that the P element should have a closing tag, since it doesn't have an EMPTY content model, as you point out - thanks for researching this.

Based on this, I think that generating unclosed P elements is a TWiki bug, since TWiki is aiming for XHTML conformance.

-- RichardDonkin - 23 Apr 2002

Interesting, somehow I missed or ignored this topic prior to PeterThoeny pointing it out to me (from KonquerorVerticalWhitespaceProblemResolution).

I'm confused about what TWiki does and why. It seems to emit a <p /> to show a blank line — it does that to separate paragraphs and when the raw text file contains a blank line. TWiki does not start, end, or surround plain text paragraphs with appropriate p tags.

Am I correct in thinking that the most correct XHTML (and HTML?) would be (from above):

<p>here is a paragraph.</p><p>here is another paragraph.</p>

Thus, the "normal" vertical whitespace separation between two paragraphs (a space that appears to be a blank line) would be by virtue of top and bottom margin, border, and padding specifications for the p element? Thus, there should normally be no need to emit a <p /> at all.

If TWiki did want to emit a blank line for some reason, per TomKagan (on KonquerorVerticalWhitespaceProblemResolution), the more proper way to do that would be something like <p>&nbsp;</p>?

-- RandyKramer - 24 May 2003

And, I'm confused about something else — on Mozilla (1.3) and IE (5.5) TWiki pages render almost identically (at least as far as vertical whitespace goes), konqueror seems to be the odd man out. Did something change in IE 6?

What I do think I notice is that IE and Mozilla may render a single <p /> tag under some circumstances, but never multiple consecutive <p /> tags. It is hard to describe, and I'm not sure I fully understand what's going on (or to state it more positively), I know I don't fully understand what's going on.

See Konqueror Renders Multiple Consecutive <p /> Tags, Mozilla and IE Do Not for my best attempt at describing the problem.

-- RandyKramer - 27 May 2003

I've started using Konqueror a bit, and the rendering of paragraph whitespace is quite annoying. Since doing proper rendering of <p>....</p> around paragraphs would make TWiki more XHTML compliant, it seems like a Good Thing anyway, so I shall try to think up a good algorithm that doesn't break things too much and also doesn't emit paragraph markers in front of non-paragraph elements (e.g. <ul> lists).

-- RichardDonkin - 09 Oct 2003

Well, I would just like to point (again) that going to XHTML is in my opinion a bad idea. XHTML is great for machine-generated data, not for systems like TWiki where some parts are hand-written (the contents). Main points:

  • Either you are 100% XHTML or not. Going "towards" it gives you nothing but falling into a grey zone where browser can show unexpected behavior. Either you have the XHTML or HTML DOCTYPE, a mix of the two is just invalid in both worlds.
  • What is the gain in being XHTML? On the other hand we would lose a lot of writing convenience of HTML, I do not want to have to close my LI tags or put quotes on border=0 attributes. And I definitely will never be able to educate users in typing valid XHTML by hand. Users just try things until it looks good in their browser. Our site will then just be a set of invalid XHTML pages instead of the current valid HTML situation.
If you want to process data coming from TWiki, just use an HTML parser, or use Tidy.

See: XhtmlConsideredHarmful

My proposed fix is thus to remove all the XHTML-isms from TWiki and going back to proper HTML.

PS: This is not an anti-XML rant. Under my direction, the Koala project made a lot of pioneering work on XML, including one of the firsts XML, XSl, and CSS validators. This is just a question of using the right tool for the job.

-- ColasNahaboo - 10 Oct 2003

In fact a lot of arguments for XHTML have been raised in XhtmlConsideredHarmful. I have added a few extra.

-- ArthurClemens - 11 Oct 2003

I don't want to get sucked into the whole XHTML argument (it seems like a good idea but if we can't have XHTML conformant users it may be better to just have a DOCTYPE declaring HTML 4.0 rather than XHTML...) - however, regardless of which camp you belong to, the current markup for paragraphs displays poorly in Konqueror (and presumably SafariBrowser), and prevents paragraphs being styled in Mozilla, so there's a practical reason to fix this. I have some code that is just about working, but needs some fixes to handle corner cases. This is quite hard to get right due to use of embedded HTML etc, but it's quite close.

-- RichardDonkin - 15 Oct 2003

Wonderful!

-- RandyKramer - 16 Oct 2003

I've attached the code I wrote - it is not fully working for important corner cases, but might help someone. Be warned, this is a lot harder than it looks - you may need to analyse a lot of the para to determine if it is 'pure HTML' rather than 'text para with some HTML'. The latter needs para rendering, the former does not...

-- RichardDonkin - 20 Jan 2004

Fix record

Topic attachments
I Attachment History Action Size Date Who Comment
HTMLhtml Test_page2.html r2 r1 manage 0.6 K 2002-04-21 - 09:27 UnknownUser Page showing this issue
Unknown file formatpatch paragraphs.patch r1 manage 2.3 K 2004-01-20 - 06:44 UnknownUser INCOMPLETE CODE for improved para rendering, needs TWiki.pm rev 1.260
Edit | Attach | Watch | Print version | History: r14 < r13 < r12 < r11 < r10 | Backlinks | Raw View | Raw edit | More topic actions
Topic revision: r14 - 2004-01-20 - RichardDonkin
 
  • Learn about TWiki  
  • Download TWiki
This site is powered by the TWiki collaboration platform Powered by Perl Hosted by OICcam.com Ideas, requests, problems regarding TWiki? Send feedback. Ask community in the support forum.
Copyright © 1999-2024 by the contributing authors. All material on this collaboration platform is the property of the contributing authors.