| ovasileva | |
| Sep 4 2017, 3:06 PM |
| F9377204: Screen Shot 2017-09-07 at 12.25.24 PM.png | |
| Sep 7 2017, 4:27 PM |
| F9377203: Screen Shot 2017-09-07 at 12.25.11 PM.png | |
| Sep 7 2017, 4:27 PM |
| F9341238: Screen Shot 2017-09-05 at 10.21.55 AM.png | |
| Sep 5 2017, 2:25 PM |
The infobox is sometimes breaking the TOC.
expected behavior: there should not be a gap between the table of contents
observed behavior: the infobox break the table of contents
Apply
#toc { overflow: hidden; }.Wouldn't applying a max-width e.g. 50% be better than a overflow:hidden?
The issue here seems to be the table of contents + infobox have greater combined width than the page itself.
We think this task is similar to T175005 but may be distinct. We're going to try and fix this issue first with the proposed solution and understand why the word wrapping is busted on list items before approaching the parent.
To do:
This seems like the same as https://phabricator.wikimedia.org/T175008#3580659 - I suggest we think of them the same - in terms of how we deal with elements floated left and elements floated to the right - e.g. should we restrict them into columns?
The issue here is the table of contents. The table of contents is attempting to take up the whole width of the screen. The infobox which appears before it in the HTML is floated right so will appear above it when possible. Applying overflow: hidden will fix this but I think this is better fixed by applying the solution in https://phabricator.wikimedia.org/T175008#3584391
Change 376266 had a related patch set uploaded (by Jdlrobson; owner: Jdlrobson):
[mediawiki/skins/Vector@master] Do not allow certain content to span entire page
So the above patch attempts to fix this by defining a fixed width for infoboxes, thumbs and table of contents - and I've put it on staging for you to test.
Note now that the table of contents appears after infobox rather than floated left. This is because of page-break-before: avoid; - do we want to drop that rule as part of this work?
Not sure if this is the best way to go - seems the toc fixed-width is now adding a lot of white space.
Examples:
http://reading-web-staging.wmflabs.org/wiki/Cat
http://reading-web-staging.wmflabs.org/wiki/Tenochtitlan
Not sure if this is the best way to go - seems the toc fixed-width is now adding a lot of white space.
This is not due to the fixed width - it's because of page-break-before: avoid; - as I mentioned above can easily drop this to fix this problem but I wanted to check if we intended TOC to behave like that.
So the current solution constraints infoboxes, floated thumbnails and table of contents to 180pt. I'm not sure if this is a sensible constraint (I got to it via trial and error) - but it seems to be half of the printed output and worked on the handful of articles I tested on. It does however mean that if content is greater than 180pt it may be clipped or behave oddly so if we merge this we may find follow up cases we need to deal with.
This will also take care of T175008. Is this a solution we want to go ahead with?
Does anyone have any other potential solutions that may be better? cc @bmansurov @Niedzielski @pmiazga
@Jdlrobson, hi Jon. Sorry for the noob question but why do we need display: table-cell on .tocnumber, .toctext? When I turn this rule and width: 180pt off, it seems to flow as I would expect.
@Jdlrobson, hi Jon. Sorry for the noob question but why do we need display: table-cell on .tocnumber, .toctext
It looks like this is used to control how the table of contents displays on long lines. I don't know how attached we are to that. We could easily disable this in mobile.
That won't help with T175008 though (hence why I think it's good to think of these 2 problems together).
I noticed we don't have this problem in Vector and the difference between Vector and the print styles is that we're displaying the table of contents as table in vector and block in print styles. Any reason why we chose to use block in print styles? If no, then the issue seems to be fixable by switching to table.
I also think that setting an arbitrary width of 180pt may cause problems down the road when infoboxes will be styled with template styles. We'll lose the flexibility of applying different widths depending on the width of the printed page.
Change 379605 had a related patch set uploaded (by Bmansurov; owner: Bmansurov):
[mediawiki/skins/Vector@master] Print styles: fix breaking of table of contents
Change 376266 abandoned by Jdlrobson:
Do not allow certain content to span entire page
Change 379605 merged by jenkins-bot:
[mediawiki/skins/Vector@master] Print styles: fix breaking of table of contents