- 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