- From: Dael Jackson <daelcss@gmail.com>
- Date: Wed, 13 May 2020 19:32:39 -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.
=========================================
Publications
------------
- RESOLVED: Publish updated WD of position-3
- RESOLVED: Publish new CR of display-3
- RESOLVED: Publish a FPWD of sizing-4
- RESOLVED: Close issue #333 (Aspect Ratio) as fixed [it is a part
of sizing-4]
CSS Cascade
-----------
- The migration path for custom origins (Issue #4985) can't be
finalized until there's a more complete proposal.
- It's important to have a migration path so that authors can
use this before every browser supports it.
- Having a way to query support will be important for authors.
- Polyfills may be the path forward, but it depends on where the
custom origins fall in specificity.
- RESOLVED: Call these "cascade layers" (Issue #4981: Better name
for "custom origins"?)
- The final design for issue #4971 (How do custom origins interact
with `!important`?) will need to wait until the definition is
more fleshed out.
- There was interest in using this as a chance to re-think how
to handle the use cases currently addressed by !important to
see if there's a different way it can be done which is more
inline with the cascade layers approach.
CSS Syntax
----------
- RESOLVED: Close no change, this is an intended difference (Issue
#4126: Input stream processing can calculate wrong
encoding)
CSS Ruby
--------
- RESOLVED: Rename collapse value [of ruby-merge] to merge (Issue
#5005: Rename ruby-merge: collapse to ruby-merge: merge)
===== FULL MINUTES BELOW ======
Agenda: https://lists.w3.org/Archives/Public/www-style/2020May/0007.html
Present:
Rachel Andrew
Rossen Atanassov
Tab Atkins
David Baron
Amelia Bellamy-Royds
Oriol Brufau
Emilio Cobos Álvarez
Dave Cramer
Elika Etemad
Simon Fraser
Megan Gardner
Daniel Holbert
Dael Jackson
Peter Linss
Myles Maxfield
Nigel Megitt
François Remy
Florian Rivoal
Jen Simmons
Miriam Suzanne
Scribe: dael
astearns: We've got enough to get started
astearns: There was a request to move MQ topics to the end
astearns: Any other agenda changes?
Publications
============
Position-3
----------
astearns: TabAtkins and fantasai have prepared a bunch of drafts
astearns: First is a WD of position-3 which has been re-written
astearns: Objections?
Rossen: Go for it
RESOLVED: Publish updated WD of position-3
Display-3
---------
astearns: They would like to update CR of display-3
astearns: Looks mostly editorial.
fantasai: Really just a clarification and shifting/improving
glossary definitions. Pulling content from css 2.1 into
display and shifting some out to position
astearns: Glanced at changes and didn't see anything about text
being shifted out. Is it mentioned?
fantasai: I think I grouped that in
astearns: Stuff added from CSS 2 is just editorial shifting from
draft to draft?
<fantasai> " Improved/moved glossary definitions relating to
absolute positioning. "
<fantasai> " Merged in additional prose from [CSS2] into the
definition of containing block. "
fantasai: Yes, this ^ pointers in CSS 2 so containing block
definition is in L3
Rossen: Were there any changes to fixed positioning?
fantasai: We did not make any changes to fixedpos or abspos in
display
fantasai: Re-wrote sticky but shouldn't be a normative impact.
Sizing and margin calc rules we left in the old as a
duplicate so people can check and we'll remove it in the
future. Intention was no change, we did add some new terms
which makes it easier for specs to hook in; absolute and
fixed position containing blocks.
fantasai: No intended normative change, there needs to be review
that hopefully we didn't break
astearns: Since this is CR, Rossen do you want more time to look?
fantasai: Those are to position. The CR we removed abspos
definition. Otherwise minor clarifications
Rossen: I was mostly asking for clarification on sticky b/c that was
the most different section compared to 2.1 in positioning. I
started reading it and it was changed significantly.
Rossen: That's fine.
Rossen: I don't have problems with display CR
fantasai: We re-wrote draft with different approach to defining. New
definition relies less on arbitrary rules and more on
conceptual definition and geometry. All text in
positioning has changed more or less. Hopefully easier to
understand and do things that make sense since it's higher
level.
Rossen: Looks great.
astearns: Point in question is if we'll update CR for display-3
Rossen: Back to your question I was fine with display CR. My
questions are on position.
astearns: Other opinions?
astearns: Objections?
RESOLVED: Publish new CR of display-3
fantasai: Question- I think this is editorial and I think that's a
different publication process.
astearns: Do we have staff on the call at the moment?
TabAtkins: I think we need to publish both, wait to get into
shepherd, and publish again
astearns: Start a thread with staff on private and try to get it
through editorial process with their help
nigel: Question on publication. This CR points to an ED for abspos
and you want to publish as a WD. I wonder if it's clearer for
wide world to wait until you're in CR for abspos
fantasai: We're nowhere near. There is cross linking and the extent
of display relying on positioning is just for definitions.
Display is in CR with minor editorial fixes
astearns: And if we have to move Display to PR before positioning is
CR we can change the links to CSS 2.1 without issues
nigel: That gets to my question, thanks
Sizing-4
--------
astearns: Last is FPWD of sizing-4
<TabAtkins> https://drafts.csswg.org/css-sizing-4/#changes
fantasai: Things in are definition of aspect ratio (issue #333). I
suggest we resolve that. Definition of
contain-intrinsic-size. Definition for stretch,
fit-content, and contain. Contain we decided to add and
stretch and fit-content were moved from L3. Contain we
added during grid where it tries to respect aspect ratio.
Useful but shouldn't be default so we decided not to add a
keyword.
fantasai: It's a diff spec, nothing is copied over
astearns: Do you want to resolve on aspect ratio before we do FPWD?
fantasai: No preference
astearns: Let's publish. Obj to FPWD of sizing-4?
RESOLVED: Publish a FPWD of sizing-4
astearns: Do you want to put the aspect ratio on agenda for upcoming
meeting? Or need resolve now?
fantasai: If we're publishing FPWD I think that means we're
resolving to have it
astearns: Oh, so given we're publishing, objections to close as
fixed?
RESOLVED: Close #333 as fixed
astearns: Other publishing topics?
CSS Cascade
===========
What is the migration path for custom origins?
----------------------------------------------
github: https://github.com/w3c/csswg-drafts/issues/4985
miriam: Based on conversation last time some of these issues maybe
should be handled with bigger questions. Some discussion of
TF or community group.
miriam: First one stands out as something we could get feedback on
miriam: If we're updating cascade how are they handled in terms of
migration path.
miriam: Issue explained by florian well. If syntax is ignorable it's
bad but hiding rules from old browsers they'll miss code
miriam: No solution in mind. Playing around I can mimic rough
behavior using custom properties. Don't know if it gets us
anywhere, but interesting I could mimic
miriam: Open to discussion on this
myles: What did custom properties do?
miriam: Create a stack of custom properties with fallback values.
Each of those acts as a level of cascade so I can decide at
which point in fallback stack I make a change. Anything more
forward in the stack overrides anything further down. Allows
me to pass in information from different intents I set up
miriam: I do use them in other ways we talked about for custom
cascades.
<AmeliaBR> `var(--overridecolor, var(--themecolor,
var(--defaultcolor)))`
astearns: florian since you just joined any feedback?
florian: I'll read offline and feedback later
AmeliaBR: miriam was introducing question on the migration path for
custom origins and authors being about to write
stylesheets that make sense in browsers that do and don't
support.
AmeliaBR: miriam had said it is both bad if old browsers treat
declarations as normal and bad if they ignore the
declarations (quoting florian) Agree both are true if
they're required, but one solution is to make sure both
things are available in that authors can write their code
in a way so that things would fallback to be regular css
cascade or write code so if custom origins not supported
it's ignored
astearns: If we design such that old browsers can read but not have
custom origins than we can do it and put things in
@supports if want ignore in older
AmeliaBR: We'd need a way of doing an @supports rule that has that
option if you don't understand don't use but also have a
way that the syntax doesn't get blocked off as
unrecognized/invalid. The options gives authors
flexibility about how initial behavior is and interacts
with a polyfill that uses classes to create same effect
florian: One worry is if there's a syntax that lets browser ignore
and apply as if not custom origin this is fragile depending
on who ships first. If dominant market doesn't ship there's
a change people will put it in there and have it not work
and than it'll be that we can't update. Not working may
require polyfills because requires authors to be careful.
myles: Another strategy is JS. It could work.
fantasai: I think either way good to have @supports so people can
figure out way to handle lack of support
fremy: It could work in JS, but in JS when all stylesheets loaded
you look at all css rules, count IDs, and append :not()s with
IDs. you can know in JS make IDs in a selector so you can
create an origin that way
florian: Thing with @supports is we have to use it as exists today
and if we introduce a new @supports you have to wait for
that. Depends on how proposal works out. Maybe a property
to order and you test the property
fantasai: I think we should have a more solid proposal first. Have
some kind of @supports but anything beyond it's not worth
discussing in the abstract. I think this is a major
feature so I don't think we should try best for backwards,
we should try our best to make this as good as possible
and than create fallback
<jensimmons> +1 to what fantasai just said
<fremy> I agree, polyfills are possible, I am not worried, so +1 to
fantasai
miriam: Polyfills rely on this falling between existing origins and
specificity. It's a bit harder if they interact with
existing origins to polyfill.
astearns: Sounds like we keep this open and in consideration as we
work on the feature and than answer once there's a more
solid proposal.
miriam: sgtm.
miriam: Same true of other agenda items
astearns: Introduce them or skip?
miriam: Either
astearns: Why don't you introduce?
Better name for "custom origins"?
---------------------------------
github: https://github.com/w3c/csswg-drafts/issues/4981
miriam: Term origin has a meaning. If this is falling anywhere
different or interacts in a different way it maybe deserves
a name without that meaning.
miriam: Some discussion. Proposal for "scope" but that's loaded.
Playing with "layers" or "intents" but don't know if there's
one that stands out.
TabAtkins: I favor "cascade layers". Distinguishes but gives right
idea
jensimmons: Talking with other folks the word layer is good. Invokes
photoshop for some authors and way it's used in graphic
design. Layer speaks for itself, it's a good word to
have in there
<jensimmons> cascade layers is :)
fantasai: How about we call them cascade layers and if we have a
better idea in the future we file an issue
miriam: Like that
AmeliaBR: Interest in expanding so existing things in spec as
origins are also cascade layers? Same argument that origin
has other meanings.
fantasai: I am cautiously in favor. Have to see how this shakes out,
but if similar mechanism we should rename. If they're
different we have to rethink.
astearns: I think it would be cool if we could redefine things in
terms of this. I don't think we should take that as a
design constraint. Nice if but not a requirement
fantasai: Yeah. Switch to cascade layers and once we figure out the
proposal more if it makes sense to combine we rename
origins
astearns: Hearing consensus on cascade layers. Anyone opposed?
RESOLVED: Call these "cascade layers"
How do custom origins interact with `!important`?
-------------------------------------------------
github: https://github.com/w3c/csswg-drafts/issues/4971
miriam: Touched on this at F2F
miriam: This ties in closely with question of where cascade layers
fit in cascade. Interact with origins or some layer below.
miriam: Question is how for normal in !important styles work in
these layers. Intertwine in a way that single layer contains
both normal and important styles so normal and important can
overrider a different layer. My sense was no, but it would
help with some use cases like new styles overriding old
miriam: Other is all important override all normal styles and you
get 2 layers for each custom cascade and then need to answer
if they reverse
miriam: Alternative is it's somewhat customizable and you can
determine which of these you want
fantasai: Definite use cases for inverted order that we have. This
is the way scoped styles work. There is a layer in between
normal and !important which is animation layer. If someone
needs a second layer they can have another custom layer
and don't need !important. Specificity problems should be
addressed directly. Reverse order important should be what
we do. Only strong use case is I have old styles I want to
be lower.
miriam: Sense is with any of these if you can create custom origins
you should be able to create any outcome from layering as
needed.
miriam: Changes ordering of layers
TabAtkins: I have an alternative. fantasai explanation is good in
many, but an independent library you don't want its
!important to leak out and overrider. Alternative is
within a cascade layer there are no !important. We ignore
or syntax error and that way we don't answer this. You
just make a higher level if you want a higher level
fantasai: I don't think that quite works.
fantasai: You as a library don't control the ordering of layers.
That's dependent on how things are imports and master doc.
Reasonable for something to express these are my styles
and these rules need to exist or it breaks. That would go
into an !important layer.
fantasai: I don't think that works super well if you have to create
layers and importer has to know the order. We have a
mechanism for !important. If a library is using it for not
important things that's bad on the library
TabAtkins: Your model is outer page is direct controller?
fantasai: I think it's possible for things to pull through multiple
levels. All levels should have idea that if something is
!important it's because it will be broken if I don't have
it.
TabAtkins: Common practice for !important is not the best thing here.
fantasai: People doing it wrong are already making broken stuff.
Example is !important is overriding animations already.
TabAtkins: Seems to be one of the largest bits there.
Distinguishable from saying layers with no importance is
anyone using cascade layers couldn't override animation.
How important is that?
florian: Reversing your argument if people want multi layer in
library to override they should create layers and
!important is to go on top of the rest.
jensimmons: You took conversation to where I was going. One of the
underlying debates is how much do we design this new
thing to be the best idea of a new thing or how much to
design to deal with how authors think they understand
origins and cascade and !important.
jensimmons: We could decide to design an API to match author current
understanding and doesn't require them to re-learn.
<florian> +1 to jensimmons
jensimmons: But I think we should believe that authors will learn
and we can teach. It will be a breath of fresh air and
people will be okay. The story will be clear. This was
old cascade, this is new, and here's a new meaning. I
think it will be fine.
jensimmons: We shouldn't worry and think about if we can jump 10
years ahead when authors know what they're doing, what
is the ideal.
<fantasai> jensimmons++
jensimmons: In this moment debating if !important should go on top.
It could be useful to them. I think think this is a big
enough change that it will lead to a new understanding.
dbaron: I wanted to throw an idea out. TabAtkins was talking about
what would happen if we didn't have !important. Some
discussion about what people would do to get it. One answer
is custom origins could let you do what !important does
today in a different way. You can say these rules are where
!important use to be in the old way.
<jensimmons> I agree with dbaron — and want to say it's super
interesting to think about not having !important
anymore. (sort of). Or doubling down on it & making it
work still....
florian: Depends on specific of proposal. What I find hard to do is
in world where you set !important you don't know how many
layers there will be because you haven't been placed.
Beauty of the model is where ever you end up your
!important is on the other side
fantasai: We have inverted order for scoped style so being
consistent is good because it helps reinforce. We have it
for origins and scoping, we should have it for layers.
myles: Wonder if you could use TabAtkins idea of no !important
allowed if we allow negative orderings so if you're in L3 you
can also control level -3 and put things there. Allows both
worlds
florian: Put rules in negative of self or negative whatever you
choose?
myles: Former
florian: How different from !important?
myles: From impl pov it's a collection of layers. It has simplicity
I assume TabAtkins looking for
astearns: Building on myles's idea instead of having ! mean invert
we can have explicit teachable syntax that says where ever
this layer goes the rule is in the inverse. We can come up
with something better than !important syntax
jensimmons: Makes me think it's hard to answer this until we have
other answers like is there nesting rules, how are they
layers declared- list or numbers or link tag? What's the
other parts. Then do we need !important?
jensimmons: I think the idea of getting rid of it is fascinating. Or
we realize that to keep things simple we need it.
jensimmons: I think people will need a way to do use case of
!important. Override animation or shift bootstrap 17
under but a couple you need above.
jensimmons: Maybe we need it going forward but not in !important
syntax. Hard to know without knowing how other part looks
miriam: I agree there's a need to escape your layer. That's a strong
use case to say this one style is required for this to work
so you have to go to extra effort to override it which is
what !important is for.
astearns: Not hearing consensus, I suggest we keep this open and
work on a syntax where we can have examples and try out
the use cases in a syntax.
astearns: Sound alight?
<fantasai> wfm
TabAtkins: Yep
jensimmons: Great discussion; fascinating.
<miriam> very, thank you all!
astearns: Yep, cool stuff. Great this is being considered.
astearns: Anything else on cascade layers?
<fantasai> +1 to miriam's use case
CSS Syntax
==========
Input stream processing can calculate wrong encoding
----------------------------------------------------
github: https://github.com/w3c/csswg-drafts/issues/4126
TabAtkins: If you recall several years ago when first discuss syntax
and character encoding in stylesheets vs css 2 we went
really simple. Only recognize a couple
TabAtkins: Purposefully match HTML closely. If you have a bite order
it's utf8 no matter the character set.
TabAtkins: Someone brought up there's a few tests in 2.1 that depend
on older 2.1 encoding detection which respect charset.
TabAtkins: Wondering if intentional.
TabAtkins: As far as I or reporter can tell no one has reported
issues on this.
TabAtkins: Keeping number of unit charset detection heuristics to a
min is good
TabAtkins: I suggest we keep current syntax and close as working as
intended
AmeliaBR: Modify tests and keep spec?
TabAtkins: Modify or drop the tests. I don't think there in the WPT
suite. Something should be done with the tests.
astearns: I have not read through original post, do you think
original poster will be satisfied with close no change?
TabAtkins: I think they will be. Mentioned they have no run into
anyone trying for it, ran into it by running test suite.
It's a little hard to activate. You have to use specific
characters at beginning of document that have right
bites. Technically possible, but not likely.
TabAtkins: I think it's mostly this test suite fails and according
to spec something should be different. Did we intend
this? And answer is yes we did
astearns: Proposal: Close no change, this is an intended difference
astearns: Objections?
RESOLVED: Close no change, this is an intended difference
astearns: Would like a needs test on this to validate in test suite
CSS Ruby
========
Rename ruby-merge: collapse to ruby-merge: merge
------------------------------------------------
github: https://github.com/w3c/csswg-drafts/issues/5004
fantasai: Rename collapse value of ruby-merge to merge. Can we
resolve?
<fantasai> https://www.w3.org/TR/css-ruby-1/#collapsed-ruby
florian: Not implemented?
fantasai: Not that I know of
florian: In favor
fantasai: I don't care
astearns: We can resolve because no one cares
astearns: Objections to rename ruby-merge: collapse to ruby-merge:
merge
<fantasai> ruby-merge: separate | collapse | auto
<fantasai> collapse -> merge
myles: Request that editor adds pictures to this section of spec
fantasai: Fair
RESOLVED: rename collapse value to merge
astearns: Talk to everyone next week
Received on Wednesday, 13 May 2020 23:33:27 UTC