On Sun, Dec 28, 2008 at 1:40 PM, Ilmari Karonen <nospam(a)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(a)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.