Bug 7933 – Empty inline elements are invisible even if they have a padding

• Component: CSS
• Status: RESOLVED CONFIGURATION CHANGED

[Simon Dorner]

This one is really simple to describe: It seems to be impossible to give an empty inline element dimensions and make visible. I tried this by giving it some padding.

This works of course if the element contains some characters other than white space. (e.g.   or "x")

The attached test case renders correctly in Gecko-based browsers, for example: http://simondorner.com/misc/safari_testcase_ff_screenshot.gif - Imho all strong and li-elements should be visible. (The container elements have a grey border to better illustrate what's missing)

This makes it impossible to replace text with a visual representation (icon or graphic text) in visual browsers and it's the only Webkit bug (?) that i really run into all the time.

[Simon Dorner]

Created attachment 7251 [details]
test case

[Simon Dorner]

Created attachment 7252 [details]
Gecko rendering (ff 1.5.0.1) for reference

[Dave Hyatt]

Yeah this is a known issue, although it's unclear to me what the correct behavior is.  If you consume/skip whitespace in and around an inline flow, should the inline flow still render?  We decided it shouldn't.

[Simon Dorner]

Thanks for the comment! Is there any way to avoid this kind of behavior in current Webkit-based browsers? I'm replacing text with images all the time to create accessible web apps.

I was testing this in different browsers and it seems that Gecko, Opera and iCab all render the inline flow (although Opera doesn't expand the parent elements).
Only IE/Mac renders identically to Webkit; IE/Win doesn't render the inline flow too - but it *does* expand the parent elements as if they contained something.

Is there really no specified way of doing this?

Along the way i ran into a related interesting behavior in Webkit that i can't yet really reduce any further. In my projects i'm replacing text using the "Off Left"-technique: I position the element that i want to remove absolutely and give it a large negative left value (left: -2000px) which visually behaves like "display: none". That way the element is still spoken by today's screen readers and users still have keyboard access to the hidden elements (think access keys for the different sections of a page, for example).

Webkit behaves as expected when i do this; it doesn't render any inline containers of the removed elements - as if they where empty or as if their contents had been removed via "display: none".

But: If i do this for a sequence of inline elements and insert some character into one of the container elements (next to the removed content) all the following elements in the sequence *are* magically rendered.

[Simon Dorner]

Created attachment 7278 [details]
Expanded test case

Expanded test case showing both behaviors in action. Maybe this deserves it's own bug?

[Joost de Valk (AlthA)]

Hyatt, what are we going to do with this?

[Robert Blaut]

As I tested today Gecko (Firefox 3) and Presto (Opera 9.5) differs from Webkit on this. I think we should consider to follow other browser in this case to be consistent with them. 

[Dave Hyatt]

We're going to fix it.  We actually got a lot of these tests working.  Now the only ones that fail are empty inlines with DOM content.

[Ahmad Saleem]

Created attachment 460172 [details]
Safari 15.5 matches other browser except one test case

I was able to reproduce this bug using Safari 15.5 on macOS 12.4 in only one test case, where there was difference in rendering from other browser as shown in the picture (as highlighted by pointing green arrow in the attached screenshot).

I reduced the test case further and it is in below test case:

Link - https://jsfiddle.net/g9v5q421/1/

If I am testing incorrectly, please retest accordingly. Thanks!

[Radar WebKit Bug Importer]

<rdar://problem/96544913>

[Ahmad Saleem]

Safari Technology Preview 164 also passes failing test mentioned by myself in attached reference screenshot, it might be another IFC progression. CCing 'Alan' to get input and marking this as "RESOLVED CONFIGURATION CHANGED". Thanks!

[alan]

Thank you, this is indeed an IFC progression!