Last modified: 2013-04-22 16:15:15 UTC

Wikimedia Bugzilla is closed!

Wikimedia migrated from Bugzilla to Phabricator. Bug reports are handled in Wikimedia Phabricator.
This static website is read-only and for historical purposes. It is not possible to log in and except for displaying bug reports and their history, links might be broken. See T42044, the corresponding Phabricator task for complete and up-to-date bug report information.
Bug 40044 - tablesorter should sort images with alt text
tablesorter should sort images with alt text
Status: RESOLVED FIXED
Product: MediaWiki
Classification: Unclassified
JavaScript (Other open bugs)
unspecified
All All
: Normal normal with 1 vote (vote)
: 1.21.0 release
Assigned To: Bartosz Dziewoński
:
Depends on:
Blocks: 31601
  Show dependency treegraph
 
Reported: 2012-09-06 08:27 UTC by Liangent
Modified: 2013-04-22 16:15 UTC (History)
7 users (show)

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


Attachments

Description Liangent 2012-09-06 08:27:16 UTC

    
Comment 1 Derk-Jan Hartman 2012-09-07 17:54:16 UTC
A bit more explanation would be appreciated. An example welcomed.
Comment 2 Liangent 2012-09-07 17:59:28 UTC
(In reply to comment #1)
> A bit more explanation would be appreciated. An example welcomed.

If a cell is <td>foo<img src="..." alt="txt">bar</td>, maybe it could be better to sort it as <td>footxtbar</td>.
Comment 3 Bartosz Dziewoński 2012-09-07 18:15:36 UTC
I think an example would be:

{| class="wikitable sortable"
|-
! Image !! Text
|-
| [[File:Example.jpg|30px|C]] || B
|-
| [[File:Example.jpg|30px|B]] || C
|-
| [[File:Example.jpg|30px|A]] || A
|}

Sorting by the first column does nothing, and it should based on image descriptions (which are handily inserted into the alt attribute). I'll try to work on this.
Comment 4 Bartosz Dziewoński 2012-09-07 19:13:51 UTC
In gerrit: https://gerrit.wikimedia.org/r/#/c/23100/
Comment 5 Daniel A. R. Werner 2012-10-05 13:30:30 UTC
This would indeed be a nice extension but it could break existing, well calculated and intended behavior.

Think of a table displaying some images in table cells (including descriptions in the alt attributes) and some text behind the pictures.
So far, the column sorted on the cell text, ignoring the images alt attributes which could have been intended behavior.
Now, with your change, suddenly the pictures would be a factor in the sorting. The sorting would change because of the alt tags which were not intended as sort keys originally.

One thing I can think of right now to avoid this would be to add a config option for the sorter to explicitly allow enabling this behavior for images. Could be handy to allow a finer grained config var which allows to either:
1. ignore alt tags (default)
2. concatinate alt tags and surrounding text
3. use alt tags only
Comment 6 Bartosz Dziewoński 2012-10-05 13:51:16 UTC
This is trivially fixed by either setting empty alt or putting the images in a separate, possibly unsortable, column.

Also, I'd very much like to see a real-world example, that is, such layout currently live on a wiki; otherwise there's no point talking over breaking compatibility when there's nothing to break.

I'm hesitant to adding more config options, wikicode is already complicated enough.
Comment 7 Daniel A. R. Werner 2012-10-05 20:31:06 UTC
Config option was not with wiki code in mind, just pretending you would initialize the sorter from JS directly on some table.

I guess having that fix as default behavior would be desirable, breaking the sort keys on a few tables on a few wikis if there is even anything out there that would run into this might be acceptable.
Comment 8 Daniel A. R. Werner 2012-10-19 13:23:33 UTC
After thinking about this again, I came to the conclusion that we basically can't predict what should be taken into account for creating the sort key. Therefore we shouldn't be smart about this and either take ALL alt tags + the text, or take only the text.

Instead of trying to be smart here, we could add an attribute to the td element which holds the actual sort key. I am not sure whether there is any attribute we can abuse for this - e.g. the title attribute. We could wait for HTML5 to use data- attributes. Since it is possible in MW table syntax to define attributes for td elements, this might be the easiest and most generic solution.
Comment 9 Daniel Friesen 2012-10-19 13:30:21 UTC
Wouldn't be much of a wait. HTML5 is already here.
Comment 10 Daniel A. R. Werner 2012-10-19 13:36:09 UTC
Sure. Just the question whether we really want to create a solution only working with HTML5.
Comment 11 Daniel A. R. Werner 2012-10-19 13:45:08 UTC
Yet another solution without HTML5 would be to introduce a 'sortable-sortkey' class. Whenever that one is added to one or several elements in the table cell, the joined texts of those will be taken as the key. For images, when the 'sortable-sortkey' class is added, the key text will be taken from the alt tag.
Comment 12 Bartosz Dziewoński 2012-10-20 16:15:39 UTC
I am *still* waiting for anybody to show me a real-world example – a page that works correctly now, but would break after my patch is applied, and preferably break in a way that is not fixable in twenty seconds.

An example page that would directly benefit from this is https://pl.wikipedia.org/wiki/Polskie_lotniska – the first columns is currently only sortable thanks to an invisible <span> with text that is inserted before the icons.

Complaining about breaking compatibility with non-existent uses is just silly, so please stop and let me improve MediaWiki's code :/
Comment 13 Jesús Martínez Novo (Ciencia Al Poder) 2012-10-20 16:45:14 UTC
I'm with Bartosz Dziewoński. When images are used in a sortable table, they should participate in the sort key along with the text, like if they were any other piece of text, and this is expected behavior. And the way an image can be translated to text is using the ALT attribute.

I already applied a fix to the sortable functions many years ago on my wiki so they work as Bartosz Dziewoński suggest, since we're using icons for special values. Never had any problem.

And the hidden <span> to fix it is a really dirty solution for something that's a bug, and it's not SEO-friendly.
Comment 14 Jesús Martínez Novo (Ciencia Al Poder) 2013-02-04 22:20:53 UTC
Gerrit change #23100 has been merged

What about submitting a note to RELEASE-NOTES?

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


Navigation
Links