W3C home > Mailing lists > Public > whatwg@whatwg.org > November 2013

Re: [whatwg] Alignment of empty buttons

From: Ian Hickson <ian@hixie.ch>
Date: Sat, 23 Nov 2013 02:41:00 +0000 (UTC)
To: Boris Zbarsky <bzbarsky@MIT.EDU>
Message-ID: <alpine.DEB.2.00.1311230236530.27139@ps20323.dreamhostps.com>
Cc: whatwg@lists.whatwg.org
On Fri, 22 Nov 2013, Boris Zbarsky wrote:
> On 11/22/13 8:44 PM, Ian Hickson wrote:
> > <select>s aren't rendered according to the CSS in the way that 
> > <button> contents are. Consider:
> > 
> >     http://software.hixie.ch/utilities/js/live-dom-viewer/saved/2654
> 
> OK, but consider 
> http://software.hixie.ch/utilities/js/live-dom-viewer/?saved=2655

Sure, <option>s are replaced elements either.


> > If the definition is wrong, let's fix it, but as currently defined, 
> > <button> isn't a replaced element by the CSS definition.
> 
> The current CSS definition is loose enough that it's not that easy to 
> tell what is or is not a replaced element by that definition, honestly.  

I agree that it's vaguer than ideal, and it might be wrong, but it's not 
_that_ vague. It says "An element whose content is outside the scope of 
the CSS formatting model", and <button>s contents aren't outside the scope 
of the CSS formatting model. It seems pretty cut and dry to me.


> > > > Setting it to 'table-row' doesn't make it a row on the outside:
> > > 
> > > Just like <img>, odd.
> > 
> > In the case of <img>, that's a bug, as far as I can tell. I don't see 
> > what in CSS would justify this behaviour.
> 
> You've expressed that opinion in the past, yes. I may even agree with 
> you on what the CSS spec says, but all UAs have this bug and none seem 
> too interested in trying to fix it (because it's hard to fix it 
> efficiently, in fact).  And at this point I'm not entirely sure a fix 
> would be web-compatible.

Well, then we should fix CSS.


> > Maybe it's a bug for <button> as well, and maybe "replaced element" 
> > needs to be redefined so that it's not about the contents but about 
> > the element having intrinsic dimensions that override normal sizing 
> > behaviour.
> 
> Or maybe we need multiple distinct concepts, yes.
> 
> Certainly the current handling of replaced elements in CSS is all about 
> them having weird sizing (because since by definition CSS has nothing to 
> say about their insides, then sizing is the only thing that remains to 
> define).  So in practice, the concepts of "has weird sizing" and "we 
> don't define what it does on the inside" got completely conflated even 
> in the spec.

Yeah. This might be something I just need to punt on, on the HTML side, 
until CSS has the right hooks to define it.


> > > I could probably describe how Gecko implements <button> if you would 
> > > like. Either here or in 
> > > <https://www.w3.org/Bugs/Public/show_bug.cgi?id=23893>. Just let me 
> > > know.
> > 
> > Sure, that'd be great. (Either place is fine.)
> 
> Will write it up.

Thanks.

-- 
Ian Hickson               U+1047E                )\._.,--....,'``.    fL
http://ln.hixie.ch/       U+263A                /,   _.. \   _\  ;`._ ,.
Things that are impossible just take longer.   `._.-(,_..'--(,_..'`-.;.'
Received on Saturday, 23 November 2013 02:41:24 UTC

This archive was generated by hypermail 2.4.0 : Wednesday, 22 January 2020 17:00:14 UTC