Last modified: 2014-02-07 21:58:45 UTC

Wikimedia Bugzilla is closed!

Wikimedia has migrated from Bugzilla to Phabricator. Bug reports should be created and updated in Wikimedia Phabricator instead. Please create an account in Phabricator and add your Bugzilla email address to it.
Wikimedia Bugzilla is read-only. If you try to edit or create any bug report in Bugzilla you will be shown an intentional error message.
In order to access the Phabricator task corresponding to a Bugzilla report, just remove "static-" from its URL.
You could still run searches in Bugzilla or access your list of votes but bug reports will obviously not be up-to-date in Bugzilla.
Bug 549 - Incorrect parsing of table headings and cells on the same line
Incorrect parsing of table headings and cells on the same line
Status: REOPENED
Product: MediaWiki
Classification: Unclassified
Parser (Other open bugs)
unspecified
All All
: Lowest minor with 4 votes (vote)
: ---
Assigned To: Nobody - You can work on this!
http://en.wikipedia.org/wiki/Bug:Tabl...
: need-parsertest, parser
: 38 4759 (view as bug list)
Depends on:
Blocks:
  Show dependency treegraph
 
Reported: 2004-09-21 18:43 UTC by Leah
Modified: 2014-02-07 21:58 UTC (History)
6 users (show)

See Also:
Web browser: ---
Mobile Platform: ---
Assignee Huggle Beta Tester: ---


Attachments
Patch to correct table parsing (2.59 KB, patch)
2004-10-17 07:23 UTC, Leah
Details

Description Leah 2004-09-21 18:43:50 UTC
{|
|-
! 1 || a || b || c
|-
|}

produces:

<table>
<tr>
<th>1</th>
<th>a</th>
<th>b</th>
<th>c</th>
</tr>
</table>

instead of:

<table>
<tr>
<th>1</th>
<td>a</td>
<td>b</td>
<td>c</td>
</tr>
</table>

which is produced by:

{|
|-
! 1
| a || b || c
|-
|}
Comment 1 Leah 2004-10-17 07:23:20 UTC
Created attachment 105 [details]
Patch to correct table parsing

This patch allows captions, cells, and headings to occur on the same line. 
Captions may only occur at the beginning of a line; cells and headings may
occur in any order.
Comment 2 Wil Mahan 2004-10-18 06:52:57 UTC
(In reply to comment #1)
> Patch to correct table parsing

Could you please provide a diff against CVS HEAD? It doesn't apply
to any recent revision.
Comment 3 Ævar Arnfjörð Bjarmason 2005-06-21 14:05:17 UTC
Added the need-parsertest keyword and removed the patch keyword since it doesn't
apply to any recent revision.
Comment 4 Zigger 2005-08-06 07:15:29 UTC
*** Bug 38 has been marked as a duplicate of this bug. ***
Comment 5 Aryeh Gregor (not reading bugmail, please e-mail directly) 2007-05-03 00:18:15 UTC
*** Bug 4759 has been marked as a duplicate of this bug. ***
Comment 6 Aryeh Gregor (not reading bugmail, please e-mail directly) 2007-05-03 00:20:15 UTC
Should we fix this so it behaves logically and break stuff, or keep it behaving
oddly forever forever?  This is probably pretty low-impact, and for any WMF
project anyone with a DB dump could locate all problem pages for fixing by a bot.
Comment 7 Mark A. Hershberger 2011-04-12 15:17:38 UTC
This has been here forever and people seem to know the work-arounds.  We may try to make the behavior more consistent in the new parser, but, unless someone steps forward with an urgent use-case, this is really low priority.
Comment 8 p858snake 2011-04-30 00:10:06 UTC
*Bulk BZ Change: +Patch to open bugs with patches attached that are missing the keyword*
Comment 9 This, that and the other (TTO) 2014-02-05 11:01:17 UTC
Someone's got to close this bug...

I think after 10 years it's safe to say this is now considered a feature. Changing this now would break a lot of existing wiki syntax out there, on WMF and on external installations.
Comment 10 Mark Clements (HappyDog) 2014-02-05 11:42:38 UTC
(In reply to comment #9)
> Someone's got to close this bug...
> 
> I think after 10 years it's safe to say this is now considered a feature.
> Changing this now would break a lot of existing wiki syntax out there, on WMF
> and on external installations.

Is there any evidence for that?  I would expect that, as a minimum, a grep of the English WP should be made to see to what extent the incorrect construction is actually being used, rather than basing this on a, possibly incorrect, assumption.

Also, has this been closed by group consensus, or is it on your own initiative?  I would say that this is one place where 'be bold' should not apply.

I vote to reopen, until we have some actual data on which to base the decision.
Comment 11 This, that and the other (TTO) 2014-02-05 12:52:14 UTC
No, just my initiative. I didn't really expect anyone to care about this bug any more. If you would like to reopen, go ahead.

Realistically though, the chance of this getting "fixed" is negligible. Whether you grep enwiki or not, any change to core wikitext (particularly something as basic and widespread as table headers) is going to break stuff for some people somewhere on some wiki. People are going to use the markup that generates the look they want, so we must assume all uses of this ! || || syntax are intended to produce the "erroneous" look.
Comment 12 Mark A. Hershberger 2014-02-05 15:50:45 UTC
I would agree with WONTFIXING this.  I have some experience with changing behavior to "fix" an old bug.  The result wasn't pretty.
Comment 13 Mark Clements (HappyDog) 2014-02-05 17:11:26 UTC
I haven't been following the discussions relating to Parsoid for quite a while, but I know that there was general acknowledgement early-on that there are a fairly large number of edge-case situations like this where the current parser does not behave as you might expect, and that in an ideal world these would all be fixed by the new parser.  It was also acknowledged that this would, potentially, break a lot of stuff, and so fixing them might not actually be sensible.

I'm sure that a general approach has been adopted by now, so from my point of view this should follow whatever approach has been adopted for other similar issues.

* If they are all WONTFIXed without any further research, due to potential breakage, then this should also be a WONTFIX.
* If they are all being kept open, with a plan to resolving them in the new parser, then this should be re-opened.
* If there is some kind of flag (global or per-feature) to enable old broken behaviour, then this should be re-opened and fixed, with an appropriate flag used to restore the existing broken behaviour.
* If - as I suspect - they were handled on a case-by-case basis, based on some metric (e.g. prevalence in some corpus) then that same metric should be applied here.

I guess my point is that this shouldn't be handled in isolation by one person (or a couple of people) expressing an opinion.  It should be handled formally via the parser team in a manner consistent with other similar issues.

On that principal, I am re-opening.  Am happy for it to be re-closed by an appropriately informed person, so long as it is handled consistently with other issues and appropriate justification is given.
Comment 14 This, that and the other (TTO) 2014-02-07 00:29:39 UTC
You're right that a more consistent approach is needed. I would welcome a "bug sprint" in the Parser category.

There are 440 open parser bugs, and while many of them are totally legitimate bugs needing to be fixed, there are a good few handfuls of bug reports that lack a clear course of action, like this one. A bug sprint would get the same pair of eyes on each of the issues, to judge them equally and knowledgeably.
Comment 15 Mark A. Hershberger 2014-02-07 21:58:45 UTC
Adding the bug wrangler since he has interest in bug sprints.

Note You need to log in before you can comment on or make changes to this bug.


Navigation
Links