[CSSWG] Minutes Telecon 2020-08-26 [css-cascade] [css-inline]

  These are the official CSSWG minutes.
  Unless you're correcting the minutes,
 Please respond by starting a new thread
   with an appropriate subject line.

Form Controls

  - The proposal for accent-color (
https://github.com/mfreed7/accent-color/blob/master/proposal.md )
      was updated after last week's discussion to include multiple
      examples of each form control.
  - The current proposal's goal is to encourage all implementations to
      have the same definition of what part of a form control is the
      accent color given a similar layout but when creating a new
      layout implementors are free to create a new definition for the
      a new design while following the spirit of the requirements.
  - The main concern about is that the proposed level of guidance to
      standardize will limit the ability to innovate and isn't
      necessary given the further level of control over form controls
      being designed in the OpenUI project.
  - The two viewpoints will need to be balanced to make sure that
      developers have enough control that they'll use the property but
      not prevent implementors from being able to iterate on their
      form controls.
  - RESOLVED: The group wants to add accent-color and discussion on
              details will continue (Issue #5187: Allow specifying the
              "accent color" of a form control element)
  - The items which still require discussion will be broken into
      separate github issues in order to create more focused

CSS Cascade

  - RESOLVED: Move this proposal (
https://gist.github.com/mirisuzanne/4224caca74a0d4be33a2b565df34b9e7 )
              into the spec (Issue #4470: Custom Cascade Layers)

CSS Inline

  - RESOLVED: Publish new WD of CSS Inline


Agenda: https://lists.w3.org/Archives/Public/www-style/2020Aug/0027.html

  Rachel Andrew
  Adam Argyle
  Rossen Atanassov
  Tab Atkins-Bittner
  Amelia Bellamy-Royds
  Oriol Brufau
  Tantek Çelik
  Daniel Clark
  Emilio Cobos Álvarez
  Dave Cramer
  Elika Etemad
  Simon Fraser
  Megan Gardner
  Chris Harrelson
  Daniel Holbert
  Dael Jackson
  Brian Kardell
  Jonathan Kew
  Peter Linss
  Alison Maher
  Myles Maxfield
  Tess O'Connor
  Melanie Richards
  Florian Rivoal
  Jen Simmons
  Miriam Suzanne
  Greg Whitworth

  Christian Biesinger
  Hui Jing Chen
  Adam Jolicoeur
  Chris Lilley
  Lea Verou

Scribe: dael

Form Controls

Allow specifying the "accent color" of a form control element
  github: https://github.com/w3c/csswg-drafts/issues/5187

  astearns: Discussed last week, bringing it up first this week. I'm
            guessing to give masonfreed a chance to give an update
  masonfreed: I heard a few action items. Main one was people wanted
              examples of existing form controls across browser/
              platform/time periods
  <masonfreed> https://github.com/mfreed7/accent-color/blob/master/proposal.md
  masonfreed: Added to the proposal doc ^
  masonfreed: You can see 5 different form controls
  masonfreed: There were several questions discussed on thread
  masonfreed: One was radio button. Question was on Chrome latest
              there's a large center blue dot on white, rest are white
              on blue. Question is doesn't that argue for single color
              and allow platform to decide.
  masonfreed: My view is no if color is specified we should follow that
  masonfreed: Similar for gradients, what does accent color do?
  masonfreed: My view that is up to implementors but try and respect
              accent color. Replace gradient with flat fill or
              integrate into gradient into whatever way makes sense.
  masonfreed: Only other open item was back to the amount of power to
              open with API. Single color or more specified with
              multiple colors.
  masonfreed: That's all I heard on the thread. Can open for

  fantasai: Based on what I've seen starting with one color makes
            sense since not much evidence of multiple. Figuring out
            how 2 colors would work together is complicated.
  fantasai: In terms of handling gradients if you set appearance:none
            everything is flat. If none is not set try and match
            platform convention. We can encourage use of accent color
            but I don't think that should disable platform styling
  <hober> +1 to fantasai's points
  masonfreed: single vs 2 color there are a number of controls in
              proposal. Even the radio button there are at least 2
              colors. If you only open one I would say you have to
              specify which part you control which leaves other
              uncontrolled. Devs want both controls on the thread
  masonfreed: appearance:none is a big hammer. It turns off all
              styling. Radio becomes an empty div. That is a complaint
              that brought us to this proposal. Radio and checkbox you
              do appearance:none and have to rebuild everything. This
              proposal was to give some control without having to

  gregwhitworth: I was initially going to +1 to fantasai in regards to
                 spirit but heard masonfreed on complexity. Maybe have
                 multiple colors but don't play into gradients. Where
                 we leverage primary|contrast proposal we provide one
                 color and allow UA to do what's best to keep spirit
                 of spec
  masonfreed: You mean take current proposal and chop of contrasting
              color but keep spec as to where first color should apply?
  gregwhitworth: No, this started on handling of gradients, correct?
  masonfreed: And radio.
  gregwhitworth: Was thinking same accent color applied within mac on
                 focus. That's where I was using as use case to have
                 gradients in future. Didn't want to discount that.
  gregwhitworth: Contrasting and primary I would keep. Too many
                 scenarios where need to exist.
  gregwhitworth: Goes into try to follow this and we don't make this
                 normative. So Safari says background is primary stay
                 true to author expectation is what you recommend.
  gregwhitworth: Radio, I could see Safari say primary is contrast in
                 Chrome. To that end I don't know how you coalesce
                 without lopping them off and hinder feature or get
                 much more prescriptive.
  gregwhitworth: Basically, I don't know

  fantasai: Thing with primary vs contrast the way accent color is
            used varies a lot. Sometimes foreground sometimes
  fantasai: They are sometimes both. Back to Aqua there was a solid
            color highlight with background color text because it's a
            dark color vs gradient and lighter gradient is foreground
            on top
  fantasai: If intention is set accent colors UA should auto generate
            variations on color and match against foreground or
            background as appropriate.
  fantasai: If you are creating variations on the color the pair of
            colors may no longer contrast.
  fantasai: I don't know how you would use the contrasting color in a
            situation like that
  masonfreed: I see that point.
  masonfreed: I did include some language that UA doesn't have to use
              exact color. That's one of the cases where you take it
              as input to the algorithm but don't have to use exactly
              that if it doesn't make sense to the gradient.

  Rossen: I'm hearing strong dev need that has been sampled over long
          time. And a good example of document that motivates and
          explains why we need and how to go about it. I hope all
          features have this level of detail and consideration when we
          bring them
  Rossen: Question is where do we go from here. Discussed over a few
          weeks. I do see pushback for various reasons. Continuing
          forward I'm trying to tease out obstacle here. What's the
          obstacle or are we pushing back just for sake of pushing back
  hober: Trying to answer. For me I generally like being able to
         specify accent color. Very important we preserve browser
         ability to adopt different designs in future and to deploy on
         different platforms and meet conventions.
  hober: Pushing back to preserve implementor flexibility to match
         platform conventions. Platforms have color conventions and
         want to be able to use those.
  Rossen: How is this different than what we do with appearance today?
          The cat is out of bag when introduced
          -webkit-appearance:none. Agree in principle to preserve
          browser innovation but I'm not sure taking away this
          flexibility is warranted here. Can you expand?
  hober: Don't understand your question
  masonfreed: I understand what you asked hober but what do you think
              in proposal is constraining the future developments?
  hober: Basic, like what if browser wants to use accent for
         checkmark, not background of checkbox
  masonfreed: That's why I kept it non-normative. It's guidance but
              not a constraint. If that makes more sense with a new
              design there's a good reason so go ahead.
  hober: Okay, gregwhitworth had said earlier if you didn't want to
         use accent in where it's specified you shouldn't use at all.
         Maybe previous call. That's different?
  masonfreed: Current language is accent colors are spec, guidance for
              what supposed to mean, but tried to thread needle
              between constrained and open. That's the intention. Open
              to clarify language
  <fantasai> "However, the intention is that if the same or similar
             accent parts exist on a given form element, it should be
             associated with the "primary" or "contrasting" colors in
             the same way across user agents."
  fantasai: We need to clarify if that's intent. Text says should be
            same across all browsers
  astearns: Acceptable to put intent behind text in spec. Be explicit
            about attempt and then put normative text so people can

  <Rossen> hober, re: "Don't understand your question" - How is
           webkit-appearance:none different in terms of overriding UA
           native controls compared to this proposal? (besides the
           fact that we won't force authors to rebuild the entire
           kitchen around the sink)
  <hober> Rossen: appearance: none is an escape hatch
  <Rossen> hober: yes, and if your position is to keep anyone from
           escaping this hatch is a much worse option
  <hober> Rossen: sorry, i'm not trying to be dumb, but i don't
          understand what you're getting at.
  <Rossen> hober: your pushback was about keeping the ability to ship
           UAs that can continue comply with the native platform right?
  <hober> Rossen: my pushback is about making sure that browsers can
          change their form control designs in the future, and use the
          author-provided accent color(s) in ways appropriate to their
          new form control designs.

  fantasai: I disagree accent color should be on same pieces across
            browsers. Intent is use as appropriate, not use accent
            color and try and match web os convention.
  masonfreed: That sounds like a core disagreement we should discuss.
  <hober> +1 again to fantasai :)
  <myles> yep
  masonfreed: What I was going for is if there's a very good reason,
           like a brand new checkbox with a completely new thing and
           no way to apply prior history you shouldn't be constrained.
           But if we're all building a box with a check we should try
           and be the same so dev can expect similar across browsers
  masonfreed: In document all checkboxes are widely the same so we
              should hope impl uniformly

  florian: I think there's a tension in requirements. Desire if some
           platform has check blue and another box blue and you say
           make a thing pink and we can do that. But if you don't know
           if it goes to foreground or background it's hard to know it
           would look right against everything else on the page.
  florian: Currently you know if it's foreground or background so you
           can pick other colors but at the expense of forcing the
           accent on a specific part. Not sure how to satisfy both
  gregwhitworth: florian hit nail on head
  gregwhitworth: To circle back in the proposal to masonfreed I put if
                 it computes to auto it's the webdev saying I want OS.
  gregwhitworth: No one disagrees with hober about forward innovation.
                 But the second someone finds interop differences it
                 will get replaced. That's what we see. I get it and I
                 agree but I don't think it's pragmatic for use.
  gregwhitworth: If we say this is limited styling and you have
                 outside of border have accent color the outline
                 becomes blue and my background is blue and I won't
                 like it. We can go that route but people will find a
                 barrier. The second we hit that people will replace it
  gregwhitworth: Worried by making this so loose people will just
                 replace it. We can say you can spec accent color and
                 UA will do best and hope experience is great. We can
                 spec that and say we recommend using these

  myles: Partially responding- I don't think that is necessarily a bad
         thing. There are different classes of desire. If web author
         wants form control same everywhere they have tools for that.
         Modifying native form controls will be different on every OS.
         Has to have flexibility
  florian: Design as is has flexibility, but nudges you in a specific
           direction. If you say accent color blue and you expect a
           blue check you'd see that and it's fine, but the background
           is blue on another browser and you can't see it against
           your blue background then you can't see it.
  florian: Having a nudge to say it's this part it gives you more
           interop to match with the rest of the page. I would be
           tempted to say spec as proposed probably gets the bias right

  <hober> I don't think it's helpful to talk about this in isolation;
          there are other efforts (e.g. Open UI) that will help add
          form control customization knobs, so the whole "if
          accent-color is too loose, people will use appearance: none"
          is a false dichotomy.

  fantasai: I agree with myles and hober. I think if you're
            appearance:auto goal should be match platform. One thing
            we can consider is to handle contrast levels instead of
            specifying 2 colors say this if contrast with foreground
            and this if contrast with background. Most of time not
            using separately for contrast, you're matching foreground
            or background.
  florian: You mean specify both with expectation browser uses one?
  fantasai: Yes.
  fantasai: And if you give 1 you give permission to browser to modify
            along brightness however it thinks appropriate. If you
            give 2 you can be more precise, but you don't get to say
            which part is used.
  fantasai: If you want to do that more manually I think we need to
            make checkboxes more stylable generally. I don't think
            accent color is place to do that
  masonfreed: Can we use example from dev in thread which is the time
              control with glyph and background behind the glyph?
              Author wanted to control the glyph and background behind
              to match control. How would they achieve that with your
  fantasai: I think that gets into...if there's a time icon on my
            control there's different ways to impl. glyph could be on
            text input background or on a button-looking thing. I
            don't know approach. They are all reasonable for platform.
            If author wants to control that specifically we need a
            model for that form control. I don't think accent color is
            way to control because browser may not be using accent
            color for that icon
  masonfreed: I see that but way it is says there might or might not
              be a glyph. If a glyph may not have backplate. If both
              use contrast for glyph and accent for backplate. If we
              impl that author would be happy. Leaves image of glyph
              to UA but controls colors.
  fantasai: But if button-like accent color is buttony part so
            convention would be bg of icon is accent color. Trying to
            say something different wouldn't work
  <gregwhitworth> +1 to what fantasai said as it sounds like we need a
                  master switch which appearance is. We should tie the
                  two in some meaningful way and if appearance isn't
                  adjusted we can achieve what hober myles was saying
  masonfreed: That's what text says. if buttony the bg should be
              accent. And that's why you need contrast color to
              control the stuff on the button. Lacking the contrast
              color the dev would be lost and have to replace the
  <gregwhitworth> +1 to masonfreed point, but there in lies the
                  problem :)

  Rossen: To hober's point earlier I agree browsers and UA should be
          able to differentiate or go to native conventions. Question
          is given that we have webkit-appearance as an escape which
          forces devs to complain for years because they're tired of
          having to use that and re-impl everything. My question is
          how is this better. Is this best way can do as a
          presentation platform?
  Rossen: Best we can do is make it appearance:none? Seems like should
          be better answer and middle ground to allow and expose these
  hober: I feel like this is a false dichotomy. Talking about this in
         isolation and not in context of other properties and
         features. If we think about all together we can see this
         question is moot. I'm not saying that the only options are
         appearance:none or accent color.
  <fantasai> hober++
  hober: Hoping openUI will increase customizability in a number of
         ways which will enable people to use more and not use escape
  hober: I don't see accent color as alternative but as a complement
         to those efforts. Platforms with accent color use somewhat
         similar and somewhat different.
  hober: Accent color on the spectrum of control is advice to the
         browser. OpenUI exposing specific parts is more at the full
         toolbox where we do what dev says.
  <gregwhitworth> that last point that hober made is what I think we
                  should explore at breakout. florian had noted he
                  thought about this. I'll start whipping up a doc
                  that explores this with concrete examples
  hober: If dev wants it on a specific part of a control I'm saying
         use what openUI exposes for that control. Accent color is a
         more general feature that should be more of a hint to the UA
         to do the right thing. You should have the extra control
         which is why openUI is exciting
  <AmeliaBR> +1 to hober's multi-level model. accent-color as a hint
             for modifying native styling, other options for more
             direct piece-by-piece control.
  hober: I think at root question misses the point. If accent color is
         the only possible option there's a point. In a world where
         we'll have other tools like openUI it doesn't hold water
  <Rossen> hober: thank you for elaborating - that was the answer I
           was hoping and looking for :)

  chrishtr: Summary on what I see where we can maybe make progress
            today. We all agree UAs should have ability to create new
            UI types over time
  chrishtr: I think any accent color we agree should be when possible
            interop in ways it applies so there isn't first mover
  chrishtr: I think spelling out non-normative text to do so will also
            help in making sure corner cases with contrast and
            darkmode are taken care of
  chrishtr: accent color is good to add, make sure text doesn't
            prevent future design, we could encourage interop, and
            have text that can work the corner cases
  * fantasai disagrees with "recommend interop" given the way it's
             being defined
  chrishtr: Is that a reasonable thing to resolve?
  astearns: I think it's more than we can currently agree on in part
            because recommend interop isn't agreed on definition
  <fantasai> I think that UAs should have ability not just to create
            new UI types over time, but to alter the design of
            existing UI types over time and across devices and
  <hober> fantasai++
  astearns: Have consensus this is good to add but details of what's
            normative and not is good to work out
  astearns: May be useful to break out current interop goals from
            future proofing. As we discuss it slides between what
            people want now and what people imagine in the future.
  astearns: Might be good to have explicit note that this could all
            change due to thing we haven't discovered. For current UA
            this is level of interop to achieve
  <fantasai> Yeah, I don't agree with that either :) See above

  masonfreed: Should I take action to further update spec text to try
              and thread needle?
  astearns: I think we should have more text to keep up and more
            discussion on issue. I think we could resolve this is a
            thing we want to add, but not other details.
  chrishtr: Could we resolve on other two points?
  astearns: We've already spent 45 minutes on this
  jensimmons: Briefly I think there's a lot of reason for optimism.
              Desire is to make sure this will be complex enough for
              future rather than drag into past. I'm personally very
              interested in and haven't been able to be as involved as
              I want.
  jensimmons: We can get somewhere great and this is hard because it's
              hard not because desire to not do it.
  <fantasai> So far no disagreement that we should have accent-color
  <fantasai> Just disagreement on how prescriptive its definition is
  astearns: Can we resolve this is something we want to add?
  astearns: Objections to continue to work on this?

  RESOLVED: The group wants to add accent-color and discussion on
            details will continue

  astearns: Helpful to break items into separate issues. masonfreed as
            you update text and look at particular items in contention
            if you can raise separate issue for each so we can have
            scoped discussion and resolution on pieces as we good may
            be good way to make progress.
  masonfreed: Will do and thank you all

  <AmeliaBR> FYI, I started a twitter poll on whether authors would
             actually use this with/without defined browser interop,
             please retweet into your audiences

CSS Cascade

Custom Cascade Layers (formerly "custom origins")
  github: https://github.com/w3c/csswg-drafts/issues/4470

  miriam: Take everyone through the proposal?
  astearns: Yeah. Summary would be helpful
  <fantasai> Proposal:
  miriam: Starting at the top, first question is where in cascade
          would author custom origin layer fit. Felt it could achieve
          all goals as higher then specificity. Putting it above
          shadow dom creates additional problems so putting it between
          solves problems
  miriam: Question about shadow dom at bottom of doc
  miriam: Interacting with !important we suggest layers exist entirely
          within defined origin. They work like origins so reverse in
          !important layers.
  miriam: Normal layers styles not explicit are at the top followed by
          named layers in order set up
  miriam: Reversed in important so layers are at bottom.
  miriam: Keeps meaning and intent of !important more clear and
          working similar but internally
  miriam: Talked about style attribute and suggestion is it continues
          to be above these layers. Have to redefine but I think has
          to anyway with scope being removed. Keeps style attribute
          like other styles.
  miriam: Levels for managing layers; does it happen at selector or
          declaration or block or importing. Suggesting block similar
          to MQ and as with existing @rules blocks can nest. Then
          layering based on order of first appearance in code
  miriam: Example reset-base components reset. Reset lowest, base on
          top of that. Order they're first discovered is order of
  miriam: In terms of ordering layers there's a way to cheat and
          declare them all. Could be with empty blocks but also
          proposing layers shorthand to let you define. That's above
  miriam: Suggesting an import syntax. Way to name and group
          everything inside a file. Helps with encapsulation.
          Bootstrap exposes layers but we can create a wrapping layer
          that keeps all bootstrap inside. Nesting doesn't impact
          order, just naming
  miriam: Various discussion on syntax and if it builds on @import or
  miriam: Nesting doesn't change order, just groups. If wrapping layer
          has name can interact with nested layers by calling that
          with some syntax for getting to layers within layers.
  miriam: By allowing unnamed layers allow a tool like bootstrap to
          have private layers. Wrap in unnamed layer and removes
          ability to call them later.
  miriam: More detail in the proposal
  miriam: Migration path since this is between specificity and style
          this can be mimicked with specificity so clearest way to
          show is list of IDs.
  miriam: Can be more clean using IS to get specificity of IDs. Path
          to polyfill
  miriam: Weakness on refactor use case. Since layers reverse in
          !import not idea but doesn't seem changes are extensive.
          Have to do something with !import styles in legacy to make
          sure they don't override in new. Not a perfect solution but
          works with a little manipulation
  miriam: Questions from thread, does load order of stylesheet matter
          so if a sheet is lazyload but lazyload first does it matter?
  miriam: Can you nest layer blocks, yes. Specificity is unchanged
          inside layers. Just subsuming it.
  miriam: If stylesheet is in multi layers it's in multi which is true
  miriam: Best syntax is open question still. Are unnamed layers
          feature or a problem? Allow hiding which is risky but
  miriam: Way to revert layers? Do we want that?
  miriam: How does light dom layers affect shadow dom layers with same
          name. Complex but think a wrapper may be able to resolve
          that powerfully

  emilio: Regarding shadow dom; how does it matter? rules in different
          trees are sorted different on top of specificity. I don't
          know how that is a problem.
  miriam: Comes into play because ordering of names determining the
          layering order
  miriam: If there are layers inside shadow dom named main and base
          and layers outside named base and main which order are they
  <fantasai> +1 to scoping layers to a shadow context
  <miriam> +1
  emilio: I see. I think layers should scope to a tree. Inside a tree
          is where you sort by specificity. Doesn't make sense to me
          to have names interact between trees. I think that's what
          you proposed with anonymous.
  miriam: Could be interesting to let you access layers inside a
          shadow dom.
  emilio: Why would you want? But does seem different discussion

  astearns: My proposal is get this proposal into the spec and start
            opening issues to dig through
  astearns: Objections to move this proposal into the spec?

  RESOLVED: Move this proposal into the spec

  astearns: Doesn't mean we're done, means we open separate issues to
            discuss each bit instead of whole. Thanks so much miriam
            for putting this together.

CSS Inline


  fantasai: Can I publish new WD of inline layout?
  astearns: Objections?
  <dauwhe> +1

  RESOLVED: publish new WD of CSS Inline

  astearns: Thanks everyone for calling in
  bkardell: Please reply to the email about a MathML meeting!

Received on Wednesday, 26 August 2020 23:29:52 UTC