Re: [css3-flexbox] Fixing the "replaced elements may or may not be inline" issue

(12/05/17 10:41), fantasai wrote:
> On 05/16/2012 07:25 PM, Boris Zbarsky wrote:
>> On 5/16/12 7:22 PM, Boris Zbarsky wrote:
>>> On 5/16/12 5:01 PM, fantasai wrote:
>>>> I think it's okay.
>>>>
>>>> An alternative would be to define a 'flex-item' value for 'display',
>>>> and make it compute to 'inline' except on children of a flex container.
>
> [snip]
> 
> I think it *is* weird. But so's putting a list of special-cased HTML
> elements into a CSS spec. So the question is, what's likely to cause
> fewer problems down the line?

Another option is that we define an anchor here (say, "flex item
elements") and put that list in the HTML spec. We could have used 'any
element that is "intended to be" a replaced element', but the HTML spec
uses a hypothetical technology so-called "Behavior CSS" to describe the
form elements so it's not clear if the term "replaced element" is still
appropriate. To answer that, we need to ask a hypothetical question,
which is "For the form elements that have 'binding: none;', do they
generate flexbox items?"

(12/05/17 23:17), Tab Atkins Jr. wrote:
> On Wed, May 16, 2012 at 11:46 PM, Boris Zbarsky <bzbarsky@mit.edu>
> wrote:
>> On 5/16/12 8:42 PM, Tab Atkins Jr. wrote:
>>> <fieldset>  is display:block already, so it's not troublesome.
>>
>> Hmm.  I guess that's OK; if someone styles it as display:inline
>> they're asking for the non-default handling.
>
> Right.  We're solely trying to handle the things that may be either
> inline or atomic-inline based on used-value-time data.  For
> consistency, we're handling some that are always atomic inlines, like
> <input>.

I am confused as to if you guys reach the same conclusion or not in this
particular case and what the conclusion is. So, for <fieldset
style="display: inline">, does it *not* generate a flexbox item because
it isn't listed in 3. or it does because it falls under

  # 2. An atomic inline-level child of a flex container

. Note that (correct me if I am wrong) <fieldset style="display:
inline;"> is an atomic inline-level because, when set with 'display:
inline', it exhibits the behavior of 'inline-block' in all browsers.

(tested with data:text/html,<!DOCTYPE html>A<fieldset style="display:
inline; border: red solid;">B<br />C</fieldset>D )

If 2. applies, then <fieldset style="display: inline"> is always an
atomic inline like <input> so for the sake of consistency it should be
listed.

(12/05/17 14:46), Boris Zbarsky wrote:
> Given
>
>   <progress>Some text</progress>
>
> in a browser supporting <progress>, is the "Some text" rendered?  If
> not, it's clearly a replaced element.

I've used this criterion to teach a folk about what a replaced element
is, but there seems to be an exception: <br>

(tested with data:application/xml,<html
xmlns="http://www.w3.org/1999/xhtml"><body>A<br>B</br>C</body></html> *)

. If <br> is a replaced element then by the definition in CSS2.1 it is
also an atomic inline and so 2. applies, but I don't think we want that
to happen. (And also it seems that in the HTML spec it's clear that <br>
is not a replaced element.)

I am not sure about what we can do about the spec-implementation
inconsistency here...


* No browser displays "B". It's interesting to note that Opera12alpha is
buggy in that it doesn't display "C" either.


Cheers,
Kenny

Received on Friday, 18 May 2012 02:38:16 UTC