Page MenuHomePhabricator

Add { overflow: hidden; } to H1, H2, H3, H4, H5, H6; this fixes bunching.
Closed, ResolvedPublic

Description

Add { overflow: hidden; } to H1, H2, H3, H4, H5, H6 in main-ltr.css (and main-rtl.css).

Originally, TheDJ proposed to add overflow:hidden; to H2 in order to prevent the header lines from touching various right-floating elements. But I discovered that applying this to all headers fixes a major problem: Bunching (where the edit links are pushed down the page). With overflow:hidden;, headers respect the margin of all floating elements, causing the edit links to stay in bounds of the headers.

Tested in IE8, Firefox 3.6 and Chrome 8 with Vector, I found no adverse effects. Long headers still line-wrap, so nothing is actually hidden. This is presumed to be beneficial for all skins.


Version: 1.17.x
Severity: normal
URL: http://e.wikipedia.org/wiki/Wikipedia:Bunching

Details

Reference
bz26449

Event Timeline

bzimport raised the priority of this task from to Medium.Nov 21 2014, 11:17 PM
bzimport set Reference to bz26449.
bzimport added a subscriber: Unknown Object (MLST).

This also needs testing in Firefox 2, IE7 and IE6.

If it degrades in those browsers to the current behaviour that would be fine, haven't tested yet though.

Tested in IE6 and FireFox 2.0; although IE6 apparently does not suffer from the bunching bug, the fix has no adverse effects. In FireFox 2, the bunching is fixed with this code.

Tested in Opera 10. Looks very promising. Testing further on enwp.

I couldn't belief we hadn't checked this before, and as a matter of fact, we did check it before. See #1629

This change was made in 2007, but reverted, because it broke on rtl wiki's and on IE for Mac. ( r24253 and r24254 )

Now of course, we don't care about IE for Mac anymore, but perhaps we can make this fix ltr specific this time and be done with it ?

I wonder which browsers exposed the rtl issues....

For one, there is no longer a direction-specific stylesheet in Vector with ResourceLoader, as there shouldn't since content and style should be seperated and could cause extension writers or gadget makers to assume overflow:hidden and it not being there for RTL languages is wrong (or the other way around).

A possible reason I can imagine it broke with RTL is the fact that overflow:hidden can sometimes (or always?) cause the float to be cleared.

A little story, see r79010. I fixed the white whitespace around the thumb by making them transparent. This causes the underlines from the <h#> to go all the way to the edge of the thumb. I dont really see a problem with it, but it's fixed by using overflow:hidden and that border around thumbs should be margin anyway (see r79086)

Alright, I'll add this to Vector tonight but not so that it fixed bunching but so that the room around the thumbnails is preserved (since without overflow:hidden underlines continue through margin)

See also https://bugzilla.wikimedia.org/show_bug.cgi?id=1629#c33

We could solve the bunching by simply not floating them. I remember prototypes in vector that had it next to the title as well.

Added to vector skin in r79087.

See https://bugzilla.wikimedia.org/show_bug.cgi?id=8814#c6 and #c7

overflow:hidden can clip long words. Workaround for Firefox:
h1, h2, h3, h4, h5, h6 { min-width: -moz-min-content }

On Firefox it is not possible to mark a text with mouse beginning inside the
overflow:hidden container and ending outside.

Despite the problems, I believe overflow:hidden is the best solution.

I think the risk of clipping long words is negligable. How about other skins. I know the problem exists in monobook. Is it worth fixing that as well?

Added to other core skins with the same heading/thumb styling in r79091.

Created attachment 7940
Screenshot of the cut-off problem

This screenshot shows the problem that fomafix is describing. The browser was Safari.

Attached:

Screen_shot_2010-12-29_at_16.54.12.png (193×659 px, 39 KB)

Without overflow:hidden the text of too-long-words continues outside the layout and requires scrolling.
Overflow:hidden hides that part. This can be fixed by adding:

word-wrap: break-word;

which is supported in CSS3 and in IE.

See also: http://krijnhoetmer.nl/stuff/css/word-wrap-break-word/

(In reply to comment #12)
Some more examples of long words in an overflow:hidden container and in particular floating objects are here: http://de.wikipedia.org/wiki/MediaWiki_Diskussion:Vector.css#.E2.80.9EVermeide_h.C3.A4ssliche_wei.C3.9Fe_R.C3.A4nder_bei_Float-Objekten_auf_nicht-wei.C3.9Fen_Hintergr.C3.BCnden.E2.80.9C

vector, monobook have
/* Tables */
table {
/* we don't want the bottom borders of <h2>s to be visible through

  • floated tables */

background-color: white;
}

I think by h2 { overflow:hidden } this is no longer necessary.

(In reply to comment #14)
I created a separate bug 26708 to remove table { background-color: white; }

  • Bug 27051 has been marked as a duplicate of this bug. ***

danny.leinad wrote:

Please look at bug28041, I'm not sure is it the same problem.

  • Bug 72 has been marked as a duplicate of this bug. ***