Chris Harrelson

I still don't see PrintColorAdjust in the dropdown here: https://chromestatus.com/guide/editall/5159639697850368 Any idea why?

I agree that Chrome appears to render this example wrong (I made the example into [a jsbin here](https://output.jsbin.com/gameleyeci)). What's wrong about it is that it has an incorrect static position...

> You can have this case (abspos element in the top layer depending on fixed pos not in the top layer), It doesn't depend on it though, right? Which is...

Update: looks like it actually renders correctly in Chrome. It pushes down the static position because the top layer is a sibling of the HTML element in the layout tree....

> I'm confused, so in chrome the top-layer reparenting also reparents the regular in-flow position? That is... not what I'd expect... What do you mean by "reparents the regular in-flow...

> It moves the static position to after the html element. Ok thanks for explaining. That's correct, but it's what I would expect. Why would you want the static position...

Update: Chromium now forces eager when printing via user-initiated and script print, as well as with iframes.

> It is unclear to me what specific spec changes need to be made on css-conditional-5 as a result of this resolution. I think the spec change needed there is...

> Could we Agenda+ this to be resolved at the next WHATNOT meeting? Done. Your preferred resolution is no change from the [existing PR's](https://github.com/whatwg/html/pull/10613) behavior, right?

> What is the status of this in the CSS WG? In terms of the CSSWG's process (which follows W3C practices), it is in an editor's draft. There have been...