Re: inline-block baseline when the baseline would be outside of the element

On 7/19/13 4:51 AM, "Boris Zbarsky" <bzbarsky@MIT.EDU> wrote:

>On 7/19/13 3:31 AM, Bruno Racineux wrote:
>>Then this stackoverflow question [1],  webkit bug report [2] brought me
>>reading this entire thread.
>
>Your issue isn't about whether baselines lie outside the element but
>just about where the baseline of overflow:hidden inline blocks is, no?
Perhaps... but it is about the difference in browsers interpreting that
baseline.

Again as per specs CSS 2.1 <http://www.w3.org/TR/CSS2/visudet.html>:
"The baseline of an 'inline-block' is the baseline of its last line box in
the normal flow, unless it has either no in-flow line boxes or if its
'overflow' property has a computed value other than 'visible', in which
case the baseline is the bottom margin edge."

In my case [1], IE and FF set the baseline at the edge of the border-box
(with a 24px defined line-height, so 14 extra pixels) because the
'overflow' property is OTHER THAN 'visible'(per spec). I actually expect
that baseline to be clipped with the overflow property, which webkit does,
but not clearly not FF or IE.

If you however set my (.cib) inline-box to 'VISIBLE' in IE and FF, they do
keep the "last line box in the normal flow" and render like webkit/blink
does where the 'in-flow line boxes' are not affected by that extra
baseline gap*. Solely for that spec bit that says I must have
overflow:visible for that?

*The gap being 14px in IE and FF: 24px line-height minus 10px border =
14px below the margin.

My case is similar to bug https://bugs.webkit.org/show_bug.cgi?id=36084

Dave Hyatt at https://bugs.webkit.org/show_bug.cgi?id=36084#c3
said: "inline-block is used heavily on OS X with
text-overflow/overflow-hidden text, and losing the ability to
baseline-align those blocks seems like a flaw in the spec to me.", hence
his logical reluctance to fix the bug for that particular case.

If not completely the same issue from a technical standpoint, these two
issues are surely connected to, by that spec.

Perhaps it is explained best by the person who reported the bug
https://code.google.com/p/chromium/issues/detail?id=258650 with:
"It doesn't have a special case for 'baseline is outside of the element's
margin box'"


>>i.e. If it's a 'span' element (inline by default) set as
>>display:inline-block, it uses the IE/FF behavior keeping the baseline
>>inside the element.
>
>I'm not sure what you mean here...
I mean that, for a inline level element such as span, webkit could fix
this bug https://code.google.com/p/chromium/issues/detail?id=258650
while retaining the current way webkit handles a block level element such
as div.

In other words, you could treat this problem with the following spec
adjustments:

A 'span' element forced as inline-block would keep the baseline like IE/FF
do. (and fix the inline-block for "native inline elements ONLY" in
webkit/blink)

While a 'div' element forced as inline-block would be kept the current way
webkit works, for "native block level elements" (and have FF and IE change
the way it handles the baseline ONLY for native block level elements).

That would give more flexibility, as to which element to use for different
needs from inline-block.

It would mean that if using a 'span' element instead of 'div' for the test
case at:
https://code.google.com/p/chromium/issues/detail?id=258650
would need to be fixed by webkit when dealing with native inline level
elements.
And that my case (using a div or native block level element) need fixing
by IE and FF.

I think such mid-ground solution would set some fairly good expectations.
Or another workable solution need to be made for the "special case for
'baseline is outside of the element's margin box"...

>
>The reason that the baseline of overflow-hidden inline blocks is defined
>like it is is that if the baseline were placed on the first line and
>then the block scrolls, things would get pretty weird.

I am not sure that you mean. I think I agree with you that webkit has it
right.
But then surely IE/FF and webkit are handling that baseline differently
for these two case scenarios, both good and bad depending on the case. And
the discrepancy among browsers can't remain that way forever...

-Bruno

[1] http://www.hexanet.com/test/

Received on Saturday, 20 July 2013 00:11:50 UTC