RE: Empty button baseline difference in IE/Firefox and WebKit browsers

Le 2014-12-16 18:41, Bogdan Brinza a écrit :
>> From: Gérard Talbot [mailto:www-style@gtalbot.org]
>> Sent: Friday, December 12, 2014 5:15 PM
>> To: Bogdan Brinza
>> Cc: W3C www-style mailing list
>> Subject: Re: Empty button baseline difference in IE/Firefox and WebKit
>> browsers
>> 
>> Le 2014-12-12 17:34, Bogdan Brinza a écrit :
>> > Hi,
>> >
>> > Here is yet another interoperability issue we've found during IE
>> > compatibility investigations, that I would like to clarify with
>> > working group.
>> >
>> > Consider the following simplified example -
>> > http://jsfiddle.net/x2vgt1xz/ - it looks to me that IE/Firefox sets
>> > empty element baseline as if the button had a content inside, while it
>> > looks like Chrome is treating the empty button as an empty inline
>> > element.
>> >
>> > We have encountered this on http://www.sportsauthority.com - the site
>> > tries to fix this for WebKit browsers with a rule offsetting title by
>> > negative 10 pixels:
>> >
>> > @media screen and (-webkit-min-device-pixel-ratio: 0) { #header
>> > #utility #sli_search_1 {
>> >                 position: relative;
>> >                 top: -10px;
>> > }
>> > }
>> 
>> <input style="border: 1px solid blue;" type="text" value="text"> 
>> <input
>> style="border: 1px solid red; vertical-align: bottom;"
>> type="submit" value="">
>> 
>> fixed the problem too.
>> 
>> My test:
>> 
>> http://www.gtalbot.org/BrowserBugsSection/css21testsuite/baseline-
>> alignment-replaced-inline-block-0xx.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.
>> "
>> http://www.w3.org/TR/CSS21/visudet.html#leading
>> 
>> Since there is no inflow line boxes when the submit button has 
>> value="",
>> then Chrome 39.0.2171.95 vertically aligns the margin bottom with the
>> baseline of the text-input button. But as soon as the submit button 
>> has text,
>> then both buttons are baseline-aligned according to their text.
>> > Which browsers behaves correctly and per spec in this case?
>> 
>> Hard to say; I'd say Chrome is strictly complying with 10.8.1.


I think Chrome is doing the right thing here; it's definitely complying.


>> On the other
>> hand, shouldn't we always assume that a submit button has a text 
>> label?
>> Why and how is it okay or correct or possible to create a submit 
>> button
>> without a label?
>> 
>> > Or is this
>> > one of the areas left to UA that has compatibility constraints for
>> > some legacy content?
>> 
>> "
>> CSS 2.1 does not define which properties apply to form controls and 
>> frames,
>> or how CSS can be used to style them. User agents may apply CSS 
>> properties
>> to these elements. Authors are recommended to treat such support as
>> experimental. A future level of CSS may specify this further.
>> "
>> 3.2 UA Conformance
>> http://www.w3.org/TR/CSS21/conform.html
>> 
>> That's why we do not have tests about inputs in CSS2.1 test suite.
>> 
>> Gérard
> 
> Thanks Gerard. This possibly explains why IE/Firefox assume there is a
> text, since in many cases that would be true. Moreover the only
> implementation difference comes from empty button here and it does
> looks interesting on Chrome. It's also interesting that your test case
> looks different on IE / Firefox / Chrome for me.

I did not check it on IE. I just thought setting the inline-block's 
line-height was the way to set the height of an inline-block inside a 
line box.

> That is quite unfortunate for interoperability. Can we all agree on
> the desired behavior here and align UAs to that? From browser
> perspective, I'm obviously biased, since IE and Firefox do match
> already, but I would be open to any WG resolution here.

I am not a member of CSSWG. But you can bring this up in one of those 
weekly Agenda conf call meeting.

> Does anybody
> has arguments to support either current IE/FF or Chrome behavior?

Gérard

Received on Wednesday, 17 December 2014 05:28:21 UTC