Last modified: 2013-04-22 16:15:15 UTC
A bit more explanation would be appreciated. An example welcomed.
(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>.
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.
In gerrit: https://gerrit.wikimedia.org/r/#/c/23100/
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
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.
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.
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.
Wouldn't be much of a wait. HTML5 is already here.
Sure. Just the question whether we really want to create a solution only working with HTML5.
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.
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 :/
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.
Gerrit change #23100 has been merged What about submitting a note to RELEASE-NOTES?
