Page MenuHomePhabricator

Category pages causes articles to list in one row and the "letter" in another
Open, LowestPublic

Description


Since a few months ago articles has started to list on one row while the letter being on a different one. Before it was something like there had to be one article on the row, and if split it would say soemthing like H (cont.)

Event Timeline

Josve05a raised the priority of this task from to Needs Triage.
Josve05a updated the task description. (Show Details)
Josve05a added a project: MediaWiki-Categories.
Josve05a added a subscriber: Josve05a.

Does it happen before you click it as well?

Does it happen before you click it as well?

Yes, this was before I clicked anything (recently updated page). But it also happens when clicking sometimes. Will add browser-info in a sec.

User agent Mozilla/5.0 (X11; CrOS x86_64 6812.88.0) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/42.0.2311.153 Safari/537.36

Operating System Macintosh
Platform UNIX
Internet Browser Chrome 42.0.2311.153
Beta version Yes
Style Sheet Support Yes
Supports Tables Yes
CDF Support No
Supports Cookies Yes
Cookies Enabled Enabled
Supports JavaScript Yes
JavaScript Enabled Yes
JavaScript Version 1.8
Gecko Engine Yes
Screen Dimensions 1366 x 768
Browser Dimensions 1366 x 633

No, it's a separate bug, not really related to T99416 (other than that both resulted from the switch to use CSS columns).

It was discussed before, although we didn't end up solving this issue: T55130#1098438.

Lacking browser support means that this is only fixable for IE 11, old Opera 12 and possibly Firefox.

Jdforrester-WMF set Security to None.

Mmm, put the letter heading and the first entry into a div/table/whatever to ensure they stick together?

That would be a terrible hack that defeats the purpose of using clumns in the first place.

Mmm, put the letter heading and the first entry into a div/table/whatever to ensure they stick together?

I think this is a good idea.

That would be a terrible hack that defeats the purpose of using clumns in the first place.

Why? Putting the letter and its first item in a div could make them stick together, with the proper styling. Why would this harm the columns?

Mmm, put the letter heading and the first entry into a div/table/whatever to ensure they stick together?

Yeah, but how, exactly? You can't wrap a heading and a single list item in a whatever.

<h2>Foo</h2>
<ul>
  <li>Foo</li>
  <li>Bar</li>
  <li>Baz</li>
</ul>
<div>
<h2>Foo</h2>
<ul>
  <li>Foo</li>
</ul>
</div>
<div>
<ul>
  <li>Bar</li>
  <li>Baz</li>
</ul>
</div>

:P

@MaxSem That breaks up the list, which creates accessability issues on its own. The better choice is to use column-break CSS. But browser support is fragmanted.

Change 261723 had a related patch set uploaded (by Bartosz Dziewoński):
Avoid widowing headers on category pages (in supporting browsers)

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

@MaxSem

I am afraid that @matmarex is right. Breaking the list would be ugly; the first item belongs to the list. Maybe putting the "h2" inside the "ul"? Is that allowed?

Maybe putting the "h2" inside the "ul"? Is that allowed?

It's probably not, but it would still probably kind of work. But it doesn't help us much, as we still have to allow column-breaking within the list (otherwise, categories with very many items under each heading would only get a single column) – we actually messed it up this way at first: T55130#1091834.

Change 261723 abandoned by Bartosz Dziewoński:
Avoid widowing headers on category pages (in supporting browsers)

Reason:
OK, I can't be bothered arguing about this.

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

This issue is so old. Let's find out a solution!

When trying to google something up, the first link -> the first answer in that link -> the first solution in that answer:

Nested List
<ul>
    <li>
        Fruit
        <ul>
            <li>Apple</li>
            <li>Pear</li>
            <li>Organge</li>
        </ul>
    </li>
</ul>

Could this solve the issue? Outer list would be non-breakable and inner list breakable.

Take a look on some other solutions in that link or google something up: Google: HTML list with caption

I don't understand how that helps. Note that we're already using a very similar markup, namely:

<div class="mw-category">
    <div class="mw-category-group">
        <h3>Fruit</h3>
        <ul>
            <li>Apple</li>
            <li>Pear</li>
            <li>Organge</li>
        </ul>
    </div>
</div>

Changing the tags does not help resolve this issue, as far as I can tell.

Could this solve the issue? Outer list would be non-breakable and inner list breakable.

That's clever, but it doesn't seem to work. Once you disallow column-breaking of some element, no column breaks will appear in it, even if you allow them for a nested element. Test case: https://jsfiddle.net/0ecqbn5L/

Well, the fiddle is broken for me because per MDN these CSS rules have got no support in browsers. I believe there must be a solution. I googled a little and I've found three interesting concepts: <ul data-title="foo"> ... ul::before; <ul><li>foo</li> ... ul:first-chld; and <dl><dt>foo</dt><dd>... I don't have time to test them

Fix it for browsers with full CSS3 multicolumn support for starters? That includes all but Firefox now.

Only old Opera and IE/Edge support break-before: avoid / break-after: avoid, which we need to prevent the breaking between the header and the list. That page is quite generous in saying Chrome "supports" multicolumn. (This lack is actually described in the footnote 1 though.)

I have already submitted the patch to use those properties long ago (https://gerrit.wikimedia.org/r/261723), but it was met with opposition.

Looks worse with two letters affected in one page:

Nowadays it may be overcome by applying

.mw-category-group {
   break-inside: avoid;
   break-inside: avoid-column;
   page-break-inside: avoid;
   page-break-inside: avoid-column;
   -webkit-column-break-inside: avoid;
   orphans: 3;
   widows: 3;
}

including some fallbacks for CSS2 and older or less smart browsers.

It is not quite clear why our CSS validation is currently refusing page-break-inside:avoid-column assignment.

By CSS3 recommendation orphans and widows are initiallly 2, may be set to 3 or kept but should be made explicit for us.

On w:de:H:VE/? you might play around.

The total number of items displayed (200) won’t be affected, just the presentation and fragmentation of column contents.

There might be other kinds of database output which could benefit as well from such rules.

BTW: note there is a rather old .mw-category { -moz-columns: 3 24em; }
where -moz- could be stripped off now.

@PerfektesChaos We tried and reverted that solution in 2015, because it results in very ugly lists if some of the headings have many more items than other. See: T55130#1091834. The problem can be seen on your example page as well, although it's not as extreme:

Well, it seems to depend on browser technology.

  • Your example browser is ignoring the orphans/widows rule. They take the wording avoid too seriously.
  • I learnt Firefox is not good at this for now.
  • https://caniuse.com/#search=orphans
  • I recall a browser which divided the S properly as expected, but I forgot which.

The development is proceeding; we should revisit this every spring.

  • At least there was progress in keeping things together since 2015.
  • Now we are grizzling that it is kept together too much, we want it to get split again.