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

[CSSWG] Minutes Telecon 2020-09-23 [css-scoping] [accent-color]

From: Dael Jackson <daelcss@gmail.com>
Date: Wed, 23 Sep 2020 19:06:04 -0400
Message-ID: <CADhPm3sKmi56w=51pjVLsXRmPca9cq4aU6cq-JiH9P0pabHjZA@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 Scoping
-----------

  - RESOLVED: Change the spec to match current web behavior so
              fallback content is not matched by ::slotted() (Issue
              #5482: Consider aligning ::slotted() for fallback
              content with implementations)
  - RESOLVED: Add more examples to this section of the spec (Issue
              #5482)

accent-color
------------

  - In discussing issue #5480 (Should interoperability be a goal for
      the `accent-color` spec?) there were two viewpoints to consider;
      implementors and authors.
      - From an implementor point of view there were still concerns
          expressed about the implementability of the accent-color
          property. It's important to continue allowing browsers to
          ignore accent-colors if necessary.
      - From an author point of view this spec should be understood as
          allowing them to provide browsers a hint as to the colors
          they prefer. Providing that hint does require a level of
          interoperability where similar form elements display the
          accent-color similarly so authors can ensure proper contrast.
  - There was general agreement that if we're doing an accent-color
      property there does need to be examples in a non-normative
      section which gives guidance and will allow authors to have some
      consistency in usage. However, there wasn't broad agreement that
      the non-normative section as written was what the group wanted
      to resolve on so discussion will go back to github with a
      request for specific feedback on how to improve the text for the
      non-normative examples in the spec.

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

Agenda: https://lists.w3.org/Archives/Public/www-style/2020Sep/0028.html

Present:
  Rachel Andrew
  Tab Atkins-Bittner
  Christian Biesinger
  Mike Bremford
  Oriol Brufau
  Daniel Clark
  Emilio Cobos Álvarez
  Elika Etemad
  Simon Fraser
  Mason Freed
  Megan Gardner
  Chris Harrelson
  Daniel Hobert
  Dael Jackson
  Brad Kemper
  Jonathan Kew
  Una Kravets
  Daniel Libby
  Rune Lillesveen
  Chris Lilley
  Alison Maher
  Myles Maxfield
  Melanie Richards
  Devin Rousso
  Jen Simmons
  Miriam Suzanne
  Greg Whitworth
  Zheng Xu

Regrets:
  Tantek Çelik
  Brian Kardell
  Florian Rivoal
  Lea Verou

Scribe: dael


  astearns: I think we have enough to start
  astearns: One change to the agenda is not talk about item 1 since we
            discussed last week.
  astearns: GH thread is long and we said last week we'd wait for it
            to be agenda+ again
  chris: Looks like we're sort of resolving but let's give another
         week. Unless jfkthame joined for this
  jfkthame: Partly but happy to leave another week
  astearns: Any other changes?

CSS Scoping
===========

Consider aligning ::slotted() for fallback content with implementations
-----------------------------------------------------------------------
  github: https://github.com/w3c/csswg-drafts/issues/5482

  rune: Case is none of browsers implemented what's in spec. Spec says
        fallback should be styled by ::slotted() but all browsers
        style elements which are slotted following assigned slot chain
        so you can get not just first slot scope but if child of
        shadow host it's flattened to next scope.
  rune: Question is if we should change spec to match implementations
        or if we should try to agree all implementations should move
        to what spec says.
  rune: Started as a bug reported by Salesforce. Bug was a corner case
        in WK which makes Salesforce think they implemented
        incorrectly, but mostly in agreement with Blink and Gecko.
  rune: First level of slotting possible to style with a normal child
        selector on the slot. If you want to style the fallback in a
        nested slotting that's currently not possible.
  rune: Talked to Polymer team at Google and people working on web
        components and they think should stick with current. Worried
        this has web compat concerns if we shift to match spec
  gregwhitworth: As I said in GH I'd like to understand what compat
                 they're worried about. Is it their own specific
                 compat?
  rune: I don't think they have specific cases. Worried in general
        there is content that will break
  gregwhitworth: Not sure why Polymer that's a component library...I'm
                 confused.
  rune: Need to check again

  gregwhitworth: Chrome status data indicates it's low in utilization.
                 Part of me feels the scenario you outlined is not
                 unheard of. My expectation...I would phrase do you
                 match spec now or do we come up with another method
                 that enables that use case?
  gregwhitworth: The use case is not invalid. Browsers aren't
                 implementing to support it. We can fix by browsers
                 match spec or we add new functionality to ::slotted()
  rune: Most common use case is style fallback in same scope where we
        have a solution. This is case of slot child of shadow host
        which slotted into a different scope.
  rune: Possibility to have syntax to target the re-slotted as
        fallback.
  rune: I don't think we would like to change Blink implementation
        unless there's a plan to change in all browsers. I saw WK
        didn't have immediate plans to do anything about it. Not sure
        if anyone from WK has specific thoughts or if it's just low
        priority
  smfr: I don't know status, guessing low priority for us

  TabAtkins: As I put in comment late in the bug the fact that spec
             says the selector passed to ::slotted() should match
             fallback content as well as actual slotted is more
             accidental. Easiest way to spec what I wanted. I don't
             have opinion on one way or other. Weak behavior
             preference that current browser is probably right because
             usually want fallback styled differently.
  TabAtkins: I'm fine with browsers keeping current. I found on
             investigation that how spec is written I don't think does
             what we want. Everyone is doing some funky "I think you
             know what I mean" behavior. The algorithm in the spec if
             you have nested shadow roots so slot going into light dom
             as written that doesn't matter for ::slotted() and it
             just sees slot children
  TabAtkins: Apparently works in Safari but Safari styles actual
             children? Confused
  rune: Bug is Safari is they match the slot which is not what's in
        spec. In Salesforce they styled the color and in Safari
        targeted the slot. If they set the border it wouldn't have
        worked.
  TabAtkins: Got it. I thought border styles also applied but if they
             don't that's fine.
  rune: Behavior in Safari is corner case
  TabAtkins: Find slottables is you find the slot elements themselves
  rune: Flattening in HTML collapses all the slots. Only thing you
        style is the elements. Can't style slots themselves
  TabAtkins: I'm pretty sure that's wrong. It's want I wanted, but not
             what I wrote.
  TabAtkins: I would like to change to match current Chrome and FF
             behavior. I support that.
  <TabAtkins> https://drafts.csswg.org/css-scoping/#slotted-pseudo Or
              hell, maybe I did write it correctly; it does say
              "assigned, after flattening", and links over to the
              "find flattened slotables" algo.

  * smfr would like the bugs.webkit.org bug for this
  <gregwhitworth> smfr: https://bugs.webkit.org/show_bug.cgi?id=169948
  <smfr> ty

  emilio: Going to say along lines of TabAtkins' opinion. Regardless
          of which way you go if you want one or the other behavior
          you need to work around it. If you want fallback and slotted
          identical style you need to spec 2 selectors. If style
          differently you need to add a bunch of rules which is tricky
          for specificity.
  emilio: As far as I can tell only thing you can't do in FF and
          Chrome is style fallback of nested slots. That doesn't seem
          like something a lot of people would want to do because
          don't know dom hierarchy of nested slot. Could be wrong.
  rune: Share understanding with emilio. You're correct about case
        where you cannot target
  emilio: Like current because if you want style and slotted children
          the same it's way easier to do than if we impl what spec
          says.

  TabAtkins: I propose we resolve to change the spec so fallback
             content are not part of content matched by ::slotted() to
             have spec match current Chrome and FF behavior
  TabAtkins: Does that work?
  gregwhitworth: Addendum request; I would love some examples about
                 here's what flattening does. I understand that's
                 WHATWG but examples in our spec as to what happened
  TabAtkins: I agree, could use examples
  gregwhitworth: If we can default style the default content it works
                 for us
  astearns: Proposal: change the spec to match Chrome and Gecko
            behavior so fallback content is not matched by ::slotted()
  rune: Noted Safari is mostly correct. It is mostly aligned
  astearns: Yeah, it's the edge case
  gregwhitworth: Yeah, it's that one bug

  RESOLVED: Change the spec to match current web behavior so fallback
            content is not matched by ::slotted()

  astearns: Objection to add more examples?

  RESOLVED: Add more examples to this section of the spec

  astearns: If there is a further use case for finding some way to
            have a style that matches slotted and fallback content we
            can add that in the future, but not necessary right now
  TabAtkins: umhum

  rune: Need tests.
  rune: When I changed impl in Chrome I didn't fail any tests so we
        need more
  emilio: I think the tests are for what should match but not for what
          should not
  gregwhitworth: Leo on our side is good with tests and I can loop him
                 in if you need help on adding tests

accent-color
============

Should interoperability be a goal for the `accent-color` spec?
--------------------------------------------------------------
  github: https://github.com/w3c/csswg-drafts/issues/5480

  <masonfreed> https://github.com/mfreed7/accent-color/blob/master/proposal.md#motivation-and-intent
  masonfreed: Heard 2 things from last time. One is ^ to add
              motivation and intent to help interpret written spec. I
              wrote that.
  masonfreed: tl;dr is it's to provide a compromise between interop
              and not constraining browser impl.

  masonfreed: Today is interop question. Are we going for interop?
              It's fundamental. Depending on your answer the spec
              changes. Should it be same across or hint to browsers?
  masonfreed: My opinion is useful either way but lose a lot if don't
              strive for interop.
  masonfreed: 2 reasons. 1 is not easily usable by devs without
              browser sniffing. Could also cause a11y and contrast
              issues if different expectation as to where the color
              goes. blue background, white accent for checkbox and you
              assume that's the background. If browser colors the
              check white you have contrast problems.
  masonfreed: I started this with the idea of a single color and went
              through how it works for each control. Realized it's
              hard to use without language on how it's used for all
              controls. Helpful to look at examples section
  masonfreed: Question today is should accent-color be interoperable.

  myles: Background concern is being able to match platform form
         controls is valuable. Some browsers system framework needs to
         fit in. Don't want to have 2 sets of form controls for web
         content vs rest of OS
  masonfreed: I think if you as a dev want to make form controls match
              platform it's easy, don't specify anything for form
              controls and it matches. If you specify colors you're
              trying to change away.
  emilio: I feel a bit the same as myles. If we try and spec form
          controls...dev may specify accent-color because chrome
          handles it and they don't look native but look better if you
          change accent color. I'm not sure your argument applies that
          some browsers will honor colors and others won't.
  emilio: For some platforms like Windows and MacOS (I think) we don't
          have much control over which colors are native and which are
          for form controls. Alternatives are remove native but you
          don't want to do same as appearance:none, right?
  masonfreed: Right. Idea here is make basic style of color easier for
              developers.
  masonfreed: The intention of proposal is that it's open to not do
              anything. It's explicit you can disregard a color. It
              says if you are going to respect it you should try and
              use it same way as everybody else. If you don't want to
              control colors of native form controls you can do that.
              But if you use accent-color you should do it same as
              everyone else
  emilio: But if Gecko and WK want to keep native appearance we have
          to impl form controls twice if we want to honor it sometimes.
  myles: Another way to say this, this is a world where some browsers
         implemented intentionally and some don't. Some browsers use
         own native design and others use non-native custom design.
         That doesn't sound like consistency. That world answers the
         question, it isn't consistent.
  masonfreed: Agree form controls are all different. Is that what we
              want is the question. If we're adding something new
              should we point it toward interop?

  jensimmons: I think there's 2 ways to look at this. One is what
              we're discussing from implementors. From author PoV is
              the other.
  jensimmons: I think some of what you're asking masonfreed gets at
              the root of the idea where coming up with accent-color
              as the property...another way to do is pseudo class for
              checkmark and another for checkbox....having something
              more vague implies the idea we're not giving you a bunch
              of hooks
  jensimmons: If I expect to say my checkbox background is blue I
              expect that everywhere. But when it comes to saying
              accent-color: blue it's implied by the property and the
              name that hey author welcome to the wide world of chaos
              and there is not consistency even in the same browser
              what's happening
  jensimmons: I thought the idea is hey we know it's chaotic so we're
              going to give authors something that's more generic and
              we'll give authors a way to say my accent-color is blue
              and it's not interoperable in a way that pixel perfect
              designs would imagine
  masonfreed: I appreciate and understand that. That is still my
              intent. Range looks different across everything. I think
              the realization I made going through each control is
              there are, in a lot of cases, 2 places where
              accent-color comes in. There's backgroundy and
              foregroundy thing. I think we're still trying to specify
              something vague but add a bit more information and
              provide more of a hint what the dev is trying to do.
  masonfreed: Providing 2 colors and some guidance feels to me helpful
              even to devs. Definitely helpful to devs. If building a
              checkbox and looks like other checkboxes it's helpful to
              me.
  masonfreed: I hear we're not going pseudo classes for everything.
              Maybe that's down the road. This is low hanging fruit
              that solves a bunch of dev problems that want to make
              the controls the right color for their site.
  masonfreed: I feel you need some level of intent about doing the
              same thing if you're going to do it.
  jensimmons: Makes sense to put something in spec so implementors
              aren't just making it up and everyone gets to a
              different idea. Say in general we think accent is here
              and other color is here so implementors can have some
              guidance and not make it up from scratch or look at
              other browsers. But maybe just a gentle suggestion
  jensimmons: You're asking should we try and get everyone to be
              definitely the same way and I don't know that we can say
              yes
  masonfreed: Adding one more thing. Way we got here is there was
              concern about first mover problems. If one browser impl
              accent-color then other browsers would be stuck
              matching. Work I did to go through each control was in
              response to this call saying let's discuss first up
              front.

  TabAtkins: Two things. 1 to talk to myles and emilio about browsers
             wanting native on particular platforms. I think that
             should be fine. Goal of form elements being stylable will
             continue to be impossible. Native form controls are
             weird. Spec allowing browsers to stick with native and
             ignore accent-color is necessary and doesn't make us any
             worse.
  TabAtkins: When talking interop, saying we need interop is nonsense.
             We need interop to make this a property. We need at
             minimum if it's a foreground or background color.
             Required to ensure element looks good against parent.
             This will be complex because things like Chrome redesign
             from where checking a checkbox swaps the background and
             foreground colors
  TabAtkins: This means chrome cannot be using blue as foreground
             accent and use that to draw background. Needs to set in
             UA that when checkbox is checked it uses flipped. It's a
             work around. If we're clear that if you give 2 colors one
             is foreground and one is background I think we're okay.
             Given there's no control what so ever right now that bit
             of requirements should insure enough interop even if
             there's a first move
  TabAtkins: Means we'd have to be careful about how we spec
  <TabAtkins> like, `input { accent-color: blue white; } input:checked
              { accent-color: white blue; }` needs to be in the Chrome
              UA stylesheet
  <gregwhitworth> +1 TabAtkins

  una: I want to speak to intent of proposal. Give authors more
       control over form styling. Problem for 20 years. If we're
       giving authors more control the authors that would case want
       consistency across brands and OSs. My worry is it seems to be
       about consistency. If there's not consistency about how colors
       applied it doesn't solve the issues the property tries to solve.
  una: Even with having background color it's different in Safari
       where there's a gradient. Solving those issues is key to making
       this something authors adopt. If we say here's the color and
       good luck and it's different across browser and OS it takes
       away the power of the property
  una: Want to argue to author intention in wanting consistency. If
       we're introducing new properties and options it should be top
       of mind

  gregwhitworth: I would like to 100% agree with TabAtkins and una.
                 This was something we were hoping to tackle at joint
                 meeting and it's because masonfreed hit nail on head.
                 Need to resolve if we agree this is a problem we're
                 solving
  gregwhitworth: There's a reason author is putting this in there.
                 They're saying I need to change this for a meaningful
                 reason. Way we start to address is recognizing
                 there's potential buckets, potential capabilities we
                 can unlock these things. We're going after the
                 extreme far end to unlock everything [in OpenUI].
                 This property is more like intent
  gregwhitworth: There is a spirit and an intent to say I'm Coke and I
                 want checkboxes to be Coke-red. I love your checkbox
                 but it's blue and it feels Chrome not Coke. I'm
                 proving you a brand hint, please apply to your
                 control in a meaningful way. That's the way it's
                 specified.
  gregwhitworth: Trying to thread the needle of allowing author to
                 have limited control, but some control, while not
                 biting entire problem. Feel it's a good first step.
  <bradk> +1 to CocaCola example
  gregwhitworth: I agree with TabAtkins that if they're using the
                 property you should leverage it. I guarantee everyone
                 has primary, secondary, etc. colors. We should be
                 able to commit to if they're native render or not
                 it's not un-implementable.
  gregwhitworth: jensimmons and una hit on it. Author problem and if
                 we feel our controls are superior to the problem
                 author is trying to solve. Agree with TabAtkins about
                 we should lock down. Appreciate masonfreed trying to
                 have the spirit
  <fantasai> +1 to gregwhitworth "please use this color in a
             meaningful way"; -1 to defining what "use in a meaningful
             way" means in terms of which parts get which color

  <TabAtkins> Important bit here is that the role of the colors
              *cannot* be semantic like "primary, secondary,
              tertiary". They *must* be functional like "foreground,
              background, shadow". Otherwise a page using "black
              white" for a checkbox, expecting a white box with a
              black check, and putting it against a black background,
              would look bad on Chrome where the background is the
              "primary" color when checked.
  <fantasai> +1 TabAtkins
  <fantasai> need to ensure contrast
  <gregwhitworth> TabAtkins: yeah, my point was that everyone does
                  have colors in their control that will be able to
                  map to the property value set
  <fantasai> wrt accent-color, I don't think making a list of "primary/
             tertiary/etc" makes sense. But listing colors, against
             which the browser will use a "pick color with most
             contrast against [color/bgcolor as needed for this
             particular use of accent coloring]", could be a good way
             to do this
  <TabAtkins> gregwhitworth: Yeah, I was just countering your use of
              "primary" in your description. ^_^

  emilio: Agree with sentiment
  emilio: Concern is implementability. We can do the work to make it
          work. If WK commit they can add coco APIs for Mac but
          there's still no control over windows. Only alternative is
          re-write form controls. We may end up doing that. I don't
          know. If you force engines to apply it then you prevent
          using native form controls
  emilio: If you don't it's not all that useful to authors because
          they can't customize
  astearns: Compromise is for a browser using native controls without
            any capability of changing the browser could say they do
            not support on that platform. Lets author know styles
            won't work as intended.
  emilio: It's an option but pages could rely on colors to work
  astearns: There will always be browsers that won't support.

  <bradk> I disagree that it should say backwards vs. foreground. If
          one native control has a border and another doesn’t, saying
          the background should be white would be much worse on the
          one with no border.
  <bradk> Seems like dark-color, secondary-dark-color, light-color,
          secondary-light-color would work better
  <TabAtkins> bradk: That doesn't work for Chrome's checkboxes vs
              everyone else's checkboxes.
  <TabAtkins> bradk: That's what I meant by "cannot use semantic
              roles, must use functional roles"

  jensimmons: I'm just confused as to where disagreement is. Feels
              like a high level debate about if we should use must/may/
              should in every part of the spec. Maybe some of spec
              should say must, some should be may, some should.
  <TabAtkins> agree with jensimmons; this has been circling for twenty
              minutes when it's actually just a debate over the
              existence of the feature itself
  masonfreed: For me the debate is the way proposal is written is the
              interop version. Alternative is strip away most of that
              to just say accent-color looks like this and browsers us
              as they say fit. Debate is spec as written vs another
              spec that reads that accent-color is a hint, use as
              you'd like

  <gregwhitworth> my main point here was that we can pick up this
                  discussion at the Open UI + CSSWG meeting
  <gregwhitworth> I have this as an agenda item
  <gregwhitworth> as it's paramount to land on aspects of interop
  <gregwhitworth> whether we do or do not

  astearns: Put another way we discussed and asked masonfreed to make
            non-normative suggestions. masonfreed is coming back for
            validation. I think we should say yes this is what we want
            or no, dial back on interop
  emilio: Assuming we spec this feature I think it should be
          sufficiently well specifies so browsers and impl can do
          something consistent.
  <TabAtkins> masonfreed: I'll make it easy: if the spec says "here's
              some colors, do what you want with them", I'll formally
              object to it. ^_^
  fantasai: I think I would go with saying spec shouldn't mandate use
            of color and instead say it's a hint. If we're switching
            to a mode of form control with a lot of author controls we
            can mandate. There is a desire for authors to influence
            without changing render at a fundamental level.
  fantasai: Main concern should be how do we get enough contrast. Some
            checkmarks use foreground and some background. Need to
            make sure we can get enough contrast. Having examples
            which are here's how it's used in some browsers is good,
            but you're using native controls and accent-color should
            be a hint that says I'd like to use this accent-color and
            please use it meaningfully. But shouldn't define meaningful
  astearns: So you think dial back on non-normative text of what you
            should do with accent color
  fantasai: I don't think we should have should or must requirement
  astearns: It's all non-normative. So you're okay with spec as-is?
  fantasai: I'm fine with it being examples
  masonfreed: All non-normative examples

  myles: We said difference is today with non-normative vs deleting
         the examples. What's the functional difference between the two
  masonfreed: Functionally means every implementation can do own thing
              and may be completely different. Chrome will implement
              the way they want. If we delete all the text. It will
              just be a rough description and no guidance as to how to
              use it.
  <TabAtkins> And I'll strongly object to a version of the spec
              without guidance on using the colors

  astearns: Back to original issue, should interop be a goal?
            non-normative examples will likely get better interop.
            Removing is more likely for non-interop
  <TabAtkins> No guidance = browser-specific, so this is a prefixed
              property, not a real property.
  <emilio> TabAtkins++
  <gregwhitworth> TabAtkins: agreed
  <gregwhitworth> emilio: you're confusing me bud
  <emilio> gregwhitworth: if we specify the property, we should
           specify what it does
  <emilio> gregwhitworth: (that's what I said when I last spoke)
  <emilio> gregwhitworth: That is regardless of my concerns about
           implementability in Gecko / WebKit
  <emilio> gregwhitworth: But I think we decided a bit ago that
           debating implementability was specifically a non-goal of
           this issues
  <emilio> this issue*
  <emilio> gregwhitworth: So I think I'm not contradicting myself, but
           maybe I'm wrong :))
  fantasai: I think the section labeled non-normative is written with
            normative language. It needs to say this is how it could
            be done but it could be done in a different way.
  <TabAtkins> If someone doesn't want the property *at all*, say that;
              trying to water down the requirements by removing
              guidance doesn't do the job.
  astearns: My way of thought is here's an example where if form
            control looks like this here's what it should do. If it
            looks different do what you want. But if you have
            something like this should is appropriate
  fantasai: In this case might want 2 examples. If it looks like this
            here's what changes and if it looks like that here's what
            else would change. So you can say your form control
            doesn't have to look exactly like that

  astearns: Can we resolve to say this non-normative section is way we
            want to proceed?
  astearns: Would anyone object to keep with advice on impl?
  fantasai: Don't want as is, but fine with a bunch of examples
  myles: Need resolutions for non-normative text?
  masonfreed: Looking for next steps
  fantasai: Happy to give more specific feedback. We can resolve on
            the normative
  astearns: This issue is about non-normative
  astearns: myles do you object to keeping non-normative? Want more
            time?
  myles: We're kind of out of time
  <TabAtkins> I would like this to wait for the OpenUI talk; this
              40min discussion did very little. :(
  <TabAtkins> Let's not talk about this again until there's a focused
              topic on it

  masonfreed: Can I get more specific feedback on the issue?
  astearns: Anyone with specific concerns please put them in the issue
            and we'll do this first thing next week
  <masonfreed> Thanks!

After call conversation
-----------------------

  <fantasai> masonfreed, the issue I have with your "non-normative"
             section is that it's worded as a set of normative
             recommendations rather than illustrative examples
  <fantasai> masonfreed, for example - The shaded background of the
             progress bar should be considered a "contrasting" accent,
             while the filled "value" portion of the progress bar
             should be considered "primary".
  <fantasai> masonfreed as opposed to something like "In this example,
             the shaded part uses the OS theme accent color; therefore
             it should be affected by accent-color"
  <masonfreed> fantasai, I understand your objection, but I don't know
               how to improve it exactly. If you would like to propose
               an alternative that says "you can use the first color
               as the background, or the foreground, or somewhere
               else", then I don't see the point of having that entire
               non-normative section in the first place.
  <fantasai> masonfreed, if you're not allowing for those
             possibilities, then your section isn't non-normative
  <fantasai> or at least, isn't really behaving as such
  <masonfreed> fantasai - let's continue the discussion on the issue.
               I'm curious to hear your specific suggestions about how
               the proposal is written.
  <fantasai> masonfreed: happy to make specific suggestions :)
  <masonfreed> Thanks!
  <fantasai> masonfreed: Largely, I agree 100% with Tab's comment here
             - https://github.com/w3c/csswg-drafts/issues/5480#issuecomment-682242811
  <fantasai> masonfreed: I think his first two paragraphs are
             basically my core position
  <fantasai> masonfreed: and my desire is for this non-normative
             section not to take away from that core position in any
             way
  <masonfreed> I think his first two paragraphs are *my* core position
               as well! And I believe (perhaps incorrectly) that I've
               written a spec that does exactly that.
  <masonfreed> I think it's important to read the non-normative text
               in the context of the normative text.
Received on Wednesday, 23 September 2020 23:06:57 UTC

This archive was generated by hypermail 2.4.0 : Wednesday, 23 September 2020 23:06:59 UTC