- From: CSS Meeting Bot via GitHub <sysbot+gh@w3.org>
- Date: Wed, 14 Dec 2022 17:32:48 +0000
- To: public-css-archive@w3.org
The CSS Working Group just discussed `[resize-observer] What should the fragment-aware behavior be when there are no fragments?`, and agreed to the following: * `RESOLVED: we will use an empty array when there are no fragments` <details><summary>The full IRC log of that discussion</summary> <bramus> oriol: we had resolution in the past that ro should expose size of all fragments, which is exposes as an array by the API. spec is only populating single item in array (1st fagment)<br> <bramus> oriol: what should happen when el has no fragments? Do we keep 0,0 as the single entry or do we want an empty array?<br> <bramus> oriol: empty array makes more sense but there is a compat argument there bc there are scripts out there at assume the entry is there<br> <bramus> oriol: otoh if there is no fragment the size is 0x0 then the prev behavior was that the callback was not called anyway.<br> <bramus> oriol: so a change might not affect existing behavior that much<br> <bramus> oriol: can we risk with empty array orshould we go with safe bet of 1 entry in array?<br> <fantasai> I think the correct thing would be a zero-sized array<br> <TabAtkins> Empty array sounds good to me.<br> <fantasai> If we can get away with it, let's do that<br> <bramus> emilio: i think we are probably gonna have to have no item but maybe keep existing behavior and call it a day.<br> <bramus> emilio: fine with empty. if compat issue then try the other<br> <astearns> ack dbaron<br> <bramus> dbaron: i have mixed feelings about this<br> <bramus> dbaron: in one sense it seems like it is the right thing and ecourages ppl to know there are fragments<br> <bramus> dbaron: are ppl going to iterate over fragments?<br> <bramus> dbaron: having an array increases the risk devs can do wrong<br> <bramus> oriol: array we have right now, changing it is not web compatible I’m sure<br> <bramus> oriol: changing from arrays to something else that is<br> <bramus> oriol: ppl assume it is an array<br> <bramus> dbaron: i agree with you there<br> <bramus> dbaron: i am worried that an empty array - even though it increases awareness - will also lead to a lot more JS errors<br> <fantasai> I think it's reasonable. This is querying things that *don't have a box*<br> <bramus> dbaron: including future ones<br> <fantasai> Why would you query the size/position of things that don't have a box in the first place? Most people won't<br> <bramus> astearns: rough concsensus that empty array is correct thing to do<br> <bramus> astearns: fear that it leads to errors, but we can try it<br> <bramus> astearns: and if there is a webcompat issues can try the other thing<br> <bramus> dbaron: i[m fine with that, taking webcompat into account and listening to devs<br> <bramus> astearns: devs who want to process all can do the right thing<br> <bramus> emilio: i think it is a usefull thing. if we can, we should go with empty<br> <bramus> astearns: proposed resolution to we will use an empty array when there are no fragments<br> <bramus> oriol: also the case of inline elems<br> <bramus> oriol: should we treat this case of having no fragments or fragments-size-0?<br> <bramus> astearns: lets resolve on simpler case first<br> <bramus> astearns: objections?<br> <bramus> RESOLVED: we will use an empty array when there are no fragments<br> <bramus> astearns: what about other case?<br> <bramus> astearns: (non-atomic inlines)<br> <fantasai> We do have fragments in that case, should we return an array of those?<br> <bramus> astearns: they have a size of 0, so we would be returning an array of 0-size fragments<br> <bramus> astearns: oriol?<br> <bramus> oriol: no strong opinion<br> <bramus> oriol: we are special casing inline elems and ignoring their size<br> <bramus> oriol: seems arbitrary<br> <bramus> oriol: saying no fragments seems better?<br> <bramus> oriol: other option we could try to stop ignorigntthe size of the inline fragments<br> <fantasai> Returning an array of 0,0 fragments is not great. An array of the actual size of the fragments would make sense, though<br> <bramus> oriol: not sure if compat issues<br> <bramus> oriol: ppl have asked before to know the size of inline elems<br> <bramus> astearns: for purpose of this issue, we can return an empty array only if there are non-atomic inlines. should raise issue for other case. currently we dont have usefull info for inline boxes<br> <bramus> astearns: seems like it could be usesfull to do something else for inlines<br> <fantasai> since we're discussing this now, do we want to consider a resolution to just return an array of actual sizes?<br> <fantasai> if anyone has a concern with that, then we can open issue and return to it<br> <bramus> astearns: proposed resolution: given the state of inline box handling in current spec, since we have nothing useful to give the developers, we will give them empty array<br> <bramus> astearns: have separate issue for things fantasai just raised<br> <oriol> The issue is https://github.com/w3c/csswg-drafts/issues/6358<br> <astearns> ack fantasai<br> <bramus> astearns: proposed resolution: return empty array for inlines but also raise issue for returning better issue<br> <bramus> fantasai: if we are ready to decide we should do instead of postponing<br> <bramus> fantasai: i would say to leave open and not resolve<br> <bramus> astearns: can you open issue for this oriol?<br> <bramus> oriol: link already pasted in IRC<br> <bramus> astearns: leave thing for inlines open<br> </details> -- GitHub Notification of comment by css-meeting-bot Please view or discuss this issue at https://github.com/w3c/csswg-drafts/issues/7734#issuecomment-1351827064 using your GitHub account -- Sent via github-notify-ml as configured in https://github.com/w3c/github-notify-ml-config
Received on Wednesday, 14 December 2022 17:32:50 UTC