create new tag
, view all tags

Bug: Minor XHTML Non-Compliance in Stock Templates

A number of templates and library routines have small problems that prevent them from being XHTML compliant. This causes problems when strict XHTML is required, as with the LaTeXToMathMLPlugin.

Test case


In templates/preview.tmpl I had to change as follows:

<   <li> To <b>save</b> changes: Press the [Save Changes] button.
<   <li> To make <b>more changes</b>: Go back in your browser.
<   <li> To <b>cancel</b>: Go back twice.
>   <li> To <b>save</b> changes: Press the [Save Changes] button. </li>
>   <li> To make <b>more changes</b>: Go back in your browser. </li>
>   <li> To <b>cancel</b>: Go back twice. </li>
<    <input type="checkbox" name="unlock" %RELEASEEDITLOCKCHECKBOX% /> Release edit lock
>    <input type="checkbox" name="unlock" value="%RELEASEEDITLOCKCHECKBOX%" /> Release edit lock
<    <font size="-1">(<a target=DontNotify" onClick="return launchWindow('%TWIKIWEB%','DontNotify')" href="%SCRIPTURLPATH%/view%SCRIPTSUFFIX%/%TWIKIWEB%/DontNotify">help</a>)</font>
>    <font size="-1">(<a target="DontNotify" onClick="return launchWindow('%TWIKIWEB%','DontNotify')" href="%SCRIPTURLPATH%/view%SCRIPTSUFFIX%/%TWIKIWEB%/DontNotify">help</a>)</font>

  • Fixed, but left RELEASEEDITLOCKCHECKBOX unchanged since the docs state to use checked="checked" -- PTh - 20 Mar 2004
  • Seems that XHTML requires input with two tags
    -- SC


In templates/search.tmpl the changes required are:

<     <b><font color="red">%LOCKED%</font><b>
>     <b><font color="red">%LOCKED%</font></b>

  • Was already fixed -- PTh - 20 Mar 2004


and similarly in templates/changes.tmpl:

<     <b><font color="red">%LOCKED%</font><b>
>     <b><font color="red">%LOCKED%</font></b>

  • Fixed -- PTh - 20 Mar 2004


In templates/oopsmore.tmpl

<         in <input type="checkbox" name="raw"> raw text format

>         in <input type="checkbox" name="raw" /> raw text format

  • Fixed -- PTh - 20 Mar 2004


The <nop> tags don't seem to be correctly processed out, leaving XHTML browsers thinking there is a </nop> tag coming. So I had to change templates/rename.tmpl

< Allow non <nop>WikiWord for the new topic name. <br />
> Allow non TWiki.WikiWord for the new topic name. <br />
and templates/renamebase.tmpl
< ---++ Change links in topics that refer to <nop>%TOPIC% in the %WEB% Web:
> ---++ Change links in topics that refer to %TOPIC% in the %WEB% Web:
< ---++ Change links in topics that refer to <nop>%WEB%.<nop>%TOPIC% in any Web:
> ---++ Change links in topics that refer to %WEB%.%TOPIC% in any Web:

  • Was already fixed in a different way in the rename script (nop filtering was missing) -- PTh - 20 Mar 2004

Edit script

In bin/edit a table marker isn't closed correctly:

<              . '</dt></tr></table>';
>              . '</td></tr></table>';

  • Was already fixed -- PTh - 20 Mar 2004

Stock Pages

  • This is fixed -- PTh - 16 Jul 2004

rdiff Pages

An interesting problem crops up with the rdiff script. If previous markup is not XHTML compliant then it will turn up again in the diffs. A possible solution here is to integrate the HMTL Tidy library. I see there is a Perl version in the works. Perhaps a meta-data tag could be attached to any pages that, upon save, do not pass the tidy test. This would be a signal that on-the-fly repair might be appropriate.

I've seen this recommended on XhtmlConsideredHarmful. Experimentally I've shoe-horned this into the view script and it seems to do the trick most of the time. I've not had time yet to figure out exactly when.

In Library Modules (TWiki.pm)

In lib/TWiki.pm, somehow leading <nop> tags are not getting removed from some cases, like when attach is run:

<         $text = "<nop><h$theLevel><a name=\"$anchorName\"> </a> $text <\/h$theLevel>";
>         $text = "<nop><h$theLevel><a name=\"$anchorName\"> </a> $text <\/h$theLevel></nop>";
<         $text = "<nop><h$theLevel><a name=\"$anchorName\"> $text <\/a><\/h$theLevel>";
>         $text = "<nop><h$theLevel><a name=\"$anchorName\"> $text <\/a><\/h$theLevel></nop>";

  • Was already fixed in a different way in the attach script (nop filtering was missing) -- PTh - 20 Mar 2004

Also in lib/TWiki.pm the sub handleUrlEncode emits the <br /> tag without the trailing slash (shows up rendering <pre> sections when doing an oops page with %PARAM% data in particular). To fix:

<     $theStr =~ s/[\n\r]/\%3Cbr\%20\%3E/g;
>     $theStr =~ s/[\n\r]/\%3Cbr\%20\%2F\%3E/g;
See HandleUrlEncodeNotSmartEnough for another patch to this subroutine.

  • Fixed -- PTh - 20 Mar 2004

This one crops up during rename/move operations, the select modifier in the option tag isn't set correctly:

<     my $marker    = extractNameValuePair( $theAttr, "marker" ) || "selected";
>     my $marker    = extractNameValuePair( $theAttr, "marker" ) || 'selected="1"';

  • Fixed with 'selected="selected"' which is the recommended XHTML syntax. Also did a minor enhancement to pre-select multiple webs -- PTh - 20 Mar 2004


TWiki version: 01 Feb 2003
TWiki plugins:  
Server OS: Linux, Red Hat 8.0
Web server: Apache 2.0
Perl version: 5.8.0
Client OS: Linux, Red Hat 8.0
Web Browser: Mozilla 1.0.1

-- SimonClift - 15 Apr 2003

Follow up

Just to bring it up again here: The <p /> which TWiki generates from time to time is also invalid XHTML markup. A blank paragraph is correctly marked up as: <p></p>

TWiki's code should be updated accordingly.

-- TomKagan - 16 Apr 2003

Indeed: http://www.w3.org/TR/xhtml1/#C_2

-- SimonClift - 22 Apr 2003

I've noted a patch in LaTeXToMathMLPluginDev to the plug-in interface that lets me get past most of the annoying XHTML problems. By adding a content type service to the plug-in interface, only those pages that contain my generated MathML get served as application/xhtml+xml and hence all other pages don't have to contain strict mark-up.

-- SimonClift - 28 Apr 2003

Perhaps someone can clarify for me. I've just installed the 01-Feb-2003 and see many gotchas with it, so I turn to the follow-up/bugreport and find pages like this.

The table below says the implementation date is TWikiRelease01Feb2003. But the evidence is that it isn't so, and in fact the "Environment" table makes it clear that this problem is in TWikiRelease01Feb2003.

What's going on here? What is the 'implementation date' supposed to mean?

Is there no "diffs" for this item? It don't see it in the CVS for preview.tmpl, changes.tmpl ...

Am I missing something here about policy?

-- AntonAylward - 29 Apr 2003

Oops... my mistake on the implementation date...

I hope these patches will go in the next release. These bugs don't interfere with TWiki when it's working in its normal mode ( text/html ) since most browsers are pretty tolerant of small mistakes. However, if you want to use MathML in the text then you need application/xhtml+xml as the content type, and Mozilla gets very, very picky.

-- SimonClift - 29 Apr 2003

Simon, your plugin API changes look quite useful - can you propose them at MorePluginHooks?

-- RichardDonkin - 29 Apr 2003

Erased previous note... the hook works, my module didn't use it correctly. I've put in the suggestion in MorePluginHooks.

-- SimonClift - 05 May 2003

Fix record

Thanks for reporting. Staring slowly on fixing this. For now bin/attach, bin/changes, bin/edit, bin/rename is fixed and in TWikiAlphaRelease. The <nop> filtering is done in the scripts, not in TWiki.pm.

-- PeterThoeny - 01 May 2003

'Page locked by another user' screen may not be XHTML. Error from XSLt document function is expected ';' this may be from a '&' that should be &amp;

  • Changed links that had param1=value1&param2=value2 to param1=value1&amp;param2=value2 -- PTh - 20 Mar 2004

-- JohnCoe - 17 Mar 2004

Fixed issues reported by SimonClift, except for topic fixes.

In TWikiAlphaRelease and TWiki.org.

-- PeterThoeny - 20 Mar 2004

the line:    (More options in WebSearch) in WebTopicViewTemplete may need to be: &nbsp;&nbsp; (More options in WebSearch) It is preventing a DOM load. This precents use of RSS info for other uses.

-- JohnCoe - 29 Mar 2004

I've just been testing the TWikiBetaRelease2004x05x07 against LaTeXToMathMLPlugin and came up with a problem in templates/preview.tmpl, in the use of the input tags. My browser complains that

   <input />
is not valid, but likes
I suppose input is not considered an XHTML EMPTY tag.

-- SimonClift - 19 Jul 2004

Hmm, what kind of browser are you using? May be you stumbled over a not-closed input tag entered by the user or supplied by a Plugin?

Empty <input /> tags seem to be valid XHTML 1.0 Transitional as indicated in the DTD: <!ELEMENT input EMPTY>. Also, it passes the validator test.

-- PeterThoeny - 20 Jul 2004

I'm using Mozilla 1.4.1, which is stock on the Fedora Core 1 distro. OK, perhaps it is a Mozilla 1.4.1 bug then, I suppose it's time I updated. indifferent

-- SimonClift - 20 Jul 2004

Edit | Attach | Watch | Print version | History: r22 < r21 < r20 < r19 < r18 | Backlinks | Raw View | Raw edit | More topic actions
Topic revision: r22 - 2004-07-20 - SimonClift
  • 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-2018 by the contributing authors. All material on this collaboration platform is the property of the contributing authors.