W3C home > Mailing lists > Public > www-style@w3.org > July 2018

[CSSWG] Minutes Sydney F2F 2018-07-04 Part I: CSS Values & Units, Backgrounds 4, Filters [css-values] [css-backgrounds] [filters]

From: Dael Jackson <daelcss@gmail.com>
Date: Tue, 24 Jul 2018 19:08:27 -0400
Message-ID: <CADhPm3tbNejBuATGXXCr0JQVNvwvtC0Kv5CD9Sam5Mardtcrxw@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 Values & Units
------------------

  - RESOLVED: <color> in <shadow> should default to currentColor
              (Issue #2766)
  - RESOLVED: drop-shadow and shadow will also default to currentColor
              (Issue #2766)
  - RESOLVED: 1) All the positions serialize the same way
                 (background-position, object-position, etc.)
              2) All of them resolve as <position>.
                 Background-position 3-value syntaxes are not allowed.
              (Issue #2274)
  - RESOLVED: All the <position> values serialize to at least two
              values. (Issue #2274)
  - There were two issues remaining to resolve for issue #2274
      (Inconsistent position serialization):
      1) How do we deal with keywords, both if the author supplies
         them and do we turn 50% into center, and
      2) The two-value vs 4-value question. Interested individuals
         will discuss these items during breaks to seek a resolution.

Backgrounds 4
-------------

  - RESOLVED: Add stripes() to border-color and outline-color (Issue
              #2532)

Filters
-------

  - dino gave an introduction to the proposal to create a color-filter
      property (Issue #2875) which modifies the color values used when
      rendering.
  - This proposal was based on the success Apple has had introducing a
      dark mode feature and would allow a dark mode to easily be set
      up on websites or in emails.
  - Generally people agreed the use case was valid and it's an
      interesting but complex problem space to try and solve.
  - If this is done there likely will need to also add a media query,
      something like prefers-colors: light | dark | any

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

Agenda: https://wiki.csswg.org/planning/sydney-2018#schedule

Present:
  Rachel Andrew, Invited Expert
  Rossen Atanassov, Microsoft
  Tab Atkins, Google
  L. David Baron, Mozilla
  Brian Birtles, Mozilla
  Tantek Çelik, Mozilla
  Dave Cramer, Hachette Livre
  Emil A Eklund, Google
  Elika J Etemad, Invited Expert
  Jihye Hong, LGE
  Koji Ishii, Google
  Dean Jackson, Apple
  Ian Kilpatrick, Google
  Chris Lilley, W3C
  Peter Linss, Invited Expert
  Myles C. Maxfield, Apple
  Cameron McCormack, Mozilla
  Xidorn Quan, Mozilla
  Francois REMY, Microsoft
  Florian Rivoal, Invited Expert
  Hiroshi Sakakibara, BPS
  Alan Stearns, Adobe
  Shane Stephens, Google
  Lea Verou, Invited Expert
  Philip Walton, Google
  Eric Willigers, Google

Scribe: myles

CSS Values & Units
==================

<color> in <shadow> should default to currentColor
--------------------------------------------------
  Github: https://github.com/w3c/csswg-drafts/issues/2766

  * fantasai thought we'd fixed this already
  fantasai: Any objections?
  Rossen: We need to make sure the people who care have a chance to
          look
  xidorn: The issue is that if it isn’t specified, the used color is
          taken from the current property
  xidorn: I think the text should just be “it defaults to currentColor”
  dbaron: The spec may have evolved from something that was more
          flexible
  chris: (sarcastically) Let’s say it’s user defined

  Rossen: Are we okay with the proposed resolution?
  Rossen: Any objections? <silence> resolved

  RESOLVED: <color> in <shadow> should default to currentcolor

  chris: There’s also the same problem with drop-shadow as well as
         shadow
  leaverou: It doesn’t work that way already?
  Rossen: Any additional comments?
  Rossen: <silence> Any objections?

  RESOLVED: drop-shadow and shadow will also default to currentColor

  <fantasai> fixed this already for text-shadow, not box-shadow,
             is what happened

Inconsistent position serialization
-----------------------------------
  Github: https://github.com/w3c/csswg-drafts/issues/2274

  ericwilligers: For one of the properties, the spec is explicit about
                 serialization, and that’s different from all the
                 other ones
  ericwilligers: Another inconsistency is that all the browsers behave
                 differently from one another
  ericwilligers: Suggestions?
  leaverou: Don’t we have a principle that shorter serializations are
            better?
  TabAtkins: Yes
  leaverou: If we follow that, 50% should not be introduced
  leaverou: Does that mean if it was specified explicitly, it should
            be introduced?
  dbaron: There are cases where you do need it to be disambiguated.
          center 10% and 10% center are different
  dbaron: Someone should go through, figure out what the compatible
          behavior is, figure out what the same behavior is, and
          figure out what should actually happen. This table is rather
          large for going through in the WG meeting
  ericwilligers: The one that’s different from the others, is that a
                 mistake and they should all the consistent?
  emilio: Yes
  dbaron: Some of these things are very easy to write as a spec
          editor, but we should be careful to stick them in when they
          cause inconsistencies like this. Implementors should be
          suspicious of them too, if they say to do something
          different from everything else

  emilio: Can we resolve on the special case being removed?
  fantasai: All the cases should be the same
  Rossen: Yes
  ericwilligers: We should think about transform origin and background
                 position, because transform origin is 3D, and
                 background position accepts the 3 value grammar. So
                 “left 10% top”
  fantasai: We’re trying to get rid of 3-value syntaxes for that reason
  fantasai: We can resolve on 2 things: 1) all the serializations
            should be the same, 2) we never serialize to the three
            value serializations, unless one of the three values is
            center, and 3)
  ericwilligers: What about always serialize to a valid <position>
  fantasai: background-position-specific syntaxes should not be allowed
            in serialization
  Rossen: Objections?

  RESOLVED: 1) All the positions serialize the same way
               (background-position,m object-position, etc.)
            2) All of them resolve as <position>. Background-position
               3-value syntax’s are not allowed.

  fantasai: We have more questions. 1) Do we ever serialize to a
            1-value syntax? Eric made an amazing chart of compat data.
            Edge takes the shortest backwards-compatible serialization
            principle very seriously, and when it can, drops down to a
            single value. The other implementations will always have
            at least 2 values
  fantasai: Should we ask Edge to change? To match everyone else? Or
            are one-value serializations actually good
  TabAtkins: This decision applies to typed OM too.

  fantasai: I think two-value syntax is more understandable to work
            with. Because if you happen to land on 50% arbitrarily, it
            would be awkward otherwise. And we have 3 implementations
            this way. So, because of minimizing the amount of work, we
            should standardize on 2-values
  heycam: Is this a general principle? Like pairs of numbers that are
          coordinates, they should always be serialized as two-values?
  fantasai: I don’t think that’s valuable.
  [some 2-axis value syntaxes use duplication for omitted values,
   so it would be less useful to duplicate in the serialization ]
  dbaron: One reason position is different is that it has a relatively
          complicated set of rules, where you’re allowed to do X Y
          order, or Y X order much of the time but not all of the
          time, which makes it complicated to figure out which values
          will round-trip correctly if you reduce it to just one
  fantasai: A more important reason is the transform-origin syntax,
            which becomes ambiguous if you only have one value
  fantasai: You wouldn’t be able to consider position as a single
            value without considering whether or not you have a Z
            component. That creates a serialization of position cannot
            be self-contained

  fantasai: The proposal: <position> always serializes at least two
            values
  TabAtkins: I’m down with that
  Rossen: It means some work for us, but ...
  TabAtkins: It means some work for all of us because we’re
             inconsistent
  Rossen: Okay.

  RESOLVED: All the <position> values serialize to at least two values.

  heycam: Is there a way to tell for a given property whether or not
          we have considered its serialization and what’s in the spec
          is a considered decision?
  fantasai: Not really
  fantasai: In most cases, you follow the general principle of
            “shortest most backwards-compatible serialization” and the
            exceptions are where we will have to explicitly say
            something. The spec says “it’s probably this” but you need
            to check in case there’s some legacy something
  heycam: I don’t like having to check
  fantasai: Are you volunteering to do the checking?
  heycam: No
  heycam: We should reflect our discussions back in the spec so we
          don’t have to check
  ericwilligers: We may not be testing in all 4 browsers
  heycam: So tests may serve this purpose?

  fantasai: When we have a 4-value syntax, do you serialize it out to
            4 values or do you compress it using calc to two values?
  Rossen: I looked at this a year ago in the context of
          object-position. Most of the testing I did cross browsers
          suggested that almost all implementations attempt to
          serialize down to calc for computed values on
          getComputedStyle(), and were inconsistent as described in
          this one for specified style serialization
  emilio: I don’t think we synthesize calc in any case for computed
          value serialization. If you specify it as calc(), and we
          cannot simplify it, but I don’t think we should use calc to
          shorten the result
  ericwilligers: We’re just talking about serialization, not computed
                 value
  emilio: It’s essentially the same thing
  ericwilligers: Yeah
  ericwilligers: We’re talking about specified values, not computed
                 styles
  ericwilligers: Blink would never give you a keyword as a computed
                 value

  Rossen: What are we thinking about in terms of 4 value serialization?
  Rossen: Should we attempt to do 2 when possible?
  plinss: Turning a non-calc into a calc seems weird
  astearns: If we can simplify a 4-value into a 2 value without calc,
            that makes sense, but if you have to use calc, then it’s
            not a simplification
  dbaron: I agree as well, though the principle that would say to use
          calc() is the most compatible syntax principle, because
          calc() got implemented in background-position background
          before the 4-value syntax
  dbaron: So for a while you were able to do the effects of the
          4-value syntax with calc, without the real 4-value syntax.
          But for now we shouldn’t do it because it’s less compatible
  astearns: We went through this when we were deciding how to use
            these values in basic shapes. What I thought we were doing
            was coming up with general principles that would generally
            be applied to other things than basic shapes. Basic shapes
            prefers two values, if you can express it without calc, so
            we may look to that as what we were trying to do years ago

  fantasai: Eric, do you have the test you used for the 4-value syntax?
  fantasai: Can you modify it from bottom right to top left to see if
            the values get dropped, or if we keep the 4 value syntax
            even in that case?
  ericwilligers: It takes me a while to get results because I use
                 browser stack.
  ericwilligers: If you tell me what you want to know, we can figure
                 it out
  <astearns> <position> in basic shapes is paragraph 2 of
             https://drafts.csswg.org/css-shapes/#basic-shape-serialization
  <fantasai> top 10% left 20%
  ericwilligers: With the suggestion that we go down do two unless it
                 introduces a calc, what effect would that be for
                 background-position?
  Rossen: The minute you have top 10% and then center ..
  ericwilligers: People were saying “we should never ever go to three”
  ericwilligers: Right 10% top will go to 4

  ericwilligers: 1 more question: right 10% top should serialize
                 differently from left 10% top???
  fantasai: That was the question I wanted to ask. We should see what
            the output is. If there is consensus, we tend to go with
            that. So I think we should investigate this question a
            little more over the break. And then go on to the issue of
            whether to serialize out keywords when you put serialize
            as a percentage
  Rossen: But this is after the discussion in the morning?
  fantasai: No, we can do it now
  fantasai: Look at the 3rd table: 30px center. Some of the
            serializations use 50%, some use the keyword center
  fantasai: The table after that: 40px top, some use 0% and some use
            the keyword top
  fantasai: So the question is, do we resolve on outputting the
            keyword when the percentage would work?
  dbaron: The bulk of the boxes are the keyword except 3 of them
  dbaron: That said, I don’t know if we should try to go through all
          of this

  fantasai: 2 questions: 1) How do we deal with keywords, both if the
            author supplies them and do we turn 50% into center, and
            2) the two-value vs 4-value question
  fantasai: We can look into that over the break.
  Rossen: This is where we are going to get a lot more calcs in
          percentages
  Rossen: Okay that’s everything for this for now.

Backgrounds 4
=============

Issues for listifying border-color
----------------------------------
  Github: https://github.com/w3c/csswg-drafts/issues/2532

  leaverou: There’s a very detailed write up in the issue of
            everything I’m going to say

  leaverou: Do people remember the issues with listifying
            border-color? A few meetings ago, we resolved to
            listifying border-colors, because 1) Authors wanted
            multiple borders, but primarily a11y needed borders that
            are both white and black so that they are visible over any
            background. So we listifying border-color with the goal of
            listifying alt he border properties
  leaverou: But when I actually tried to listifying border-color,
            there were several issues.
  leaverou: 1) Because of the way listified properties work, if the
            lists are mismatched, the shorter lists are padded with
            the last term, which means if you have a border-width of
            10px, and say 3 border colors, then 10px becomes 10px,
            10px, 10px, which gives you a width of 30px. So setting
            border-color has the effect of tripling your border width.
            Weird, and this is the first time
  heycam: Wouldn’t this happen with any other listified properties?
  leaverou: Others don’t stack. Backgrounds and animations are
            independent. But border-width, they stack, they aren’t
            independent.
  tantek: Or you have to do weird math, which is worse.

  leaverou: Other issue: based on how other properties were listified,
            the property got almost the same syntax it already had,
            but you could add more with commas. So, previously it
            accepted 4 colors, you could have 1-4 colors, then commas,
            then 1-4 colors, etc. This inverts the relative power of
            white space and commas, which is not how authors think
  leaverou: You can see an example in the issue
  leaverou: It’s quite unexpected.
  leaverou: For those reasons, fantasai and I were thinking of an
            alternative way to do multiple border colors, because
            there aren’t many use cases of multiple colors with
            different styles. All use cases for multiple borders are
            essentially cases for multiple colors on a solid border.
            So we were thinking how can we have multiple colors on
            existing borders. The idea is to define a function, we
            called it stripes(), which lets people define a
            1-dimensional image which is weird but we already have
            0-dimensional images, and it can be used in border-color,
            and it has to be 1-dimensional image because otherwise it
            would be difficult to define how it works around
            border-radius. To cover the most prominent use cases it
            would include lengths and percentages, and would work with
            fr values
  <tantek> Lea's proposal looks like an improvement to me
  leaverou: I have a list of the use cases we tried to cover in the
            issue, and a table of what the different syntaxes would
            look like. We also considered letting border-color accept
            a sequence of color stops, but that’s not convenient,
            because with borders, people usually wants stripes not
            gradients, and it’s hard to make stripes with the gradient
            syntax
  fantasai: You don’t want absolute positions the way gradient stops
            do them, but rather widths that stack
  leaverou: We also considered using a new border-stripes property.
            But it has weird affects. It combines with border-color in
            a confusing way, because unless there are transparent
            stripes, you don’t see border-color. In general, having
            properties that disable other properties is some of the
            most confusing parts of css

  emilio: Firefox used to have multicolor border support, by using a
          new property
  leaverou: Yep, and it was confusing
  chris: We decided not to do it the Firefox way
  dbaron: It was a hack to create a certain button style without
          making extra dives
  leaverou: I used it 10 years ago to simulate box shadow

  TabAtkins: I like it

  astearns: What happens when the total sum of the width exceeds the
            border width?
  TabAtkins: You just only render the border-width of the stripes
  leaverou: We can just scale it down. We do it with border-radius, if
            the total radii overlap, then it gets scaled equally
            across the entire box
  astearns: That could work, but what about fractional widths? Those
            go to 0? So you have a 2px white fractional black, 2px
            white
  TabAtkins: *describes another example*
  fantasai: It’s better than clamping.
  fantasai: It gives you reasonable behavior when you grow and when
            you shrink
  TabAtkins: We already have mechanisms (percentages) to do this.
  TabAtkins: This allows you from putting in more stripes than you need
  TabAtkins: So if you alternating 1px stripes, you just make a super
             long one, and no matter how wide the border happens to
             be, it will just work (in the clamping situation)
  frremy: Animations work better too
  leaverou: If you want to reveal stripes, you could always animate
            them from 0
  TabAtkins: Not if we scale the values
  leaverou: Non-zero lengths will be scaled down, but if you want to
            progressively animate,
  TabAtkins: You can already achieve accordion effect
  fantasai: What if you want 2px red, 2px white, 2px red. But if the
            border grows, you want the white to grow
  fantasai: When you scale up, you want red on the outside, you
            preserve the red, white, red
  TabAtkins: use min() and max() instead.
  leaverou: What do we do if we want a thinner width than what we
            have? In fantasai's example, what if our border is 10px
  TabAtkins: We follow gradients. The last color continues
  fantasai: Or the last implied color could be transparent
  TabAtkins: But then the border doesn’t look thick
  fantasai: If you want it to be thick, put 1fr at the end

  TabAtkins: When this is used in a 2 dimensional context, then this
             should be a gradient in some arbitrary direction
  fantasai: I don’t think the testing and implementation effort of
            making stripes in 2d only for an arbitrary direction makes
            any sense
  TabAtkins: Here we’re just talking about stretching and scaling

  Rossen: What if we repeat the pattern?
  leaverou: We can introduce that later. Let’s keep it simple.
  fantasai: It answers the question of what to do if you don’t have
            enough stripes
  TabAtkins: Don’t be arbitrarily different. Do what gradients do
  fantasai: No
  TabAtkins: No
  TabAtkins: Be consistent
  fantasai: This isn’t gradients
  TabAtkins: This is gradients
  fantasai: This is stripes
  leaverou: Gradient color stops are defined absolutely, and there is
            no fr

  Rossen: Stop. Are we trying to add this to backgrounds-4?
  All: Yes
  Rossen: We can work this out later
  Rossen: Was there anything else you wanted to go over technically as
          part of the proposal?
  leaverou: No
  Rossen: Should we add this? Are there still too many open issues for
          it to be added?
  TabAtkins: Using the stripes functions as a border color and not
             listifying border color makes more sense than what we
             already have
  <tantek> agreed
  fantasai: This is a better solution.

  fantasai: My question: whether to use border-stripes or to add this
            to border-color. In general, colors cannot take a 1d
            image. Any property that ends in -color takes a color.
            This is not a color, it accepts a 1d image
  astearns: border-color-stripes?
  fantasai: border-stripes is okay
  leaverou: What about the confusing interactions?
  fantasai: It's okay.
  astearns: Some behaviors fall out of the description
  astearns: e.g. might answer question of what to do when you run out
            of stripes

  frremy: That isn’t great because if you pad a border stripes with
          the border color, the issue is that the border color by
          default is non transparent, but your stripes may be
          transparent, then should you display the border-color under
          the stripes? If you do, you lose the whole point of having
          transparent stripes
  fantasai: You should show border underneath this property
  leaverou: You often want them to stack, to have a fallback that you
            don’t have to repeat it in your gradient

  xidorn: I don’t understand the interaction here
  [question about border-image]
  fantasai: border-stripes and border-color both disappear when you
            use border-image

  chris: This will need some good examples
  TabAtkins: Or we just do stripes() and we don’t have to deal with
             this stuff
  leaverou: Yep
  fantasai: Yep
  leaverou: If we do it with a stripes function and not a separate
            property, we can extend this to other properties
  fantasai: The other properties need a 0-dimensional color, or a
            2-dimensional image. If you applied stripes to those other
            places, you would need to also specify a direction and
            turn it into a 2-d thing
  leaverou: I said “if it’s needed” and it may not be needed
  fantasai: We could re-use the syntax. It doesn’t have to be a
            functional notation
  leaverou: We would have to add a new property for each of those cases
  fantasai: That’s okay

  Rossen: Do we prefer the stripes functions? Or a new property
  fantasai: border-stripe
  TabAtkins: stripes function
  <leaverou> stripes function
  <tantek> stripes function
  astearns: One reason to have the function is that we noted that
            listifying properties is confusing. Stripes() makes
            specifying these stripes more comprehensible. If we use a
            property, we’re back to a list.
  leaverou: Yes
  Rossen: Another benefit is you can have the border color and the
          stripes in the same definition, so you can have your border
          color as defined green, but you can also define the stripes
          on top that may or not have green
  leaverou: So you can do them both in the same property
  Rossen: Yes.
  TabAtkins: Why do you need that?
  Rossen: So you can have the last value be transparent, and the
          default shows through
  fantasai: The main benefit of the border-color being separate is so
            that they can cascade independently. If they're not
            cascading independently, then there’s no point
  chris: The original reason for this was because a11y wanted to have
         a black and a white outline, and outline is defined in term
         of border. With this syntax, you say “black white” and you’re
         done.
  chris: Let’s not make a new property.

  tantek: Is stripes just a subset of gradients?
  <tantek> Is stripes a subset of gradients?
  <leaverou> tantek: No, gradients are 2D images. Also, gradient color
             stops define positions, not widths.
  <TabAtkins> tantek, this needs a 1d "image", so that it can
              automatically orient "inside"=>"outside" as you draw the
              separate border edges.
  <tantek> TabAtkins so it would be more work to set separate
           gradients for each border side then?
  <TabAtkins> tantek: It's *substantially* more work, yes, *and* it
              doesn't work well with border-radius either.

  Rossen: Proposal: adding stripes() to border-color and outline-color
  Rossen: Any additional concerns? Comments that would change this
          resolution, or objections?

  florian: How does it interact with border-style: double
  fantasai: You clip out the border shape.
  Rossen: Just like it would work with gradients
  leaverou: I think he’s asking about double borders, not dotted and
            dashed.
  chris: It’s a clip mask effectively.
  leaverou: Double has two different colors, and inside and an outside
  florian: nope, that’s something else
  leaverou: You’re right
  dbaron: We could say that inset outset groove and ridge would just
          get treated as solid because you’re picking your colors
          yourself now and that overrides those styles.
  florian: You can use it as fallback.
  leaverou: right!
  leaverou: I like that
  chris: yeah.
  Rossen: Any objections?

  RESOLVED: Add stripes() to border-color and outline-color

  <xidorn> suspect people would want to use it in shadows,
           text-decoration-color, caret-color, column-rule-color
  <xidorn> eventually
  <fantasai> xidorn, which axis are you striping for column-rule-color?
  <fantasai> ditto shadows
  <xidorn> fantasai, shadow is the same as border, which can go
           outwards or inwards I think?

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

  Rossen: Do we now publish a new working draft?
  fantasai: I don’t know what state the rest of the draft is in,
            not great though
  leaverou: we’ve published a working draft before, right?
  fantasai: nope
  Rossen: This is level 4, right?
  leaverou: yes, it needs lots of cleanup
  Rossen: Let’s not publish

Filters
=======
Scribe: fantasai

color-filter
------------
  Github: https://github.com/w3c/csswg-drafts/issues/2875

  dino: Some background...
  dino: Same way that Windows has done for decades, Apple's latest OS
        has a “dark theme”
  dino: Where user has a checkbox where they can choose between light
        or dark mode
  dino: You can see my browser is in dark mode atm
  dino: System apps have implemented this
  dino: Seems pretty popular
  dino: This is about how you can apply something like that to the Web
  dino: Particularly relevant to us for mail messages
  dino: which are web pages
  dino: What we wanted to do was automatically convert a page to dark
        mode
  dino: To do that, you want white to go to black, but you want hues
        to stay the same
  dino: e.g. blue shouldn't become orange
  dino: We had the idea to use color-filter
  dino: This takes filters just like 'filter'
  dino: But doesn't have ability to move pixels
  dino: It's a paint-time effect

  chris: Is this a straight 255 minus effect?
  dino: Yes
  [dino shows off invert()]
  dino: It's not like a regular filter. No stacking context. Just
        applies to colors
  dino: Colors of gradients, anywhere a <color> appears
  dino: Doesn't affect images
  dino: Because when you switch to dark theme, you don't want to have
        images invert
  dino: or emoji colors to invert etc.

  dino: We don't actually want to just invert the colors
  dino: Here's an example - invert(0.83) hue-rotate(180deg) saturate(3)
  dino: White goes to dark gray, bump saturation to compensate for
        grayishness, and then hue-rotate gets our colors back to what
        they would be without inversion
  dino: Works nicely. Better on my laptop than on the projector here.
  dino: This other column does some additional tweaks using JS, to
        look a little better.

  dino: Anyway, this is what we're using to display mail messages now
  dino: We have heuristics, if a marketing mail sets bgcolor, we won't
        do it
  dino: but for plaintext or simple HTML messages, we'll apply the
        filter

  dino: What we've got here is not Web-exposed, just in Mail
  dino: We can talk more later about Media Queries and how to interact
        with the Web
  dino: But a Web page could e.g. change colors manually in response
        to a media query, or they could use color-filter
  dino: It's just maths on red/green/blue channels of the colors
  dino: images are untouched
  dino: No stacking context
  dino: It's inherited, so you can undo it in a subtree

  chris: Initial value?
  dino: none
  chris: You say not images, but some parts of CSS are <image>s...
  dino: Gradients is a good example. If your background image is a
        gradient, you apply it to the color stops
  leaverou: What about custom properties that have been defined to
            accept <color>?
  fantasai: Gets applied when you apply the color to a CSS property?
  TabAtkins: But you don't want to double-apply for typed variables
  ...
  xidorn: Is it applied during cascading or what?
  emilio: Computed value is not affected
  fantasai: used-value time operation
  astearns: currentColor
  fantasai: probably fine
  heycam: <canvas> ?
  dino: Wouldn't apply to canvas

  dino: Currently implemented not for Web, in apps like Mail etc.
  dino: We think it makes sense for the Web
  dino: As a way to help authors adjust page

  leaverou: What about color modification functions?
  TabAtkins: Amelia asked that already in the issue. I think having
             both is useful

  leaverou: Are there uses other than dark themes?
  dino, chris: high-contrast

  dino: One of the greatest benefits we've found, before this people
        with vision issues that didn't like bright content would be
        constantly swapping between inverted/non-inverted mode
  dino: And that's a screen-time effect
  dino: And then we had to un-invert the images to make that useful
        for them
  dino: And then also create all these stacking contexts, which
        affects the page
  dino: So this is pretty nice.
  dino: So this might be a nice forced option
  dino: That the user could apply, e.g. "I want to see this web site
        dark"

  leaverou: Does it also apply to colors in inline SVG?
  dino: Yes
  leaverou: Wouldn't this be ...
  leaverou: You can have bitmaps inside an SVG
  leaverou: Seems like it would interact badly
  dino: Could have a UA rule that sets it back to none
  dino: We've mostly experimented with Mail. Haven't tried to apply to
        the Web yet

  <dbaron> This seems like a reasonable feature, although I'm
           skeptical about the readability of the mail in the use case
           Dean described given the massive differences in perceived
           luminance between the R, G, and B channels. (e.g., blue on
           black is hard to read, as is green on white)

  heycam: What if page wants to try handling it themselves?
  dino: This is a complicated topic, wanted to deal later, but let's
        talk about it now
  dino: If the browser is being told to apply dark mode automatically,
        what should we do?
  dino: If there's a media query that allows the page to detect if the
        user wants dark mode
  dino: Should the browser automatically flip the page or not?
  dino: It would be very odd for MQ to trigger behavior change
  fantasai: We do have precedence
  frremy: On Windows 8, if you resize an application to be in phone
          mode, we would scale the website down, except if it used
          @viewport
  florian: That's not a media query. @viewport is *supposed* to have
           an effect on the page
  florian: Opera did that for projection media type.
  <tantek> similarly with full screen
  dbaron: Been done before, but not a good idea. Poor API
  dino: API I think that would provide it is also bad
  dino: It's <meta viewport>
  ...

  florian: MS has an alternative to that, it's a property
  florian: can say "for this subtree, I've done it"
  emilio: Could say color-filter: none
  florian: *If* the browser is doing this with color-filter and not
           some other mechanism
  dino: So you'd set that property on the body
  fantasai: Can we use html, not body? *hates HTML's <body>
            propagation*
  heycam: Is this about high-contrast?
  Rossen: Yes

  dino: The only thing I don't like about that is it forces you to
        resolve style before you decide what you've got to do
  dino: meta tag doesn't have that problem
  dino: but then can't exclude part of the page
  Rossen: In practice, ppl tend to opt out on things like menus and ...
  dino: So that's actually main reason we don't want to do it
        automatically
  dino: built-in form-controls look weird
  dino: but ppl don't use built-in form controls that much, they use
        bootstrap etc.
  TabAtkins: Uhhh,, no???
  TabAtkins: The whole point of using built-in form controls is that
             they work properly on all platforms, e.g. apple watch

  florian: We've discussed similar model for auto-adjustment of colors
           for printing
  florian: Where author might want the browser to not make changes to
           the colors, because they already turned on colors and stuff
  florian: “Browser has magic adjustments. I want to opt out on this
           part of the page.”
  dino: It worries me a bit that including any style sheet could
        override this
  florian: meta tag seems the wrong layer to do it
  fantasai: That's true of viewport meta in general. Should be in
            style sheet

  dino: Suppose you include your favorite UI library. It supports dark
        mode.
  dino: Should it put "I support dark mode" property on the html?
  frremy: No, you set the property on the elements in your framework.
          Not on the whole page
  dino: So bounding to a tree
  florian: It's just a property. You *can* use it on <html>, but could
           apply only to components.

  <tantek> what about where web devs have matched color related values
           with colors in images?
  tantek: Did you talk about use case of matching colors in a JPEG?
  dino: Could just set the filter to none
  florian: Could use property to express two different things
  florian: “Dear Browser, don't do it, because I've done it myself.”
           vs “Dear Browser, don't do it, because here it's not
           appropriate”
  dino: So property is nice there, can say "Don't use on this color of
        red, because it has to match the red of these shoes" but rest
        of page is fine

  heycam: Are we considering possibility of mechanisms other than
          color-filter() being set to handle these cases?
  heycam: Because if not, then maybe we don't need a separate filter
  dino: So far color-filter has been enough for us, but we've only
        been looking at mail
  dino: Haven't tried browsing the web to see what happens on random
        content
  astearns: It's the exceptions I'm worried about
  astearns: In mail, generally the background is set on the body
  astearns: but on web pages could be arbitrary div
  dino: We found a lot of messages that don't set a bgcolor
  dino: but content sets bg white
  dino: that's why we couldn't layer mail over a gray application
        background
  dino: had to put some smarts into analyzing the page
  dino: If we can detect that the page wants a white background,
        because it's set some things to white...
  dino: But so far color-filter has been enough

  dino: Good news is implementation is quite easy
  dino: Just at the point of where you're asking for the color value
  dino: It's great, makes it easy to be a render-time effect
  dino: math is pretty easy
  dino: can also cache the values

  heycam: Some properties to control the color space that we
          interpolate in
  heycam: for animations and gradients
  heycam: That would happen with original color values before
          transforming them?
  dino: Don't think there's case where you'd want to change colors
         *and* change interpolation space
  dino: No idea why red-blue gradient, why if you invert it you'd want
        it to be in linear-rgb
  dino: If you ask for gradient colors, you get filtered colors, and
        then interpolate like gradient said to
  dino: Of course could put property with a media query if you wanted
  chris: So this modification happens last, just before rendering
  dino: Right.
  dino: Computed style is still the original color

  dino: While we're talking about this, maybe talk about MQ
  dino: Our current one that we use internally, is
        prefers-dark-interface
  dino: Think it's more prefers-dark-content
  TabAtkins: prefers-dark
  dino: Lines up with prefers-*
  dino: User is requesting that they prefer this type of content
  florian: I'm supportive of prefers-type MQs,
  florian: Question is what is the other options?
  florian: Can you express no preference in addition to expressing
           preference for light?
  ...
  dino: prefers-dark: light seems weird
  fantasai: Just rename it to something else, e.g.
            prefers-colors: light | dark | any
  ...
  heycam: Say you have a site which is already dark, like
          DaringFireball, and you turn on the browser option "Please
          automatically make this dark for me"?
  heycam: Are there options to keep it dark?
  dino: I think we need to be careful to say that "Please make this
        dark for me" can't be a universal hammer
  dino: It's hard to tell
  dino: E.g. we try with scrollbars, to try to guess whether page is
        light or dark and make scrollbars match
  dino: Because DaringFireball sets bgcolor which is neither white nor
        back
  dino: we probably wouldn't change anything
  heycam: Is that a case where the author should indicate they already
          support dark?

  dino: Question is, does anyone want to force bright?
  dino: If you set bgcolor to hot pink, might say that you support
        dark and they'll get hot pink anyway
  dino: Also for mail you'd get hot pink
  dino: ...

  florian: Do ppl anticipate forced-darkening of pages?
  dino: There are a lot of users who seem to want that
  dino: They've set up shortcuts to invert the page
  dino: They toggle this on and off as they browse different pages
  florian: If you have prefers-dark and forced-dark on at the same
           time, what does that mean?
  dino: ...
  dino: If the page says 'I did dark mode' then we wouldn't force it

  dbaron: Did some experiments with this sort of color inversion maybe
          8-10 yrs ago
  dbaron: One problem I ran into in the end, and dino's example with
          mail was showing it, is that you can't actually do a good
          job of preserving both saturation and lightness contrast at
          the same time
  dbaron: because the contributions of red green and blue channels to
          luminance is very very different
  dbaron: In the difference of white vs black, the luminance
          perception of that is 70% green 23% red and 7% blue or
          something like that
  dbaron: which means that fully saturated blue is quite readable
          against white, but unreadable against black
  dbaron: and fully saturated green is quite readable against black
          and unreadable against white
  dino: Which is why my third column was there, it bumped dark blues
        to lighter blues... blends a light-ish blue over every
        color ...
  astearns: I expect as your designer looks at more and more pages,
            they would find additional tweaks they'd want to make to
            the filter
  astearns: I can see the usefulness for this feature for browser UI
  astearns: as something you can toggle, and you can flip it back if
            it isn't working
  astearns: from a design perspective
  astearns: I can't imagine someone wanting to tweak their colors with
            such a blunt hammer
  astearns: Create a light theme and a dark theme as a designer, never
            going to be a filter that'll get you from one to the other
  astearns: So from UA perspective I see the usefulness
  astearns: but from author perspective I can't see the use case for
            the color-filter property
  <chris> for sRGB it is 21.26% red 71.52% green 7.22% blue

  Rossen: Thank you for demos and explanations, and that's a wrap for
          this issue.
Received on Tuesday, 24 July 2018 23:09:29 UTC

This archive was generated by hypermail 2.4.0 : Friday, 25 March 2022 10:09:11 UTC