Unwanted vertical single-pixel gap appears between floated elements

• Component: Layout and Rendering
• Status: NEW ---

[Richard Hallas]

Created attachment 254576 [details]
Screenshot shows an unwanted vertical pixel gap where two abutting elements fail to touch together

Please visit http://www.careyblyton.com and view the 'breadcrumbs' (page location information) area that appears in the bottom-right corner of every page (white text on a blue background).

NB This problem is relatively trivial, but it's important because (a) it's fairly new misbehaviour (i.e. something that used to work correctly but no longer does), and (b) it has already propagated to the current releases of all the other WebKit-based browsers (i.e. Safari, Chrome, Opera etc.). In other words, the only mainstream browser (on the Mac) that still renders this page element correctly is Firefox, whereas it used to look as it should in all browsers.

The problem is that a vertical gap is appearing between two grouped elements. The 'breadcrumbs' component is made up of an area of white text on a blue background, which is floated to the right within the fixed-position group, and a small graphic to 'smooth' the text area into a decorative blue bar at the foot of the page; this small graphic is floated to the left of the text area.

The two elements should physically touch each other, such that they appear to create a single component. However, in recent releases of WebKit (including the current version 8.0.6 of Safari on Mac OS X 10.10.3), a single pixel's gap has started to appear between the two elements. This used not to happen, and I am not sure at what stage the problem started to appear. I have not as yet discovered a way to work around the problem by changing the CSS; adding extra borders or adjusting padding, for example, still results in the gap appearing.

Please note that the gap seems to be one pixel wide regardless of the screen resolution or scaling. For example, on my new iMac with Retina display, using a native 1x mode (e.g. 5120x2880) shows the gap as being one physical screen pixel wide. However, if I switch to my normal scaled screen mode (i.e. 2560x1440 in 2x detail), the gap is *still* one physical screen pixel wide - i.e. only 'half a pixel' in terms of the website itself and the (standard 72dpi resolution) bitmap graphics that it uses.

[zalan]

The gap is caused by the fact that WebKit table rendering has not been transitioned to subpixel layout/rendering.

The gap is formed between the pageidgraphic and pageidtext. However if the container's display type (paged) is changed from inline-table back to block, the gap disappears. I couldn't figure though why it is set to inline-table the first place. 

<div id="paged">
  <span id="pageidgraphic"></span>
  <span id="pageidtext">Home</span>
</div>

[Richard Hallas]

zalan: Thank you very much for those extremely helpful comments.

The reason why the container was set to inline-table was to do with what happens if the page isn't wide enough to accommodate all the text (i.e. if the breadcrumbs text becomes very long and the page happens to be very narrow). With inline-table set, the browser splits up and rewraps the content, and it remains visible; without it, the content pops off the bottom of the page.

Anyway, after a little experimentation I've fixed the problem by removing the float: right; from the 'pageidtext' element. I can't remember at this stage why both elements were floated (perhaps that was a mistake), but I don't think they needed to be. By ceasing to float the text component and retaining the inline-table setting of the parent element, it continues to work as before in very narrow confines, but the pixel-gap problem goes away.

So, my site is fixed; great! Thanks again.

I still think it was worth reporting the problem, though, because the pixel-gap behaviour is new to recent versions of WebKit (it didn't exist when I created the site).

[zalan]

> I still think it was worth reporting the problem, though, because the
> pixel-gap behaviour is new to recent versions of WebKit (it didn't exist
> when I created the site).
Sure, thanks for reporting! This bug is now blocked by bug 132010.