Open Bug 919281 Opened 11 years ago Updated 2 years ago

horizontal scrollbar appears, in HiDPI mode only, on page using negative letter-spacing approximately the width of a space to make the space go away (e.g., via Pure CSS framework)

Categories

(Core :: Layout: Text and Fonts, defect)

Product:
Core
Component:
Layout: Text and Fonts
Type:
defect

Tracking

()

People

(Reporter: cleonis.bugzilla, Unassigned)

References

(Depends on 1 open bug)

Details

Attachments

(1 file)

Small test case to reproduce the bug, uses Pure CSS framework
403 bytes, text/plain
Details 
This bug also appears under OSX on Retina displays. I discovered it while working on a layout with Yahoo's Pure CSS framework, see the issue filed at https://github.com/yahoo/pure/issues/497 . Tested on Firefox 38.0.1, OSX 10.10.3. I've attached the test case from that issue here.
This is an old bug that perhaps needs to be reprioritized as it's currently unassigned after more than 18 months.

Chiming in, it appears that sometimes FF renders width: 100% as 1px wider than the actual available space. In the Pure example:

.pure-u-1-1 {
    width: 100%; // changing this to 99.99% solves the problem
}

Obviously we don't want to use 99.99% when we really mean 100% just to squash a FF bug.
Product: Firefox → Core
So looking at the testcase in comment 1, what happens there is that a block has a negative letter-spacing and contains two inline-blocks separated by a space each of which has width:100%.  A minimal testcase that has the required properties:

  data:text/html,<!DOCTYPE html><style>div { display: inline-block; width: 100% }</style><body style="letter-spacing: -0.31em; margin: 0; padding: 0"><div></div> <div></div></body>

So what seems to happen here is that we end up with two lines in that body block.  The first line has the inline-block, which has a width exactly equal to the body width, and then has a single text box containing the space between the inline blocks.  This text box about 1px wide. The overall bounds of the line then end up about 1px wider than the viewport.  The second line then has the second inline block.

If letter-spacing is zero, then the box containing the space is still on the first line, but has zero width.

So I tried some other values of letter-spacing.  Once it gets negative enough, the issue appears.  For example, if I set it to -4.5px, then the text box ends up 0.5px wide.  If I set it to -5px, it ends up 1px wide.  If I set it to -10px (or in fact anything less thatn -6px) then the text box ends up 6px wide.  If I set it to -100px the text box ends up 96px wide.

So it sounds like we're including letter-spacing somehow when deciding how big to make that text box (and in particular whether it fits) but not when computing the resulting width of the line.

Here's a testcase that makes it glaringly obvious:

  data:text/html,<!DOCTYPE html><style>div { display: inline-block; width: 100% }</style><body style="letter-spacing: -200px; margin: 0; padding: 0"><div></div> <div></div></body>

I expect that testcase shows the problem in both hidpi and non-hidpi mode, btw; the original testcase happened to only trigger the problem in hidpi mode because the negative letter-spacing was so close to the size of a space char (4px in my case).

James, why exactly is that small negative letter-spacing there?

David, who, if anyone, is currently available to look into the linelayout end of this?
Status: UNCONFIRMED → NEW
Component: General → Layout: Block and Inline
Ever confirmed: true
Flags: needinfo?(dbaron)
Justin, 

Thanks for taking a closer look at this. The negative letter spacing in Pure-grids is there to collapse whitespace. The value is slightly different for some old IE browsers. So it could be that it was targeting webkit back when it was first done. That was many versions of FF ago, and HiDPI displays were not yet common, so the problem wouldn't have appeared when Pure grids were developed.

In a future release I will be revisiting whether this is necessary any more. Still, it's odd that FF is not consistent between HiDPI displays and non, and that Safari and Chrome don't display the problem.
Summary: HiDPI mode enforces wrong horizontal scrollbar on some websites → horizontal scrollbar appears, in HiDPI mode only, on page using negative letter-spacing approximately the width of a space to make the space go away
Summary: horizontal scrollbar appears, in HiDPI mode only, on page using negative letter-spacing approximately the width of a space to make the space go away → horizontal scrollbar appears, in HiDPI mode only, on page using negative letter-spacing approximately the width of a space to make the space go away (e.g., via Pure CSS framework)
So we need to rewrite letter-spacing anyway; see bug 299943 and dependencies.

That said, it does seem like there's an independent bug here.  In general, trimmed whitespace shouldn't contribute to overflow.  If the letter here weren't whitespace, it would have wrapped -- so it does seem rather like trimmed whitespace here.

Then again, presumably when we trim whitespace, we have to undo the effect of the letter-spacing originally applied to it -- and maybe in this case the letter-spacing wasn't actually applied originally?  Or something like that.  (Then again, it looks like text that overflows due to negative letter-spacing *doesn't* contribute to overflow!)

This seems like an extremely obscure bug, though, that's only worth prioritizing if the framework in question is widely used and this problem is encountered regularly.

It's also not at all clear to me that the discussion from comment 1 to the end is the same underlying problem as comment 0.  In fact, I think it's pretty clearly not; comment 0 appears to be a general complaint about high DPI mode causing Web pages not to fit within the display.  That said, I guess we should probably keep the bug being about what it's been from comment 1 to the end.

Maybe the way forward here, though, is to apply the permitted "implementation-dependent limit" to negative letter-spacing (per http://dev.w3.org/csswg/css-text/#propdef-letter-spacing ) and prevent letter-spacing from ever going backwards.  That would address various other issues as well.
Depends on: 299943
Flags: needinfo?(dbaron)
Component: Layout: Block and Inline → Layout: Text
OS: Windows 7 → All
Hardware: x86 → All
Version: 24 Branch → Trunk
Maybe John is interested in looking at this, although it's probably not at the top of the priority list.
Flags: needinfo?(jdaggett)
Flags: needinfo?(jd.bugzilla)
Severity: normal → S3
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Creator:
Created:
Updated:
Size: