- From: Dael Jackson <daelcss@gmail.com>
- Date: Wed, 4 Nov 2020 09:15:59 -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 Variables & CSS Conditional ------------------------------- - RESOLVED: Close this issue no change (Issue #3171: Is trailing semicolon valid in @supports conditions) CSS Conditional --------------- - RESOLVED: The CSS.supports() function considers all namespaces invalid (like .querySelector() does), the @supports rule consults the stylesheet's namespace map (Issue #3220: Define whether/how it matters if namespace prefixes are declared) - RESOLVED: Confirmed that !important is allowed in @supports - RESOLVED: Publish a CRD of CSS Conditional L3 CSS Color & CSSOM ----------------- - RESOLVED: Serialize RGB and RGBA with commas (Issue #1004: Serialization of specified <color> values) - RESOLVED: If the color has non-1 alpha, use the rgba() function (Issue #1004) - RESOLVED: Add some text about specified values and color keywords in specified and computed are given in lowercase (Issue #1004) - ChrisL will add specified values to all of the color spaces. CSS Images ---------- - RESOLVED: UAs should ignore EXIF data that comes after image data (Issue #4929: Allow impls to not respect exif data if it's after the image data) - RESOLVED: Authors MUST NOT put EXIF data after the image data (Issue #4929) - The existing spec text ( https://www.w3.org/TR/css-images-4/#image-file-formats ) will be used as a starting point for issue #4640 (Integrate with SVG Integration spec) - RESOLVED: Treat aspect ratio of 0 or infinity as auto, propagate to the aspect-ratio property behavior as well (Issue #4572: Zero or infinite intrinsic ratio) - RESOLVED: Accept fantasai's edits [ https://github.com/w3c/csswg-drafts/commit/ff22f40a630e2a120396d6a0f95d78e7601fb644 ] (Issue #4164: Should the values of image-orientation include the <angle> variants?) ===== FULL MINUTES BELOW ====== Agenda: https://wiki.csswg.org/planning/tpac-2020#agenda-schedule Present: Rachel Andrew, Fronteers Rossen Atanassov, Microsoft Tab Atkins-Bittner, Google Christian Biesinger, Google Mike Bremford, BFO Oriol Brufau, Igalia Tantek Çelik, Mozilla Hui Jing Chen, Salesforce Elika Etemad, Invited Expert Brandon Ferrua, Salesforce Simon Fraser, Apple Megan Gardner, Apple Brian Kardell, Igalia Jonathan Kew Rune Lillesveen, Google Chris Lilley, W3C Ting-Yu Lin, Mozilla Alison Maher, Microsoft Myles C. Maxfield, Apple Inc. Theresa (Tess) O'Connor, Apple Morgan Reschenberg, Mozilla François REMY, Invited Expert Florian Rivoal, Invited Expert Jen Simmons, Apple, Inc. Alan Stearns, Adobe Miriam Suzanne, Invited Expert Lea Verou, Invited Expert Greg Whitworth, Salesforce Scribe: gregwhitworth CSS Variables & CSS Conditional =============================== Is trailing semicolon valid in @supports conditions --------------------------------------------------- github: https://github.com/w3c/csswg-drafts/issues/3171 TabAtkins: So the spec for conditionals is fairly clear, grammar doesn't allow semicolon at the end <TabAtkins> http://software.hixie.ch/utilities/js/live-dom-viewer/?%3C!DOCTYPE%20html%3E%0A%3Cstyle%3E%0A%40supports%20(background%3A%20green)%20%7B%0A%20body%20%7B%20background%3A%20green%3B%20%7D%0A%7D%0A%40supports%20(background%3A%20red%3B)%20%7B%0A%20body%20%7B%20background%3A%20red%3B%20%7D%0A%7D%0A%3C%2Fstyle%3E TabAtkins: browsers match, at least Chrome & FF - only question dbaron wanted the semicolon to be valid due to copy/paste and leaving it in there TabAtkins: Should we change the grammar? TabAtkins: Currently everyone is consistent jensimmons: I did this yesterday actually florian: This is a property where consistent behavior is very important florian: Yesterday it didn't work but at least it didn't work everywhere TabAtkins: yep, WPT would show that and the change is relatively small astearns: People do have to prioritize it bkardell: Agree with florian concerns because we have interop. I don't think we've had that kind of change that people would rely on bkardell: There would be a period of several years of chaos bkardell: For authors and it will boil down to users and users don't care about this and this is maybe saving devs a few minutes to learn it <fantasai> +1 to no change <emilio> +1 for that, no point in creating a compat issue where there's none TabAtkins: Sounds like the room is leaning towards No Change <huijing> I also think the as-is is good jensimmons: I'm ok with it, people need to learn it; or re-learn it florian: Given a time-machine I'd have a different opinion RESOLVED: Close this issue no change CSS Conditional =============== Define whether/how it matters if namespace prefixes are declared ---------------------------------------------------------------- github: https://github.com/w3c/csswg-drafts/issues/3220 TabAtkins: Things that take a namespace value, such as the attr function <TabAtkins> @supports (content: attr(n|href)) { } TabAtkins: in this case if the n namespace is not declared, should this supports declaration valid or not? TabAtkins: Emilio had an opinion 14 mins ago TabAtkins: only consider it valid when the namespace has been declared TabAtkins: I don't like namespaces so I don't care <TabAtkins> document.querySelector("a|b") TabAtkins: emilio also pointed out ^ (example) does check the namespace map TabAtkins: thus we should probably stay consistent with APIs that care about namepaces * Chris points out it's a corner case TabAtkins: it shouldn't matter, as chris said it's a corner case fremy: one thing - you have to re-verify the at-supports after loading other style sheets fantasai: no - that's not true, namespaces are per file <fantasai> https://www.w3.org/TR/css-namespaces/#scope fremy: how does that work in queryselector? rune: yeah I don't get how query selector will work <emilio> It does _not_ check the ns map, there's no ns map to check TabAtkins: at-supports should query the stylesheets namespace value <emilio> But yeah @supports could TabAtkins: So, I'm fine with emilio's opinion fantasai: I'm in favor of whatever's easy to implement as well <TabAtkins> proposed resolution: the CSS.supports() function considers all namespaces invalid (like .querySelector() does), the @supports rule consults the stylesheet's namespace map chris: I just want it defined astearns: any objections? RESOLVED: The CSS.supports() function considers all namespaces invalid (like .querySelector() does), the @supports rule consults the stylesheet's namespace map Are there issues with !important in @supports? ---------------------------------------------- github: https://github.com/w3c/csswg-drafts/issues/5559 TabAtkins: This is going to be similar to the first one TabAtkins: Syntax currently allows !important at the end; it has no impact on the result TabAtkins: Implementations that I tested ignore it consistently. Should this be confirmed that we're fine with or not? TabAtkins: Simon found it unfortunate possibly in the past? I feel we're going to lean towards consistency florian: So you can include it? TabAtkins: Yes Chrome/FF do, just ignore it florian: That's good, we may have something later that people can check for that Proposed Resolution: Closed - no change <bkardell> WebKit also seems green in the test RESOLVED: Closed no change: !important can be used in @supports Publication ----------- chris: We're at 0 open issues, that means we'll be able to publish a CR thing outside of privacy and i18n astearns: Deadline? chris: No fantasai: We can publish a crd anytime we want astearns: Are there other changes? chris: Every edit since 2013 astearns: On something that's a short list :P astearns: Should we have a crd to help others fantasai: I think it's a good idea Proposed Resolution: Publish a CRD of CSS Conditional L3 RESOLVED: Publish a CRD of CSS Conditional L3 CSS Color & CSSOM ================= Serialization of specified <color> values ----------------------------------------- github: https://github.com/w3c/csswg-drafts/issues/1004 chris: We already have a resolution to move serialization out of OM into color chris: We don't know how to do that with RGB and I need that <TabAtkins> minor testcase: http://software.hixie.ch/utilities/js/live-dom-viewer/saved/8611 <TabAtkins> Shows Chrome and Firefox agreeing on serializing specified values to the legacy rgba()-with-commas syntax chris: We've already decided since impl determine it's 8 bit we resolve it's in a 255 space; and that's fine chris: If you have a fully opaque color you can miss out on the alpha channel chris: We don't resolve on always using rgba; nor to always use commas, etc <chris> https://drafts.csswg.org/css-color/#resolving-color-values chris: If you look at section 4.6 I have put what I believe to be the current consensus in there chris: showing that you can use decimals in the rgb values and what it maps to chris: how that works with integers and others with commas chris: Which way do people want? TabAtkins: I thought we discussed this before - and we leaned towards compat due to so much color parsing out there chris: I'm fine with that Proposed Resolution: Serialize RGB and RGBA with commas RESOLVED: Serialize RGB and RGBA with commas <TabAtkins> proposed resolution: if the color has non-1 alpha, use the rgba() function [unminuted conversation about process] astearns: and this matches all browsers? TabAtkins: Chrome & FF <emilio> would be surprised if Safari didn't match this either fwiw <bkardell> WebKit output of the test TabAtkins embedded above https://www.irccloud.com/pastebin/sCLw0tYI/ RESOLVED: If the color has non-1 alpha, use the rgba() function <TabAtkins> http://software.hixie.ch/utilities/js/live-dom-viewer/saved/8613 chris: It's clear it's little r, little g, little b chris: but if you spell it currentColor should you get CurrentColor, currentColor, etc TabAtkins: tab discusses interop: FF gives back specified, Chrome gives it canonical form chris: Anyone from Mozilla willing to sign up to change the serialization behavior? astearns: I'm fine specifying lower case chris: There's an example where you type in a name and you get back the name and you get RGB value <emilio> Firefox's behavior is just an accident of this "preserve the specified keyword" for color keywords like "blue" <emilio> Which is an special case that all browsers seem to share TabAtkins: In computed value, only specified value TabAtkins: specified values is woefully underspecified TabAtkins: since we know color has quirks here we should reference that <TabAtkins> Notably, "CurrentColor" serializes in lowercase *everywhere*, including Firefox Proposed Resolution: Add some text about specified values and color keywords in specified and computed are given in lowercase RESOLVED: Add some text about specified values and color keywords in specified and computed being given in lowercase chris: We resolved lch should resolve to lab chris: The spec as it is currently correct. So for color values you'll get a 0-1 range, you'll get lower case? TabAtkins: Ideally you shouldn't have to specify everything in lower case TabAtkins: you should probably just assume that's the case so you don't over-specify chris: System colors each compute to itself, the used value is the actual color in RGB. I need an example there Fingerprinting via Deprecated System Color Values ------------------------------------------------- chris: We have two types of system colors; un-deprecated and old horrible ones chris: There is a fingerprinting issue and what they correspond to chris: I just went through and mapped the deprecated ones to undeprecated ones. <TabAtkins> https://github.com/w3c/csswg-drafts/issues/5553 TabAtkins: I'm fine with what's written there chris: This is a change, this is not what people currently do chris: Is everyone ok with that <chris> https://drafts.csswg.org/css-color/#deprecated-system-colors fantasai: Overall, I totally agree with what you're doing fantasai: If we're concerned with compat with borders, we could define the highlight/shadow colors to use the inset/outset formulas chris: We should but I don't care fantasai: I figured I'd point it out chris: Yeah, they're deprecated Computing device-cmyk() ----------------------- chris: device-cmyk() is now defined, you only use the legacy as a last resort chris: explains example - the computed value will be lab chris: when you go through the ICCC profiler it pops out a lab value chris: everyone ok with that? *a lot of head nodding* chris: No ones yelling so I'll assume we're good to go Editing Serialization Rules --------------------------- ACTION: chris Add specified values to ALL of color chris: Is this good enough that I can remove the section from CSSOM? TabAtkins: This doesn't define serialization, this defines values chris: So I need a separate section? TabAtkins: It's worth being precise about this chris: ok, I'll make a new section that outlines they're types verse strings florian: We'll need to be precise as libs exist that depends on this <TabAtkins> here's some serialization code I've written, should be copyable https://drafts.css-houdini.org/css-typed-om/#cssom-serialization chris: thank you - that's what I needed chris: We're getting to the point where we can publish again astearns: That's it for color, I'll update issue 585 CSS Images ========== Allow impls to not respect EXIF data if it's after the image data ----------------------------------------------------------------- github: https://github.com/w3c/csswg-drafts/issues/4929 TabAtkins: So the image orientation from image value allows you to use the exif data and rotate accordingly TabAtkins: Some people noted that the location is flexible. If the exif data can live at the end and you can not initially do the orientation if you're progressively rendering TabAtkins: Recommending to not support exif data if the exif data comes after the image data leaverou: Any numbers on how common this is? TabAtkins: No TabAtkins: Someone mentioned it was less likely, but no strict numbers chris: Cameras have that first and the only cases where this will get messed with is the tools that will shove it at the end TabAtkins: Once the image data starts the browser will ignore any other exif data <smfr> I find it really weird that css would say anything about how images are encoded <smfr> I think we treat this as a “bad image” and just let the bad stuff happen <smfr> also might be hard for implementors: not sure if we can ask our image framework HOW the metadata is ordered <smfr> what about a small image which is loaded in 1 go and the EXIF data is still after the image data <smfr> would be OK with a MAY <smfr> don’t want it to be a MUST because of reasons above TabAtkins: While weird, all browsers are doing this astearns: We're doing bad things now because we haven't found exif prior to rendering florian: What about cache scenarios? iank: I wouldn't bet on that, it's often sometimes slower astearns: What if we have UAs may choose to ignore exif data if it isn't before the image data chris: Advise authors to avoid putting it at the end since there isn't interop TabAtkins: Then we could go with a should then hober: smfr says he's ok with may florian: Not having interop is bad too <TabAtkins> smfr, you okay with SHOULD? <TabAtkins> (probably with an explicit callout to violations being due to image-decoders not reflecting the ordering) <smfr> ok with SHOULD astearns: Should we be "UAs should ignore exif data that comes after image data" Proposed Resolution: UAs should ignore exif data that comes after image data astearns: I thought loading the image included looking for exif data TabAtkins: yeah, it's not a precise term RESOLVED: UAs should ignore exif data that comes after image data fantasai: Should we also say authors SHOULD NOT use such images? TabAtkins: I think we should do an authors MUST NOT fantasai: We should give a clear guidance to not do that astearns: If we put in author guidance, we should make sure to put in example of why they shouldn't Proposed Resolution: Authors MUST NOT put exif data at the end of the image RESOLVED: Authors MUST NOT put exif data after the image data <jensimmons> author conformance!! ++ <break> Integrate with SVG Integration spec ----------------------------------- scribe: fremy github: https://github.com/w3c/csswg-drafts/issues/4640 chris: svg integration has two things, only one of which got folded in svg 2 chris: One is what happens when you embed in svg chris: The other is what happens when you use svg in html TabAtkins: What needs to be done? chris: We need to decide what we do, and what we map to each of these modes Rossen: Shouldn't we do more of this ahead of time? Rossen: and make a concrete proposal? chris: Yes, we should probably do that, and investigate whether script can run, animations can run etc... florian: For the cursors we already specify one of these modes TabAtkins: I think for general css images we also specify a mode I think TabAtkins: but yeah we should probably do more work on this before submitting to the group Rossen: ok let's do that Rossen: Was that everything about the topic? chris: Yes <fantasai> https://www.w3.org/TR/css-images-4/#image-file-formats fantasai: There is a proposal in images 4 fantasai: I pasted the link fantasai: (reads aloud) [At minimum, the UA must support the following image file formats when referenced from an <image> value, for all the properties in which using <image> is valid: - PNG, as specified in [PNG] - SVG, as specified in [SVG11], using the secure static mode (See [SVG-INTEGRATION]) - If the UA supports animated <image>s, SVG, as specified in [SVG11], using the secure animated mode (See [SVG-INTEGRATION]) The UA may support other file formats as well.] florian: Seems to be what we do for cursor chris: Ok, I think this makes sense chris: I will review and bring this back if needed <florian> https://www.w3.org/TR/css-ui-3/#ref-for-url-value%E2%91%A0 Rossen: thanks! ACTION: ChrisL to review SVG integration mode for css-images Zero or infinite intrinsic ratio -------------------------------- github: https://github.com/w3c/csswg-drafts/issues/4572 TabAtkins: Someone brought up an interesting test case showing the effect of an svg with infinite width or height ratio TabAtkins: In both cases, browsers treat it as having no ratio at all TabAtkins: (see examples in the issue) TabAtkins: This is not specified right now TabAtkins: If you just follow the spec right now, you should get an infinite ratio, not what we have right now TabAtkins: but we can add an exception in the images spec to cover this so implementation won't have to change florian: But that is different from the aspect-ratio behavior? TabAtkins: Yes, I think this is just for compat, there is no good reason for this TabAtkins: but since it's not very important, matching legacy makes sense to me fantasai: I think it's weird we do two different things emilio: Or we could make the aspect-ratio do the same thing TabAtkins: We are probably fine to go either way in behavior TabAtkins: If we want to align, I am happy to do that do florian: Can we do the reverse? The property does what svg does now TabAtkins: Would break consistency, but both will florian: Let's do that, sounds like an error case fantasai: Yeah, let's be consistent fantasai: Either the svg or the property, and let's pick it Rossen: I think the second one is easier on implementation TabAtkins: It's not yet implemented Rossen: For svg Rossen: it's more difficult to fix svg TabAtkins: That violates our open-bound policy TabAtkins: I don't like that much TabAtkins: but ok, I'm willing to bend on this because it's not important emilio: But infinity can't map to infinity anyway emilio: there is a limit TabAtkins: Clamping doesn't break continuity TabAtkins: So there is not reason not to clamp TabAtkins: but I could go either way Rossen: Given there is no strong reason in either direction, let's try to resolve to do the same as current svg? florian: The svg spec says one thing florian: The svg should fix their spec too florian: otherwise we make a weird exception for aspect-ratio then down the line someone can fix the svg code chris: Well, that's a bug in the spec chris: svg2 was not supposed to add new features and to document existing behavior chris: so we should fix the spec not to allow this Rossen: I am fine reaching out to svg if we resolve this Rossen: Any objection? TabAtkins: proposed resolution is to treat aspect ratio of 0 / infinity as auto TabAtkins: this will propagate to the prop behavior as well RESOLVED: Treat aspect ratio of 0 or infinity as auto, propagate to the aspect-ratio property behavior as well Should the values of image-orientation include the <angle> variants? -------------------------------------------------------------------- github: https://github.com/w3c/csswg-drafts/issues/4164 TabAtkins: fantasai made the most recent edits, maybe she should introduce Rossen: The discussion is long, but the relevant bits are at the end <fantasai> https://github.com/w3c/csswg-drafts/commit/ff22f40a630e2a120396d6a0f95d78e7601fb644 fantasai: I made some clarifications about this fantasai: I marked the angle values as deprecated and optional for implementations fantasai: except if you want to support CSS-PRINT fantasai: the property overall is optional but not deprecated TabAtkins: For compat reasons fantasai: I wanted to check if that was ok florian: Is the print profile style still relevant? fantasai: No idea fantasai: That community is not involved here anymore fantasai: I would propose to finish the spec, and remove in the next level TabAtkins: Yeah I don't think we don't want to take that work ourselves (as browser vendors) TabAtkins: That comes back from the times where browsers didn't respect EXIF TabAtkins: We still want the "none" value because some websites wanted that for compat TabAtkins: The angle values are not really useful I think ???: There is also a way to rotate the page, right? TabAtkins: Yes, but that is very different florian: Usually I care about print, but this florian: I don't care Rossen: ok, any objection? TabAtkins: why not remove? <tantek> CSS profiles in general have kinda been left behind. <tantek> Print profile being a deadend NOTE is fine. fantasai: We already resolve to keep it in the spec TabAtkins: [looks at the issue] <faceless2> +1 to tab's wording TabAtkins: The resolution says will be dropped fantasai: ... in the next level Rossen: Let's move on TabAtkins: ah ok RESOLVED: Accept fantasai edits
Received on Wednesday, 4 November 2020 14:17:06 UTC