- From: Dael Jackson <daelcss@gmail.com>
- Date: Thu, 7 Jan 2021 05:40:53 -0500
- 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 Contain & CSS Scoping
-------------------------
- There are proposals for Container Queries (
https://github.com/w3c/csswg-drafts/issues/5796 )
and Light-DOM Scope ( https://github.com/w3c/csswg-drafts/issues/5809 )
available for review prior. Everyone is encouraged to read the
proposals and engage on github.
- RESOLVED: Publish FPWD of L5 of Cascade
CSS Grid
--------
- RESOLVED: Stretch alignment doesn't disable the aspect ratio. It
can distort it if the other axis is constrained (Issue
#5713: Note implies losing an aspect-ratio when it
shouldn't?)
CSS Pseudo
----------
- RESOLVED: Add an :autofill pseudo-class to selectors (Issue #5775:
:autofill pseudo-class)
CSS Shapes
----------
- RESOLVED: Merge this PR into next level of Shapes (Issue #5674:
Allow CSS grammar for path shapes)
CSSOM
-----
- RESOLVED: Go with Emilio's naming and Sam's amendment (Issue
#5649: The way CSSStyleDeclaration exposes properties is
not ideal)
CSS should define and use consistent terminology for words like
"deprecated", "obsolete"
---------------------------------------------------------------
- RESOLVED: Close no change but open issues on spec areas where it's
not clear what the intent was for a deprecation (Issue
#5644)
CSS Overflow
------------
- RESOLVED: Add the box keywords to the overflow-clip-margin (Issue
#5801: Add box-edge values to overflow-clip-margin)
Cascade / Pseudo-elements / Values / Fragmentation
--------------------------------------------------
- RESOLVED: Color inherits according to first line inheritance.
currentColor keys off value of that fragment per
fragment (Issue #1510: currentColor when fragments have
different colors)
- RESOLVED: Have font-relative units key off the font size per
fragment (Issue #1510)
===== FULL MINUTES BELOW ======
Agenda: https://lists.w3.org/Archives/Public/www-style/2021Jan/0000.html
Present:
Rossen Atanassov
Tab Atkins-Bittner
Tantek Çelik
Hui Jing Chen
Elika Etemad
Brandon Ferrua
Simon Fraser
Mason Freed
Megan Gardner
Chris Harrelson
Daniel Holbert
Dael Jackson
Dean Jackson
Ian Kilpatrick
Ting-Yu Lin
Peter Linss
Alison Maher
Florian Rivoal
Alan Stearns
Miriam Suzanne
Scribe: dael
astearns: I think we have enough people to get going
astearns: Does anyone have any changes to the agenda?
astearns: Happy new year and thanks everyone for joining the first
meeting of 2021
astearns: I did send a message about extended virtual meetings next
month. Unless I hear differently I'll set those up at the
end of the week.
CSS Contain & CSS Scoping
=========================
5-minute intro on new Cascade Layer draft, and two issues put up for
TAG review
--------------------------------------------------------------------
Cascade 5: https://drafts.csswg.org/css-cascade-5/
Container Queries: https://github.com/w3c/csswg-drafts/issues/5796
Light-DOM Scope: https://github.com/w3c/csswg-drafts/issues/5809
miriam: The first one is adding cascade layers to cascade 5 spec. I
have a first ED of the spec up on github and would love some
review.
miriam: It links to a number of issues we can discuss, maybe at F2F.
Would love feedback to push forward
<florian> [Only briefly looked at the cascade 5 draft, and plan to
spend more time on it later, but so far so good]
miriam: Next are 2 proposals I put related to cascading. One is a
proposal pushing container queries forward and the other an
approach to scope in the light dom.
miriam: Fairly different from other scope proposals.
miriam: Both of those I would love feedback and discussion. Would
love a sense of interest and if we should keep pushing
fantasai: I propose we put cascade 5 for fpwd either this or next
week. It reflects the discussion and good to get
officially published
<fantasai> https://services.w3.org/htmldiff?doc1=https%3A%2F%2Fdrafts.csswg.org%2Fcss-cascade-4%2F&doc2=https%3A%2F%2Fdrafts.csswg.org%2Fcss-cascade-5%2F
astearns: Is it diff spec?
fantasai: It has everything. Because cascade 4 is stable didn't need
to do much
astearns: I'd be happy to do fpwd. Anyone want to wait till next
week or review or do we resolve today?
astearns: Prop: FPWD of L5 of Cascade
astearns: Objections?
RESOLVED: Publish FPWD of L5 of Cascade
<chrishtr> Congratulations!
<miriam> 🎉
astearns: Any other initial reactions to the new proposals?
florian: To the question of if she should continue pushing on this,
yes.
Rossen: We did get the scoped proposal in tag and we will be talking
about it and reviewing shortly so expect engagement and
feedback soon
miriam: Thank you
astearns: Yes, both have been put up for tag review so we should
expect to see something from tag for both
miriam: Should I also post cascade layers for tag review?
Rossen: Generally the earlier you engage with tag the better. There
are plenty of folks in both groups so having the home court
advantage we see early work. But yes, please engage with tag
once explainer is ready
fantasai: Since tag is dealing with turnover and we have a bunch of
open issues maybe we go through the issues next month and
then give to tag.
Rossen: If this is an early review or a design review it depends.
You're suggesting stable and up for review. I was suggesting
early draft review which is lighter weight and gets some
feedback
iank: Agree with Rossen that earlier is better
miriam: Okay, will work on it
astearns: Thank you for all this, miriam, this is great stuff
<Rossen> huge +1 on this being great work!! Thank you miriam & co.
CSS Grid
========
Note implies losing an aspect-ratio when it shouldn't?
------------------------------------------------------
github: https://github.com/w3c/csswg-drafts/issues/5713
fantasai: Have agreement that stretch on its own in single axis
shouldn't cause you to lose aspect ratio.
fantasai: I think we're clear on that and it's editorial. We did
have implementors doing something different
<fantasai> https://github.com/w3c/csswg-drafts/commit/f5823bc7d64106a160b5473a972bbb744f27262b
<fantasai> clarification ^
<fantasai> https://github.com/w3c/csswg-drafts/commit/93ea82e30baf4c9b887a5d60e89f90a5411e94f7
<fantasai> additional fix in css-align ^
iank: I filed this because we were looking how stretching works in a
single axis internally. Noticed all implementations of grid
throw away aspect ratio in this condition. I think a lot of
confusion was from note which is being fixed
iank: 10-15 tests in the suite which are testing the broken
behavior. I'm prepared to fix the tests but it would mean all
impl will fail the tests
iank: If we have agreement this is correct, then this is an fyi to
fix impl
dholbert: Does this make grid more like flexbox?
dholbert: More consistent or shifting?
iank: Yes, makes them more consistent. If you stretch image in one
axis the aspect-ratio is typically preserved
fantasai: I think the fix to the note is correct. Will this change
behavior for an image with no alignment but it is in a
grid? Normal in both axis. If that behavior would change
there's web compat issue
iank: Normal in both axis doesn't imply stretching so it's fine.
This is only when stretching in one axis or the other
Rossen: And stretching only?
iank: Correct. The weirdness here is that if you stretch in the
inline axis for a grid item the image was distorted. You have
to opt into this so I'm fairly sure it's web compat. But there
are a lot of tests testing the broken behavior
astearns: Would it make sense when you update tests for you to open
bugs on all engines?
iank: Depending on set up tests themselves failing might cover. Does
cover FF. But I'm happy to file bugs as well
astearns: Anyone with concerns?
fantasai: Proposal: stretch alignment doesn't disable the aspect
ratio. It can distort it if the other axis is constrained
astearns: Objections?
RESOLVED: stretch alignment doesn't disable the aspect ratio. It can
distort it if the other axis is constrained
CSS Pseudo
==========
:autofill pseudo-class
----------------------
github: https://github.com/w3c/csswg-drafts/issues/5775
astearns: This is emilio who is likely not here
tantek: Are there particular concerns?
florian: Given it exists and unlikely to be removed makes sense to
have it. I'm wondering about privacy concern of it. Content
of field isn't changed but if it is filled by a human or
something saved might have privacy considerations
fantasai: I feel there are other ways to get that information. If
all forms are filled in a second it is autofill
tantek: That does sound like a concern to raise. Sounds like :visited
florian: Yes, just thinking about it.
tantek: At a minimum I think it's excellent feedback. Maybe they can
document it as a potential privacy concern.
tantek: It would be good to get that as feedback from the WG
florian: I'll drop it in GH
fantasai: Should we resolve to add the pseudo class?
astearns: Prop: Add an :autofill pseudo class to selectors
RESOLVED: Add an :autofill pseudo-class to selectors
CSS Shapes
==========
Allow CSS grammar for path shapes
---------------------------------
github: https://github.com/w3c/csswg-drafts/issues/5674
TabAtkins: I've been looking for something like this for a while.
SVG path is a little weird. Right now you have to do path
as a string and you can't concat a string it means you
can't build path with variables
TabAtkins: User friction thing
TabAtkins: Proposal, not from me, from Noam, with good syntax
converting svg syntax to css friendly version. I really
like how it looks. Extensible to logical coordinates. I
think this is a nice good approach and I'd like to add to
spec
fantasai: I reviewed the PR and discussion and I think it's a good
proposal, well specified
dino: I left some minor comments, but don't care if they're not
addressed.
dino: If one was to animate; this was defined as equivalent to SVG
path so thus if you animate between the svg rules apply and
thus you need same number of segments with same type?
TabAtkins: Yeah
dino: Therefore a curve, if a command was curve xy via something if
one gave 2 coordinates and the other 1 they would not animate,
right?
dino: The distinction between quadratic and cubic is number of
params, not command type.
dino: Maybe a bit strange curve says where it's going first. But
again it's minor. I'll mention it, but I don't care
astearns: And one of the reasons to take the PR is so we can open
more issues to make amendments. I assume animations is not
defined in PR so we'd unpack in spec.
TabAtkins: Yeah
astearns: dino you mentioned you made comments. I saw one on PR
about typo
dino: They're all minor and can be issues after
astearns: Hearing agreement. Objections to merge this PR?
RESOLVED: Merge this PR into next level of Shapes
CSSOM
=====
The way CSSStyleDeclaration exposes properties is not ideal
-----------------------------------------------------------
github: https://github.com/w3c/csswg-drafts/issues/5649
astearns: This issue is full of Europeans. Anyone can take it?
TabAtkins: I'm happy to run it since our people are okay with it
TabAtkins: emilio points out that the way CSS style declarations
expose properties is weird. Per current CSSOM definitions
all properties and @rules are merged into same object and
they work or don't
TabAtkins: Proposal to solve is split apart interfaces for style
rules and each @rule that uses .style so they are
distinct name spaces
TabAtkins: Sounds good to me. Anders says seems fine because
exposing all @rule on every style rule seems weird as well
TabAtkins: Sorry, we resolved on overall proposal
astearns: emilio added specifics
TabAtkins: Specific proposal is add a batch of interfaces named
[reads from
https://github.com/w3c/csswg-drafts/issues/5649#issuecomment-742760748
]
<fantasai> wfm
TabAtkins: Use those as extensions of css style declarations and
they have appropriate descriptor names. Looking for
opinions on naming.
TabAtkins: I think names are fine
astearns: Anyone else have an opinion?
fantasai: Sam had an opinion to have everything else named
descriptors. That's the counter proposal. That also works
and I think slightly better
astearns: Proposal: Go with emilio naming and Sam's amendment
RESOLVED: Go with emilio naming and Sam's amendment
CSS should define and use consistent terminology for words like
"deprecated", "obsolete"
===============================================================
github: https://github.com/w3c/csswg-drafts/issues/5644
florian: Raised a while back by Mike Smith indirectly because he was
confused. Used deprecated in a few places and the meaning
has changed over time. Should we use deprecated for all the
meanings or do we be more specific
florian: Could be using as "this feature is bad idea but we have it"
or "this feature is old bad name but we're documenting it".
Or "we're documenting it but browsers are removing it". Or
in HTML "we're not specifying this feature but we're
telling you it used to exist".
florian: The first two are the ones we use. Maybe that's fine. Maybe
we should pick it to mean one.
florian: No strong opinions on which way, but this is the question
florian: Reason Mike Smith reacted is we documented as deprecated
something with an old name but he thought we meant this is
old do not use. That's where potential need to distinguish
came from
fantasai: We use in English meaning to express disapproval. If an
implementation required to have it, then that's separately
documented via RFC2119 terminology. Either must impl or
should impl. We're clear. If we discourage users that's
separate term. Deprecated is basically a value judgment
and an indication of preference from WG
fantasai: I think we're clear on what's required and what's
discouraged.
florian: As long as we keep being explicit for deprecated feature
normative requirements we're good.
florian: I'm fine closing no change, but it was raised
<tantek> should we escalate to the TAG to provide a more precise
definition of "deprecate(d)" and "obsolete(d)" for
consistent use across W3C specs?
smfr: I think it's important to distinguish recommendation for
authors and instructions for implementors. Maybe something
being obsolete should only be things in spec and deprecation
is for UAs.
florian: We do distinguish but we do with explicit text, not keywords
fantasai: We say UA must or should and users should or should not. I
don't think we use deprecated in the place of must or
should. Maybe some image angles will become obsolete.
Otherwise we use deprecated where we prefer people didn't
use it but you might have to in certain contexts because
it's out there
smfr: A clear distinction between browsers might have to impl and
authors might have to use is useful
florian: We absolutely should have that distinction. But do we do it
through terminology or through text?
fantasai: We say it's deprecated and you have to implement or and
you shouldn't implement. The conformance requirements is
expressed with RFC2119
<tantek> should we stop using those terms then?
smfr: I think better explained with examples
astearns: We do most often add text describing our intent. In cases
where it's not clear we can open issues to make that
better. But not come up with specific spec terms
astearns: I think I would rather not a specific term because
sometimes people don't follow links for meaning so it
could hide things that are in prose
astearns: Proposal: Close no change but open issues on spec areas
where it's not clear what the intent was for a deprecation
tantek: Should we discourage future use of those terms?
fantasai: When we say something must be impl but authors shouldn't
use...must be impl like system colors but this is a bad
idea so it shouldn't be in your css vocabulary
tantek: Should we discourage editors from using deprecated or
obsoleted?
fantasai: I don't think so. They have useful meanings in English
astearns: They're useful terms we're just not loading them with
anything besides standard English meaning
astearns: Objections?
RESOLVED: Close no change but open issues on spec areas where it's
not clear what the intent was for a deprecation
<tantek> no objection, though it does feel odd to use terms as
"English meaning" that are used more precisely by other
specs
CSS Overflow
============
Add box-edge values to overflow-clip-margin
-------------------------------------------
github: https://github.com/w3c/csswg-drafts/issues/5801
fantasai: A lot of confusion in chrome bug by authors that expected
border edge to a box [missed]. It has borders and radius
and it clips to the inner edge. In corner with curve it
clips to curved edge. Looks a bit weird if contents are
only replaced element. Why doesn't it clip to content edge?
fantasai: If you spec padding and borders on replaced element
because it curves the edges of the box including content
the replaced element will get a curved edge. But if you do
it on a container the contents still show.
fantasai: Frequently wanted. We have overflow clip margin that takes
a length and lets you clip a little outside the box. Could
add content-box padding-box and border-box as keywords
that sets the margin to the appropriate offset.
fantasai: That's the use case and proposal. Question is do we want
to do that?
astearns: Keywords alone or supply a length?
fantasai: Keywords alone, length, or combo
florian: Reasonable. What is implementor interest?
chrishtr: I think it's okay. Tried implement a couple months ago and
it was easy
smfr: I need more pictures, hard to understand. Insetting the inner
curved border radius by some amount?
chrishtr: Top of issue green and red; they want inner and outer
curve to match
smfr: White stripe is padding and they want that curved?
chrishtr: Yep
myles: It's possible to achieve that. This proposal is to make it
easier?
fantasai: Yeah, you'd need a wrapper element to get that otherwise.
And you'd have to match the radius correctly. You can do
it but it's awkward
smfr: Always inset not outset?
fantasai: A positive value outsets from the edge it would clip. So
you can outset or inset. Proposal here is add keywords
that match the box edge
smfr: And if you are outside child elements paint on top of border?
fantasai: Yeah
smfr: And this is ones without overflow hidden?
fantasai: You'd need to apply a clip
smfr: Also about clip path?
florian: Not clip path. Overflow
smfr: Inset the rectangle and recompute border radius that's okay.
fantasai: Just about inset and outset from border edge for overflow
property
smfr: Okay
<fantasai> https://drafts.csswg.org/css-overflow-3/#overflow-clip-margin
dholbert: It sounds like this is clipping padding separate than
clipping content?
fantasai: Currently have overflow clip margin. If we allow a
content-box value we would need to inset. It would clip
contents, not the element.
chrishtr: It already only clips content. This changes dimensions of
clip. Size and border radius
dholbert: Padding is clipped at curved border and that controls
where content is clipped
chrishtr: Padding is clipped as normal.
fantasai: By the background-clip
chrishtr: What you can already spec as different rectangles. This is
only to apply to content
Rossen: Is there any additional implications to box shadow?
fantasai: Doesn't effect. Only effects content
florian: We just talked through how it only effects normal border
box. In Backgrounds 4 we had corner shape property to cut
at an angle. Expectation is will have new corner shapes
that might make impl a bit harder.
florian: Doesn't change usefulness, but does it change the concern
on impl?
chrishtr: Does this thing let you spec the angle?
florian: Only switch from rounded to a straight diagonal line right
now. May expand to different corner shapes.
myles: Not sure there would be consensus this property you described
would grow. Used to have more values and we got rid of them.
I'd be surprised if we add a lot more
chrishtr: I would agree. It already has the need to geometrically
expand or contract without complex code. I don't think we
would spec difficult cases
florian: Cool. I was just hoping that we weren't missing a case for
complexity
fantasai: Drawing the complex border is a bigger problem then
changing the clip
astearns: I think I heard questions from each implementor
astearns: Sounds like consensus to add these keywords to
overflow-clip-margin
astearns: Concerns?
astearns: Add the box keywords to the overflow-clip-margin
astearns: Objections?
dholbert: border-box, padding-box, content-box?
fantasai: Yes
fantasai: padding-box is default
chrishtr: Can the syntax be implemented incrementally? Someone
implements lengths and add this later?
fantasai: Should be fine. As long as you don't parse the syntax you
don't implement it's good
RESOLVED: Add the box keywords to the overflow-clip-margin
Cascade / Pseudo-elements / Values / Fragmentation
==================================================
currentColor when fragments have different colors
-------------------------------------------------
github: https://github.com/w3c/csswg-drafts/issues/1510
<fantasai> https://jsfiddle.net/ehzknab5/2/
fantasai: Bunch of properties that can take currentColor. The
rendering in FF that's screen-shotted is outdated. If you
load newer FF all properties are correctly handled
fantasai: Seems to be what author expect. Implemented by one
browser. I'd like to resolve that's how it's done
astearns: Different opinions?
astearns: I'd rather not resolve on "do what is says in the issue".
Summary?
fantasai: Proposal: color inherits according to first line
inheritance. currentColor keys off value of that fragment
per fragment
astearns: Concerns? Objections?
RESOLVED: Color inherits according to first line inheritance.
currentColor keys off value of that fragment per fragment
<fantasai> https://github.com/w3c/csswg-drafts/issues/1510#issuecomment-689042237
fantasai: Related is for fonts which is comment from oriol ^
fantasai: If first and third line match it's implemented by that rule
astearns: Second is do the same thing for font relative units?
fantasai: Yes, key off font size per element
astearns: Objections?
RESOLVED: Have font-relative units key off the font size per fragment
myles: First letters are big. If you use em you get the big size for
that element
fantasai: This is first-line. It's the innermost element. There are
issues around that and I think they're filed. But it's a
separate kind of mechanism than first-line
astearns: We're at time. Should we walk back resolution, myles?
myles: No, we can continue
astearns: Thanks everybody for calling in and we'll talk next week
Received on Thursday, 7 January 2021 10:41:38 UTC