Want to take part in these discussions? Sign in if you have an account, or apply for one below
Vanilla 1.1.10 is a product of Lussumo. More Information: Documentation, Community Support.
1 to 7 of 7
What browser are you using?
I've not heard of that error before. nLab pages don't quite validate according to the strictest interpretation of the XHTML+MathML+SVG code, but that's due to something a little daft in the SVG part of the specification. None of the validation errors are to do with what you mention.
(I was quite impressed that there's a poll somewhere about the nLab! Less impressed when I saw the number of people who voted ...)
For the record, I'm using Firefox 3.5.7 on Linux.
Okay, was talking to the admin at work, and he suggested that perhaps the validation wasn't checking everything. I thought this was a silly idea but checked anyway.<br /><br />In the xml 1.0 spec it says<br /><br /><blockquote >The ampersand character (&) and the left angle bracket (<) MUST NOT appear in their literal form, except when used as markup delimiters, or within a comment, a processing instruction, or a CDATA section. If they are needed elsewhere, they MUST be escaped using either numeric character references or the strings " &amp; " and " &lt; " respectively. The right angle bracket (>) may be represented using the string " &gt; ", and MUST, for compatibility, be escaped using either " &gt; " or a character reference when it appears in the string " ]]> " in content, when that string is not marking the end of a CDATA section.</blockquote><br /><br />Those instances clearly aren't within a comment or a CDATA section, and it looks like processing instructions are <a href="http://www.javacommerce.com/displaypage.jsp?name=pi.sql&id=18238" >something wierd</a>.<br /><br />So it looks like it is invalid. I think.
I've just looked at the page source and I don't see what you see. I see:
<script src="/javascripts/page_helper.js?1266480024" type="text/javascript"></script>
and similarly in the other place that you mention. Try clearing your cache and trying again.
The maintainer of Instiki assures me that the garbage is not produced by Instiki. He further suggests that it is produced by a proxy and that it is the proxy that is broken, not instiki! It may be that the proxy inserts it wherever it sees a link for some internal reason, but that it does so in a non-XML-compatible way. Of course, with most sites that doesn't matter since most sites are just tag soup. But for the rare website that actually serves proper XHTML, result: misery.
"in halls" sounds British, so I'm sure you'll appreciate the quote: "We apologise for the inconvenience" but in this case I can complete it with: "but it's not our fault"!
I hope you get it working. In the meantime, if you're able to hack a bit of javascript, you could try writing a greasemonkey script to take out the nasty string again.
1 to 7 of 7