- From: Dael Jackson <daelcss@gmail.com>
- Date: Thu, 7 Apr 2022 05:55:15 -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 Contain
-----------
- RESOLVED: Require the container name in the shorthand syntax (Issue
#7142: container :/ size)
CSS Content
-----------
- RESOLVED: 'none' does not compute to 'normal' (Issue #6503:
Implementing content:none on elements is not
web-compatible)
CSS Images & Overflow
---------------------
- RESOLVED: Add this path forward to the spec with a note linking
back to this issue (Issue #7144: How do object-overflow
and object-view-box interact with overflow and
overflow-clip-margin?)
- A use counter will be added to track the current usage of
overflow:visible on replaced elements. If the use counter comes
back with data this might be a breaking change the group will
revert the above resolution and go back to exploring a separate
property to have this behavior.
- The spec text written for the above resolution will need to add
details for handling of overflow-x and overflow-y
CSS UI
------
- RESOLVED: Add a URL parameter-specific version of image-set
function to the cursor property (Issue #5831: Should the
cursor property support image-set()?)
CSS Cascade
-----------
- RESOLVED: Close no change (Issue #7083: Should 'revert' really
treat animation origin as author origin?)
- RESOLVED: Specify what browsers currently do (Issue #7054: revert/
revert-layer with logical properties)
===== FULL MINUTES BELOW ======
Agenda: https://lists.w3.org/Archives/Public/www-style/2022Apr/0000.html
Present:
David Baron
Oriol Brufau
Elika Etemad
Simon Fraser
Megan Gardner
Chris Harrelson
Daniel Holbert
Dael Jackson
Ian Kilpatrick
Vladimir Levin
Peter Linss
Alison Maher
Cameron McCormack
Florian Rivoal
Alan Stearns
Miriam Suzanne
Regrets:
Tab Atkins Bittner
Delan Azabani
Jonathan Kew
Scribe: dael
astearns: Announcement- We are going to have a physical TPAC with
hybrid meetings
astearns: W3C management made the decision today they are going to
hold the physical meeting. Working with A/V contractors for
better cameras and mics for the event and to get good
ventilation
astearns: Agenda-wise we'll skip item 4
astearns: Got a request to move item 6, but I don't see Chris yet.
We'll move up to #3 unless someone else can take
astearns: Okay, let's put it as item 3
astearns: Other changes?
CSS Contain
===========
container :/ size
-----------------
github: https://github.com/w3c/csswg-drafts/issues/7142
miriam: Since last week the spec is now up to date with current state
of all the syntax changes
miriam: Only thing missing from ED is CSSOM resolutions. All syntax
is up to date which should help with this conversation
miriam: Sebastian pointed out in thread currently it allows the
shorthand syntax for container which takes name and
type...currently both are optional meaning it could be empty
as well as original issue where if only a type have to start
with a /
miriam: Proposal here is we could require a container name in the
shorthand
miriam: since we are right now container type of style is default on
every element and heavily encourage names. If you just need a
type you can use the longhand
miriam: That's the proposal. Open for questions
astearns: If I recall correctly have plenty of places where
shorthands cannot express every possible value longhands
can do
miriam: And you could express it, but have to explicitly use 'none'
in name of syntax
astearns: Proposal: Require the container name in the shorthand syntax
miriam: Right
astearns: Any concerns?
astearns: Objections?
RESOLVED: Require the container name in the shorthand syntax
CSS Content
===========
Implementing content:none on elements is not web-compatible
-----------------------------------------------------------
github: https://github.com/w3c/csswg-drafts/issues/6503
dholbert: Basically we arrived at a point where wondering if
content:none and normal should be 2 values as computed
style or if it should be alias
dholbert: Seems everyone impl as 2 values. I think that's new
information
dholbert: I think we want to stick with that unless reason to change
dholbert: Some subtlety around how none resolves to normal and
browsers disagree a bit but I think it's mostly known bugs.
dholbert: I think this issue is no change, but not 100% sure. oriol
has done more investigation and left useful comments.
Curious his thoughts
oriol: The thing is that in Blink while content:none and normal are
different computed values you cannot observe it from webpages.
One resolves to the other. Possible this could change. When I
impl none I didn't want to risk compat but I didn't try.
oriol: In WK there's a recent change from Jan where if set
content:none gCS provides none. Otherwise get normal. So get
different in WK and they didn't have to revert so seems it's
web compat
oriol: I think FF implemented and that's web exposed. So maybe can
consider different and say resolve to themselves
florian: I think historically the 2 main contexts were regular
elements where content:none did nothing and before and after
pseudo where "normal" was empty. marker forces difference
where normal isn't empty but none is.
florian: From there I think should try for as distinct as we can. If
we have compat issues we can do to the extent required but
should keep separate by default
astearns: dholbert you suggested close no change?
dholbert: I had forgotten what oriol mentioned. I tend to think we
should wait to see how the WK change survives. If they can
keep as distinct in gCS that's the simplest and I'm sure
easy change for Gecko and Blink
dholbert: Potentially resolve in favor of that but might be premature
since WK has recently shipped so I don't know how much
exposure it has got
<florian> [seems reasonable to me]
astearns: Make no resolution and leave issue open for now?
dholbert: Yeah. Might re-agenda+ for another question. I think
original request to make them compute to same I think have
decided we don't need to. now question of if we can keep
them distinct
dholbert: I can add a summary on the issue
astearns: Could resolve we're not going to have them compute to each
other
dholbert: Happy on that since it matches existing impl
astearns: Proposal: none does not compute to normal
astearns: Will leave issue open with summary from dholbert on what we
need to see with time
astearns: Objections?
RESOLVED: 'none' does not compute to 'normal'
CSS Images & Overflow
=====================
How do object-overflow and object-view-box interact with overflow
and overflow-clip-margin?
-----------------------------------------------------------------
github: https://github.com/w3c/csswg-drafts/issues/7144
khushal: Supporting css overflow and overflow clip
khushal: All replaced elements clip to content box by default. Each
except SVG don't support overflow. When overflow is on SVG
it diverts
khushal: SVG clips to content box and we don't support properties
that make it scrollable
khushal: Discussion on issue toward supporting overflow for all
replaced elements similar to SVG. All values supported
except those that make it scrollable
khushal: Ways in clipping diverges instead of doing the behavior in
engine retail with UI css. Because it's in UI CSS devs can
override
khushal: Want to mention that we brought up this question with
overflow for replaced elements and talked about adding
object-overflow to permit
khushal: In trying to explain interaction with overflow we realized
it was easier to do similar so we can remove this property
from the spec
smfr: Sounds like in proposal that you're allowing author to set
overflow:visible on replaced element. Is that true?
khushal: If a website had overflow:visible today and defaulted to
clip, it would now apply and cause visible
smfr: Seems like could be compat issue
khushal: Did come up that it might break backwards compat. Applying
this property on existing page wouldn't have worked and does
now. Could try and get use counter for how often it's used
to confirm compat isk is minimal
smfr: 2nd question is UA applies overflow:hidden. Does that allow
scripts to programmatically scroll?
khushal: That's a way replaced elements have behaved differently.
Script won't be able to
smfr: Should UA stylesheet use overflow:clip?
khushal: Yes, you're right
smfr: Thought I saw issue on iframes. Is this proposed for that?
khushal: Another issue about which elements to limit this. Security
reasons for iframes so could make it !important so devs
can't override for something like iframe
smfr: When a replaced element has overflow because overflow:visible,
ink or layout?
khushal: ink overflow
smfr: Different to overflow on normal element, right?
khushal: Right. Had discussed for object overflow that overflow for
replaced should be considered ink
smfr: I think because list of issues I'm not a big fan, but want to
hear others
<iank> is it enough to support just overflow:clip & overflow:visible ?
<smfr> what about overflow-x & overflow-y?
florian: I overlap with some of smfr. You said all values except
scroll. but all of overflow other than visible and clip
support scrolling
florian: You talked about UA using overflow:clip, but it said in
issue if author did overflow:scroll it was like hidden but
hidden is scrollable.
khushal: It should say clip. Anything that defines scroll maps to
clip for replaced elements
astearns: And for values of overflow that are not clip or visible do
we want them to work and make a scrollable thing or should
they all function as overflow:clip
khushal: Later. All overflow:clip for replaced elements
astearns: So they only get clip and visible
khushal: Right. Either clipped or visible
astearns: Question on IRC about overflow-x and -y. If we set -x are
things visible in -y?
khushal: I think it's reasonable for overflow clip and visible to be
different in x or y direction
khushal: I'm interpreting if you set overflow-x:clip and -y:visible
it will clip in x and not y
<iank> I think part of the question is if you do overflow-y: scroll
for example
florian: Yeah, I don't see why different for this
smfr: Yeah, sounds okay
astearns: Other questions or concerns?
iank: I think part or a question that needs to be answers if you set
overflow-y:scroll what happens
iank: There's various fixup today
florian: I guess either you first fixup the other dimension to be a
scrolling value and then they both become clip or you coerce
scrolling to slip immediately and other remains visible
chrishtr: 3rd alternative could be ignore values other than visible
and clip. Can set but don't do anything. Compute to visible
chrishtr: May be less confusing than apply some behavior but not all.
It would clip but not scroll and might not know why
astearns: Use counter suggested for overflow:visible. If we want that
need a use counter for all the other values on replaced
elements
chrishtr: Then alternative is we could go with new css property to
avoid the concerns. Does seem behaviors are similar to SVG?
iank: chrishtr if I understand correct and we just do visible and
clip are there compat concerns since clip hasn't been out long
chrishtr: Good point. Coerce hidden and scroll to visible then it's
only sites with overflow clip
smfr: Isn't compat issue overflow:visible?
vmpstr: Right, it's the other side
smfr: And object:fit would leak pixels
khushal: I think it's something like object:position that would leak
smfr: aspect-ratio resize version of object:fit doesn't that cause
bits of image to leak and if it's overflow:visible it adds ink
overflow
khushal: Right. If dev used overflow:visible and object-fit:cover
they would get slipping now but overflow visible would start
after this
florian: Back to visible in 1d and scroll in the other...I suspect
doesn't matter for use case because you can get one behavior
so for impl PoV seems easier to add conflict resolution as
is. Visible in 1 and scroll in other leads to visible
dimension hidden and now both behave as clip
florian: Suggest to me we don't need to change style computation pass
khushal: 2 issues. First how to deal with overflow in x and y
direction being different. If 1d says visible and other
scroll we coerce to scroll and then clip
khushal: Second is if it's set to visible in both directions where
previously ignored and now visible. Is there a way to check
or is this a deal breaker
florian: Need use counter. If it's a lot it's a deal breaker but if
it's rare maybe not a problem
smfr: Do we know if reset stylesheets set overflow:visible
iank: I don't think it's common. Might be wrong
fantasai: I want to bring up opinion from TabAtkins in thread.
Overflow as a property currently clips to padding edge.
Type of clipping we're looking at is content box. Replaced
elements are special magic or do we need 2 properties?
fantasai: oriol mentioned 7188 with a use case for clipping replaced
elements to padding box. Haven't looked in detail but worth
considering before we decide to merge to 1 prop
<fantasai> https://github.com/w3c/csswg-drafts/issues/7188
khushal: Suggestion on issue for changing ref box is UI CSS rule. The
discussion on issue was toward if start allowing overflow on
replaced elements makes sense for overflow to work as well.
Idea was default behavior is done with existing properties
and devs can change
fantasai: Okay
<florian> that makes sense to me
<heycam> wonder if it would be difficult to make the use counter
check for overflow:visible only if there's ink overflow
astearns: [reads IRC from heycam]
astearns: I think use counter is of overflow:visible is set on
replaced elements at all. If it is can evaluate usage to
see if introducing ink overflow is going to be unacceptable
change
heycam: Just looking to see if can skip manual step to check influence
astearns: Before we collect use counter, say the use counter gives it
as very rare. Would anyone continue to have a problem with
this change? Is it worth the use counter?
smfr: Need use counter data because would be compat. If use counter
data is okay I'm okay with it
astearns: Use counter seems like the next step. Given the details
about various values and which replaced elements this
impacts and overflow-x and -y and writing all that down.
Once we have use counter data we can come back
chrishtr: So accept pending use counter?
astearns: Resolution is collect data and wait to resolve until it's
analyzed
fantasai: With a bias toward accepting if use counter says it's okay
chrishtr: I think reasonable in my opinion to accept change and if
use counter says otherwise we revert
plinss: Quick point on use counter data. I think if use counter shows
a lot of usage it's easy to say no. If use counter shows
little usage that doesn't mean it's clear. Could be a lot of
data behind something like corporate firewalls. If use
counter is extremely low fine, but if use count is marginal
might be breaking more than we think
astearns: As far as accept change for now and revert I do like having
spec text as opposed to a summary
chrishtr: I would point out failure is showing more ink overflow
which is not that bad
astearns: But could obscure content. Making things unreadable that
used to be readable is something we have to avoid
fantasai: Example from smfr about cover image that is visible outside
of img element suddenly could be significant data loss. If
we do find significant use. Currently doesn't have effect
but if someone used overlay-general selectors could have
effect
florian: I think use counters are in engine so could get behind
corporate firewalls, but wouldn't get offweb usage like epub.
iank: Not necessarily. Depends on if org has opted into metrics
collection. Orgs typically do opt out
iank: Other point is we do have some use counter blindness. I don't
think will be case for this. Corps tend to use frameworks so if
we see something on public likely to see it in the blindspot as
well. Fair bit of correlation for these rendering changes
<fantasai> +1 to iank, unlikely to find this problem on intranets if
open web doesn't show the problem
smfr: I think might be first time we allow contents to overlap
border. Makes me wonder if we spec the paint order
fantasai: Same as other elements
smfr: So paint on top of borders?
khushal: Was going to add SVG allows overflow today and I think they
draw on top of border
smfr: Okay
iank: So replaced elements paint in content phase?
astearns: We have spec a content phase in painting?
<fantasai> CSS2 appendix E
<fantasai> https://www.w3.org/TR/2011/REC-CSS2-20110607/zindex.html#q23.0
<fantasai> The painting order of border vs replaced content is
already defined
khushal: Another question - earlier resolved having new behavior
thought object overflow which is new property where if set
to visible only contents of replaced element can overflow.
khushal: If we do see use counter usage is high enough that change is
risky, would it be good to continue using object overflow
and come back to group on how to handle if visible is
defined?
astearns: Makes sense to me. If what discussed today doesn't work we
figure out how object overflow would work as a separate
property for this use case
khushal: Issue was if object-overflow as defined in spec exists how
does overflow interact with replaced and my take away is it
continues as is. We can come back for more concrete
resolution
astearns: So adding the path of using overflow on replaced elements
in a draft
fantasai: Add and mark as tentative pending data with a link to the
issue
astearns: Remove object overflow or put an issue on that?
fantasai: I would go with remove from spec and mentioning in issue
that if we can't go in direction we're trying we may
reconsider
astearns: Objections to Add this path forward to the spec with a note
linking back to this issue
RESOLVED: Add this path forward to the spec with a note linking back
to this issue
CSS UI
------
Should the cursor property support image-set()?
-----------------------------------------------
github: https://github.com/w3c/csswg-drafts/issues/5831
florian: Has always supported url production to point to image
florian: Since css ui 3 spec says it's allowed to support image
production to do image sets, gradients, etc
florian: It's as a may because as of time for css ui 3 no one did it
florian: Since then we have 1 shipping and 1 experimental of more
than urls but supporting image-set function as long as
image-set only contains links to urls.
florian: One possibility is we keep spec as is. Other is we
explicitly call out now that there's 2 impl is you can do
url and this version and may the rest. 3rd is switch entire
spec to using image production and encourage browsers to
fill in what's missing
astearns: Opinions?
* fantasai has no opinion
florian: I'm inclined to spec what is implemented. We were refraining
because no one had done it. Still not all impl but since we
have more spec that would be nice. Can't just use image-set
production because no one does gradients.
florian: Since we have multiple implementations we should spec it
astearns: I think fine to spec what's impl. I assume there's no tests
in wpt
florian: I haven't checked. As a spec writer I didn't create
iank: This just covers image-set. Also the image function. Was that
impl?
florian: Don't think so. Only seen image-set with URLs. spec allows
more but I don't think anyone has impl
astearns: Prop: Add a URL parameter-specific version of image-set
function to the cursor property
astearns: Objections?
RESOLVED: Add a URL parameter-specific version of image-set function
to the cursor property
astearns: Please do add tests
florian: Sure
CSS Cascade
===========
Should 'revert' really treat animation origin as author origin?
---------------------------------------------------------------
github: https://github.com/w3c/csswg-drafts/issues/7083
astearns: Suggested resolution at the end from TabAtkins
<fantasai> https://github.com/w3c/csswg-drafts/issues/7083#issuecomment-1083631261
fantasai: We suggest for revert-layer no change. There are use cases
and how set is most natural way. This issues is around
revert. We suggest close no change because this is
specified and impl. If people think treat same as
revert-layer that is reasonable behavior; main problem is
it's a change
astearns: Prop: Close no change
<miriam> +1 close no change
fantasai: Yeah. Unless someone feels significantly better to behave
same as revert-layer
oriol: Initially I filed this because impl that way had some
performance cost in WK and in Blink there was a comment saying
it disabled optimization. In discussion of issue turned out
changing wouldn't improve perf in Blink because disabled due
to em units.
oriol: So I think changing would not improve perf so we can close no
change
astearns: dbaron you commented. Is this okay?
<dbaron> no objections
astearns: objections to Close no change
RESOLVED: Close no change
revert/revert-layer with logical properties
-------------------------------------------
github: https://github.com/w3c/csswg-drafts/issues/7054
fantasai: Proposal: Spec what's implemented
astearns: Is that the whole things?
oriol: The thing is what happens if you have mix of logical and
physical and set one to revert-layer do you roll back to same
ignoring pairing property?
oriol: I looked at impl and all agree that first they run the escape
and when have final writing mode turn them physical ones.
Logical and physical properties convert into same mapping.
Once resolved you revert into resolved property
oriol: If you have margin-left and revert-layer and previously you
set margin-start you revert to that.
oriol: Proposal is revert after resolving the properties
fantasai: Makes sense to user. revert is rolling back value on this
property to what would have been if author stylesheet
didn't exist and this has that effect
astearns: Thanks oriol
astearns: Objections to specify what browsers currently do
RESOLVED: Specify what browsers currently do
astearns: Thanks everyone for calling in and we'll talk next week
Received on Thursday, 7 April 2022 09:56:55 UTC