[css-display][css-position] Computed value of float with absolute positioning when there is no box?

[Loirooriol]

CSS 2.1 and CSS Position say

1. If 'display' has the value 'none', then 'position' and 'float' do not apply. In this case, the element generates no box.

But does this affect the computed value of position or float?

Both Firefox and Chrome seem to think that the computed value should be the specified one. However, if you specify both absolute positioning and floating, Edge computes float to none, according to

2. Otherwise, if 'position' has the value 'absolute' or 'fixed', the box is absolutely positioned, the computed value of 'float' is 'none'

Anyways, the interesting case is display: contents, which didn't exist in CSS 2.1. I guess it should interact with position and float just like display: none does.

However, in this case Firefox and Chrome also compute float to none when an element with display: contents has both both absolute positioning and floating.

<div id="test1" style="position: absolute; float: left; display: none"></div>
<div id="test2" style="position: absolute; float: left; display: contents"></div>

getComputedStyle(test1).float; // "left" on Firefox and Chrome, "none" on Edge
getComputedStyle(test2).float; // "none" on Firefox and Chrome

What is the expected behavior?

[Loirooriol]

There is also the case of being inside a display: none element:

<div style="display: none">
  <div id="test3" style="position: absolute; float: left"></div>
</div>

getComputedStyle(test3).float; // "none" on Firefox, Chrome and Edge

I don't see why this should be different than when having display: none itself.

[fantasai]

Proposed resolution is that an element with display: none, a child of an element with display: none, and an element with display: contents should all behave the same with respect to computed value computations, and therefore the full set of computed value transformations in CSS2.1§9.7 should be applied in all three of these cases.

Possible edits:

• Remove bullet [css-syntax] Add a Previous Version link to the CR. #1 and the “Otherwise” in item List of changes from 3 #2 -- the fact that display: none doesn't generate a box is already described under the definition of display: none.
• Copy text about “if 'position' has the value 'absolute' or 'fixed', the box is absolutely positioned, the computed value of 'float' is 'none'” into bullet [css-syntax] Add a Previous Version link to the CR. #1.
• Put “if 'position' has the value 'absolute' or 'fixed', the computed value of 'float' is 'none'” as step 0. In step 2, remove “the computed value of 'float' is 'none'”. (Then renumber the steps to start with 1 again.)

[css-meeting-bot]

The CSS Working Group just discussed Computed value of float with absolute positioning when there is no box?, and agreed to the following resolutions:

• RESOLVED: Make the changes listed in css2.1 and position

The full IRC log of that discussion

<dael> Topic: Computed value of float with absolute positioning when there is no box?
<dael> Github: https://github.com//issues/1436
<dael> fantasai: The issue is about if display has value of none 2.1 rules say position and flow don't apply and this short circuts the rest of display conputations. Normally if you have position absolute and float left float computes to none. If you have display none the computation doesn't happen. However, this becomes interesting with display: contents. What do we do for that one.
<dael> TabAtkins: This is where display: contents is the same problem as none, it's just someone is more freshly looking.
<dael> fantasai: Anything display: none due to parents the float computes to none. We propose any element with display: none , chidl of display: none or display: contents they all behave the same in respect to these transformations.
<fantasai> https://github.com//issues/1436#issuecomment-313215820
<dael> fantasai: We proposed specific edits in the issue. We'ld like a resolution to make them consistant and then a second for people tor eview the proposed edits.
<dael> dbaron: Idea is you make them consistant by always applying the rule where if position is absolute float is none.
<dael> TabAtkins: It's bad that it's inconsistant.
<dael> Rossen_: We already do...in all cases we would applyt hte rules and it seems FF and Chrome from reading the issue have a half and half where you do it for display: content but not display: none so you ahve branching somewhere.
<dael> dbaron: I'd be hesitant to have special rules for decendants.
<fantasai> dbaron: But I'd be okay to make them all float: none
<dael> Rossen_: There shouldn't be any special casing for decendants. I was highlighting that in this case you're not going to apply float computation rules, but with display: contents you will. If we all align and make it always apply then it will be more itnernally consistant and interop
<dael> TabAtkins: It matches IE always and Chrome & FF except in cases with display: none. Always applies is a small change.
<dbaron> s/float is none./float is none?/
<dael> Rossen_: I'm fine making the changes to css position. fantasai you said there might be changes to css 2?
<dael> Rossen_: Or is it css display?
<dael> fantasai: Yes for css2. There are edits in the issue. IT would be good for someone to check those
<dael> Rossen_: I did check, but those edits appear in css2.1 section 9.7 and in css position. I can reflect the position changes. Q is do we need to do anything on css-display
<dael> TabAtkins: I don't think so. Algo is only in 2.1 and position. There's nothing special in display.
<dael> Rossen_: Sounds good.
<dael> astearns: sounds like we need to resolve to make edits in css position. WOuld it make sense to make the edits, round of review, and then backport to css2?
<dael> TabAtkins: We were operating off 2.1 algo so we know what needs to be changed.
<ChrisL> we resolved to request CR on css display in February. Is there some issue with the disposition of comments of the transition request? bert was handling it
<dael> astearns: So we'd resolve the change for both position & 2.1
<dael> TabAtkins: Yeah.
<dael> astearns: Obj?
<dael> RESOLVED: Make the changes listed in css2.1 and position

[dbaron]

Could somebody:

• add a test to web-platform-tests to reflect the change, and
• file bugs on the engines that don't pass, pointing to this issue and the test?

(I think it's reasonable to ask that when we're proposing changes to 2.1.)