Last modified: 2011-03-13 18:04:35 UTC
Per the title. Currently if I want to give a list attributes of any kind, I have to use the relatively unsightly HTML syntax. Tables, table rows, and table cells can all be given attributes elegantly; I suggest we extend the same syntax to lists. # attributes for list | attributes for first list item | item content # attributes for second list item | item content Now, obviously stray pipes would cause breakage in a simplistic implementation. Therefore, the parser would need to verify that the seeming attributes are actually attribute-like before considering them attributes (as well as, of course, stripping unwanted attributes). If a reasonable check like that is made, I anticipate no existing list on all of Wikimedia servers would break (there may be lists of HTML attributes *with* values, but those aren't going to include pipes). * | attributes for first list item | item content with no list-wide attributes due to empty list-wide-attribute section * | that pipe is printed literally, unlike the pipe above, because of potential for collision (and anyway it's not useful) : if (a || b) // "if (a" doesn't look like an attribute, so it's literal : style="text-indent: 1em;" | ++a; // That's a valid attribute, so it's interpreted as an attribute : string="Hello, world!" | d ? exit() : continue; // This is so unlikely that we probably want to consider it an attribute to save parser time (i.e., whatever matches /[\t ]*([a-z]+ *= *['"]?.*?['"]? +)+/i or whatever) The same could be extended to initial whitespace, i.e., wiki-<pre>. (I actually wanted that just today: I had something where I wanted the formatting but not the background and border.) In fact, if anything this is more useful than the preceding, because if you have wikimarkup inside the content there's no way to get a <pre> tag with attributes (which is why [[Family tree of the Greek gods]] still has that rather ugly grey background). attributes for <pre> | content this is part of the same <pre>, so this is content despite the pipe | more content . . .
My gut feeling is that this would break horribly. We have Wiki lists nested in Wiki tables, plus Wiki lists in XHTML tables, and vice versa, plus templates like the weird {{!}}, it's just not the point where you'd risk to add some kind of heuristical "|" interpretation. If I understand your idea correctly you can use ?<span what="ever">stuff</span>.... instead of ?what="ever"|stuff............. in most cases, admittedly 13 characters more, but clean. This won't work for list item numbers, but there you have short <ol><li></li></ol> solutions. I never tried to mix this with Wiki markup, but for Wiki tables using </td><td> works. In rare cases (within templates) where such kludges are necessary, e.g. [[Template talk:Evaldemo]].
(In reply to comment #1) > My gut feeling is that this would break horribly. > We have Wiki lists nested in Wiki tables, plus > Wiki lists in XHTML tables, and vice versa, > plus templates like the weird {{!}}, it's just > not the point where you'd risk to add some kind > of heuristical "|" interpretation. Since tables only use isolated pipes either to start a line (begin a table cell) or on a line that starts with a pipe (end cell attributes), neither of those can interfere with a syntax that only operates when the line begins with a list marker, provided the implementation is good--something that would, of course, have to be tested for any given implementation. > This > won't work for list item numbers, but there > you have short <ol><li></li></ol> solutions. The idea is to extend wiki syntax enough so that you don't have to resort to HTML every time you want a useful effect. I did have list item numbers in mind, as well as list types (AaIi, circle disk square, you know). This isn't something that can't be reproduced with HTML, but no wikimarkup is hard to reproduce with HTML.
This is an unnecessary complication; syntax changes require a very very high bar for entry. WONTFIX.
