[Brion Vibber wrote] :
<b>First paragraph
Second paragraph
Just thinking aloud, but could this be made equivalent to:
============================== '''First paragraph
Second paragraph ==============================
... which currently produces HTML-compliant output?
[Adrian Buehlmann wrote] :
We need them because the "|" of wiki table interferes with template "|" and ParserFunctions "|".
Yes, it is slightly unfortunate that "|" has been overloaded to mean both a parameter and to perform table-related functions.
Of course with 20/20 hindsight, it's easy to say it could be useful to have two different constructs for these purposes. I suppose it's theoretically possible to introduce a new construct of some type (example: "%") to indicate parameters (since I suspect parameter delimiters are probably used less than "|" in tables), and have an overlap period when both the new and the old construct work to allow transitioning, and to then turn off/deprecate "|" for parameters. Then the old HTML "<table>" syntax could be dropped if there was general support for it (bias disclaimer: I personally prefer the wiki-table-syntax to the HTML-table-syntax), because "|" would no longer interfere with templates or ParserFunctions.
In such a scenario, the question main though is whether $gain >= $pain. The pros and cons are probably something like this:
$gain: * For people who prefer wiki tables to HTML tables. * Gain in standardization (only one table format to understand, rather than two). * Gain in simplifying the Parser slightly by eliminating HTML table syntax and "|" ambiguity (maybe?) * Gain for people who want to use table-related syntax as parameters to templates or ParserFunctions.
$pain: * Transition costs in moving pages using old parameter syntax to new parameter syntax. * Transition costs in moving some pages from old HTML table syntax to wiki table syntax. * The Parser implementation pain. * Adjustment pain for people who prefer HTML table syntax.
All the best, Nick.
Nick Jenkins wrote:
[Brion Vibber wrote] :
<b>First paragraph
Second paragraph
Just thinking aloud, but could this be made equivalent to:
============================== '''First paragraph
Second paragraph
Well, what do you mean by "equivalent to" here?
Wiki bold/italics (with ''...'' and '''...''') are handled on per-line basis currently, cut off at the end of the line. This means that within a single paragraph we can have:
normal'''bold normal
which converts to output:
<p>normal<b>bold</b> </p>
So what's the desired behavior for this input:
normal<b>bold ?????
Should it close off the inline tag at the end of the paragraph:
<p>normal<b>bold ?????</b></p>
or at the end of the line?
<p>normal<b>bold</b> ?????</p>
Further what about the interaction between <b> and ''' used together? Are they separate? How should we treat something like this:
<b>bold'''????'''????</b>
The most sensible probably is to continue thinking of <b> and ''' as distinct items, resulting in output like this:
<b>bold<b>????</b>????</b>
The nested bolds are perfectly legal, if pointless. :)
It would probably *not* make sense to treat that as equal to:
'''bold'''????'''????'''
which would render as:
<b>bold</b>????<b>????</b>
To return to the original question: to do that, we probably need to know where the paragraph boundaries are at the time HTML normalization is done. That probably means either doing block level conversion to HTML *before* normalization, or doing them together in one pass.
-- brion vibber (brion @ pobox.com)
Well, what do you mean by "equivalent to" here?
I mean this: <b> === ''' and probably this: </b> === '''
normal'''bold normal [ ... ] at the end of the line?
<p>normal<b>bold</b> ?????</p>
Yes at the end of the line.
As part of the Wiki Syntax Project we spent lots of time cleaning up excess line breaks (especially from newbies), and the sooner people realize line breaks are not required (or even helpful in most cases), the better.
How should we treat something like this: <b>bold'''????'''????</b>
Like this: <b>bold</b>????<b>????</b>
It would probably *not* make sense to treat that as equal to: <b>bold</b>????<b>????</b>
Why not? It makes perfect sense to me! ;-)
There is no such thing as a double-bold. There is no bold-bold, and there's no point in hiding that from people, or in pretending that such a thing exists by giving them two independent bolding mechanisms that refuse to talk to each other.
As a result of treating them differently, this renders wrong: ====================================== <b>bold<font style="a">'''????'''????</b> ====================================== (using r14547 *without* Tidy the line renders as "bold????????</b>", all in bold)
If it was this treated as this, it would render better: ====================================== '''bold<font style="a">'''????'''????''' ======================================
Even with that, it still leaves the entire line in bold because it doesn't close that font tag - so it's still not perfect, but it is better.
All the best, Nick.
Nick Jenkins wrote:
It would probably *not* make sense to treat that as equal to: <b>bold</b>????<b>????</b>
Why not? It makes perfect sense to me! ;-)
There is no such thing as a double-bold.
Sure it does. You could even make the style sheet show it that way, if you really wanted. :)
There is no bold-bold, and there's no point in hiding that from people, or in pretending that such a thing exists by giving them two independent bolding mechanisms that refuse to talk to each other.
Like, say, <b> and <strong>?
-- brion vibber (brion @ pobox.com)
"Nick Jenkins" wrote:
Yes, it is slightly unfortunate that "|" has been overloaded to mean both a parameter and to perform table-related functions.
Of course with 20/20 hindsight, it's easy to say it could be useful to have two different constructs for these purposes. I suppose it's theoretically possible to introduce a new construct of some type (example: "%") to indicate parameters (since I suspect parameter delimiters are probably used less than "|" in tables), and have an overlap period when both the new and the old construct work to allow transitioning, and to then turn off/deprecate "|" for parameters. Then the old HTML "<table>" syntax could be dropped if there was general support for it (bias disclaimer: I personally prefer the wiki-table-syntax to the HTML-table-syntax), because "|" would no longer interfere with templates or ParserFunctions.
I'm sure | is more used as parameter delimiter than table marker. You only need to count the number of [[link|named links]] a page has, and the number of tables.
[Platonides wrote] :
I'm sure | is more used as parameter delimiter than table marker. You only need to count the number of [[link|named links]] a page has, and the number of tables.
Indeed, thank you - I clean forgot piped/named links, which I suppose really are just another type of parameter delimiter. Phooey!
Hmmm... so essentially we have: * HTML tables probably cannot be dropped until wiki tables can be passed as parameters to templates / ParserFunctions. * There are lots of wiki tables and parameter limiters already in deployment, so changing either does not seem practical. * It's only the intersection of these two things that seems problematic due to the "|" being ambiguous.
Maybe some kind of escaping is possible, such as backslashes, e.g.:
{{#ifeq: 1 | 1 | {| border="1" | test |} }}
... that would hopefully break very little, although it looks pretty yucky.
All the best, Nick.
"Nick Jenkins" wrote
.... Maybe some kind of escaping is possible, such as backslashes, e.g.:
{{#ifeq: 1 | 1 | {| border="1" | test |} }}
... that would hopefully break very little, although it looks pretty yucky.
http://meta.wikimedia.org/wiki/Talk:ParserFunctions#Requests_and_proposals
There is another escaping proposal: http://meta.wikimedia.org/wiki/Talk:ParserFunctions#.7B.7B.23_.3Cwikisyntax....
--Adrian Buehlmann
wikitech-l@lists.wikimedia.org