Re: [csswg-drafts] [resize-observer] Consider a mode to indicate that a single pass is all that is needed / perform double settlement pass (#6173)

> Console warnings are outside of the spec. The error warning was explicitly designed to get developer's attention. The theory behind it was that without the error, it would be easy to develop badly performing code.

Yeah, that is understandable. I can see why you would want to get the users attention since it is possible that the errors are a serious problem. I took mine very seriously as well until I fully understood what was going on; I think we definitely want to allow for that level of awareness still.

> sometimes RO limit error is acceptable, and there is no way for web developers to distinguish between acceptable and unacceptable errors inside the error handling routine.

That is basically correct. The common solution today is silence everything; since it's much cheaper and "mostly correct" since an infinite loop is often "obviously" wrong (though, not always)

Aside from your previous suggestions (which I think are good; though I lean more towards a suppression callback). I hinted at this above with the flag, it's just a different level of abstraction that it's done at. Honestly, I think it's the most flexible option and would allow us the most accordance to do the "right thing" but would require more education on the scenarios that it's acceptable.

The most common scenario where you want this to be "OK" is I think the case where you did a self modification and it won't trigger any other changes. This makes up the majority of the cases I've seen, though I admit my exposure is a single one at the companies I've worked.

What is your take on:

> We could also change the bail mechanism to be O(2N) instead of O(N) with the following algorithim adjustment to the specification (3.4.1. Gather active observations at depth):

from above? To try and simplify it, we would basically check allow the callback to run again on the same node once more to accommodate the fact that sometimes it may settle after a 2nd iteration. I don't love it because:

1. It's obviously more expensive; specially if the operation doesn't terminate / settle
2. It's a breaking change technically because we would begin running users code more than once and this could potentially introduce timing related bugs.

Still, it is appealing in it's own way because it's basically like saying "do a 2nd pass with an iteration limit of N = 2", which AFAIK from the original repo notes (from what I can tell it was talked about here: https://github.com/WICG/resize-observer/issues/7)

The con listed there "cons: limit is arbitrary." is legitimate, but if N = 2 then it's less arbitrarily, it's basically "did the layout converge on an acceptable state?" 

So, it is tempting since it would reduce developer friction and make it do the "right thing" from time to time. To make it a non-breaking change, I guess it could be an optional flag.

As someone that did the original implementation I would love your thoughts on this and if it was talked about (I am sure it was!) -- I don't mind doing the leg work of fleshing out the actual proposal, I just want to ensure I have the facts right and my naive interpretation isn't bad. 


-- 
GitHub Notification of comment by hilts-vaughan
Please view or discuss this issue at https://github.com/w3c/csswg-drafts/issues/6173#issuecomment-812964333 using your GitHub account


-- 
Sent via github-notify-ml as configured in https://github.com/w3c/github-notify-ml-config

Received on Sunday, 4 April 2021 03:27:01 UTC