Dan: punted to the plenary

TODO: Lea leaves comment after breakout (Done)

@hober and I discussed this in a breakout today during our VF2F. We think that the improvement this feature offers over the existing JS library appears to be very incremental, so it appears that the benefit of adding this feature to the Web Platform does not outweigh the additional complexity, and the cost of breaking one of the fundamental assumptions of CSS.

Dan: marked as proposed closing. On 24th May they said they're proposing a change, if agreed the scope of the issue will be much lower. Sounds like a change in scope and this issue is no longer relevant?

Rossen: I think we already discussed it and resolved. Based on our discussion end of May in CSS wg - we've resolved common visibility auto - that was one of the feedbacks that started this conversation... I don't see what else here is needed to continue to talk about.

Dan: we can close this?

Rossen: yeah. User benefit will be pretty great. Reduces need for javascript tricks people were using. This suite of capabilities is coming along pretty nicely. This is just a small addition to overall capabilities. we should not hold back on it.

Dan: We will close at the plenary.

Lea: I didn't see a response

Dan: wait more

Dan: not much since may...

Rossen: we have a css wg resolution a couple of days after the last comment which constrains ... to auto matches only... by virtue of doing that we are scoping its effect quite a bit. So that part is fine. That was one of the points raised initially by ..? Some of it started from Lea's feedback. We have a good resolution on that issue.

Dan: can we close? if they've taken on board our feedback in their design. Do we have further objections? Can we live with it? And/or is there additional work going on in css so it doesn't need to be on TAG's docket?

Rossen: Definitely work going on. in terms of capability..

Dan: there's no privacy and security section. They say there's no need.. have we addressed that previously?

Rossen: I don't think so

Dan: is there some kind of privacy aspect?

Rossen: i don't see how

Lea: they've reduced the cases that violate CSS reactivity but it's still violating it part of the time.. philosophical purity is at the bottom of our priorties so if authors really want this and it's really needed then I guess it shold be fine. I don't like it but.. whatever.

Rossen: essentially this is a broader effort to reduce the overall resource loading during initial loads, there was an umbrella feature called ... where you don't have the content as part of the layout and rendering, but if you search for something with ctrl+f you actually will force the content to get populated and you will get from a user pov what you would have had anyway, however ..

Dan: if something only partially loads, like article text?

Rossen: right, you have loaded your content but you're not necessarily building the rendering part for it, you've parsed it and have the content and you can search it, might do initial layout for it, this is where thesee things are coming into play, the sizes for things, arranged that way, scrollbar has the size it would if laid out normally, but it's not rendered. Now when you go to search and for example scroll into view now the implementation needs to catch up and make sure what's in front of hte user is not a bunch of blanks. This is this whole feature. It had some weird name. This is part of it where the intrinsic size is for an image which is not rasterized and decoded yet, so you don't know what the intrinsic size of the image is

Dan: all aimed at faster page load?

Rossen: yes. And improve other thigs like battery life, memory footprint, cpu etc. Benefits for sure. But these are UA performance optimizations targeted features

Dan: lea what's your objection?

Lea: same objection that we have discussed in the past and gave as feedback - that css has always been this nice reactive language hin which things apply and stop applying without side effects. No ordered steps, current state is always a function of what is currently applying. Value in that simplicity. Last remembered state introduced here breaks this fundamental assumption. First css feature to break this, introducing side effects that persist after certain state has stopped applying introduces state that is not inspectable and has no obvious cause. But it's a philosophical objection.

Dan: I see.

Lea: breaks one of the assumptions of CSS. It is about authors - this is an assumption authors could make, whereas now thye have to take side effects into account. I don't want to stop a feature that is going to help authors

Rossen: users more than authors. From a tooling pov the simplicity that you were referring to also is a huge help to tooling. WYSIWYG developers.

Lea: I hadn't even thought about wysiwyg. Yeah. Also given it works in that way I'm not sure what is the benefit over a js library. that's exactly what a js does, remembers th elast state. Seems the main benefit of this is avoiding including a js library. The drawback is that it breaks one of the very fundamental design principles of css

Dan: you say the theoretical purity is ..

Lea: is it theoretical purity?

Dan: not if that's a principle that has all of these other benefits for developers and for the platform and tools. It's not theoretical purity, it's more.. purity.

Lea: I don't want to stop progress because of purity

Rossen: not about stopping progress, it's about whether or not the language constructs are invalidated

Dan: if other things make that assumptions, tools and stuff that processes css or that authors css makes that assumption and that assumption is broken by this thing.. the feedback from someone else - is that the side effect introduced does not persist after the property has stopped applying. Does that mean there's no side effect at all?

Rossen: well. after the property has stopped applying. You have to ask - what is that 'after' point? If the property applies at a particular frame, when all of the stylesheet and everything is calculated, then this is consistent with css. The effect of the property here is based on some user action, scroll things into view etc..

Dan: if there's something to push back on from a purity perspective we're definitely the ones to do it. We shouldn't pull back from that unless we think they are willing to clarify the design or change the design so it does not have this property

Lea: where do you see this quote?

Dan: in comment from 28th April.

Lea: a different property.. if contain intrinsic size auto is applying, the size is remembered for as long as content visibility auto is applied as well. If content visibilty auto is removed the ua forgets about the size. So there is a side effect when contains intrinsic size auto is removed

Dan: why don't we clarify that? I'm sympathetic to the use case of faster rendering

Lea: that's why I'm saying I'm not sure we should stall progress

Dan: worth continuing to raise the issue. There are side effects to changing this side effects thing. there are unintended consequences where if you change a precept that everyone working in this space knows and agrees to then there are the possibility of unintended consequences

Lea: we said they're breaking the princiople 100% of the time and they made a change so they're breaking it 30% of the time.. but if they're breaking it even 1% of the time it's no longer a universal assumption. Every tool that processes css now needs to take that into account, this edge case, this different behaviour

Dan: that needs to be written down in our feedback.

Lea: I can write a comment

Dan: very fundamental CSS issue about side effects...

Lea: they do make a good point about scrollbars.

reviewing last comment

Rossen: christian basically says you can do this already with scrolling?

Lea: well we can't say if it's a fundamental rule of css if scrollbars also have a similar behaviour.

Rossen: I see christian's point. he's technically correct but the side effects we're talking about here that have the negative behaviour to users -

Lea: element has style that is not a function of the current state.

Dan: [use of the word magic...]

Lea: magic - when behaviour cannot be explained with code or complex heuristics...

Hadley: It usually means we don't understand it. Or there are people who aren't good enough to understand it.

Rossen: or when it's too big to fit in a paragraph...

Rossen: not sure ... I am very familiar with where they're coming from ... it's something we did many years ago in IE9 - predict sizes of media - doing your layout. Approx size, don't have to do a lot of compute .. saved a ton of battery and CPU - and then when you load them and you're close then the user sees no [movement]. From that PoV I sympathize.. and it's generalized. So you can create a wireframe of layout that can then be filled in... Does it have side effetcs? it could if you get it wrong. glitches of re-layout. I convinced myself that this is OK.

Peter: in general that style or layout state is left over from a previous algo is confusing - on the other hand I can think of some situations where we have to go there eventually. I'm OK with this.

Rossen: was curious if this has side effects to transitions in animations...

Dan: set to proposed closed?

Rossen: sounds ok.

Rossen: I will leave the comment.

Rossen: i think their answer to my question is these are non-transitional values. It is what it is.. they still need to make that more clear in the spec, otherwise they're not introducing anything necssarily new here in terms of transtions and animations, so from that point of view I think the feedback is to update the spec. Now the rest of this seems to be going towards closure.. I'll respond, can mark as proposed close

Peter: close in plenary?

Rossen: if they reply by then.

Peter: I'm concerned about making it non-transitional.. bad develoer experience

Rossen: auto is almost always non transitional. Don't know of cases where transitioning from or to auto is transitional

Peter: cases where it could be, but complicated

Rossen: I'm not going to ask them to invent better css out of that feature

Peter: fair enough