- From: Dael Jackson <daelcss@gmail.com>
- Date: Fri, 15 May 2020 18:38:12 -0400
- 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
out.
- 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).
===== FULL MINUTES BELOW ======
Agenda: https://wiki.csswg.org/planning/virtual-spring-2020#day-two-time-slot-b
Present:
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
branding
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
specificity
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:
https://github.com/w3c/csswg-drafts/issues/4981#issuecomment-621975440
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
asking.
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
around.
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
origins
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
alternatives?
<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
https://github.com/w3c/csswg-drafts/issues/4971
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
it
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:
https://github.com/w3c/csswg-drafts/issues/4981#issuecomment-622090790
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
them)
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
overrides
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
order.
<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
itself.
<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
origins?
<dbaron> leaverou, I think that's the feature Tab was just saying is
essential
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
stack.
<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