.content table.infobox td:only-child { width: 100%; }

?

that could work but then the <tr> won't match the full width if there are 2 <td>s

for 2 the <td> should be 50% each
for 3 the <td> should be 33%

and so on.. is there a way to do that?

This issue indeed affects mobile devices only (mobile frontend). It was implemented in T162913 because some infoboxes could be narrower than the display width (the infobox width did not automatically matched the display width, it was adapting to the text width instead). But the new rule makes the column width unpredictable. Another example of the suboptimal behaviour could be seen in this article (mobile view). Only two columns, but it's in multiple columns infobox. In the mobile view, the first column is much wider than the second column.

The rule can be probably removed safely if another way how to ensure 100% infobox width (on the mobile devices) is found.

The rule can be probably removed safely if another way how to ensure 100% infobox width (on the mobile devices) is found.

I agree, but I tried couple of other ways :( no luck so far. need a <table> expert the 100% width is an important part of mobile infoboxes.

table.infobox td {
  width: 100%;
  whitespace: nowrap;
}

WFM in Chrome (58.0.3029.110) on macOS Sierra (10.12.4).

By requiring the content of all tds to be rendered on one line, we force the browser into laying out the second td with equal weight.

@phuedx can't do that either

Ugh.

If we want 100% row width, why are we trying to force 100% width into cells, not rows?

The rule

.content table.infobox tr { width: 100% }

will not work?

Or can´t the width rule be implemented directly into infobox definition

   
.infobox {
  font-size: 90%;
  position: relative;
  border: 1px solid @colorGray14;
  margin-bottom: 2em;
  text-align: left;
  background-color: @colorGray15;
  width: 100%;

as above?

@Vachovec1 that was my thinking too.. but tr 100% and table 100% does not ensure that. HTML argh!!

i ran into this problem today as well. A 3 column table had the last column at 50%, but due to both other columns claiming 100%, they got ALL the space, whereas the rest got nothing.

The primary problem here is that are tables are display:block (to account for potential viewport overflow). That's why the row's don't fill out, which the width:100% tries to compensate for.

I see two options

1: exclude .infobox from that general overflow statement for tables.
2: maybe we can make use of flex box ? (remove the old rule, and have progressive enhancement ?

@media (max-size: 720px) {
    .infobox {
        display: flex;
        flex: 1 1 100%;
        flex-flow: column nowrap;
    }

    .infobox > tbody {
        display: flex;
        flex-flow: column nowrap;
    }

    .infobox > tbody > tr {
        min-width: 100%;
        display:flex;
        flex-flow: row nowrap;
    }

    .infobox > tbody >tr > td,
    .infobox > tbody >tr > th {
        flex: 1 0;
    }
}

I tried this on https://en.m.wikipedia.org/wiki/Dutch_East_Indies, and if we'd adapt the infobox to have a max-width on the first column, it would look pretty ok (i see that infobox is actually being phased out, so that first column wouldn't even be a problem (it was an accessibility problem anyways).. Let's try the others:

Also seems reasonable with the cs. page

@TheDJ I like the flexbox approach!

Do you think it's reliable to use flexbox for us? if so, I would be happy to update the description and get this card ready for development.

also cc @phuedx @Jdlrobson ^^ do we use flexbox anywhere else?

In T168716#3396497, @Nirzar wrote:

also cc @phuedx @Jdlrobson ^^ do we use flexbox anywhere else?

We use it in RelatedArticles IIRC.

In T168716#3395825, @Nirzar wrote:

Do you think it's reliable to use flexbox for us? if so, I would be happy to update the description and get this card ready for development.

With the appropriate prefixes, FlexBox is supported by all Grade A browsers. As is always the case with styling, we should define a functional set of rules for browsers that don't support FlexBox – a number of Grade C- browsers – and a set of rules for those that do such that they take precedence. We could consider the current set of rules functional enough and then adopt @TheDJ's (excellent) solution.

One more repetition for good measure: there should be an AC that the current styles aren't destroyed when introducing the FlexBox solution.

Note that my patch always divides infobox columns equally. I'm not entirely sure if that is a problem anywhere, so I'd definitely suggest to test it more widely, before rolling it out to production.

As @phuedx says we do use it.. however RelatedArticles is JavaScript only so we don't care about grade C browsers. As Sam suggests, we should make sure it renders okay on grade C browsers. I'll update description.

@TheDJ or Wikimedia Developers in Africa (or anyone else) if you want to submit a patch I'll happily review/merge. I'd love to fix this but don't have the bandwidth myself right now :(

@Jdlrobson, sadly for me that my internet connection is rated Wikipedia Zero and I can't view images on this ticket, I would have worked on this :(, Maybe someone else will.

The same rule is causing problems in T179808
We should probably merge the two tasks since they are closely related.

They are duplicates, in my browser the CSS rule causes problem more like in T179808 than the one printscreened in the description

@Jdlrobson, removing Africa-Wikimedia-Developers tag as this features on Google-Code-in-2017.

Imported as https://codein.withgoogle.com/tasks/5830357251260416/

Change 399866 had a related patch set uploaded (by Divadsn; owner: Divadsn):
[mediawiki/skins/MinervaNeue@master] Fix infobox styles to work well with multiple column infobox rows

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

@Jdlrobson as you are my second mentor of the task on GCI and @D3r1ck01 isn't able to see any images here, could you please help me to recreate the example article fully for my local devwiki? :)

I only managed to install the necessary extensions and to copy some of those templates from Czech Wikipedia, but it somehow haven't worked out. That's why I am unsure about my patchset.

Change 399866 merged by jenkins-bot:
[mediawiki/skins/MinervaNeue@master] Fix infobox styles to work well with multiple column infobox rows

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

Hey @divadsn ! Sorry for the delay. I took a look and it looks good.
I verified the fix with the following config:

$wgMFContentProviderClass = 'MobileFrontend\ContentProviders\MwApiContentProvider';
$wgMFMwApiContentProviderBaseUri = "https://cs.wikipedia.org/w/api.php";

I then visited http://localhost:8888/w/index.php/Jarmila_Kratochv%C3%ADlov%C3%A1. Hope that's helpful to you in future!

Pulling into sprint for visibility. @Nirzar can you sign off by looking at several pages on staging?

@Jdlrobson, oh great to know, thank you! :)

this is breaking default table styles for all infoxes on staging

@divadsn I had to revert the change as it was a little over-zealous - sorry i missed that in review - the border, background and other styles were removed but we need to retain those. Are you able to still work on this change and address that?

@Jdlrobson sure, I could try looking into that by the end of this week, is it high priority?

@divadsn end of the week would be great if you can commit to that!

Will work tomorrow, I had some school exams to pass today :)

Change 404094 had a related patch set uploaded (by Divadsn; owner: Divadsn):
[mediawiki/skins/MinervaNeue@master] Fix infobox styles to work well with multiple column infobox rows

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

I'm sorry that I've overlooked the basic styling of those elements, now I re-done the patch and kept those styles in tact, only changed the scaling behavior.

@divadsn it seems design wise this looks good although Nirzar notices the infobox shrinks a little on some pages (although I think the new size reflects the actual size of the infobox). There's a minor comment on the patch (DRY) but apart from that I think this looks good to go. Let me know what you think - that can always be fixed in a follow up if you think it makes sense!

Change 404094 merged by jenkins-bot:
[mediawiki/skins/MinervaNeue@master] Fix infobox styles to work well with multiple column infobox rows

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

@Jdlrobson, do we have a target article for this test on Staging? I have been looking for an article using the template in question, but I have not found one.

You can compare http://reading-web-staging.wmflabs.org/wiki/Jarmila_Kratochv%C3%ADlov%C3%A1 to http://en.m.wikipedia.org/wiki/Jarmila_Kratochv%C3%ADlov%C3%A1 (in the latter note the width of the first column is considerably greater than the others)

In T168716#3913425, @ABorbaWMF wrote:

@Jdlrobson, do we have a target article for this test on Staging? I have been looking for an article using the template in question, but I have not found one.

If you have a local MediaWiki instance for testing purposes, you can use this one:

In T168716#3869390, @Jdlrobson wrote:

I verified the fix with the following config:

$wgMFContentProviderClass = 'MobileFrontend\ContentProviders\MwApiContentProvider';
$wgMFMwApiContentProviderBaseUri = "https://cs.wikipedia.org/w/api.php";

I then visited http://localhost:8888/w/index.php/Jarmila_Kratochv%C3%ADlov%C3%A1. Hope that's helpful to you in future!

@Jdlrobson I will follow-up that patch with better looking rules :)

@ABorbaWMF yes I can switch staging to load cs wiki instead of enwiki if you want me to. Just ask here and I'll make that happen.

I am not seeing a difference between staging and production when it comes to the example articles. Maybe it is because I am using enwiki in both places? I'm not sure.

Staging	Prod

Note: noticed the name at the top of the infobox is not centered either.

@ABorbaWMF the problem with the header of this infobox has nothing to do with this task. It's T168861. The infobox header can be inserted two ways: as "title" (caption over the top of the table) or as "above" (text within the uppermost cell of the table). In the mobile view, the first option results in a line of unformatted text as we can see here. The second option works as expected - the result is a formatted (centered, enlarged, custom colored etc.) caption.

Oh, I totally missed that. Yeah, it looks ok. Thanks @Vachovec1