W3C home > Mailing lists > Public > www-style@w3.org > December 2014

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

From: Bogdan Brinza <bbrinza@microsoft.com>
Date: Tue, 16 Dec 2014 23:41:09 +0000
To: Gérard Talbot <www-style@gtalbot.org>
CC: W3C www-style mailing list <www-style@w3.org>
Message-ID: <BN1PR03MB1374695E508D96A2FB494BEAF6C0@BN1PR03MB137.namprd03.prod.outlook.com>
> 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. 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.

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. Does anybody has arguments to support either current IE/FF or Chrome behavior?
Received on Tuesday, 16 December 2014 23:41:39 UTC

This archive was generated by hypermail 2.4.0 : Friday, 25 March 2022 10:08:49 UTC