I don't know whether to call this a bug or not, but since it does cause problems, here goes.

When TWiki renders formatted text into HTML, it does not insert end tags for many generated tags (p, ul, li, dt, dd etc.). While this is generally not a problem for most browsers, it's both technically incorrect, and i've found a situation where it acually does harm.

I've been working on adding stylesheets to TWiki, and actually have it working - and it mostly looks great! However, I got funny results when trying to style paragraph <p> and unordered lists <ul>. In the case of the 'p' tag, styling is mostly ignored. In the case of ul tags, I got funny/ugly rendering from the browser (IE 5.5).

I think this happens because the browser never sees what it thinks is a complete element - and i'm guessing that "apply styles" is done on seeing the end tag, not a new start tag that automagically ends the previous element.

I also wonder if this might not slow browser side rendering somewhat?

It's also worth noting that implied end tags where never official and, with the advent of XHTML and XML, are actually illegal. Someday browsers might not be so permissive...

I'd take a stab at fixing the rendering in Wiki.pm in Wiki::GetRenderedVersion, but i'm not sure I entirely understand the code. I think it's just a matter of enclosing the matche components in parens and then subbing <p>$1</p>, but it might also need something like the "$insidePRE" or "$insideTABLE" flags. It's not clear to me how all the newlines can be removed (as I read it) and yet, it still can figure out where to put 'p' tags!

-- DavidLeBlanc - 01 Apr 2001

Actually, omitting some end tags in html was really legal and specified in the spec and DTD. Some tags (hr, br, img) even must not have end tags (<hr></hr> is an error). Omitting </td>, </li> is really correct.

What you experience is actually bugs in CSS styling in some browsers.

The best short-solution would be to render in xhtml instead of html. A nice solution would be to render in xml, so that the TWiki engine could render "abstract" xml concepts and leave the styling to CSS and/or XSL in templates. However, browser support for this is not really there yet, and could be set as an option but not the default.

I changed the classification to feature instead of bug as the HTML generation is not buggy. Changing to an XHTML/XML generation is more than just a bug fix, it would involve a redesign, and may have unwanted side effects (for instance, one could not include anymore "legacy" html in the text, but correct XHTML, that many people may not be accustomed to yet.

-- ColasNahaboo - 02 Apr 2001

Alas, when those end tags ARE in place, then the CSS works quite correctly! I check on both NS 6 (Mozilla actually) and IE and they both worked as expected on "balanced" markup and didn't on markup with omitted end tags.

So called empty tags such as <br> (actually, elements with no content) indeed may not have an end tag, but those tags which have both a start form and an end form are preferred to be used in pairs. I don't have the time to go off and check if the SGML DTD's for HTML do indeed allow for ommited end tags (later)ok, it does, but I was under the impression that, while browsers would accept them, they are at best poor form.

I most sincerely beg to differ.. THIS IS A BUG, if for no other reason then that it causes incorrect operation of stylesheets. If you insist that TWiki can't be fixed to generate cannonically correct HTML, then please let me know and i'll discontinue working towards adding stylesheets to TWiki. It would just generate more bug reports when it fails to work as a user expects, especially given that it will work for them on their favorite browser(s) if the markup is correct.

BTW, one measure of whether or not TWiki generated code is buggy is to useHTML Tidy at W3.org. It's very good at checking and reporting conformance. It will also correct markup too, which might be informative as well.

-- DavidLeBlanc - 02 Apr 2001

Ok, I went and looked at the HTML 3.2 recommendation (http://www.w3.org/TR/REC-html32) at w3.org and found this (excerpted):

P paragraphs The paragraph element requires a start tag, but the end tag can always be omitted. Use the ALIGN attribute to set the text alignment within a paragraph, e.g.

UL unordered lists These require start and end tags, and contain one or more LI elements representing individual list items.

OL ordered (i.e. numbered) lists These require start and end tags, and contain one or more LI elements representing individual list items.

DL definition lists These require start and end tags and contain DT elements that give the terms, and DD elements that give corresponding definitions.

PRE preformatted text Requires start and end tags. These elements are rendered with a monospaced font and preserve layout defined by whitespace and line break characters.

DIV document divisions Requires start and end tags. It is used with the ALIGN attribute to set the text alignment of the block elements it contains. ALIGN can be one of LEFT, CENTER or RIGHT.

CENTER text alignment Requires start and end tags. It is used to center text lines enclosed by the CENTER element. See DIV for a more general solution.

BLOCKQUOTE quoted passage Requires start and end tags. It is used to enclose extended quotations and is typically rendered with indented margins.

FORM fill-out forms Requires start and end tags. This element is used to define a fill-out form for processing by HTTP servers. The attributes are ACTION, METHOD and ENCTYPE. Form elements can't be nested.

ISINDEX primitive HTML forms Not a container, so the end tag is forbidden. This predates FORM and is used for simple kinds of forms which have a single text input field, implied by this element. A single ISINDEX can appear in the document head or body.

HR horizontal rules Not a container, so the end tag is forbidden. attributes are ALIGN, NOSHADE, SIZE and WIDTH.

TABLE can be nested Requires start and end tags. Each table starts with an optional CAPTION followed by one or more TR elements defining table rows. Each row has one or more cells defined by TH or TD elements. attributes for TABLE elements are WIDTH, BORDER, CELLSPACING and CELLPADDING.

As you can see, some end tags ARE mandatory, and include some of the ones that I reported (UL, DL ...).

-- DavidLeBlanc - 02 Apr 2001

The rendering of TWiki can (and should) be made cleaner. I did some little of that already, but still way to go. As a goal, the TWiki core should be HTML 3.2 compliant (low RequiredEnvironmentForTWiki), but lean towards XHTML (clean standard). I am not sure if this is at all possible. The core should be as clean as possible, so that users can tweak the templates for CSS for example.

To do items:

• Change all tags to lower case
• Use closing tags as recommended by XHTML, but not if it breaks HTML 3.2

The TopicClassification of this topic is bouncing all over the place, I just set it to FeatureToDo

-- PeterThoeny - 03 Apr 2001

Thanks Peter. I'll continue to work on stylesheets! I really think they'll empower TWiki a lot.

About your "to do items": could you add "remove styling from generated html"? If you're uncomfortable with that would it be possible to add some sort of variable that would have style stuff in it based on some option and empty if the option is set for "no generated styles"?

WRT to end tags, AFAIK using an otherwise optional (omitted tag in SGML parlance) is never an error, and so using end tags should not break conformance with HTML 3.2 and does conform with XHTML. XML creators chose to not have optional start/end tags because they vastly complicate parsing of markup since it puts the parser in the postion of having to guess what tag goes where. As we all know, computers don't guess very well

Nicholas, if I was abrupt in yesterday's posting, I apologize!

-- DavidLeBlanc - 03 Apr 2001

Follow up in ConvertToXHTML10.

-- PeterThoeny - 16 Apr 2001