- From: Dael Jackson <daelcss@gmail.com>
- Date: Wed, 11 Nov 2020 19:30:04 -0500
- To: www-style@w3.org
========================================= These are the official CSSWG minutes. Unless you're correcting the minutes, Please respond by starting a new thread with an appropriate subject line. ========================================= CSS Color 4 and CSS Color Adjust 1 ---------------------------------- - There were concerns about trying to remove the actual value of colors from the getComputedStyle return (Issue #5710: Shielding system colors to avoid fingerprinting) so much of the group was leaning toward no change and documenting the fingerprinting risk. However, the group is going to wait a week before resolving to allow for checking with privacy teams. CSS Fonts 4 ----------- - RESOLVED: Republish a new WD [of Fonts 4] CSS Color 5 ----------- - The group discussed the proposal to add currentBackgroundColor to Color 5 (Issue #5292: Add `currentBackgroundColor` Variable). The use case is to make it easier to have style elements like borders be defined based on their background color. During the conversation there was a fair amount of implementation complexity uncovered since there is often transparent background values. Discussion will return to github to determine if the benefit outweighs the implementation complexity as well as dive further into the detailed requirements. CSSOM View ---------- - RESOLVED: For quirks mode only, the scrolling element should follow same propagation as the overflow:clip (Issue #5601: Document.scrollingElement doesn't reflect viewport propagation correctly in presence of overflow: clip) - RESOLVED: No change (Issue #5260: No way to access the viewport size without losing precision) - emilio will experiment with allowing the viewport size to return doubles to see if it really causes the compat issues which lead to the above resolution. If there aren't compat issues he'll re-open the issue. If there are compat issues he'll create a new issue to develop a separate API to return the doubles. CSSOM ----- - In order to define how rounding should function in CSS (Issue #5689: Is `round` special in CSSOM?) requires a conversation around which is the best language to match. Discussion will continue on GitHub until there's a more definite proposal. - RESOLVED: Have different interfaces for declarations blocks that expose a different set of descriptors/properties (Issue #5649: The way CSSStyleDeclaration exposes properties is not ideal) CSS Values ---------- - RESOLVED: Publish a new WD for Values 4 ===== FULL MINUTES BELOW ====== Agenda: https://lists.w3.org/Archives/Public/www-style/2020Nov/0009.html Present: Rachel Andrew Adam Argyle Joseph Arhar Rossen Atanassov Tab Atkins-Bittner David Baron Christian Biesinger Mike Bremford Oriol Brufau Emilio Cobos Álvarez Brandon Ferrua Simon Fraser Chris Harrelson Dael Jackson Brian Kardell Jonathan Kew Una Kravets Vladimir Levin Daniel Libby Chris Lilley Peter Linss Alison Maher Florian Rivoal Jen Simmons Alan Stearns Miriam Suzanne Lea Verou Greg Whitworth Regrets: Megan Gardner Daniel Holbert Scribe: dael Rossen: I think we have quorum at this point and we've given a couple minutes. Let's get started Rossen: As usual wanted to call for additional items or agenda changes necessary fantasai: One thing <fantasai> https://github.com/w3c/csswg-drafts/issues/5630 fantasai: I still need a response from WK on ^ Rossen: Is that something that needs group time? fantasai: Waiting for webkit. Someone needs to answer smfr: I'll ping myles and see if he can get to it astearns: I have one astearns: Last week I started calling out people with old drafts on TR with the 6 year old CSS Scoping. Another 6 year old /tr is CSS Shapes. Rossen and I are editors so I'm calling myself out to get Shapes updated Rossen: Thank you for calling us out now. We have a race with TabAtkins to see who updates their 6 year old draft first Rossen: Anything else? CSS Color 4 and CSS Color Adjust 1 ================================== Shielding system colors to avoid fingerprinting ----------------------------------------------- github: https://github.com/w3c/csswg-drafts/issues/5710 fantasai: We were going over the privacy considerations for color adjust fantasai: main issue was way system colors were exposed through systemColor keywords or when we force because getComputedStyle returns used value rather than computed fantasai: Three options. 1) can't fix. 2) computed value gets returned not the used. Not sure webcompat implications. 3) return a value to getComputedStyle which is not necessarily the value actually used fantasai: Could return the same standard values. For forced colors return the color that would have been the color before we forced fantasai: Question is do we want to do something like that? Upside is reduce fingerprinting. Down side is if author wants to do something based on system colors they can't do calculation based on that chris: I fairly recently added something for deprecated system colors which was mandatory mapping to non-deprecated. I'm not sure if that helps but it would mean used color would be same as a non-deprecated colors fantasai: This is about non-deprecated. That reduces number of keywords but problem still exists <leaverou> if you're interested in web compat, system colors are only used in 0.2% of pages (any system color) Rossen: With options 2 & 3 I'm curious if system colors will be that useful at that point. Lot of guidance on how to use system colors, especially in settings of forced colors where people encouraged to use system colors elsewhere if they take colors in their own hands Rossen: With that in mind I'm not sure how attainable 2 and 3 will be from author capability fantasai: Can still use system color, just can't use a variation on the system color. You can't compute a value based on actual value Rossen: That was my point chris: I think that's reasonable. I don't see call to modify system colors. Point is they're semi-standard. If you change no benefit over spec directly leaverou: I checked web compat and system colors are only in 0.2% of pages in http archive Rossen: That's quite a bit <leaverou> There is also data per color here: https://docs.google.com/spreadsheets/d/1sMWXWjMujqfAREYxNbG_t1fOJKYCA6ASLwtz4pBQVTw/edit#gid=279222916 emilio: I was going to point out opposite. Probably we cannot change. We need to return an actual color. Even though not used explicitly they're used by default in UA. Pretty sure people look at getComputedStyle on a select and expect a color back Rossen: Related, if we restrict system colors to keywords only would using them as part of a color function still function? TabAtkins: Yeah. Exposing actual color to scripts is the thing. Using them is fine smfr: If you have special behavior for system colors you have to track through color modifications like lighter and darker. You'd have to mask it all the way through TabAtkins: Yep. Similar to :visited which is tricky <chris> system colors only used for links now, https://drafts.csswg.org/css-color-4/#sample chris: We changed user stylesheet for light/dark. Only three uses remain ^ iank: I wanted to say I'm a little concerned about compat situation of changing getComputedStyle. As a webdev I did see code which would explicitly read out the color from getComputedStyle to determine if a11y mode is on. Some investigation would have to check if major web properties broke under a11y modes with this change TabAtkins: Ultimately if we say no it's okay. It just needs to be documented as a fingerprinting risk. If we're okay with it we can leave as is. It's the only fingerprinting surface in the spec iank: Not saying no, saying compat risk florian: Given these are maintained they could switch. If they are not there's a risk indeed Rossen: Sounds like there's go with option 1 which is say no and document the fingerprinting or take another option based on additional research and experimentation Rossen: As a group are we comfortable with option 1? Objections to say no change on this and we'll document the fingerprinting exposure? smfr: I need to talk to privacy people before I agree Rossen: In that case we'll leave it open as is. In both cases we need more data before we resolve Rossen: smfr can you follow up and we bring it back next week? smfr: Sure. Rossen: Let's do that. We'll give the Apple folks a week and depending on how things go we may pick option 1 Wide Review of CSS Fonts 4 ========================== github: https://github.com/w3c/csswg-drafts/issues/4944 Rossen: Do we want a new CR? fantasai: It's a WD chris: Yes we do fantasai: Chris wanted the next as CR but it's not there RESOLVED: Republish a new WD CSS Color 5 =========== Add `currentBackgroundColor` Variable ------------------------------------- github: https://github.com/w3c/csswg-drafts/issues/5292 una: The idea behind currentBackground came from work in color 5 with color mix. Use case I see commonly is unity within an element where you want a border or a shadow to be related to the primary color of an element which is usually the background una: Right now need a separate variable. currentBackground would be useful here to use the background color. una: A bit of discussion on issue. Way I see it is because transparent is default value you look for closest parent with a color and use that una: leaverou had a great comment about a current function to take any inherited keyword. That would work for things like font weight for text decor. una: Would love questions, comments, thoughts leaverou: The clarify my proposal is not for current function to take any property as an argument. I said this is useful but since in future we want similar perhaps syntax should allow for us to add more keywords in future leaverou: I suggested starting with color and background color. It's no more complex then keywords but it's more extensible for the future. If it's a function that's like any property or longhand that's harder to impl. I wouldn't want to stall this very useful feature by making it complex una: Agree. Starting with subset of arguments for current is a great route TabAtkins: I have a slight objection to trying to generalize to a current function because behaviors won't be same. Discussion in thread about if currentBackgroundColor would compute to self or would compute at computed value time and inherit as that color. TabAtkins: Suspect for background color because transparent we wouldn't want the behavior of currentColor. Tying together in one syntax implies similar behavior. Since our two examples are divergent I'm not convinced we'd have coherence in our 3rd or 4th leaverou: Keyword that looks like currentColor also suggests they might be the same? TabAtkins: Yes, but we can't avoid that much similarity. A brand new current has a more implicit guarantee of similar I think emilio: I want to say on the call xidorn's concerns about implementation complexity vs benefit. Hesitant about mode dependencies because get complex. Not sure the use case warrants another one una: I think it's a common pattern to have a base color for a component, cards, sidebar, whatever where you have a color theme and additional color values for items in that component based on the theme. I've mostly seen that primary color be the background. That's the inspiration on existing common UI patterns Rossen: Going back to meta point of do we want to pursue...handling semantics later...is this something we want to pursue as part of color 5? Rossen: Use cases and usefulness. Do we have enough merit we can say it sounds like good to put in? <leaverou> +1 would want to pursue <brandon> +1 this would be very useful fantasai: Question is if the use case is strong enough it outweighs dealing with implementation complexity. You have to look through transparent things. If you have an image as the background the base color is not necessarily the color because might have semi-transparent on top so it might not rep the color you want. Also issues with how and when this computes fantasai: On the other hand, we have the use case. I believe una it exists. You can work around with a variable but it's more work for author to establish a convention and stick to it. I haven't read deeply into impl complexity. I think that's what it boils down to. Does it balance out. chris: My point was about you can...first if you look at examples in color 5 for contrast they implicitly use background as the first color for contrast. Simplifies things. On the other hand you've got partial transparency and you could have an image color background color isn't used. chris: At the moment we're sticking a color in there and it's author convention that it's the background. An improvement is good even if not bullet proof leaverou: I wanted to say fantasai raises valid concerns. Would it be possible to have a syntax for composited background color. Start from current and go up until you meet opaque and composite. Use cases from una in need of that, as is the contrast case fantasai: What about an image? Have to narrow to a point leaverou: Images makes it more complex and we don't want to deal. But there's an algorithm for a single color which you can plug into color functions. <gregwhitworth> do we mean true composition because that comes far after style <gregwhitworth> so that would need a round trip to compute <chris> maybe we need a NaC (Not a Color) value smfr: Running algorithm which leaverou described is expensive. You'd have to re-evaluate every frame with animations. I don't think practical. <gregwhitworth> +1 to smfr <gregwhitworth> we investigated this for a dynamic accessible focus rect and decided to not pursue it although I think that still has a higher likely hood of implementation given it only applies to focusable elements Rossen: Given conversation this generated and the thread on GH we can go back to GH and continue there and don't resolve pursue or not now. I see decent support in IRC and decent amount of concern. Rossen: I recommend we continue on GH and bring back in a week or two una: sgtm. Answering about compositing I do think it'll be heavy to calculate that because happens after paint. We could still do it with alpha included and we don't use that value and apply style declarations using that. Lots of places where want alpha and it multiplies on background color alpha. I don't think it's as complex as figuring out composited color. That would be great, but I understand complexity Rossen: Thanks Rossen: Sounds like we should go back to GitHub. Okay? una: Yep CSSOM View ========== Add notIfViewed to ScrollIntoViewOptions; add FocusScrollOptions ---------------------------------------------------------------- github: https://github.com/w3c/csswg-drafts/pull/5677 Rossen: Is zcorpan on or can someone take this? Rossen: It's a PR we want to approve Rossen: Added to the agenda a couple weeks ago Rossen: What did we end up doing last week with the previous PR? TabAtkins: Should move on unless anyone has reviewed Rossen: If this was an exercise to get review to the PR so be it Rossen: Consider yourself asked to review Document.scrollingElement doesn't reflect viewport propagation correctly in presence of overflow: clip -------------------------------------------------------------- github: https://github.com/w3c/csswg-drafts/issues/5601 emilio: The overflow propagation section in css overflow and document.scollingElement disagree. document.scrollingElement returns the body if overflow was propagated from it. That's not what it does if account for overflow:clip emilio: Fix is simple but may be we want to change overflow propagation behavior chrishtr: Are you saying in the issue example scrolling elements should be html not body? emilio: Yes because overflow is hidden effectively. Not visible. It propagates as hidden to the viewport chrishtr: Yep. Rossen: Your proposal is to go with fix the bug or change overflow propagation behavior? <fantasai> wfm emilio: Change scrolling element to match overflow propagation emilio: As far as I can tell that's what Gecko does smfr: Change scrolling element for overflow:clip so it matches overflow:hidden on root emilio: Right emilio: That's what css overflow requires emilio: Overflow:clip behaves same as hidden in the test case smfr: What is scrolling element not in quirks? emilio: document.element smfr: sounds good chrishtr: agreed Rossen: Proposal: For quirks mode only the scrolling element should follow same propagation as the overflow:clip RESOLVED: For quirks mode only, the scrolling element should follow same propagation as the overflow:clip No way to access the viewport size without losing precision ----------------------------------------------------------- github: https://github.com/w3c/csswg-drafts/issues/5260 emilio: window.innerheight and width are lengths. Bad because you want viewport width, especially for fractional widths. No work arounds. emilio: I know there's history here and that some of OM prep remained as long intentionally but I don't think this was one. emilio: I think we should be able to change smfr: Sounds fraught with compat risk. Will people parse int on inner height? emilio: This came from slight change to Firefox UI that added a half pixel to UI which reduced viewport. A bunch of sites broke. I think this fixes more, esp for uses that use zoom-like things to change viewport size. emilio: You can always parse it. Right now people set .width to value of innerWidth and that leaves seams when on fractional dpi context emilio: Agree there is risk emilio: If people think this is not a bad idea I can try to change gecko and see if other engines will follow. If you're convinced it can't happen no point to try smfr: Not convinced but when we tried with other metrics it was a problem. Other option is new APIs that return doubles. Happy for you to try and if it works I can try on WK. Needs extended in the wild tests Rossen: We tried something similar in IE9 days. We exposed a bunch of OM and I believe this is one we changed because a lot of problems. I remember fighting with cnn.com which was fighting to try and readjust and avoid scrollbars. Rossen: At that time we could confuse such a large property so I'm not sure what would be there for small end of the web. I would not underestimate compat risk emilio: But inner width and height don't depend on scrollbars. Not sure it can be the case. But sure. Rossen: That's the feedback for now. If we proceed another point in issue from florian where we took a no change for media width and height. The issue is linked Rossen: We can follow that emilio: That was very much the opposite emilio: As far as I can tell the proposal in the other was rounding for MQ, right? florian: As far as I can tell what this means in MQ stays what they are because make sense that way on OM stays because compat. End result is inconsistent. If we want consistent we have to break one Rossen: Do we favor the risk or the similar. It was the argument of sticking with compat emilio: Fair. I think I'm still going to give it a shot. Nightly or beta to see if there's wreckage. If there is I'll propose a new API. If that sounds good I don't need resolution Rossen: Resolve no change, emilio experiments? emilio: Agree no change for now. Spec shouldn't change without proof change is compatible florian: We're not saying it's the end of the story. I don't think we should close, we should resolve you're investigating Rossen: Closing and resolving are different. If there's more information with strong suggestion in opposite we revisit Rossen: Objections to resolve no change? RESOLVED: No change CSSOM ===== Is `round` special in CSSOM? ---------------------------- github: https://github.com/w3c/csswg-drafts/issues/5689 chris: Context was I was going through cssom definition of serializing color because we resolved on moving it to color 4. Had a special definition of rounding. Seems there is a reason, mainly for negative numbers, that you have to spec chris: Do we want this in cssom or copy to color 4, assume rounding is rounding? I wanted guidance before I remove the section TabAtkins: Legit question. Confusing if round up means toward infinity or away from 0. Ideally shouldn't restate in algos and we should have a statement in OM about how to round TabAtkins: Not sure if Infra has a need emilio: CSS Values should have something about this because came up when dividing numbers Rossen: Had similar discussions around math functions and aligning to a particular language. Discussion around mod operator TabAtkins: I suspect match JS because if someone were to impl on their own that's what would happen TabAtkins: Apparently C++ and JS differ in default rounding up TabAtkins: Is it better to match JS, C++, Rust or what? emilio: Rust does C++ as far as I can tell TabAtkins: So away from 0 fantasai: C++ probably makes more sense for CSS Rossen: Trying to avoid whole discussion about how to align better with math/js/other language which is the discussion we had before which was heated and we kept coming back to it. I would suggest take this back to the issue and come back with a proposal Rossen: We could spend the next 7 minutes just shifting through languages chris: Fine for me CSS Values 4 ============ fantasai: We were just talking values. Values 4 draft is super out of date TabAtkins: I think we discussed in past, just waiting on significant changes list Rossen: We can call one right now TabAtkins: Yeah. Changes list is pretty good. Kept reasonably up to date Rossen: Objections to publish a new WD for Values 4 RESOLVED: Publish a new WD for Values 4 CSSOM ===== The way CSSStyleDeclaration exposes properties is not ideal ----------------------------------------------------------- github: https://github.com/w3c/csswg-drafts/issues/5649 emilio: It's a mess everywhere. I made a proposal. Seemed to be agreement to try and go for it emilio: Not in love with...need to decide on names. I'm fine deciding the names on GH or another call emilio: Idea is to have different interfaces for different declarations. fontFace only has a set of descriptors. Spec is sad and doesn't match browsers. Maybe WebKit but it adds descriptors. emilio: Agreement from browser engines it's a decent path forward Rossen: You're okay continuing discussion in GH? emilio: It would be ideal to resolve on separate interfaces for declarations that declare different things. Names tbd TabAtkins: I would love to have this. Please have it Rossen: Do you have proposal written up? Is it a PR or anything more? emilio: I can summarize in IRC fantasai: Go ahead <emilio> Having different interfaces for declarations that expose a different set of descriptors/properties <emilio> declaration blocks* I guess, naming in the spec is wrong fantasai: I think it's good for each to have different set. Exposing declarations that don't apply is confusing and may have future problems Rossen: I'm hearing support Rossen: We can resolve to adopt the proposal and you can come back with more concrete interfaces. Does that work? emilio: Sounds great Rossen: Objections to Having different interfaces for declarations blocks that expose a different set of descriptors/properties RESOLVED: Have different interfaces for declarations blocks that expose a different set of descriptors/properties Rossen: Top of the hour. We have quite a bit of issues for next week. Thank you all for calling and have a great week. We'll chat next week
Received on Thursday, 12 November 2020 00:31:17 UTC