- From: CSS Meeting Bot via GitHub <sysbot+gh@w3.org>
- Date: Wed, 09 Oct 2019 16:45:03 +0000
- To: public-css-archive@w3.org
The CSS Working Group just discussed `device-pixel-border-box size`, and agreed to the following: * `RESOLVED: Add API to get content box height and width in device pixel sizes to resize observer. Only return when requested and applies to all element.` <details><summary>The full IRC log of that discussion</summary> <dael> Topic: device-pixel-border-box size<br> <dael> github: https://github.com/w3c/csswg-drafts/issues/3554#issuecomment-538465771<br> <dael> astearns: Discussed device-pixel-border-box size at TPAC<br> <dael> astearns: I recall we still weren't sure how change will effect Safari. Example have now been provided. Do we have enough information on impact to Safari?<br> <dael> smfr: Saw a couple of examples. I think Chris said he ran the tests on Macbook pro retina with the fixes and it made it look better. Can't say without doing work in webkit, but I think sufficient proof this is useful. On non-apple it's well known it's necessary<br> <dael> astearns: Any other new information?<br> <dael> ??: Nothing new except demos and version of chrome that fixes<br> <astearns> s/??/chrishtr/<br> <dael> smfr: I'm surprised you could get good results. Most macbooks have default scaling. Surprised you got good results on a machine with that behavior<br> <dael> chrishtr: It's not the newest<br> <drousso> presnet+<br> <dael> [audio problems<br> <dael> chrishtr: Tested on not absolute newest, but a macbook pro retina. I think it does have value and OS scaling if it's outside of control of application those situations can't be fixed<br> <dael> smfr: What I'm interested in understanding is if on hardware with builtin scaling suc htat you never get pixel perfect is there improvement in device-pixel-border-box ? Is there value in making it optional and allow UA to not provide if it thinks it can provide better. Or do we make it required and force UA to do this when it's not going to get better<br> <dael> myles: Easy to test if you change resolution of OS in your macbook pro<br> <dael> astearns: Sounds to me like we don't have an objection to adding device-pixel-border-box size to the API, but may want another issue about behavior of API possibly making it optional?<br> <dael> chrishtr: Would app fallback be multiply css pixel width and height by device-pixel ratio if UA doesn't supply?<br> <dael> smfr: Impl will alreayd have to multiply by device-pixel-ratio. No, does multiply. Okay.<br> <dael> chrishtr: That was the point, rounding or flooring can't get consistent<br> <dael> smfr: Okay, then makes optional thing annoying<br> <dael> chrishtr: I don't know if built in scaling is higher quality but we got really good results on macbook pros even with non-1 to 1 scaling.<br> <dael> smfr: Okay<br> <dael> s/ chrishtr / ken<br> <dael> smfr: Not objecting to adding. Question if needs to be rectangle or just a size since left and top don't mean anything<br> <dael> chrishtr: Use case for canvas sizing top left not nec<br> <dael> smfr: We don't have a dom size object<br> <dael> chrishtr: Yep. More consistent to have a rect, rect does have meaning. Not used in canvas case<br> <dael> ken: Position of rect a little confusing if you consider overflow area<br> <dael> chrishtr: Does mean where it is on device window though<br> <astearns> s/ken/myles/<br> <dael> chrishtr: It's used within the native texture if there's not special scaling smfr referred to. If texture is scrolled it's still...it doesn't take into account transforms and scrolls<br> <dael> myles: Values off the top of the screen?<br> <dael> chrishtr: I think would be fine to have size only for this reason<br> <dael> chrishtr: top left doesn't seem to mean much, want to know canvas size<br> <dael> astearns: Array of 2 values or are you minting a new size objection?<br> <dael> chrishtr: I don't know. Maybe new size object?<br> <astearns> s/objection/object/<br> <dael> smfr: If it always integral?<br> <dael> chrishtr: Yeah<br> <dael> smfr: Maybe you jsut have two long on the entry<br> <dael> chrishtr: THat are just width and height<br> <dael> chrishtr: As relates to desire to add the eq method to getBoundingClientRect it would change to get device pixel width and height<br> <dael> smfr: If we agree to resizeObserver do we still need?<br> <dael> chrishtr: Don't think so, but ?? from Mozilla thought case was strong so I was okay adding<br> <dael> smfr: Which case was it?<br> <astearns> s/??/Jeff Gilbert/<br> <dael> chrishtr: You have a full screen where you don't want resizeObserver and you want a slight jump on resize frames<br> <dael> ken: Jeff also had concerns that it fires late and application would fall behind a frame which is legit concern<br> <dael> myles: You would need to executecode every frame with this. resizeObserver means code only called when need to be.<br> <fantasai> s/executecode/execute heavy calculations/<br> <dael> ken: Agree, but in experience from a dev on FF stack we felt it was important to aleviate concern. And FF intends to not recompute if layout isn't dirty<br> <tantek> regrets+<br> <dael> smfr: I don't want every getBoundingClientRect to be more expensive<br> <dael> chrishtr: Adding a new thing<br> <dael> smfr: Okay, okay. Should discuss sep.<br> <dael> chrishtr: Okay with me. Is Jeff Gilbert on? Want ot make sure he's okay to separate.<br> <dael> chrishtr: If he's not, maybe tentatively do that.<br> <dael> ken: I think Jeff would object. Not to represent his opinion, but I think he would.<br> <dael> chrishtr: Great to resolve device-pixel-border-box size makes sense and then follow-up on the other one<br> <dael> chrishtr: To make progress.<br> <dael> ken: Want progress too<br> <dael> astearns: smfr you would rather continue new API discussion or resolve to add it and continue discussion?<br> <dael> smfr: Prefer to fork into separate issue<br> <dael> fantasai: Question, says doing device-pixel-border-box size. What if person wants size of padding or content box?<br> <dael> chrishtr: Those other boxes have use cases and tracked via other issues on the spec<br> <dael> florian: But not at device pixel level the others<br> <dael> chrishtr: No. Only use case for device pixels is canvas<br> <dael> fantasai: But why wouldn't people using canvas want to paint inside the border?<br> <AmeliaBR> Wouldn't it be the content-box that is important for the canvas? Since that's what they're using in their code?<br> <dael> chrishtr: Canvas has a certain size and border is outside of that. Browser does that for you.<br> <dael> fantasai: boder box size includes border so if it's not included it's not a border box<br> <dael> chrishtr: It's the device pixel box size in case of canvas. It's actual size of canvas<br> <dael> fantasai: Then it's the content box and we should call it that and not border box<br> <dael> chrishtr: Right<br> <Zakim> fantasai, you wanted to ask about padding/content boxes<br> <dael> ken: Sounds good<br> <dael> astearns: Other discussion?<br> <dael> fantasai: Summary of proposal?<br> <dael> astearns: Add an API to get canvas height and width to resizeObserver<br> <dael> chrishtr: Actual device width and height of the canvas. When changes resizeObserver fires.<br> <dael> fantasai: I want to be clear. Adding and API which is only available on canavas element. Reflects pixel size of content box of canvas element<br> <dael> fantasai: And it has a name that is not device-pixel-border-box<br> <dael> chrishtr: Yes<br> <dael> smfr: Available for any element you resizeObserve not jsut canvas<br> <dael> fantasai: Have had various discussion on only canvas or all and want to be clear<br> <dael> chrishtr: Only use case I know is canvas. Could do it for all<br> <dael> smfr: I wonder if this should be something the user of the API request.<br> <dael> chrishtr: For any API you ask for what you want and you're saying only available on canvas?<br> <dael> smfr: ONly want browser to do computation if author asks for data<br> <dael> chrishtr: For sure. Part of draft spec to observe multiple types of boxes. You say what to observe. I agree browser should only do this if needed<br> <dael> astearns: Further question of if someone requests this on not canvas what happens<br> <dael> chrishtr: Allow or not allow is both okay. In terms of APIs implicity maybe better on all<br> <dael> smfr: Can imagine on something like video. Better on all<br> <dael> chrishtr: No impl difficulty from allowing it<br> <dael> fantasai: Add API to get content box height and width in device pixel sizes to resize observer. ONly return when requested and applies to all.<br> <dael> chrishtr: Can bikeshed name<br> <dael> florian: Not obj, but want to be cautios on all elements. pixels vs device pixels people can get confused about and I have mild concern making this too easily available people will try and use it.<br> <dael> astearns: A lot of things discussing now should be separate issues once we have draft text in place.<br> <dael> astearns: objections to adding this?<br> <dael> RESOLVED: Add API to get content box height and width in device pixel sizes to resize observer. Only return when requested and applies to all element.<br> <dael> astearns: Thanks chrishtr<br> <dael> chrishtr: I appriciate all the feedback<br> <dael> ken: Thanks for discussion<br> <dael> fantasai: Want to discuss optionality<br> <dael> astearns: Add an issue for that<br> </details> -- GitHub Notification of comment by css-meeting-bot Please view or discuss this issue at https://github.com/w3c/csswg-drafts/issues/3554#issuecomment-540086408 using your GitHub account
Received on Wednesday, 9 October 2019 16:45:06 UTC