I don't like either SPAN or DIV myself. It makes editing Wikipedia articles look too much like editing HTML. I'm more HTML-literate than a lot of Wikipedia editors, and I usually read anything with a div in it as "blah blah formatting crap" and skip past it. Granted, some of the same holds true for tables, even in wiki-syntax, but that's probably unavoidable without an wysiwyg table editor. But I think we could at least limit the non-humanly-transparent stuff in the source; the move from divs for floating images to using the extended image syntax is a huge step in the right direction.

In general, I agree. I also think we should think of the wiki syntax as having parts that *resemble* HTML, rather than *incorporating* html elements. After all, we might want to make them behave in non-HTML ways - limit them, extend them, render them in non-HTML or non-CSS skins, etc. For that reason, it's probably sensible to keep down the number of elements that look like they're HTML tags. But that's just my view.

I think there could be a use for semantic classes that are easily readable--along the lines of <math> we could have <anythingelse>, but I think the syntax for that has already been proposed and discussed at length (anyone have a pointer to that discussion?).

You're thinking of the "extension syntax" - the vote page on meta is http://meta.wikipedia.org/wiki/Extension_Syntax#Erik.27s_proposal (Erik's being the proposal that won). However, note that these are more than just semantic classes - they are markers that essentially tell the parser to hand the contents off to something else, and not process it itself. Semantic classes would need to be slightly more arbitrary than that, I'd have thought - lots of them, maybe even user-defined. For that, it probably is best to stick to some kind of <X Y=Z></X> format, or similar.

I suppose span could do that as well if kept to a simple class-based usage like the <span class=reptile> you proposed, but the word "span" isn't really intuitive to anyone who doesn't know HTML, and I don't see why that would be preferable to <reptile>blah</reptile>, which is readable by just about everyone (if indeed "reptile" were a sematic markup tag we thought useful).

-Mark

Yes, "span"'s not great, and given my reservations about "including" HTML expressed above, I'd prefer to see a custom piece of markup that *generated* span tags in normal skins. This would then give us free reign to define its use, behaviour, limits, etc. and decide how we want it to be rendered in any given skin. Since it's only useful once you've got a system for defining what the information's actually going to be *used* for, there's no real point in rushing in and incorporating syntax that might turn out to be unsuitable.