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

[CSSWG] Minutes Virtual F2F 2020-04-30 Part I: CSS Cascade [css-cascade]

From: Dael Jackson <daelcss@gmail.com>
Date: Fri, 15 May 2020 18:38:12 -0400
Message-ID: <CADhPm3uA_HpvhcBqQQLRc57tPdgDAKABjHQ2igPmLQxRqY4ESg@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 Cascade

  - There are a bunch of custom origins github issues the need to be
      considered together in order to shape the definition of custom
      origins. The goal of this F2F was raise the issue awareness in
      order to head toward a resolution.
  - A lot of the initial conversation reaffirmed the desire and value
      to solving custom origins.
  - Issue #5003 (Where do "custom origins" fit into the cascade) ties
      into issues around how !important is handled (issue #4971) and
      better explaining/handling of specificity (issue #4981).
  - The suggestion for handling `revert` is to have two options, one
      to go back just one layer and another to go all the way back to
      the original. There is a need to keep the keyword the same,
      though, because there's already author confusion about `revert`
      and `initial`

  - There were several points raised about if nesting was necessary
      for issue #4969 (What are the proper "levels" for managing
      "custom origins"?) or if each custom origin could just be its
      own file.
  - Whatever solution is accepted it should be something where we can
      start simple and expand later. Simplicity will allow authors a
      better chance at understanding how custom origins can be used.
  - If two libraries are trying to use the same custom origin space,
      there needs to be a way for the author to say which should win
  - If origins is done with the multiple file route there needs to be
      a way to organize them for large teams and a way to optimize the
      loading of them for people not using HTTP/2

  - A custom origins focused task force will be organized to focus
      specifically on making progress around custom origins (similar
      to the grid task force).


Agenda: https://wiki.csswg.org/planning/virtual-spring-2020#day-two-time-slot-b

  Adam Argyle, Google
  Rossen Atanassov, Microsoft
  Tab Atkins, Google
  L. David Baron, Mozilla
  Amelia Bellamy-Royds, Invited Expert
  Christian Biesinger, Google
  Mike Bremford, BFO
  Oriol Brufau, Igalia
  Tantek Çelik, Mozilla
  Emilio Cobos, Mozilla
  Dave Cramer, Hachette Livre
  Elika Etemad, Invited Expert
  Simon Fraser, Apple
  Daniel Holbert, Mozilla
  Koji Ishii, Google
  Brian Kardell, Igalia
  Ian Kilpatrick, Google
  Chris Lilley, W3C
  Peter Linss, Invited Expert
  Stanton Marcum, Amazon
  Myles Maxfield, Apple
  Cameron McCormack, Mozilla
  Nat McCully, Adobe
  Theresa O'Connor, Apple
  Xidorn Quan
  Manuel Rego, Igalia
  François REMY, Invited Expert
  Florian Rivoal, Invited Expert
  Cassondra Roberts, Red Hat
  Jen Simmons, Mozilla
  Alan Stearns, Adobe
  Miriam Suzanne, Invited Expert
  Lea Verou, Invited Expert

Scribe: myles

CSS Cascade

Where do "custom origins" fit into the cascade
  github: https://github.com/w3c/csswg-drafts/issues/5003

  miriam: The high level concept here is, as an author, writing
          stylesheets, we barely interact with origins in a way that
          we think about
  miriam: but, they provide an interesting balance between different
          intents that style sheets can come from. In the initial
          proposal for CSS, the browser wants there to be a good
          readable default. The user wants consistency and
          customization control. The author wants uniqueness and
  miriam: There are these 3 intents that are being balanced, and they
          are scoped to different participants in the system. As
          authors, we understand that we're getting these other
          intents as defaults, and they can override us, but since our
          author layers are right in the middle, we often don't think
          about origins specifically, or how they work in the cascade.
  miriam: And even !important which is this clever flipping of power,
          it's flattened out into higher specificity.

  miriam: This relates to how authors write their own styles. Authors
          have their own intents and will try to layer them. CSS has
          an inverted triangle with 7 layers, and tries to map them to
  miriam: You start with reset, or base styles at a low specificity,
          then you add other layers like a design system or framework,
          or themes, or components, and then overrides or states that
          might have a higher level of specificity. But it doesn't map
          perfectly to specificity
  miriam: There are good reasons to be very specific about a broad
          default. Like in UA stylesheets - there's lots of nesting to
          get specific about target defaults. That makes sense. The
          ideas don't map perfectly
  miriam: Is there a way to give authors the ability to create these
          layers for themselves. Where in the cascade does that
          happen? How does it interact with scoping? (That's a related
          issue.) We have to pull them apart. Scoping relates to
          subtrees in the dom, or specificity of selectors in the dom,
          it's dom related, where this is more "how do I layer
          different intents of a style".

  miriam: So, the biggest question here, and others tie into it, is
          where do these fit? 5003, where do custom origins fit in the
          cascade. Origins and importance? Do they nest down in
          somewhere? This relates to other issues like how they relate
          to !important and scoping or shadow dom
  miriam: Those issues come into play based on what we decide here.

  Rossen: Thank you for the great intro overview.

  miriam: 5003 was me starting to think through where it might fit. I
          propose here in the issue it could be nested under scoping,
          though TabAtkins raised a question around the use cases in a
          different issue that would contradict that. I'm not sure the
          proposal here fits every use case.
  <astearns> tab's comment:
  miriam: In this proposal, I was thinking for most of these use cases
          like a layering of a framework, a theme, design system,
          component, it wouldn't need to be at a high level. TabAtkins
          pointed out it would need to be to layer new styles over old
          styles, where you want importance to have more impact
  TabAtkins: You do not want the onion layering inner/outer thing, you
             want oldstyle normal & oldstyle !important to be
             together, then you want newstyle normal and newsytle
             !important to go together. This would require
             reinterpreting what !important means in a custom origin.
             Styles in the normal case would be imported as necessary.
             If you're in a custom origins, you get a new style place
             that's above origin. !important is a toggle in there that
             puts you in a new layer

  Rossen: Would `revert` be scoped to the origin
  miriam: It seems `revert` would be useful in this, so that's worth
  TabAtkins: My first thought, I would think we would still want
             revert to clear the entire author relation. If that's how
             it's used today, and you migrated to custom origins, it
             would be bad to have that stop and leak some old styles
  TabAtkins: Then I'm not super clear on what use cases there would be
             to clear out the styles just form one custom origin
  Rossen: I'm thinking of forced colors, overrides that are there for
          UA reasons
  Rossen: Today they revert all the way back. If we only did that in a
          custom origin, like you said, that would lead to a lot of
          weird other styles
  florian: If one of your layers is a reset, using revert to go back
           to the reset styles isn't crazy
  jensimmons: Maybe we need two different controls. One that lets you
              go back all the way, and one that lets you go back to
              just one layer
  <fantasai> +1 to jensimmons
  <dbaron> +1 to jensimmons on multiple reverts
  <AmeliaBR> +1 to Jen's comment; both use cases are valid

  fremy: I recently on twitter I was a thread with a company
         misunderstanding `revert` or `initial` and people trying to
         explain it, and it was still wrong. We need to start worrying
         about how many reverts and initial because eventually people
         are not going to understand it any more
  miriam: Authors got the idea that initial would work more like
          revert does, and were used to it before revert became
          available. Authors are using initial thinking it takes them
          to browser defaults, and it doesn't.
  TabAtkins: That's why the keyword we have, ignoring future keywords,
             should do the same it does today, so it can do the same
             thing to does today of reverting to the UA stylesheet
  florian: Today we can't determine the difference between "going back
           to the browser" and "blowing away all user styles"
  TabAtkins: It should blow away all the styles in the world of custom

  jensimmons: Avoiding complexity is a value that we hold and should
              apply, so maybe revert-foobar and that is the more
              precise tool, and just revert as we have it today blows
              everything away
  jensimmons: That makes sense to me

  florian: One question: Now we're exploring whether custom origins
           should be per origin or something in between .... is there
           a specific problem here? Why are we looking into
  <fantasai> florian++
  miriam: I wasn't here for the initial conversation, so I was going
          off the notes. There were issues raised in that thread. I
          wasn't there for that thread. It also seemed like maybe we
          could avoid the issues with importance and scoping shadow
          dom. So I was looking into that. I don't have a strong
          reason for that.
  TabAtkins: The reason why using origins might be problematic, in an
             issue by emilio: shadow dom scopes impose another level
             between specificity and origins. Right now, that's not
             too bad because there are only 2 origins today. But if we
             add more origins, we now have an interleaving of shadow
             scoping and custom origins. A linear list of things turns
             into a matrix of specificity complications, which is bad
             for both authors and implementations. This isn't fatal,
             but if we could do this below shadow dom scoping, it
             would help.
  <tantek> agreed re: specificity has been far too complex for
           authors, especially teams

  AmeliaBR: The idea of how does this interact with the cascade and
            importance. It's important to keep this as simple as
            possible. The biggest author complaint is how complex
            specificity is and importance, and how you get a lot of
            unexpected consequences and interactions. Keeping this as
            tightly contained with as few cross interactions as
            possible is important.
  AmeliaBR: Having this new origin or cascade level whatever it is,
            completely contain all of its contents so that even if
            there's an !important rule it's only more important than
            other things there, that makes sense. If you really want
            overrides, then you take a different cascade custom
            origin which is your origin for your override. We don't
            need to interact them all together.
  <jensimmons> the !important debate is on
  AmeliaBR: Just so its really explicit. Before you have this layering
            of custom origins as well, so authors are thinking about
            how these interact intentionally, let's not have
            interactions that are hard to control

  fantasai: I disagree with Amelia.
  fantasai: I think the origin layering that we have is really good,
            and the interaction we have between normal rules and
            !important having a reverse stacking effect, we do that
            for scoping right now also. For the same reasons you want
            overrides here.
  fantasai: If your problem is you want something to have more
            specificity in a layer, then solve that in that layer.
            !important is more suited for cross-origin overrides.
            If we need more control over specificity, we can add
            more control over specificity. This isn't it.
  fantasai: Interaction is useful because you can get overriding
            behavior. Many examples do need that. Like, suppose you
            have a slide show system. You'll set up a set of base
            styles as defaults, but there are some rules that make
            the system work, and those should be !important.
            That's an important feature for custom cascade origins.
  fantasai: If you think the stack as a level with its own !important
            next to it is needed, then we can consider a nesting
            structure, but the override and the inverted priority of
            !important rules is useful in the cascade and it should
            stay the same here as in other aspects of cascade.

  florian: I'm in agreement. A lot of the confusion we see about
           specificity is that people don't want specificity, they
           want custom origins. Specificity is the wrong tool there.
           And people struggle !important because they want
           specificity. We should just give them the right tools.
  <fremy> (likes what florian said, but it's tricky to get this right
          I think)
  <leaverou> Another reason specificity is confusing is that it's a
             bad heuristic. It tries to predict importance based on
             querying logic, and it's frequently wrong (with :not()
             being a common case of that)

  miriam: This is idealistic, but some idea in my mind that people can
          learn how importance and origins work from having access to
  Rossen: That's nobel.
  fantasai: I like that. I agree with florian. Specificity is
            heuristic. It doesn't always work. There are features that
            people want such as origins and scoping in the cascade. A
            lot of specificity failures seem more like needing
            controlled scoping, "The stuff local to here always wins
            over the stuff that's defined for the page as the whole".
            People try to do this with specificity but sometimes their
            rules are not strong enough to insulate, and things break.

  <TabAtkins> Proposal for this issue:

  Rossen: A lot of the conversation is around reaffirming the fact
          that we do want custom origins and we want to get them
          working. This is another confirmation based on jensimmons's
          awesome demo and talk back in the real F2F in January.
  Rossen: The actual current topic is "where do they fit?" Can we make
          some decision here?
  Rossen: We need something more concrete to play with

  jensimmons: There is a debate to be had about how !important works.
              It's ticket 4971
  jensimmons: I want to switch to 4969. Where do custom origins fit
              reminds me of a conversation I had with miriam a couple
              weeks ago
  jensimmons: (custom origins aren't my idea, I just got to present
  jensimmons: It was a conversation about 4969
  <castastrophe> https://github.com/w3c/csswg-drafts/issues/4969
  Rossen: Before we switch topics, this is going to get dumped into a
          different issue. But we have a queue. Let's flush the queue.
          I agree this is more of a umbrella feature issue rather than
          .... [missed]

  florian: TabAtkins earlier said that shadow dom is a source of
           complexity. Is there a way to recast the current shadow dom
           thing into custom origins once we have them, so we wouldn't
           need two layers, and just merge them and stop worrying
           about the interaction?
  TabAtkins: We can't reasonably recast existing shadow dom styling
             into custom origins. The interaction is "outer styles
             that get put in via ::part pseudos vs the styles that are
             defined inside the shadow root"
  TabAtkins: Given there's infinite nesting, it's not possible to
             recast in terms of custom origins

  AmeliaBR: On this topic, this issue, where do they fit in the
            cascade. We had agreement that there's a natural cascade
            when it comes to comparing with browser and user styles
            and !important, but shadow dom is the complication, and
            the other one is animations and transitions, where are
            currently defined in terms of a separate origin that
  AmeliaBR: That's another weird set of possible interactions that
            needs to really be written out and the shadow dom thing
            needs to be written out so the use cases are logical for
            shadow dom especially, there are very clear use cases of
            defaults and overrides, and these need to interact in a
            useful way.

  Rossen: These are great additions to things that need to be taken
          into account.
  Rossen: I want us to move forward and make progress on other issues.
  Rossen: we have about 20 minutes remaining here for custom origins.
  Rossen: We barely started making any progress
  Rossen: jensimmons wanted us to go to 4969
  jensimmons: Yes
  jensimmons: It's a big chunk
  <TabAtkins> Agree that we should hit the various issues to bring the
              talking points into people's heads; we shouldn't expect
              final progress on this here at this meeting.

What are the proper "levels" for managing "custom origins"?
  <Rossen> github: https://github.com/w3c/csswg-drafts/issues/4969

  jensimmons: I like thinking of this practically. Bootstrap wants to
              use this, and it makes multiple custom origins inside of
              itself. This is given off to an author. As miriam and I
              were talking through, we have nesting, bootstrap has a
              file, and many imports, each one has a level as custom
              origin, then you put that into an author project, then
              an author project has its own levels, and that has its
              own nesting. That is just a lot of complexity.
  jensimmons: Maybe instead, it could be that each origin is in a
              separate CSS file. There's not a need for particular
              properties be in one origin and others in another origin
              within the same file. The files could be in its own
              origin, or multiple files could be in the same origin.
              This could be part of the <link> element
  jensimmons: If bootstrap wants this, they would give you an HTML
              template that is a suggestion
  <astearns> If we go with this idea then using the 'sources' name
             makes even more sense

  miriam: I've gone either way in that conversation. Advantages to
          nesting are that the final user gets some final control
          while other parts of the system can still use the tools. So
          a design system or a tool like bootstrap could have its own
          internal layering and a user could subsume those layers into
          their own project. That's a use case
  miriam: It is clear that that interacts with how these would be set.
          If they are only set in HTML there is no concern for the
          nesting. They're set at the final point of import or <link>.
          If we start allowing them to be set internally somewhere,
          then we have to allow the nested use case because it would
          not be good if bootstrap could create high origins and I
          have to fight their origins and we end up in a new battle
          over control. The author needs final say
  miriam: Either they're set just there, or we have to handle the
          nested situation

  <fantasai> I think, we should think about this as all being in
             separate files for now, for simplicity. We can always add
             syntax for "embedding" such files into a document later
             once we figure everything else out. But should definitely
             be able to pull in the files through a CSS style sheet --
             this is a CSS feature, not an HTML feature.
  AmeliaBR: Which of these can be expanded on later?
  AmeliaBR: Having something that could be an attribute on <link> or
            @import or something like that, we could have that, and we
            could add an @rule later.
  AmeliaBR: I'm not sure how easy it would be the other way around.
  AmeliaBR: Another issue was about having a sensible upgrade path.
            That's related.
  AmeliaBR: How can we keep it simple to start while still adding the
            potential for new features if they turn out to be required?

  hober: I wanted to echo something florian said. Fundamentally, this
         feature adds complexity in an area which is already complex
         and confusing. My inclination is to do the simplest possible
         thing. Regarding if there should be nesting, or sections,
         etc. The simplest that is possible is what we should do here.
         I like the file-wide, the entire file is one one origin idea.
         Should we be specify at @import time, and how to do that, my
         inclination for simplicity wars with my inclination to not
         diverge <link> from @import. Those shouldn't diverge. If
         something can be part of <link> but not @import, that's a
         sign we've failed.
  hober: Where I'd like to end up is either some kind of file-wide
         declaration at the top of a style sheet and no change to any
         import mechanism, or an equivalent change to all import
         mechanisms, and no ability to declare it file-wide (only
         declared by the importer)
  <bkardell> +1 to tess' points
  <faceless2> +1 as well
  AmeliaBR: To clarify, When I was talking about @rule, I was talking
            like @supports or @media groups a bunch of declarations. I
            agree that <link> and @import should be functionally
            equivalent. That's not 100% everything in control of the
            HTML author, but we have a restriction on that saying that
            @import need to go at the top so there's a clear source
  <hober> <link rel=stylesheet>, @import(), and CSS Modules. are those
          the three import cases?

  fremy: I don't think it makes a lot of sense to put it on <link>. It
         makes more sense inside the document. All the sub origins you
         have and their order. That's different from each single file
         to add all these rules in one origin. Each CSS file should be
         able to put rules in each origin if needed. The HTML could
         add a <meta> tag to list all the origins. The stylesheet
         shouldn't define the origins. That should be in the HTML
  <fremy> <meta name="css-origins" value="reset bootstrap-reset
          some-lib-reset bootstrap-styles my-site-styles" />
  <fremy> ... then in the css @origin (bootstrap-reset) { ... }

  fantasai: If this is a CSS feature it should be possible to do in CSS
  fantasai: It should be possible to link to a stylesheet and that
            pulls in everything that's necessary for the entire
            document. Everything we do should have CSS syntax.
  fantasai: It might be possible to have segments of a single file in
            different origins. But now we should think of them all in
            separate files because we will need for that. Creating
            syntax for blocks inside a file will be easier if we
            figure it out at the file level.
  TabAtkins: First, strong agreement with fantasai. All great stuff.

  TabAtkins: Regarding simplest possible. I generally agree with
             hober. We shouldn't over-engineer this for fanciness
             sake. But it needs to handle modularity sufficiently well.
  <fantasai> +1 to Tab
  <hober> yes, TabAtkins, it definitely needs to be as complex as it
          has to be. I just don't want it to be any more complicated
          than that. :)
  TabAtkins: Say Bootstrap needs their own origins 0-6, and an author
             needs to work around that by putting code above or
             around it. But what if you're using two libraries? They
             will conflict and do something bad. Some degree of
             nesting or scoping is going to be necessary unless we
             want to repeat the z-index wars again.
  <dbaron> +1 to Tab on nesting
  TabAtkins: That will be a requirement for the final solution
  <leaverou> If two libraries colonize the same origin space, would
             there be a way for the end user (author) to order these
  <dbaron> leaverou, I think that's the feature Tab was just saying is

  miriam: It's worth remembering that in the discussion of complexity
          because flexbox is complex because people are using it to do
          grids. It's a question of "are we solving the problem." It
          seems less complex if we solve the problem

  florian: There are two aspects to nesting. 1. Once the layers are in
           the right place, do we need nesting to do something useful
           in terms of !important fighting itself or not. 2. Figuring
           out where they fit
  florian: It seems to me that we might need nesting for the second
           one but not for the first one. If bootstrap wants a bunch
           of layers, that's reasonable. The user of bootstrap doesn't
           need to know how the layers works. But we don't need
           multiple layers of !important interact with themselves and
           not with the users' code. So, in the end, you might not
           want bootstrap1, bootstrap2, etc. When someone imports
           bootstrap, they decide bootstrap is below them and they go
           on top, without having to worry about internals of bootstrap
  florian: This doesn't mean !importance of boostrap needs to be
           inside that
  florian: What we should be looking for is using nesting to figure
           out where the levels fit
  fremy: I don't like that because if bootstrap resets its styles, my
         library wants to put styles between those two, and that would
         be impossible in this idea
  <tantek> What if Bootstrap's architecture is all by itself overly
           complicated and fundamentally broken? Optimizing/solving
           for Bootstrap may be futile
  <tantek> I'd rather we make something simple that enables new
           developers to create something much easier to use that
           makes Bootstrap obsolete and abandoned.

  heycam: Responding to point about having an origin per file. I agree
          with hober and others who are saying it would be good to
          concentrate on something that's simple but extendable in the
          future if we find out we need these complications.
  heycam: But for the origin per file thing, if we're following the
          rule that we should have CSS syntax for everything we do,
          then we just need to be careful to design some syntax that
          doesn't just apply to a file at the time, but is something
          like an @rule that is self contained
  heycam: It's common for bundlers to concatenate CSS stylesheets that
          get fetched over the network. We've seen problems with that
          in the future. Something that clearly contains the rules in
          the stylesheet is recommended.
  Rossen: I agree.

  <TabAtkins> "Nesting" isn't necessarily the right concept here (that
              does imply that all the sub-layers go in one spot), but
              rather that the outer page can control where exactly a
              sub-project's layers go in the overall page's layer
  <fantasai> +1 TabAtkins
  <fantasai> TabAtkins, more specifically, I think a project should be
             able to control the stuff inside it, and the outer scope
             can't rearrange. But outer scope re-arranges everything
             it imports, with each direct import treated as atomic
             even though it may contain sub-origins
  <TabAtkins> fantasai, Yes. *Possibly* with an ability for a project
              to project its layers into reorderable groups (like
              normal vs important, or reset vs actual, like fremy
              said), but that's probably more complexity than needed
              right now.

  jensimmons: About making separate origins in separate files, if we
              don't do that, if we do allow segments of CSS in one
              file to be in different origins. Maybe we can name
              origins like variables, to explain how they act, or
              maybe it's a set of numbers, the desire to keep it as
              simple as possible is good.
  jensimmons: If we just have one origin per file, we don't have to
              solve that problem. Instead, the onus can be on solving
              this outside those CSS files
  jensimmons: What fantasai said about needing CSS syntax for all
              features is interesting though.
  jensimmons: Another thing that the frontend development world has
              adapted to create many files for keeping code organized
              and making it easier for multiple people to work on
              code. SASS has a technique that people use a lot where
              there's a main file where there's a file that lists
              other files. There's a meta file that lists the files.
              In a way that's what HTML is being used for. Perhaps we
              add something to CSS which is a manifest which describes
              other files.
  jensimmons: The other thing is if we were to say no, you have to
              have separate files, and there is no concatenation, is
              everyone using HTTP/2? Because that's the reason build
              systems concatenate things to lower the number of HTTP
              requests. Not great for performance. Unless HTTP/2 takes
              over the world
  jensimmons: florian said what I was going to say. If nesting is
              allowed, does the nesting get flattened and then
              delivered, or does it stay unflattened somehow. This is
              where the complexity for the brain-space in authors
              could get out of control. We all agree we want to avoid
  jensimmons: We don't want a system where a team of 40 people can't
              keep track of how things work because of nesting inside
              nesting inside nesting etc.

  Rossen: There's lots of progress on this issue
  miriam: I think we've covered a lot of the issues. I'd love if one
          or two people could help me flush them out from here.
  rossen: The one thing we need as a set of next steps is to write
          down some of the guiding principles that were used here, and
          use them as a guiding mechanism for designing next steps.
          Whether we're talking about how the origins or defined
          assuming they already work somehow and once this is done we
          can find how and where they interleave and interact
  <fantasai> maybe useful to draft principles into
             https://wiki.csswg.org/ideas or something
  astearns: It might be useful to have a regular meeting on custom
            origins for a while. One / month, once / fortnight
  astearns: The only topic is what the current issues are for this. So
            we can make some quicker progress.
  Rossen: Sounds good. Like the "grid task force".

<br type=5min>
Received on Friday, 15 May 2020 22:39:00 UTC

This archive was generated by hypermail 2.4.0 : Monday, 23 January 2023 02:15:14 UTC