- From: Boris Zbarsky <bzbarsky@MIT.EDU>
- Date: Fri, 22 Nov 2013 20:54:07 -0500
- To: Ian Hickson <ian@hixie.ch>
- Cc: whatwg@lists.whatwg.org
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 >> Basically, the concept of "replaced element" as you interpret it is not >> quite flexible enough to describe all the things that "don't behave like >> normal CSS boxes" that we have around. > > "As I interpret it" is "as it's defined in CSS". Maybe. It doesn't seem to be how UAs interprets it... Here's a simple testcase of interest, by the way: data:text/html,<!DOCTYPE html><button style="position: absolute; left: 0; right: 0">Some text</button> note that Blink and Gecko apply the replaced element sizing rules here. So does Presto. IE11 and WebKit don't seem to. > 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. As I said, UAs do various stuff here, not all of it self-consistent. >>> 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. > 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. >> 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. -Boris
Received on Saturday, 23 November 2013 01:54:45 UTC