On Sun, Dec 28, 2008 at 1:40 PM, Ilmari Karonen nospam@vyznev.net wrote:
A simpler, though more heavy-handed, approach might be simply to disallow dashes in section anchors (presumably replacing them with ".2D"). This would leave any dashed IDs free for other uses.
That's pretty heavy-handed indeed. It's awfully arbitrary to demand all our users use camel-case or underscores for their id's.
We might be able to adapt the existing code in the parser that prevents duplicate section anchors from occurring: just prepopulate the list of already seen anchors with any IDs that occur in skins.
That wouldn't help id's that are manually specified, though. We don't want those to conflict either, do we? Maybe we do, if the interface element doesn't appear on the particular page . . . you might legitimately want to fake some interface element's style in some cases, I guess. Doesn't seem like we should encourage that, though, it could lead to abuse. (Beansy question: are there any places where id's are used to do something in JavaScript, that people could exploit by adding wikitext with those id's?)
The big problem there is that there's no sensible way to disambiguate them. Probably the best we can do would be to silently drop any duplicates. Or maybe replace them with a really in-your-face "disambiguation" like OMG-DUPLICATE-ID-whatever-FIX-IT-YOU-IDIOT-1. :)
Anyway, this kind of sounds like something Tidy ought to be doing. Doesn't it?
IIRC, Tidy outputs some comment like "Serious XHTML error" when it encounters duplicate id's, exactly because in the general case it's scary to try fixing those. If we're really going to police this in the software rather than just declaring it PEBKAC (and I'm not sure we should), we'd need to implement logging first for a while and make sure the more egregious cases are fixed before messing everything up.
I think it's probably okay the way we have it now. You can mess things up if you manually specify id's, but that's your problem. I could see the argument that only sysops should be allowed to create invalid markup, though (which they inevitably can in JS and CSS, and in HTML via JS).
On Sun, Dec 28, 2008 at 2:50 PM, Platonides Platonides@gmail.com wrote:
May this be time to propose again a 'validation' mode / debug output?
Somewhere to place that kind of warnings: *Skipping duplicate id 'foo' *Adding </div> for you *Inexistant attribute foo for span removed *Too many templates added. Stopping template expansion etc.
It could be added to the html comment with preprocessor data, or perhaps as a new box in preview mode. In no way it is expected to appear in the page viewing, nor I am saying that we should [[Execution by burning|burn]] (yet) people not writing 100% conformant wiki-text. Also, could be collapsed by default to not discourage new comers. The point is that getting a better insight on how mediawiki is "helping" would be most valuable when studying why a [[Template:Esoteric|esoterism]] isn't working.
If we did this, we'd probably want multiple channels of output, debug and warning at least. Warnings should only be raised when what the user intended is clearly not happening: when duplicate id's or nonexistent attributes are removed, for instance, or template expansion is halted. Automatically closing tags isn't something that should be mentioned unless the user specifically asks for that level of nitpicking, if even then. Wikitext doesn't need to aspire to be XML.