[whatwg] Alignment of empty buttons

[Christian Biesinger]

Hi,

I had to recently investigate issues with the alignment of empty
buttons, i.e. , and I noticed some browser
differences.

Specifically, take this testcase:
http://plexode.com/eval3/#s=aekVQXANJVQMbAx14Hz1PdQFcAYMbARIYUVkcAYYOfp8Zo6WFn6KkXphDVlVVUE+bnZ8aEawBsk8dEJaYmB11HwEdtLa4H8PNt08fA14A

Where should the button be positioned relative to the input field (or
if you prefer, the baseline of the block)? Chrome dev, IE and Opera
put the bottom of the button a bit higher than the bottom of the
input, whereas Firefox seems to approximately center the button on the
line (though without using vertical-align:middle).

Chrome stable puts the top of the button slightly below the top of the input.

Any suggestions for what the right behavior here is...? Note that this
isn't an entirely academic question, because websites do use empty
buttons (styling them with a width, height and background image).

-christian

Re: [whatwg] Alignment of empty buttons

[Boris Zbarsky]

On 4/25/13 1:43 PM, Christian Biesinger wrote:

Where should the button be positioned relative to the input field (or
if you prefer, the baseline of the block)?


The question you are really asking is "where is the baseline of the 
button?", right?



Chrome dev, IE and Opera
put the bottom of the button a bit higher than the bottom of the
input, whereas Firefox seems to approximately center the button on the
line (though without using vertical-align:middle).


Gecko puts the baseline of the button at the baseline of the button's 
text, and if the button is not auto-height the extra height is added (or 
removed) equally from above and below the text.


It looks like Chrome dev does the same unless there's no text in the 
button, in which case they put the baseline at the bottom margin edge 
(more inline-block-like behavior?).


-Boris

Re: [whatwg] Alignment of empty buttons

[Christian Biesinger]

On Thu, Apr 25, 2013 at 10:48 AM, Boris Zbarsky  wrote:
> On 4/25/13 1:43 PM, Christian Biesinger wrote:
>>
>> Where should the button be positioned relative to the input field (or
>> if you prefer, the baseline of the block)?
>
>
> The question you are really asking is "where is the baseline of the
> button?", right?

True - when I started writing the email, I thought that Firefox was
actually centering the button, which I only later realized wasn't
quite correct.

>> Chrome dev, IE and Opera
>> put the bottom of the button a bit higher than the bottom of the
>> input, whereas Firefox seems to approximately center the button on the
>> line (though without using vertical-align:middle).
>
>
> Gecko puts the baseline of the button at the baseline of the button's text,
> and if the button is not auto-height the extra height is added (or removed)
> equally from above and below the text.

Hm, but I don't think that's completely correct, because then the
positioning should stay the same when I start entering text in the
button, right? Or does adding text make the text run have height,
affecting where the extra height gets added?

I think what you are saying is: in Gecko, baseline of a button is
(content_box_height - text_height) / 2 + text_ascent

(BTW, where is that code located? I tried and failed to find it :( )

> It looks like Chrome dev does the same unless there's no text in the button,
> in which case they put the baseline at the bottom margin edge (more
> inline-block-like behavior?).

That sounds probably correct. I don't understand inline layout very
well, though I'm trying to learn...

-christian

Re: [whatwg] Alignment of empty buttons

[Boris Zbarsky]

On 4/25/13 1:58 PM, Christian Biesinger wrote:

Gecko puts the baseline of the button at the baseline of the button's text,
and if the button is not auto-height the extra height is added (or removed)
equally from above and below the text.


Hm, but I don't think that's completely correct, because then the
positioning should stay the same when I start entering text in the
button, right? Or does adding text make the text run have height,
affecting where the extra height gets added?


If I recall exactly how this code works, if there is no text then the 
baseline goes at the bottom of the (empty) content box and then the 
extra height is added on both sides.  Once you have text the baseline 
goes on the baseline of the text, which is slightly above the bottom of 
the content box to allow for descenders.



I think what you are saying is: in Gecko, baseline of a button is
(content_box_height - text_height) / 2 + text_ascent


Mm Measured from where?


(BTW, where is that code located? I tried and failed to find it :( )


http://hg.mozilla.org/mozilla-central/file/690b5e0f6562/layout/forms/nsHTMLButtonControlFrame.cpp#l308 
(see the GetBaseline() call and the adjustment by "yoff", where "yoff" 
is half of the extra height we have.  This is computing the ascent of 
the box; the baseline position in the box is then considered to be 
"ascent" from the top.



I don't understand inline layout very well


Does anyone?  ;)

-Boris

Re: [whatwg] Alignment of empty buttons

[Christian Biesinger]

On Thu, Apr 25, 2013 at 11:05 AM, Boris Zbarsky  wrote:
> On 4/25/13 1:58 PM, Christian Biesinger wrote:
>>>
>>> Gecko puts the baseline of the button at the baseline of the button's
>>> text,
>>> and if the button is not auto-height the extra height is added (or
>>> removed)
>>> equally from above and below the text.
>>
>>
>> Hm, but I don't think that's completely correct, because then the
>> positioning should stay the same when I start entering text in the
>> button, right? Or does adding text make the text run have height,
>> affecting where the extra height gets added?
>
>
> If I recall exactly how this code works, if there is no text then the
> baseline goes at the bottom of the (empty) content box and then the extra
> height is added on both sides.  Once you have text the baseline goes on the
> baseline of the text, which is slightly above the bottom of the content box
> to allow for descenders.

Ah... I see. So my formula below is not quite correct in that
text_ascent is only added if there is text.

>> I think what you are saying is: in Gecko, baseline of a button is
>> (content_box_height - text_height) / 2 + text_ascent
>
>
> Mm Measured from where?

>From the top of the content box? Maybe I'm using the term wrong - I
mean the border-box minus borders and padding, which is a slightly
different definition than you used above.

>> (BTW, where is that code located? I tried and failed to find it :( )
>
>
> http://hg.mozilla.org/mozilla-central/file/690b5e0f6562/layout/forms/nsHTMLButtonControlFrame.cpp#l308
> (see the GetBaseline() call and the adjustment by "yoff", where "yoff" is
> half of the extra height we have.  This is computing the ascent of the box;
> the baseline position in the box is then considered to be "ascent" from the
> top.

Ah, I see. It's not entirely clear to me what ASK_FOR_BASELINE means
and what ascent is initialized to when it's not set to that value, but
perhaps those details are not so important right now. That said, what
if there is no child? I guess this discussion doesn't really belong on
this mailing list.

-christian

Re: [whatwg] Alignment of empty buttons

[Boris Zbarsky]

On 4/25/13 3:10 PM, Christian Biesinger wrote:

 From the top of the content box? Maybe I'm using the term wrong - I
mean the border-box minus borders and padding, which is a slightly
different definition than you used above.


That's the content box, yes.


Ah, I see. It's not entirely clear to me what ASK_FOR_BASELINE means
and what ascent is initialized to when it's not set to that value


Basically in this case it means that the child (the anonymous block we 
put inside the button) said "I'm not computing my ascent unless I have 
to; please call GetBaseline() on me to find out what my ascent is".  If 
ascent is not set to ASK_FOR_BASELINE then it's already set to the 
ascent of the child.



That said, what if there is no child?


In Gecko's implementation of buttons there is always an anonymous block 
child wrapping the button contents.


> I guess this discussion doesn't really belong on

this mailing list.


Well, the larger point of "button baselines need to be defined" kinda 
does, either here or on www-style...


-Boris

Re: [whatwg] Alignment of empty buttons

[Christian Biesinger]

On Thu, Apr 25, 2013 at 12:17 PM, Boris Zbarsky  wrote:
> On 4/25/13 3:10 PM, Christian Biesinger wrote:
>> Ah, I see. It's not entirely clear to me what ASK_FOR_BASELINE means
>> and what ascent is initialized to when it's not set to that value
>
>
> Basically in this case it means that the child (the anonymous block we put
> inside the button) said "I'm not computing my ascent unless I have to;
> please call GetBaseline() on me to find out what my ascent is".  If ascent
> is not set to ASK_FOR_BASELINE then it's already set to the ascent of the
> child.

Oh I see now, this is after calling Reflow on the child. Makes sense.

>> I guess this discussion doesn't really belong on
>> this mailing list.
>
>
> Well, the larger point of "button baselines need to be defined" kinda does,
> either here or on www-style...

True, that one belongs here (or on www-style).

There's also the secondary question on whether an empty button should
have a line or collapse. Note that in most browsers, an  looks different from a ...

-christian

Re: [whatwg] Alignment of empty buttons

[Christian Biesinger]

On Thu, Apr 25, 2013 at 10:48 AM, Boris Zbarsky  wrote:
> Gecko puts the baseline of the button at the baseline of the button's text,
> and if the button is not auto-height the extra height is added (or removed)
> equally from above and below the text.
>
> It looks like Chrome dev does the same unless there's no text in the button,
> in which case they put the baseline at the bottom margin edge (more
> inline-block-like behavior?).

I looked at this some more. It seems that for an empty button in
Chrome dev, the baseline gets put just before the bottom padding (by
virtue of implementing buttons via flexbox, which defines that as the
synthesized baseline).

Chrome stable is a little trickier since it depends on the height of
the button, but for "small" buttons I think it uses bottom of margin
box, whereas for "big" buttons the baseline is calculated like for an
inline-block div that has text in it.

IE (and Presto) seems to put it at the bottom of the margin box:
http://jsbin.com/ehosup/2

Obviously, the difference between Chrome dev and IE is subtle with the
default style.

-christian

Re: [whatwg] Alignment of empty buttons

[Christian Biesinger]

fantasai pointed out that CSS does specify this:
"If the box does not have a baseline, align the bottom margin edge
with the parent's baseline."
(http://www.w3.org/TR/CSS2/visudet.html#propdef-vertical-align)

Sounds like there's a bug in Firefox and (still) in Chrome dev.

-christian

On Thu, Apr 25, 2013 at 10:43 AM, Christian Biesinger
 wrote:
> Hi,
>
> I had to recently investigate issues with the alignment of empty
> buttons, i.e. , and I noticed some browser
> differences.
>
> Specifically, take this testcase:
> http://plexode.com/eval3/#s=aekVQXANJVQMbAx14Hz1PdQFcAYMbARIYUVkcAYYOfp8Zo6WFn6KkXphDVlVVUE+bnZ8aEawBsk8dEJaYmB11HwEdtLa4H8PNt08fA14A
>
> Where should the button be positioned relative to the input field (or
> if you prefer, the baseline of the block)? Chrome dev, IE and Opera
> put the bottom of the button a bit higher than the bottom of the
> input, whereas Firefox seems to approximately center the button on the
> line (though without using vertical-align:middle).
>
> Chrome stable puts the top of the button slightly below the top of the input.
>
> Any suggestions for what the right behavior here is...? Note that this
> isn't an entirely academic question, because websites do use empty
> buttons (styling them with a width, height and background image).
>
> -christian

Re: [whatwg] Alignment of empty buttons

[Boris Zbarsky]

On 5/3/13 7:07 PM, Christian Biesinger wrote:

fantasai pointed out that CSS does specify this:
"If the box does not have a baseline, align the bottom margin edge
with the parent's baseline."
(http://www.w3.org/TR/CSS2/visudet.html#propdef-vertical-align)


Yes, but that _if_ the box does not have a baseline.  CSS does not 
specify what replaced elements do or do not have baselines (and it's not 
completely clear even whether  is a replaced elements)...


-Boris

Re: [whatwg] Alignment of empty buttons

[Ian Hickson]

On Fri, 3 May 2013, Boris Zbarsky wrote:
> On 5/3/13 7:07 PM, Christian Biesinger wrote:
> > fantasai pointed out that CSS does specify this:
> > "If the box does not have a baseline, align the bottom margin edge
> > with the parent's baseline."
> > (http://www.w3.org/TR/CSS2/visudet.html#propdef-vertical-align)
> 
> Yes, but that _if_ the box does not have a baseline.  CSS does not 
> specify what replaced elements do or do not have baselines (and it's not 
> completely clear even whether  is a replaced elements)...

The HTML spec is pretty explicit about it not being:

# When the button binding applies to a button element, the element is 
# expected to render as an 'inline-block' box rendered as a button whose 
# contents are the contents of the element.
 -- http://www.whatwg.org/specs/web-apps/current-work/#the-button-element-0

-- 
Ian Hickson   U+1047E)\._.,--,'``.fL
http://ln.hixie.ch/   U+263A/,   _.. \   _\  ;`._ ,.
Things that are impossible just take longer.   `._.-(,_..'--(,_..'`-.;.'

Re: [whatwg] Alignment of empty buttons

[Boris Zbarsky]

On 7/12/13 4:08 PM, Ian Hickson wrote:

The HTML spec is pretty explicit about it not being:

# When the button binding applies to a button element, the element is
# expected to render as an 'inline-block' box rendered as a button whose
# contents are the contents of the element.
  -- http://www.whatwg.org/specs/web-apps/current-work/#the-button-element-0


Hmm.  Is that compatible with the sizing of absolutely positioned 
buttons with "left:0; right: 0"?


For that matter, what happens to buttons if their display style is 
changed (e.g. to block)?


-Boris

Re: [whatwg] Alignment of empty buttons

[Ian Hickson]

On Thu, 25 Apr 2013, Christian Biesinger wrote:
> 
> I had to recently investigate issues with the alignment of empty 
> buttons, i.e. , and I noticed some browser differences.
> 
> Specifically, take this testcase: 
> http://plexode.com/eval3/#s=aekVQXANJVQMbAx14Hz1PdQFcAYMbARIYUVkcAYYOfp8Zo6WFn6KkXphDVlVVUE+bnZ8aEawBsk8dEJaYmB11HwEdtLa4H8PNt08fA14A
> 
> Where should the button be positioned relative to the input field (or if 
> you prefer, the baseline of the block)? Chrome dev, IE and Opera put the 
> bottom of the button a bit higher than the bottom of the input, whereas 
> Firefox seems to approximately center the button on the line (though 
> without using vertical-align:middle).
> 
> Chrome stable puts the top of the button slightly below the top of the 
> input.
> 
> Any suggestions for what the right behavior here is...? Note that this 
> isn't an entirely academic question, because websites do use empty 
> buttons (styling them with a width, height and background image).

On Thu, 25 Apr 2013, Boris Zbarsky wrote:
> 
> The question you are really asking is "where is the baseline of the 
> button?", right?
> 
> Gecko puts the baseline of the button at the baseline of the button's 
> text, and if the button is not auto-height the extra height is added (or 
> removed) equally from above and below the text.
> 
> It looks like Chrome dev does the same unless there's no text in the 
> button, in which case they put the baseline at the bottom margin edge 
> (more inline-block-like behavior?).

On Thu, 25 Apr 2013, Christian Biesinger wrote:
> 
> Hm, but I don't think that's completely correct, because then the 
> positioning should stay the same when I start entering text in the 
> button, right? Or does adding text make the text run have height, 
> affecting where the extra height gets added?
> 
> I think what you are saying is: in Gecko, baseline of a button is 
> (content_box_height - text_height) / 2 + text_ascent

On Thu, 25 Apr 2013, Boris Zbarsky wrote:
> 
> If I recall exactly how this code works, if there is no text then the 
> baseline goes at the bottom of the (empty) content box and then the 
> extra height is added on both sides.  Once you have text the baseline 
> goes on the baseline of the text, which is slightly above the bottom of 
> the content box to allow for descenders.

The spec claims that:

# When the button binding applies to a button element, the element is 
# expected to render as an 'inline-block' box rendered as a button whose 
# contents are the contents of the element.

What this means exactly...

   http://software.hixie.ch/utilities/js/live-dom-viewer/saved/2413

I think the buttons and the divs in this example should basically have the 
same dimensions and positions (colours might differ). Nobody seems to 
quite agree, but I can't work out what they're doing exactly (or why). The 
spec seems like a pretty sane middle ground, though.

-- 
Ian Hickson   U+1047E)\._.,--,'``.fL
http://ln.hixie.ch/   U+263A/,   _.. \   _\  ;`._ ,.
Things that are impossible just take longer.   `._.-(,_..'--(,_..'`-.;.'

Re: [whatwg] Alignment of empty buttons

[Ian Hickson]

On Fri, 12 Jul 2013, Boris Zbarsky wrote:
> On 7/12/13 4:08 PM, Ian Hickson wrote:
> > The HTML spec is pretty explicit about it not being:
> > 
> > # When the button binding applies to a button element, the element is
> > # expected to render as an 'inline-block' box rendered as a button whose
> > # contents are the contents of the element.
> >   -- http://www.whatwg.org/specs/web-apps/current-work/#the-button-element-0
> 
> Hmm.  Is that compatible with the sizing of absolutely positioned 
> buttons with "left:0; right: 0"?
> 
> For that matter, what happens to buttons if their display style is 
> changed (e.g. to block)?

As far as I can tell, browsers keep treating it as an inline-block box in 
those cases. Do you have a specific case in mind that isn't handled that way?

-- 
Ian Hickson   U+1047E)\._.,--,'``.fL
http://ln.hixie.ch/   U+263A/,   _.. \   _\  ;`._ ,.
Things that are impossible just take longer.   `._.-(,_..'--(,_..'`-.;.'

Re: [whatwg] Alignment of empty buttons

[Boris Zbarsky]

On 9/4/13 8:07 PM, Ian Hickson wrote:

As far as I can tell, browsers keep treating it as an inline-block box in
those cases.


OK, that works, I guess.  That does mean that buttons are a replaced 
element, clearly, though...  Something needs to spell that out.


-Boris

Re: [whatwg] Alignment of empty buttons

[Ian Hickson]

On Thu, 5 Sep 2013, Boris Zbarsky wrote:
> On 9/4/13 8:07 PM, Ian Hickson wrote:
> > As far as I can tell, browsers keep treating it as an inline-block box 
> > in those cases.
> 
> OK, that works, I guess.  That does mean that buttons are a replaced 
> element, clearly, though...  Something needs to spell that out.

In what sense?

The definition of "replaced element" here:

   http://www.w3.org/TR/CSS2/conform.html#replaced-element

...doesn't seem to apply to . The rendering of  is very 
much in CSS' scope, no?

-- 
Ian Hickson   U+1047E)\._.,--,'``.fL
http://ln.hixie.ch/   U+263A/,   _.. \   _\  ;`._ ,.
Things that are impossible just take longer.   `._.-(,_..'--(,_..'`-.;.'

Re: [whatwg] Alignment of empty buttons

[Tab Atkins Jr.]

On Thu, Sep 5, 2013 at 1:47 PM, Ian Hickson  wrote:
> On Thu, 5 Sep 2013, Boris Zbarsky wrote:
>> On 9/4/13 8:07 PM, Ian Hickson wrote:
>> > As far as I can tell, browsers keep treating it as an inline-block box
>> > in those cases.
>>
>> OK, that works, I guess.  That does mean that buttons are a replaced
>> element, clearly, though...  Something needs to spell that out.
>
> In what sense?
>
> The definition of "replaced element" here:
>
>http://www.w3.org/TR/CSS2/conform.html#replaced-element
>
> ...doesn't seem to apply to . The rendering of  is very
> much in CSS' scope, no?

Technically, no, buttons are still replaced elements.  In practice,
buttons are pretty much stock CSS elements across all user agents, and
we should probably standardize that.

~TJ

Re: [whatwg] Alignment of empty buttons

[Boris Zbarsky]

On 9/5/13 4:47 PM, Ian Hickson wrote:

In what sense?


In the sense that if its computed display is "block" but its layout 
behavior is not that of a non-replaced block (CSS 2.1 section 10.3.3 and 
so forth), then it's clearly a replaced element with layout behavior 
defined by something other than CSS.



The definition of "replaced element" here:

http://www.w3.org/TR/CSS2/conform.html#replaced-element

...doesn't seem to apply to . The rendering of  is very
much in CSS' scope, no?


Sure doesn't seem to be, since no UA actually renders style="display: block"> the way a CSS block renders; they do something 
totally different which is presumably covered by some other spec (e.g. 
HTML).


-Boris

Re: [whatwg] Alignment of empty buttons

[Ian Hickson]

On Thu, 5 Sep 2013, Boris Zbarsky wrote:
> On 9/5/13 4:47 PM, Ian Hickson wrote:
> > In what sense?
> 
> In the sense that if its computed display is "block" but its layout 
> behavior is not that of a non-replaced block (CSS 2.1 section 10.3.3 and 
> so forth), then it's clearly a replaced element with layout behavior 
> defined by something other than CSS.

Hm, it's true that s do seem exceedingly eager to remain 
inline-block-esque even when set to more block-like display types.


> > The definition of "replaced element" here:
> > 
> > http://www.w3.org/TR/CSS2/conform.html#replaced-element
> > 
> > ...doesn't seem to apply to . The rendering of  is 
> > very much in CSS' scope, no?
> 
> Sure doesn't seem to be, since no UA actually renders  style="display: block"> the way a CSS block renders; they do something 
> totally different which is presumably covered by some other spec (e.g. 
> HTML).

The definition above talks only about the contents of the element, not 
the element itself, except that the element may have intrinsic dimensions. 
In the case of , the contents are very much rendered by CSS. It's 
the element itself that defies CSS rules.

So it's something, but not a replaced element.

It does respond to 'display', just not as you'd expect. For example, 
setting it to display:table doesn't make it a table on the inside:

   http://software.hixie.ch/utilities/js/live-dom-viewer/saved/2650

Setting it to 'table-row' doesn't make it a row on the outside:

   http://software.hixie.ch/utilities/js/live-dom-viewer/saved/2651

Setting it to 'display:block' does seem to make a difference, though:

   http://software.hixie.ch/utilities/js/live-dom-viewer/saved/2652

Browsers (I mainly tested Gecko and WebKit) are remarkably interoperable 
around this.

I've filed a bug to track this:

   https://www.w3.org/Bugs/Public/show_bug.cgi?id=23893

If anyone has any suggestions on how to spec this, I'm eager to here 
them.

-- 
Ian Hickson   U+1047E)\._.,--,'``.fL
http://ln.hixie.ch/   U+263A/,   _.. \   _\  ;`._ ,.
Things that are impossible just take longer.   `._.-(,_..'--(,_..'`-.;.'

Re: [whatwg] Alignment of empty buttons

[Boris Zbarsky]

On 11/22/13 6:00 PM, Ian Hickson wrote:

Hm, it's true that s do seem exceedingly eager to remain
inline-block-esque even when set to more block-like display types.


Or when set to display:inline, for that matter.


The definition above talks only about the contents of the element, not
the element itself, except that the element may have intrinsic dimensions.
In the case of , the contents are very much rendered by CSS. It's
the element itself that defies CSS rules.


By that argument, as  is a non-replaced if the 
s are rendered by the rules of CSS (which in Gecko they are, by 
the way).  But I don't see anyone making that argument...  I don't think 
it's any more valid for a button.


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.  But as I understand, the purpose 
of the concept was precisely to describe all such things.



It does respond to 'display'


So does .


just not as you'd expect. For example,
setting it to display:table doesn't make it a table on the inside:


Yes


Setting it to 'table-row' doesn't make it a row on the outside:


Just like , odd.


Setting it to 'display:block' does seem to make a difference, though:

http://software.hixie.ch/utilities/js/live-dom-viewer/saved/2652


Hey, like .  ;)


Browsers (I mainly tested Gecko and WebKit) are remarkably interoperable
around this.


Yes, they've basically reverse-engineered each other, I expect.  Even a 
few years ago there was less interop here.



If anyone has any suggestions on how to spec this, I'm eager to here
them.


I could probably describe how Gecko implements  if you would 
like.  Either here or in 
.  Just let me 
know.  In rough terms it acts like a replaced element with some custom 
sizing behavior for display-outside purposes and more or less like a 
block for display-inside purposes.  Much like 
content except without 
establishing a new absolute containing block (unless positioned) or CSS 
viewport... There's a lot of details, obviously.


-Boris

Re: [whatwg] Alignment of empty buttons

[Ian Hickson]

On Fri, 22 Nov 2013, Boris Zbarsky wrote:
> On 11/22/13 6:00 PM, Ian Hickson wrote:
> > Hm, it's true that s do seem exceedingly eager to remain 
> > inline-block-esque even when set to more block-like display types.
> 
> Or when set to display:inline, for that matter.
> 
> > The definition above talks only about the contents of the element, not 
> > the element itself, except that the element may have intrinsic 
> > dimensions. In the case of , the contents are very much 
> > rendered by CSS. It's the element itself that defies CSS rules.
> 
> By that argument, as  is a non-replaced if the 
> s are rendered by the rules of CSS (which in Gecko they are, by 
> the way).

s aren't rendered according to the CSS in the way that  
contents are. Consider:

   http://software.hixie.ch/utilities/js/live-dom-viewer/saved/2654


> 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". If the definition is 
wrong, let's fix it, but as currently defined,  isn't a replaced 
element by the CSS definition.


> > Setting it to 'table-row' doesn't make it a row on the outside:
> 
> Just like , odd.

In the case of , that's a bug, as far as I can tell. I don't see what 
in CSS would justify this behaviour.

Maybe it's a bug for  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.


> I could probably describe how Gecko implements  if you would 
> like. Either here or in 
> .
> Just let me know.

Sure, that'd be great. (Either place is fine.)

-- 
Ian Hickson   U+1047E)\._.,--,'``.fL
http://ln.hixie.ch/   U+263A/,   _.. \   _\  ;`._ ,.
Things that are impossible just take longer.   `._.-(,_..'--(,_..'`-.;.'

Re: [whatwg] Alignment of empty buttons

[Boris Zbarsky]

On 11/22/13 8:44 PM, Ian Hickson wrote:

s aren't rendered according to the CSS in the way that 
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,Some text


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,  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 , odd.


In the case of , 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  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  if you would
like. Either here or in .
Just let me know.


Sure, that'd be great. (Either place is fine.)


Will write it up.

-Boris

Re: [whatwg] Alignment of empty buttons

[Ian Hickson]

On Fri, 22 Nov 2013, Boris Zbarsky wrote:
> On 11/22/13 8:44 PM, Ian Hickson wrote:
> > s aren't rendered according to the CSS in the way that 
> >  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, s are replaced elements either.


> > If the definition is wrong, let's fix it, but as currently defined, 
> >  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 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 , odd.
> > 
> > In the case of , 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  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  if you would 
> > > like. Either here or in 
> > > . 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.   `._.-(,_..'--(,_..'`-.;.'

Re: [whatwg] Alignment of empty buttons

[Boris Zbarsky]

On 11/22/13 9:41 PM, Ian Hickson wrote:

Sure, s are replaced elements either.


You mean aren't?

Except in UAs where they seem to be, right?

For what it's worth,  didn't use to be in Gecko either, in this 
sense, until we made it so in 
https://bugzilla.mozilla.org/show_bug.cgi?id=591619



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 s contents aren't outside the scope
of the CSS formatting model. It seems pretty cut and dry to me.


Is  a replaced element?  Why or why not?

Maybe my point is that this definition has little to do with what UAs 
are actually doing...



Well, then we should fix CSS.


Imo, yes.

-Boris

Re: [whatwg] Alignment of empty buttons

[Boris Zbarsky]

On 11/22/13 9:57 PM, Boris Zbarsky wrote:

For what it's worth,  didn't use to be in Gecko either, in this
sense, until we made it so in
https://bugzilla.mozilla.org/show_bug.cgi?id=591619


And to be clear, all that this did is add the equivalent of:

select > :not(:any(option, optgroup)) { display: none; }
optgroup > :not(option) { display: none; }

except also applying to textnodes and operating directly on used style, 
not computed style (which is why it's now a replaced element per your 
definition, since those two exceptions cannot in fact be expressed in CSS).


None of this is very interoperable, of course; e.g. 
http://software.hixie.ch/utilities/js/live-dom-viewer/?saved=2655 and 
http://software.hixie.ch/utilities/js/live-dom-viewer/?saved=2657 are 
rendered quite differently in Gecko and WebKit/Blink.  The latter seem 
to have option and select being a lot more replaced-elementish than they 
are in Gecko.


-Boris

Re: [whatwg] Alignment of empty buttons

[Ian Hickson]

On Fri, 22 Nov 2013, Boris Zbarsky wrote:
> On 11/22/13 9:41 PM, Ian Hickson wrote:
> > Sure, s are replaced elements either.
> 
> You mean aren't?

Right. They have nothing to do with CSS.


> Except in UAs where they seem to be, right?

They aren't replaced elements, by the CSS definition in any UA, as far as 
I can tell.


> > 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 s contents aren't 
> > outside the scope of the CSS formatting model. It seems pretty cut and 
> > dry to me.
> 
> Is  a replaced element?  Why or why not?

No, since the insides of  are clearly in scope of the 
CSS formatting model.


> Maybe my point is that this definition has little to do with what UAs 
> are actually doing...

Well, that's an issue for www-style, I guess.

-- 
Ian Hickson   U+1047E)\._.,--,'``.fL
http://ln.hixie.ch/   U+263A/,   _.. \   _\  ;`._ ,.
Things that are impossible just take longer.   `._.-(,_..'--(,_..'`-.;.'

Re: [whatwg] Alignment of empty buttons

[Boris Zbarsky]

On 11/24/13 8:12 PM, Ian Hickson wrote:

On Fri, 22 Nov 2013, Boris Zbarsky wrote:

On 11/22/13 9:41 PM, Ian Hickson wrote:

Sure, s are replaced elements either.


You mean aren't?


Right. They have nothing to do with CSS.


In Gecko they do: they're just blocks.


They aren't replaced elements, by the CSS definition in any UA, as far as
I can tell.


Some UAs render a  inside an  as specified by CSS.  Some do 
not.  How are they not replaced elements in the latter?


-Boris

Re: [whatwg] Alignment of empty buttons

[Ian Hickson]

On Sun, 24 Nov 2013, Boris Zbarsky wrote:
> On 11/24/13 8:12 PM, Ian Hickson wrote:
> > On Fri, 22 Nov 2013, Boris Zbarsky wrote:
> > > On 11/22/13 9:41 PM, Ian Hickson wrote:
> > > > Sure, s are replaced elements either.
> > > 
> > > You mean aren't?
> > 
> > Right. They have nothing to do with CSS.
> 
> In Gecko they do: they're just blocks.
> 
> > They aren't replaced elements, by the CSS definition in any UA, as far 
> > as I can tell.
> 
> Some UAs render a  inside an  as specified by CSS.

(That's non-conforming, as far as I can tell, for what it's worth. The 
HTML spec says you're supposed to render elements according to what they 
represent, and  elements represent an option in a select, with a 
label, value, etc; children elements have no bearing on all this.)


> Some do not. How are they not replaced elements in the latter?

I don't know what it would mean for them to be replaced elements. The 
 is a replaced element, but its contents have no bearing on the 
CSS spec at all.

But this doesn't seem like a productive avenue of debate, since we've 
already agreed that the term we're debating is defined incorrectly anyway.

-- 
Ian Hickson   U+1047E)\._.,--,'``.fL
http://ln.hixie.ch/   U+263A/,   _.. \   _\  ;`._ ,.
Things that are impossible just take longer.   `._.-(,_..'--(,_..'`-.;.'

Re: [whatwg] Alignment of empty buttons

[Boris Zbarsky]

On 11/24/13 10:27 PM, Ian Hickson wrote:

(That's non-conforming, as far as I can tell, for what it's worth. The
HTML spec says you're supposed to render elements according to what they
represent, and  elements represent an option in a select, with a
label, value, etc; children elements have no bearing on all this.)


I realize that's your opinion and what you've put in the spec for now, yes.


Some do not. How are they not replaced elements in the latter?


I don't know what it would mean for them to be replaced elements. The
 is a replaced element, but its contents have no bearing on the
CSS spec at all.


Why not?

Seriously, how is this different from  being a replaced element 
with a  inside, apart from arbitrarily deciding that it 
should be different?



But this doesn't seem like a productive avenue of debate, since we've
already agreed that the term we're debating is defined incorrectly anyway.


Fair enough.

-Boris

Re: [whatwg] Alignment of empty buttons

[Ian Hickson]

On Sun, 24 Nov 2013, Boris Zbarsky wrote:
> On 11/24/13 10:27 PM, Ian Hickson wrote:
> > (That's non-conforming, as far as I can tell, for what it's worth. The 
> > HTML spec says you're supposed to render elements according to what 
> > they represent, and  elements represent an option in a select, 
> > with a label, value, etc; children elements have no bearing on all 
> > this.)
> 
> I realize that's your opinion and what you've put in the spec for now, 
> yes.

Putting it that way makes it sound like what the spec says here is 
controversial, but really, it's not. HTML has never supported other 
elements in s either at the conformance level or the parser level 
(it's one of the few elements with dedicated rules in the parser), the 
backwards-compatible rendering requires blatently non-CSS behaviour like 
hiding text nodes, making s match platform conventions is 
incompatible with making it stylable at this level given how varied the 
platforms are, etc.

If we wanted to make  stylable, we'd have to define how it worked, 
and that would be non-trivial.


> > > Some do not. How are they not replaced elements in the latter?
> > 
> > I don't know what it would mean for them to be replaced elements. The 
> >  is a replaced element, but its contents have no bearing on 
> > the CSS spec at all.
> 
> Why not?
> 
> Seriously, how is this different from  being a replaced element 
> with a  inside, apart from arbitrarily deciding that it 
> should be different?

It's more like . The CSS model just doesn't apply. Even in Firefox, 
it's not really CSS that's working there. It's some weird proprietary 
variant. I mean, as you've pointed out, child nodes of the  that 
aren't  or  are mysteriously hidden, but also, the 
 elements obey some values of 'display' but don't obey e.g. 
'position' or 'float'; 'white-space' doesn't seem to work right in a 
 or ; the height of the  seems to be based in some 
weird way on the height of some of the s... in the drop-down mode, 
it's even worse, with the text not lining up with the widget, and so on. 

(By the way, in testing this, I discovered  isn't supported 
in Firefox. Also, the default styles for  drop-downs on Mac don't 
seem to match platform convensiots. Also, I don't know what's going on in 
this mess of a test, but clicking the drop-down widget causes Firefox to 
peg the CPU on my machine on Firefox 26:

   http://software.hixie.ch/utilities/js/live-dom-viewer/?saved=2658

HTH. Also ::first-line on a display:table-row doesn't seem to be work, 
though I couldn't tell if that was per-spec or not. It doesn't seem to 
work for regular s either.)

-- 
Ian Hickson   U+1047E)\._.,--,'``.fL
http://ln.hixie.ch/   U+263A/,   _.. \   _\  ;`._ ,.
Things that are impossible just take longer.   `._.-(,_..'--(,_..'`-.;.'

Re: [whatwg] Alignment of empty buttons

[Boris Zbarsky]

On 11/25/13 12:59 AM, Ian Hickson wrote:


It's more like . The CSS model just doesn't apply. Even in Firefox,
it's not really CSS that's working there. It's some weird proprietary
variant.


It's really not, once you have a DOM and are inside .


I mean, as you've pointed out, child nodes of the  that
aren't  or  are mysteriously hidden


That's , not .


but also, the  elements obey some values of 'display' but don't obey 
e.g.
'position' or 'float';


That's pure CSS: it's a !important rule in a UA stylesheet.  I guess you 
could claim that supporting !important in a UA stylesheet is a 
proprietary extension, albeit one that's in the process of being specified.



'white-space' doesn't seem to work right in a  or ;


  option { white-space: nowrap !important; }

in UA stylesheet.


the height of the  seems to be based in some
weird way on the height of some of the s...


That's about , not .


in the drop-down mode, it's even worse


My comments were specifically about  in a listbox.  A combobox 
is a different and more complicated story (though even there the layout 
of the  itself is pure CSS in Gecko).


Put another way, there is no custom layout code for  in Gecko. 
It's all done entirely by the CSS renderer, based on the computed values 
of CSS properties for the element.  Some of those computed values come 
from !important rules in a UA stylesheet, but that's it.



(By the way, in testing this, I discovered  isn't supported
in Firefox.


That's correct.  https://bugzilla.mozilla.org/show_bug.cgi?id=40545


HTH. Also ::first-line on a display:table-row doesn't seem to be work,
though I couldn't tell if that was per-spec or not. It doesn't seem to
work for regular s either.)


::first-line on a display:table-row shouldn't work in Gecko right now, 
yes.  Whether it's per-spec depends on which spec you're reading and the 
phase of the moon.  ;)


It should work on a block, of course, and does in my testing.

-Boris

Re: [whatwg] Alignment of empty buttons

[Tab Atkins Jr.]

On Mon, Nov 25, 2013 at 4:32 AM, Boris Zbarsky  wrote:
> That's pure CSS: it's a !important rule in a UA stylesheet.  I guess you
> could claim that supporting !important in a UA stylesheet is a proprietary
> extension, albeit one that's in the process of being specified.

Already specced and in CR: 

~TJ