Page MenuHomePhabricator

Categories should be displayed in a responsive table and be mobile friendly.
Closed, ResolvedPublic

Description

Go to:
http://en.m.wikipedia.org/wiki/Category:Massacres_in_Iraq

This displays terribly on a small screen as the HTML markup is a table.

If a 3 column layout is really wanted the column-count css rule should be used on a single list element.

Details

Reference
bz53130

Related Objects

Event Timeline

There are a very large number of changes, so older changes are hidden. Show Older Changes

No only in 10 [1]. but does this really matter?
As a single list the category list is still readable on IE albeit long.
Currently however it is /not readable/ on a mobile phone (320px resolution).

You wouldn't spend time worrying about making an old black and white TV spend time showing HD movies so why would you spend time worrying about making column-count work on IE...?

[1] http://caniuse.com/multicolumn

wmf.amgine3691 wrote:

Currently 12.63% support (according to link.) More importantly, from that source none of the mobile browser have complete support except Opera mini. ("Note: Partial support refers to not supporting the break-before, break-after, break-inside properties. Webkit browsers do have equivalent support for the non-standard -webkit-column-break-* properties.")

I think the main thing I'm trying to get at is don't use a table and instead use something that falls back to a single column (the same effect could be made using 3 DIVs)

On mobile it doesnt matter if the column-count property doesnt work as this will simply show a single list which is the needed behaviour there anyway.

matthiasbecker1967 wrote:

Actually the user should be able to adjust the number of columns shown in his preferences. Me for example often works in categories with typically long article's names which unnecessarily break lines, others might have other preferences because mainly work with categories in which article names are mostly short.

Change 187952 had a related patch set uploaded (by Bartosz Dziewoński):
CategoryView modified to use css columns

https://gerrit.wikimedia.org/r/187952

Patch-For-Review

Screenshots:

Before:

Full support

Hilariously, these four browsers provide three different renderings in total (they split columns differently). All do it correctly.

Opera 28 (like Chrome, like Safari):

Firefox 35:

IE 11:

Opera 12:

Partial support

Firefox 3.6:

(does not support break-inside: avoid; or any of the variants, so the headings sometimes get separated from the lists)

No support

IE 8:

IE 6:

Change 187952 merged by jenkins-bot:
CategoryView modified to use css columns

https://gerrit.wikimedia.org/r/187952

matmarex closed this task as Resolved.Feb 23 2015, 5:22 PM
matmarex removed a project: Patch-For-Review.

Awesome! Thanks guys for getting this fixed!

Sumit added a comment.Feb 25 2015, 1:15 PM

I learnt a lot too,while fixing :)

Edokter reopened this task as Open.Mar 5 2015, 9:22 AM
Edokter added a subscriber: Edokter.

Reopening, because I am not quite happy with its implementation.

  1. There is no -o-column-count property; it should be removed from mixins.less.
  2. The number of columns is still fixed to 3, or 1 below 768px using @media queries, and nothing in between.

Why have you not used column-width instead, which changes the number of columns automatically without the need for queries? This can be combined with column-count: 3 to restrict the maximum number of columns.

TheDJ added a subscriber: TheDJ.Mar 5 2015, 11:32 AM

wow, this totally backfired. probably not tested break inside with large categories.

https://en.wikipedia.org/w/index.php?title=Category:Living_people&from=9th%20W

The third column is empty because it is made up of only 'A'.
-webkit-column-break-inside: avoid is the cause. Also would prefer column-width,

Sumit added a comment.Mar 5 2015, 1:56 PM

Removing "-webkit-column-break-inside:avoid", would cause continuing subcategories to go over to next column, but doing that in the following patch, since the above issue is more important. Also, adding a width of 300px as column width in the first patch

Change 194512 had a related patch set uploaded (by Sumit):
Category view modified to use column width

https://gerrit.wikimedia.org/r/194512

@Sumit, What determined the break between columns when tables were used? That same algorith can be used to allow/force a column break as well by inserting an element that has page-break-before: always; property set.

It was a pretty lame algorithm that had several bugs filed against it – it just tried to fit the same number of links into every column, not taking headings into account at all. Let's try not to use it.

The purpose of the break-inside: avoid is to avoid line breaks directly following headings (and preferably also line breaks before/after first/last element of a list). That would be better implemented with break-after and break-before, but support for column content is generally spotty (outside of the commonly trod areas), so this would have to be tested in various browsers. Anyone wants to try implementing?

I recommend at least the set of browsers I tried before, preferably with better test categories, since mine were clearly lacking. :)

Sumit added a comment.EditedMar 5 2015, 3:27 PM

@Edokter, the previous table implementation simply divided the categories into 3 parts, one for each column, and in case of a subcategory going over to next column, it added a "...contd" text. See here https://gerrit.wikimedia.org/r/#/c/187952/10/includes/CategoryViewer.php , Removing "column-break" here would achieve the same result except for the "...contd" message in case of overflow of subcategory
If we can do without the "...contd" message, I guess, restricting break-inside to just list would do

In that case, the avoid-break code should be aplied to the individual list items, and not the entire block.

@matmarex, the break-before/inside/after properties enjoy a wider support then columns, so I foresee no problems there.

I'll believe it when I see it. :)

Thanks for that example @TheDJ - i wish we had better test pages for this sort of thing. I'm agnostic to what we do to fix this as long as we don't bring back tables :-) Even with a long column like that, we are serving mobile users a lot better!

/me dreams of a future when beta labs master runs on english wikipedia for any mediawiki dev :-)

wow, this totally backfired. probably not tested break inside with large categories.
https://en.wikipedia.org/w/index.php?title=Category:Living_people&from=9th%20W

[...]

The third column is empty because it is made up of only 'A'.
-webkit-column-break-inside: avoid is the cause. Also would prefer column-width,

For comparison, in Firefox 31 ESR this category looks like this:

Three columns are used, but the first only contains one entry.

That hurts... :)
https://developer.mozilla.org/en-US/docs/Web/CSS/page-break-before
https://developer.mozilla.org/en-US/docs/Web/CSS/page-break-after
https://developer.mozilla.org/en-US/docs/Web/CSS/page-break-inside
Supported since IE4(!)
Only page-break-inside was a bit late, being introduced in IE8, but we don't need that anyway.

These only apply to page breaks (when printing), not column breaks (except sometimes on Firefox, which is a browser bug).

https://developer.mozilla.org/en-US/docs/Web/CSS/break-before
https://developer.mozilla.org/en-US/docs/Web/CSS/break-after

Supported pretty much nowhere. I made a quick test page: http://jsfiddle.net/9rb5wtj1/1/ and indeed, only Opera 12 and IE 11 worked. Newest Chrome and newest Firefox failed. If you can make it work, I'd love it.

…as I said, I'll believe it when I see it.

It works in so far that the paragraphs are not broken up. In the context of pagebreaks, columns are treated as pages. Anyway, we should just avoid breaks in the list items for the time being.

I may have spotted another issue: expanding subcategories make other elements "jump" between columns, sometimes even the expanded entry itself. Test page, Firefox 36.
Before:


After:

That is somewhat expected; columns actually behave as one long page, which have basically been cut into three pieces. So when content is added, anything 'below' is pushed 'down' to the next column.

Should this bug be renamed or a new bug created? The issues seem to be around the desktop experience now and I'm having difficulty following it...

It concerns both desktop and mobile, so i would say rename.

Jdlrobson renamed this task from Categories should not be rendered in a table (do not display well on mobile) to Categories should be displayed in a responsive table and be mobile friendly..Mar 12 2015, 8:57 PM
Jdlrobson removed a project: Readers-Web-Backlog.
TheDJ added a comment.Mar 30 2015, 6:41 AM

We really need to find a way around this. It looks so broken to some users that they ask on the Help desk: "I wanted to add columns to the list but could not figure out how or where to do it."

Anyone got ideas, other than revert ?
Cause this proves once more that column support in browsers is just not working yet as it should.

Sumit added a comment.Mar 30 2015, 3:06 PM

The most evident problem here is that of columns not breaking when a single category is too long. The patch set https://gerrit.wikimedia.org/r/194512 addresses this problem and here's its output on latest Chrome and Firefox, with this test case(a single long category). The patch atleast seems to improve upon the problem
Chrome 40:


Firefox 36:

Another test case referring to

https://en.wikipedia.org/w/index.php?title=Category:Living_people&from=9th%20W

Chrome 40:


Firefox 36

PleaseStand added a subscriber: PleaseStand.EditedMar 30 2015, 6:06 PM

I don't see how it would be possible to fix the CategoryTree problem (mentioned above in T55130#1102370 and reported by another user as T92767) while still using CSS multi-column layout (as opposed to, e.g. multiple divs styled as table cells) for this. How would you tell the browser to keep the entire tree view in a single column and not rebalance the columns, yet not put everything into a single column and not constrain the column height either? (At least without some ugly hack like copying the remaining links in the column into a separate "overlay" element I don't think so.)

Are there other ways we can reduce this to one column without column count on mobile? A full revert would mean it being extremely broken on mobile again so if we do decide this is a failed strategy I'd like to find a better approach (float: left but not on mobile? other? ).

I'm still having trouble understanding exactly what the bugs are.

We really need to find a way around this. It looks so broken to some users that they ask on the Help desk: "I wanted to add columns to the list but could not figure out how or where to do it."

What does this mean? Can you illustrate this with a before/after screenshot and point me at some links? I'm struggling to understand exactly what right now is causing issues for our users.

Change 194512 merged by jenkins-bot:
Category view modified to use column width

https://gerrit.wikimedia.org/r/194512

We really need to find a way around this. It looks so broken to some users that they ask on the Help desk: "I wanted to add columns to the list but could not figure out how or where to do it."

What does this mean? Can you illustrate this with a before/after screenshot and point me at some links? I'm struggling to understand exactly what right now is causing issues for our users.

https://en.wikipedia.org/w/index.php?title=Category:Living_people&pagefrom=Aarnes%2C+Tom+Aage%0ATom+Aage+Aarnes#mw-pages

Should get fixed by the patch that TheDJ just merged.

Thanks @matmarex
I imported this to beta labs and http://en.wikipedia.beta.wmflabs.org/wiki/Category:Living_people?pagefrom=Aarnes%2C+Tom+Aage%0ATom+Aage+Aarnes#mw-pages is indeed looking better.

Are there any other problems we need to resolve?

Sumit added a comment.Apr 1 2015, 4:46 PM

If the issue seems to be resolved by the latest patch, shall we close this?

matmarex closed this task as Resolved.Apr 1 2015, 6:44 PM

Yeah, I think.

Are there any other problems we need to resolve?

Headings can be "orphaned" at the end of a column with all their pages being in the next column. But we should think about that in a separate bug.

(I am not sure if I should open another bug, reopen this, or what.)

On cs.wikipedia, we’ve had a number of complaints regarding a reduction of the number of columns on category pages. And indeed, it seems the current version seems to reduce the number of columns on category pages from 3 to 2 at least in Firefox&IE on a 1280px screen:

The current column definition seems to be column: 3 25em, which for the 14px font translates to 350px of column width, plus 1em of column-gap, and therefore, 1078px of space required for three columns. However, a 1280px screen seems to have only 1038px left for content, so it displays only two columns. The column width would need to be reduced to 24em to fix that.

Edokter added a comment.EditedApr 13 2015, 1:17 PM

I agree... I choose 25em initially, but failed to test it 'live'. 24em seems like a good value.

(edit) I'll add that luckily, it is now possible to adjust the columns locally by adding the following to Common.css:

.mw-category {
  -webkit-column-width: 24em;
  -moz-column-width: 24em;
  column-width: 24em;
}

Change 206394 had a related patch set uploaded (by Mormegil):
Fix category column count regression

https://gerrit.wikimedia.org/r/206394

Change 206394 merged by jenkins-bot:
Fix category column count regression

https://gerrit.wikimedia.org/r/206394

Change 206419 had a related patch set uploaded (by Bartosz Dziewoński):
Fix category column count regression

https://gerrit.wikimedia.org/r/206419

Change 206419 merged by jenkins-bot:
Fix category column count regression

https://gerrit.wikimedia.org/r/206419

Nnemo added a subscriber: Nnemo.Sep 30 2015, 7:10 PM

Rather than CSS multi-column blocks, may be we should use CSS flex layout (which can still have a fallback to multicolumn), to give consistant presentation of cells without undesired column-breaks (flex layout is on a grid but with implicit rows which can be vertical or horizontal, and where full cells can be wrapped and still maintain their alignment.
The fFlex layout is very used on mobile sites (and implemented in all mobile browsers) as it allows a great flexibility of formats, and better accessibility for touch. They have the clean layout of tables, but without forcing a static number of columns or rows, and allow designing the UI so it will get only one scrollbar (horizontal or vertical), never two and it is well suited for mobile phones which can be easily rotated between paysage and portrait. They work magically for all the builtin UI of the OS (e.g. in config menus) and for most apps.
The only problem is flex layout is still new on desktop browsers and some old desktop browsers (and some old browsers for smartTVs that don't rotate and frequently have antique renderers) don't have it (but the same devices also have problems for multicolumn and support of tables is frequently full of bugs/caveats or require device-specific developments and severe degradation of UI features, so I doubt Wikis are even usable on these devices; I think that users that have these device don't use it really to browse the net, and will still have more recent and decent smartphones or tablets; given the lifetime of mobile devices which is roughly 3 years, and flex design and modern browsers implementing it on these mobiel devices have been on market since more than 5 years, I don't think the flex layout will cause compatibility problems; in fact there's probably now a better support for flex layout than multicolumn which was intended for paged devices, i.e. printing, or desktop on large screens in landscape mode).

The flex layout (where the inline progression is still horizontal but cells align vertically on successive rows is better: it allows reading the content entirely in one direction, without having to rollback to top of the next column on long lists: multicolumn layout works well only when the maximum height reached when the width is restricted: it is poor when there are 2 or 3 columns that can fit). With a flex layout, you should render cells with small horizontal margins, but large vertical margins to give a correct visual cue on the expected direction of reading, but also to allow better touch accessibility, you can enhance this layout using thin horizontal rulers between rows, i.e. horizontal borders at top/bottom, but no side border at all on left and right.

Sumit removed a subscriber: Sumit.Apr 17 2018, 6:34 PM

If using CSS multicoluln layout, prefer using column-width rather than column-count (even if the specified value 3 is small). And please avoid specifying the width in absolute units, use font-size relative units according t othe text content (this is also needed for accesbility, as users may want to have larger font sizes).

matmarex removed a subscriber: matmarex.Apr 17 2018, 6:36 PM
Krinkle added a subscriber: Krinkle.May 6 2018, 3:03 AM

This was done, years ago, on both mobile and desktop, in the way you specified (column-width, using ems).

https://en.wikipedia.org/wiki/Category:Fruit
https://en.m.wikipedia.org/wiki/Category:Fruit