W3C home > Mailing lists > Public > www-style@w3.org > April 2019

[CSSWG] Minutes Teleon 2019-04-24 [mediaqueries] [css-color] [css-lists] [cssom] [css-images]

From: Dael Jackson <daelcss@gmail.com>
Date: Wed, 24 Apr 2019 19:48:38 -0400
Message-ID: <CADhPm3vQ0PESbiFHo+d9qKxwS5-fFo5EcX-w3mGNdfmaBh+Chg@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.
=========================================


Media Queries
-------------

  - RESOLVED: Leave inverted colors as is, add webkit UA stylesheet as
              an example implementation for MQ L5 (close no change)
              (Issue #3858)
  - RESOLVED: Add inversion rule to the UA stylesheet (Issue #3858)
  - The authors were asked to revisit and update the security and
      privacy section for levels 4 and 5.

CSS Color
---------

  - RESOLVED: Add the original list of colors from TabAtkins and
              fantasai as well as ones by smfr and ActiveText (Issue
              #3804) [List: Canvas, Text, LinkText, VisitedText,
              Highlight, HighlightText, GrayText, ButtonFace,
              ButtonText, ActiveText, Field, FieldText]

CSS Lists
---------

  - There are use cases to support solving issue #3667 (Need a way to
      return the max value of a counter within a scope). Google is
      looking more to see if they're interested in implementation a
      solution.
  - RESOLVED: Publish new WD of Lists
  - RESOLVED: Add fantasai as editor CSS Lists L3

CSSOM
-----

  - The original use counter for issue #3814 (Figure out what to do
      with non-standard CSSStyleSheet methods in WebKit / Blink) was
      too high for the methods to be dropped, however the data will be
      looked at more closely to ensure it's not erroneously high.
  - RESOLVED: Non-initial custom properties should be exposed on
              computed style objects, open a new issue about defining
              order (Issue #1316)

CSS Images
----------

  - The group was actioned to review and give feedback on the request
      from WHATWG around lazyload (
https://github.com/w3c/csswg-drafts/issues/3659 )

===== FULL MINUTES BELOW ======

Agenda: https://lists.w3.org/Archives/Public/www-style/2019Apr/0017.html

Present:
  Rachel Andrew
  Rossen Atanassov
  Tab Atkins
  David Baron
  Amelia Bellamy-Royds
  Oriol Brufau
  Tantek Çelik
  Emilio Cobos Álvarez (IRC Only)
  Dave Cramer
  Elika Etemad
  Simon Fraser
  Tony Graham
  Dael Jackson
  Brad Kemper
  Peter Linss
  Chris Lilley
  Anton Prowse
  Manuel Rego Casasnovas
  Melanie Richards
  Florian Rivoal
  Jen Simmons
  Greg Whitworth

Regrets:
  Alan Stearns

Scribe: dael

Media Queries
=============

Remove or expand inverted-colors
--------------------------------
  github: https://github.com/w3c/csswg-drafts/issues/3858

  florian: I think the initial issue was raised because wording wasn't
           clear. I've done an edit. It's supposed to trigger when
           entire screen is flipped pixel by pixel. Author needs to
           know to double invert images and the like.
  florian: Because wording was ambiguous there were questions if it
           triggered during a smart invert. Also expand to all things
           like night mode.
  florian: My take is don't change. Full invert MQ is useful because
           there's a predictable way to react. A general 'your screen
           has been filtered somehow' doesn't have a strong way to
           respond so no use case. Having made the editorial
           correction I think close no change

  dbaron: Is spec clear on what inversion means in this context?
  florian: Probably not. It's graphical operation that effects all
           pixels. It's not clear if it's different for every pixel
  dbaron: And if you want to correct images you need to know what
          inversion operation to do
  florian: Good point, should clarify. I don't know if there's
           multiple ways done in practice
  TabAtkins: 2 ways. Safari does fancy that doesn't invert images
  florian: Not that one. It's within the non-smart is there a hue
           rotate, inversion around gray point?
  TabAtkins: I think math is the same between everybody.

  florian: Smart one doesn't match this. This is all the pixels have
           been flipped. If it's smart we don't need to react so don't
           need MQ
  TabAtkins: Disagree with this. There are multiple mitigations for
             the page. Some apply across several different types of
             inversion. If you do smart inversion page wants to still
             remove shadows. Having images not be inverted but the
             rest does means the pages with smart will not have their
             shadows with fixed
  florian: But if we conflate the 2 you get the wrong answer for a
           system
  TabAtkins: Yes. Given that inversion exists to flip light vs dark
             mode of the page and we have light/dark mode happening
             maybe we can assume inversion will decrease in use and
             drop the MQ.
  florian: I suspect smart version usage will fade to dark/light mode.
           Does that apply to dumb which is easier for OSs? Those
           trying to be smart will be smart
  TabAtkins: Android has every single pixel inverts mode
  florian: OSX has that
  TabAtkins: These MQ are for when an author should apply mitigations.
             Either design around mitigations themselves or don't do
             it at all. Doing around a feature that has multiple
             mitigations isn't a good design for the future
  TabAtkins: I propose that invert colors as current defined is not
             good because limits to every px inverted. We should
             either drop it completely and assume it's a corner case
             due to new functionality or we make it more complex and
             break it down by mitigations authors would apply
  florian: Please invert images, please remove shadows?
  TabAtkins: Yes
  fantasai: It's a bit overkill
  TabAtkins: Agree. Removing is better
  fantasai: Design where you don't know what you're responding to
            doesn't have purpose. Current definition that you've
            inverted entire screen has usefulness. It's nice that
            we're moving toward place that people recognize that
            inversion is to handle dark mode and they're doing smarter
            inversion is good.
  fantasai: As long as full screen inversion does exist and it seems
            likely to continue to exist for a while...iOS isn't the
            only browser. There are smaller devices that are doing
            what they're doing. We'll have to deal with full screen
            inversion for a while. MQ on that isn't unreasonable
  Rossen: Windows supports inverted and it's used quite a bit. I
          sympathize with TabAtkins that this one query that only
          covers one case isn't sufficient. Might consider adding to
          this so you can handle the smart invert iOS supports. I
          didn't hear if there's anything on Android. But there's 2
          cases that capture everything. Full inversion or smart which
          is no image and control

  TabAtkins: I expect we can get as far as we need by splitting into
             2. Are images inverted and is everything else inverted?
             MS would respond yes to both, Safari yes to 1. That's all
             authors need to mitigate. Will images look weird and will
             the rest of the page look weird. We should address those
             two directly
  AmeliaBR: When talking 2 MQ is it 2 keyword values for inverted
            colors?
  florian: I think it's 2 separate. Media features can be used without
           an argument and if you have multi keyword it's muddled
  AmeliaBR: Disagree. Some mitigations we want for both. Removing
            shadows is if inverting colors is true for any keyword.
            For keyword that specially indicates not images you can do
            something specific for images
  florian: Could, but easy to misuse.
  AmeliaBR: Up to the spec to be more specific about what things mean
  florian: I don't think can fix bad API design with good documentation
  TabAtkins: Most usable as 2. You can do mitigations on images for on
             MQ and color on the other.

  florian: Existing stays as is and add one for inverted images?
  fantasai: No, current is full screen inversion.
  TabAtkins: Defined as that but can change definition
  fantasai: Shipping now
  <tantek> this is iOS 12.1 BTW
  <tantek> Interesting, I just found the iOS setting in Settings >
           General > Accessibility > Display Accommodations > Invert
           Colors - then two mutex radio buttons: Smart Invert (* ),
           Classic Invert (* )
  TabAtkins: iOS would start matching inverted color. I think they do
             now so no behavior change I believe. New query for
             inverted images would match android and edge but not iOS

  dbaron: I wanted to mention it's worth considering if users expect
          this information to be exposed. Not clear to me that they do
          or that a user choosing to use inversion would expect
          webpages to know. It's additional information to fingerprint
          and users might not want web pages to know about that.
  <tantek> +1 to that
  florian: Fair
  fantasai: I think we opened that door with all the other preferences
            like color-scheme and reduced-motion. Not sure this is a
            big different in exposure
  dbaron: Users are choosing or not to expose that information. They
          can not expose if they prefer. I guess that's true here too.
          But those seem more like a preference. I guess it's OS
          level. It's just more bits of information
  * fantasai would like to hear from smfr
  AmeliaBR: To follow up dbaron point I agree with the general concern
            about fingerprinting and this is a a11y functionality.
            Less of a fingerprinting vector than others as it's
            something people toggle on and off. Worth talking about.
            Every MQ is a fingerprinting vector
  AmeliaBR: It is exposed in iOS but it doesn't mean they looked into
            what users want. Especially since benefit of this MQ we
            can only come up with 2 rules that would make sense

  AmeliaBR: I went on queue to say that when talking about the 2 MQ
            option we have to start looking at that this has shipped
            in one UA. I'd like someone who is familiar with iOS to
            talk if they're on the call and how they impl smart
            inversion and if they currently recognize in the MQ when
            someone does a double inversion and if they're avoiding a
            triple inversion. I was thinking smart inversion came
            through CS mechanism
  AmeliaBR: Through cascade it wouldn't hurt to have author rule, but
            maybe incorrect if it's from OS level compositor. Before
            we agree to 2 MQs lets talk to people using feature to see
            if necessary.
  <TabAtkins> https://github.com/w3c/csswg-drafts/issues/3807#issuecomment-481868265
              Comment from Dean about history of Apple's inversion
  smfr: As far as I understand, iOS and I think Mac is when the user
        toggles the a11y setting the entire screen is inverted and WK
        applies a CSS filter to image elements and likely others. It's
        possible an author could re-invert the images if they only
        looked at inverted colors MQ. No smarts to avoid extra invert
  florian: If you're using CSS it wouldn't be a double invert.
  AmeliaBR: Would cascade cancel?
  smfr: Maybe you're right. Not sure if it's CSS or programmatic. I
        think you're right
  florian: Should check.

  tantek: Couple of things. First is I don't think we should use
          reasoning door is open to justify adding something. Always a
          false dichotomy. We do things on spectrum where it can be
          better or worse.
  <tantek> https://drafts.csswg.org/mediaqueries-4/#priv-sec
  tantek: Looked at security and privacy of MQ draft and it's out of
          date for reflecting how MQ can be used for fingerprinting.
          Granularity of fingerprinting from MQ has greatly increased
          since L3. Needs a callout
  <fantasai> https://drafts.csswg.org/mediaqueries-5/ ?
  tantek: If it's a CR and not a REC we should update. Since it's in
          formating we should be able to edit during CR
  <chris> +1 to updating the S&P section
  tantek: Given potential negative aspects I would like to see some
          actual use cases where feature is a strong benefit to an
          author. What is the actual strong use case where an author
          needs this today. Otherwise not sure it meets bar to include
          it over potential drawbacks
  TabAtkins: Inverting images is main thing. Images of real stuff like
             people looks horrifying when inverted naively. Removing
             shadows is good, but not necessary. If we can focus on if
             images are inverted or not that's highest value

  <smfr> WebKit UA stylesheet has:
         @media (inverted-colors) {
           img:not(picture>img), picture, video {
             filter: invert(100%);
             }
           /* Images and videos double-inverted. */
           }
  Rossen: Sounds like smfr found the UA stylesheet that supports that
          WK does this through CSS because author style sheet won't
          double invert it

  Rossen: I see florian on the queue. I want to try and close on this.
  florian: Brief comment. To tantek on privacy and security the one in
           L4 is outdated. This feature is in L5 which doesn't even
           have a privacy and security so we need to create one.
  tantek: L5 needs to exist, L4 needs updated because it's not
          honestly reflective

  Rossen: Back to topic at hand. We know what WK does. We know
          inverted colors on both android and windows apply to full
          screen. What do we do with this MQ. Leave as is? Bring
          additional query that's excluding images or something?
  florian: Include the bit of UA stylesheet WK has so if authors want
           this they know exactly how so we don't fight with WK
  <AmeliaBR> +1 to standardizing the UA rule
  Rossen: You propose leave the feature definition as is and add
          example of WK UA stylesheet of how they do inversions and
          how can be used to mitigate.
  AmeliaBR: I'd suggest most UAs impl
  Rossen: It's up to UAs to do it or not
  AmeliaBR: We can standardize UA stylesheet and important we do. WK
            rule filters on picture elements, not images inside so if
            someone filters all images you get a double inversion
  <fantasai> +1 to AmeliaBR
  AmeliaBR: Having a standard rule this is how you do it is more
            reliable
  <chris> +1 to AmeliaBR
  <florian> +1
  Rossen: Would that need to include SVG?
  AmeliaBR: It wouldn't need to

  Rossen: Proposal: Leave inverted colors as is, add webkit UA
          stylesheet as an example implementation for MQ L5
  Rossen: Additional comments or objections?
  florian: I'm good with it as a normative addition to UA stylesheet
  Rossen: 2 resolutions then
  TabAtkins: If you're going to fix images automatically you must do
             it via this CSS would be the second
  Rossen: First is about the original issue which is no change to
          invert colors MQ. Objections?

  RESOLVED: Leave inverted colors as is, add webkit UA stylesheet as
            an example implementation for MQ L5 (close no change)

  Rossen: Second is Add inversion rule to the UA stylesheet.
          Objections to that?

  RESOLVED: Add inversion rule to the UA stylesheet

  Rossen: Third is an ask to authors to revisit privacy and security
          section for L4 and L5

CSS Color
=========

Support high-contrast/dark mode colors
--------------------------------------
  github: https://github.com/w3c/csswg-drafts/issues/3804

  TabAtkins: Working from the presentation of Rossen and
             melanierichards. fantasai and I put together proposal for
             high contrast stuff in CSS. Defining system colors, some
             exist and some new, that map to categories from Rossen
             and melanierichards
  TabAtkins: Only addition is a visited link color in addition to
             normal and that's because it's already in system colors.
             MS could set to same color if they want.
  TabAtkins: Idea being is we adapt MS rules for how to apply that
             says you apply these system colors where ever necessary.
             There's a MQ that says these are on and you may want to
             adjust your styles.
  fantasai: Resolved on that earlier, need to add the colors. Resolved
            on the MQ and properties. This is about making changes to
            CSS color L4 to un-deprecate a subset of the system colors
            and add a couple of new ones
  fantasai: New is page background, scrollbar, link text, visited link
            text
  dbaron: Active link text?
  fantasai: Might need to add that, yes
  <TabAtkins> Canvas* (we'd have liked to call this “Background” but
              that's already used for something else)
  <TabAtkins> Text*
  <TabAtkins> LinkText*
  <TabAtkins> VisitedText*
  <TabAtkins> Highlight
  <TabAtkins> HighlightText
  <TabAtkins> GrayText (could be aliased to InactiveText or
              DisabledText for clarity)
  <TabAtkins> ButtonFace (could be aliased to Button for consistency)
  <TabAtkins> ButtonText

  AmeliaBR: Couple other suggestions in thread of colors used in UA
            stylesheets. Some of which not named
  fantasai: Discussion about adding field values for text inputs. I
            don't have a strong opinion on that. Wanted to make sure
            got minimum set MS was using in high contrast mode. If WG
            wants to add field and field text can add
  <TabAtkins> Looks like additional stuff is just "Field" and
              "FieldText"
  Rossen: High contrast PoV your set of colors maps to what's
          required. I don't have strong pref for additional ones, I
          don't know use cases. I guess people creating own components
          and want closer to current system controls sounds reasonable.
  <AmeliaBR> and ActiveLinkText
  <fantasai> or ActiveText

  Rossen: Want to hear from the rest of group
  Rossen: Taking silence as supportive
  Rossen: Proposal: un-deprecate or add the list above
  fantasai: * is added
  AmeliaBR: IRC discussion mentions the others
  fantasai: ActiveLinkText and Input field background and foreground
            color
  fantasai: We pulled old names for those, don't know if they're
            necessary. I think we at least need to minimum set for MS
            high contrast. If people want to add others I'm fine
  Rossen: Objections to add the original list of colors from TabAtkins
          and fantasai as well as ones by smfr and ActiveLinkText

  RESOLVED: Add the original list of colors from TabAtkins and
            fantasai as well as ones by smfr and ActiveText

  fantasai: On ActiveLinkText we have LinkText and VisitedText. We
            went shorter version of names because match selector
  Rossen: Shorter makes sense
  AmeliaBR: There's already ActiveButtonText so that's only confusion
  AmeliaBR: If it needs to be clear ActiveText is color for active
            links
  fantasai: Active button can be own thing
  Rossen: Okay. Previous resolution stands
  Rossen: Resolution is ActiveText not ActiveLinkText

Pseudo Elements
===============

Should CSSPseudoElement have a pseudo() method?
-----------------------------------------------
  github: https://github.com/w3c/csswg-drafts/issues/3836

  Rossen: heycam or emilio or anyone else want to cover this?
  TabAtkins: Rather move on

CSS Lists
=========

Need a way to return the max value of a counter within a scope
--------------------------------------------------------------
  github: https://github.com/w3c/csswg-drafts/issues/3667

  fantasai: This was a feature request to add ability to retrieve
            highest value a counter picked in a document for something
            like numbering page 2 or 5. Functional notation like
            counter. Asking WG if interested now, future, or never?
  [silence]
  <dbaron> I don't think I'm particularly interested...
  Rossen: Not sure how to read the silence. Can we say never?
  <tantek> [silence] seems like enough reason to postpone discussing,
           maybe til f2f?

  TabAtkins: Functionality exists in paged CSS via special pages
             counter. Bit of a special case. Use case is clear there.
  TabAtkins: Added to triage list so can get answer from engineers
             soon, but no answer now. Personally in favor
  dauwhe: Have use cases for this in paged media. See utility for long
          publications
  Rossen: Hearing some favorable comments and the need for it. It's
          not never, but doesn't sound like we can resolve now. Let's
          close, move one, and revisit when have more information from
          impl.

Publication
-----------

  fantasai: On topic of lists, css lists has been updated with a major
            clean up and resolutions folded in
  <fantasai> https://drafts.csswg.org/css-lists-3/
  fantasai: If want to review can do this next week, but want to pub
            new WD
  Rossen: We can publish it. I don't know if anyone will come up with
          reasons

  RESOLVED: Publish new WD of Lists

CSSOM
=====

Figure out what to do with non-standard CSSStyleSheet methods in
    WebKit / Blink
----------------------------------------------------------------
  github: https://github.com/w3c/csswg-drafts/issues/3814

  Rossen: Anyone to take this?
  <emilio> Given the comments, I'll just spec them
  <emilio> sorry, can't join via audio / video, on the phone
  TabAtkins: Based on eric's numbers, unless someone can make argument
             that our numbers aren't actual usage they're too high to
             drop. .rules is almost a full percentage point of page
             loads
  TabAtkins: If not removing, should look to add. But emilio says no
             one cares on their side. I don't know best thing, but
             removing isn't in the cards for us
  AmeliaBR: Clarification: implementation of these they're aliases for
            standard features?
  TabAtkins: There's one that's slightly different, but yes

  dbaron: Will impl these in browsers that don't have them break
          feature detection?
  TabAtkins: Don't know. I just have use counter data, not information
             on how they're actually used. But numbers of use is too
             high
  * emilio was hoping not, but that's a very good point
  dbaron: Seems weird because I don't recall pages broken due to not
          having them
  TabAtkins: Feature detection- I didn't mean they're to tell you're
             in blink but something that iterates over a bunch of
             properties to see what exists. That's caused high use
             counters in the past. That might be the case at which
             point we might remove, but as of right now can't remove

  Rossen: Other action if we don't remove? Add to CSSOM?
  TabAtkins: Not right now. emilio asked if should or should remove
  Rossen: Current data says cannot remove unless you want an action to
          see if you can get deeper into data to figure out if it's
          meaningful or triggering from auxiliary detection rules. Up
          to you
  TabAtkins: Put it for triage. I'll get back to you
  Rossen: Reasonable.

Should custom properties be exposed on computed style declarations?
-------------------------------------------------------------------
  github: https://github.com/w3c/csswg-drafts/issues/1316

  Rossen: heycam added and then lively discussion. Who wants this?
  TabAtkins: I can. I support it. If we allow interaction of custom
             properties via OM we should expose what's non-initial.
             Makes sense to make when you gCS from there. Technical
             questions on the API, but can be resolved by emilio as he
             feels fit.
  TabAtkins: Should resolve non-initial custom prop should be exposed
             on computed style objects
  Rossen: Other opinions?

  Rossen: Objections to non-initial custom properties should be
          exposed on computed style objects
  <emilio> There's an issue with ordering of properties
  <emilio> Also, what happens with registered properties that have an
           initial value
  Rossen: emilio points out issue with ordering?
  Rossen: Does that change opinion?
  <emilio> Basically, order in WebKit is just hash ordering, Gecko is
           cascade order. Defining alphabetic ordering or such may be
           problematic (need to sort every indexed operation and such)
  <emilio> Leaving ordering undefined might be ok
  TabAtkins: I think it's still useful. Need to figure out the answer.
             I'm confident emilio will put something good in the spec.
             What's the order you all use?
  Rossen: Gecko says cascade
  Rossen: Order undefined would be a lot of contradictory behavior
  Rossen: Resolve on adding and open issue on dealing with order?
  TabAtkins: Okay
  <emilio> Sgtm
  Rossen: Support overall behavior. Technical order issue should be
          separate.

  Rossen: Prop: non-initial custom prop should be exposed on computed
          style objects, open a new issue about defining order

  RESOLVED: Non-initial custom properties should be exposed on
            computed style objects, open a new issue about defining
            order

CSS Images
==========

lazyload
--------
  github: https://github.com/w3c/csswg-drafts/issues/3659

  Rossen: Ask from WHATWG. fantasai you want to introduce?
  fantasai: Mostly I wanted to call attention to the thread to make
            sure we respond in a timely manner
  Rossen: Action for everyone to read up and engage in github. I'll
          add to agenda next week if not high response

  Rossen: One minute left. Let's push the remaining topic to next week

CSS Lists
=========

  fantasai: Can we add me as a List L3 editor?
  Rossen: There's a spec you're not an editor of??????

  Rossen: Objections to add fantasai as editor CSS Lists L3?
  TabAtkins: No objections

  RESOLVED: Add fantasai as editor CSS Lists L3

  Rossen: Thanks and we'll chat next week
Received on Wednesday, 24 April 2019 23:49:35 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 22:53:13 UTC