Re: [css3-flexbox] possible-paradox in spec: effects of "float" on a table-component in a flex container?

(12/10/24 3:34), Daniel Holbert wrote:
> The flexbox spec's "float has no effect" doesn't seem to apply,
> because the <td> element isn't a flex item.  So presumably we should
> apply the rules for floats from CSS 2.1 section 9.7: convert the
> <td>'s display value to "block" and float the element (in what
>  containing block...?)
> BUT that causes problems:

Just curious. Is Gecko doing the 'display' value conversion and
determining the containing block of a float at the same time?

>  (a) now our td is display:block, so it *is* a flex item.  So now, the
> "float has no effect" rule suddenly *is* applicable.  So maybe our
> float-triggered display:block conversion should be reverted, to honor
> that?  (But then it would no longer be a flex item, and float *would*
> have an effect again... and around and around we go)

I think this is actually tolerable. In CSS 2.1, the phrase "has no
effect" and the "Applies to:" seem to mean "it has no effect after the
computed value stage", so as long as the layout effect of 'float'
doesn't start to manifest in the computed value stage it should be fine?

> POSSIBLE RESOLUTION: I believe an earlier version of the spec said
> something like:
>   # float has no effect on a child of a flex container
>   # except to change their "display" value.

This makes me wonder if we need

  | float has no effect on a child of a flex container expect to change
  | their "display" value, CSSOM, and the "float" of a child of it if
  | the child has "float: inherit".

Having said that, I am fine with this spec tweak.

Web Specialist, Oupeng Browser, Beijing
Try Oupeng:

Received on Wednesday, 24 October 2012 01:41:14 UTC