W3C home > Mailing lists > Public > www-style@w3.org > November 2020

[CSSWG] Minutes TPAC F2F 2020-10-22 Part I: CSS Variables, CSS Conditional, CSS Color & CSSOM, CSS Images [css-variables] [css-conditional] [css-color] [cssom] [css-images]

From: Dael Jackson <daelcss@gmail.com>
Date: Wed, 4 Nov 2020 09:15:59 -0500
Message-ID: <CADhPm3vCFNtsd6ZQuCXMtwjQ1n0MpHEJdc9yKms5SvCKCSZ+tA@mail.gmail.com>
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

This archive was generated by hypermail 2.4.0 : Wednesday, 4 November 2020 14:17:07 UTC