Re: Site HTML filtering, Phase II

[jonadab]

Actually, the Perlmonks stuff is pretty simple. The only hard part is remembering which of the less common but harmless and useful HTML tags don't work. (ISTR that cite doesn't work, but I could be misremembering; maybe it was q that doesn't work. I'm not sure. I often just use them anyway, because when they're what you intend, there's nothing else with the right semantics.) That, and remembering the entity for escaping the left square bracket. (I usually just put code tags around it. Easier to remember.) If you want to see some needlessly complicated and gratuitously different site markup, have a look at Wikipedia sometime. I am continually thankful that Perlmonks markup is mostly just HTML.

Can't we just have a setting that puts an implicite <code> and </code> around our postings?

Well, you could always change your node template to that in protest. Such a protest would have about as much impact on the rest of us as Coruscate's XP/reputation/voting protest, but we'd all know where you stand on the issue.

My first reaction when I read the description of these new changes is that the error checking is quite lenient. I suppose that's a good thing. If I had written the checker, it would probably just reject or escape anything that's not wellformed (in addition to anything that smacks of javascript), which would probably be a major annoyance to people who still write legacy HTML, of whom there are still quite a few out there I suspect, the number of years since XHTML was put forward notwithstanding. So, be happy that tye wrote it, because he did a pretty good job IMO of making the checker as lenient as could be reasonably hoped for. (There are people who would want no checker at all, but I think you understand why that would cause problems in practice.)

update: Heh. Sure, I say that, and then I see that the error reporting is showing an error in the perfectly cromulent markup that is my signature, crossing out the closing tag on my horizontal rule element. Probably because it's an empty element. Guess I'll switch to the newer XML-style of closing (at the end of the open tag) for empty elements. It's probably been chopping out my closing hr tag all along and I never noticed due to the lack of error reporting.

update2: Heh again. The XML-style closing / gets stripped out too, though it doesn't generate any warning at level 3. Next time I preview a new node I'll see whether it shows at level 4. Not that it matters, I suppose; it all gets doctyped at 4.0 Transitional anyway, so I don't think there's a single browser anywhere that actually cares about closing off empty elements. I was just closing them off on principle.

update3: Hmmm... What I *thought* I saw was that it actually got stripped. What I *actually* discovered is that View Selection Source in Mozilla does not give exactly the same source as View->Page Source does. The former shows <hr> and the latter shows <hr />. Weird.