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
Preview
In
templates/preview.tmpl
I had to change as follows:
25,27c25,27
< <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>
52c52
< <input type="checkbox" name="unlock" %RELEASEEDITLOCKCHECKBOX% /> Release edit lock
---
> <input type="checkbox" name="unlock" value="%RELEASEEDITLOCKCHECKBOX%" /> Release edit lock
56c56
< <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
<input></input>
-- SC
Search
In
templates/search.tmpl
the changes required are:
33c33
< <b><font color="red">%LOCKED%</font><b>
---
> <b><font color="red">%LOCKED%</font></b>
- Was already fixed -- PTh - 20 Mar 2004
Changes
and similarly in
templates/changes.tmpl
:
32c32
< <b><font color="red">%LOCKED%</font><b>
---
> <b><font color="red">%LOCKED%</font></b>
- Fixed -- PTh - 20 Mar 2004
Oops
In
templates/oopsmore.tmpl
33c33
< in <input type="checkbox" name="raw"> raw text format
---
> in <input type="checkbox" name="raw" /> raw text format
- Fixed -- PTh - 20 Mar 2004
Rename/Move
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
9c9
< Allow non <nop>WikiWord for the new topic name. <br />
---
> Allow non TWiki.WikiWord for the new topic name. <br />
and
templates/renamebase.tmpl
41c41
< ---++ 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:
45c45
< ---++ 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:
247c247
< . '</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:
2292c2292
< $text = "<nop><h$theLevel><a name=\"$anchorName\"> </a> $text <\/h$theLevel>";
---
> $text = "<nop><h$theLevel><a name=\"$anchorName\"> </a> $text <\/h$theLevel></nop>";
2294c2294
< $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:
1755c1755
< $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:
1694c1694
< 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
Environment
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
&
- Changed links that had
param1=value1¶m2=value2
to param1=value1&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: (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
<input></input>
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.
--
SimonClift - 20 Jul 2004