- From: Dael Jackson <daelcss@gmail.com>
- Date: Thu, 6 Apr 2023 14:06:57 -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.
=========================================
Upcoming F2F
------------
- Based on the initial poll the target for a F2F will be the second
or third week in July. The chairs will now look for a host in
the east coast of the Americas.
- There will be a follow-up poll shortly to get more specific
details about availability for travel.
Publication
-----------
- RESOLVED: Republish WD of css-highlight-api-1
CSS Pseudo
----------
- RESOLVED: If there is color in the author origin the UA must
respect that color exactly, including its alpha (Issue
#6853: Safari’s ::selection “wash” and UA tweaks to
highlight colors)
- RESOLVED: If there isn't a color from the author origin the UA may
apply magic (Issue #6853)
- Input is needed from authors on issue #6641 (Custom properties on
:root) to determine which option is the least bad based on the
downsides they present.
CSS Cascade
-----------
- RESOLVED: Accept @sheet with URL fragment referencing rule. Exact
details to be in the Cascade spec (Issue #5629: Multiple
stylesheets per file)
CSS Values
----------
- RESOLVED: Negative <resolution> values are invalid (Issue #8532:
Specify argument range for resolution)
- RESOLVED: Spec it as undefined (Issue #8527: Consider removing
asymptotic special-cases for tan())
===== FULL MEETING MINUTES ======
Agenda: https://lists.w3.org/Archives/Public/www-style/2023Apr/0002.html
Present:
Rossen Atanassov
Tab Atkins
Elika Etemad
Megan Gardner
Chris Harrelson
Daniel Holbert
Dael Jackson
Sanket Joshi
Ian Kilpatrick
Peter Linss
Cameron McCormick
Florian Rivoal
Cassondra Roberts
Regrets:
Rachel Andrew
Brian Birtles
Yehonatan Daniv
Jonathan Kew
Miriam Suzanne
Bramus Van Damme
Lea Verou
Chair: Rossen
Scribe: dael
Rossen: Let's get going
Rossen: As usual, I want to ask for additional agenda items. I have
one topic about the F2F poll
Rossen: Any other topics or changes to the agenda?
Rossen: Poll I posted on the private list has...thanks to everyone
that participated. Looks like 2nd or 3rd week of July is
strongest
Rossen: That is when both myself and astearns are available and
mostly everyone else who responded is green or yellow
Rossen: With those being most probably I'll follow up with an ask
for anyone willing to host as well as potential places we
can host
Rossen: As I mentioned in previous email we want to target east
coast timezone which is eastern Canada to central and south
America so quite a bit of land coverage.
Rossen: fantasai had some great ideas on location but we need
someone to cover hosting
fantasai: I know some people are under travel restrictions either
due to company policy, budget, or personal preference. We
need to know those because if changing location or venue
would change attendance we need to know that
fantasai: Rossen if you would poll for that it would be great. We're
only having one so we want everyone that is willing to be
able to attend
Rossen: Now that we have these two weeks identified we can narrow
this down
WD republish for css-highlight-api-1
====================================
github: https://github.com/w3c/csswg-drafts/issues/6900#issuecomment-1494678089
Rossen: Are we ready to start the republishing process?
sanketj: I think changelog is only thing left
Rossen: Anything else you wanted to cover? I think we have a
resolution but happy to record one more.
sanketj: I think these were all deltas since last WD. Not quite
ready for CR. Has been a while since we last published.
Rossen: Happy to record a resolution with the changes you outlined.
Rossen: These are the changes going into the WD. Unless someone
objects would like a resolution to proceed
florian: Think it's good. Seems all edits are editorial or backed by
resolution
RESOLVED: Republish WD of css-highlight-api-1
CSS Pseudo
==========
Safari’s ::selection “wash” and UA tweaks to highlight colors
-------------------------------------------------------------
github: https://github.com/w3c/csswg-drafts/issues/6853
fantasai: The problem here is that certain UAs make tweaks to
highlight color spec by author such as making
semi-transparent. That means rendering differs across UAs.
I believe FF is only one using colors given as is. This
can create contrast problems because author can use a
color that is fine when semi-transparent but unreadable
when opaque
fantasai: There was a bug report on this with white text and white
background. Looked great on Safari, was completely
unreadable in Firefox.
fantasai: Either we decide we're adding alpha channel magic and use
the same magic or we should agree to use colors as
specified
fantasai: I don't want every UA to do whatever and they end up
unreadable
florian: Desire to match platform is understandable but leads to
this where authors use something not interpretable, and
thereby unreadable in some cases
Rossen: Yeah, this is a problem when unreadable
fantasai: Default it's fine to do whatever but we need to agree on
how the colors are used
Rossen: Anyone have an opinion on if we want to add alpha channel
magic or agree on the specific colors? Which path forward?
florian: I suspect what fantasai hinted at which is once color is
spec use that it's the easiest path forward. Having to spec
magic I'm not sure if it's doable. Matching native isn't
something we can set in stone. Do native magic by default
but when a color is set do that
Rossen: I agree that it would be an uphill battle
GameMaker: Can someone explain the demo page? I see a slider that
changes color but I'm not sure what this is trying to show
iank: If you slide all the way to the right on Safari you'll see the
magic alpha applied on Safari
GameMaker: That makes sense
GameMaker: In general against trying to codify this. We work with hi
and it might change in 10 years. Letting UAs do what they
want when there isn't a color that's great. But when
author says I want this color I think we can get behind
that
Rossen: Magic described will match the current magic giving the
alpha in the last stop on Safari?
Rossen: The demo page which in Safari adds an alpha channel in the
last stop when it's opaque. My question is if we allow for
other browsers to match that magic is that the effect we
want?
iank: Proposal is the opposite
florian: Opposite because in the demo author has spec the color. If
the author hadn't specified a color all browsers could do
whatever magic they want
heycam: I think there's a question of exact mechanism to determine
author has given a color. What's the value of the selection
color going to be by default. A system color keyword?
fantasai: Either system color or not specified other than an
internal keyword. I think system colors is most
straightforward
heycam: Author can't read because getComputedStyle::selection?
fantasai: There's a compat vs security discussion on there
florian: Worried about round tripping?
heycam: More about the exact way of determining the author wrote a
color
florian: As long as it's written you don't have a preference?
heycam: I prefer value of property rather than result of cascade.
Seeing if there's a rule with a color property
GameMaker: Sounded like we might lean toward defining this and I
would say we don't want to define special magic
florian: Not looking for special magic, but looking for when it does
and does not apply
GameMaker: Sounds like on same page
Rossen: Let's look for resolution
fantasai: Here's what's tricky. Spec says each system color computes
to corresponding color in color space. So at computed time
we don't know it's a system color
florian: We would need to do what heycam doesn't prefer
heycam: Do we have other examples of looking at cascade to determine
if something was spec?
iank: Maybe highlight?
florian: I think there's logic around bg and fg. Can we use same
logic around having set things?
<fantasai> https://drafts.csswg.org/css-pseudo-4/#paired-defaults
florian: I think 2 part resolution. Part 1: When the author has not
specified a color the UA may do what they want. When author
has specified a color UA must use as is
florian: Second is investigating what do we consider author has set
a color
florian: Maybe we push second part to later?
iank: Inside of Blink we have a mechanism to detect if something is
spec by an author. We use it rarely, appearance and highlight
stuff. I don't know if WK has that
florian: Found what I was talking about. Condition is if bg color
yields a cascaded value from author origin. We could use
that
florian: Not as simple as heycam wanted
fantasai: But it's something you're already detecting
heycam: If other things use this mechanism I guess it's okay
Rossen: Proposal: For colors that originate in the...
florian: If there is color in the author origin the UA must respect
that color
Rossen: Objections?
RESOLVED: If there is color in the author origin the UA must respect
that color exactly, including its alpha
Rossen: Do we need to resolve on the magic?
florian: If there isn't a color from the author origin the UA may
apply magic
Rossen: Happy to resolve on that
Rossen: Objections?
RESOLVED: If there isn't a color from the author origin the UA may
apply magic
PaulG: Was the alpha transparency magic from Safari because they
were rendering on top of the text? Do we need to add to spec
selection is rendered under text?
fantasai: That is in the spec
chrishtr: Does resolution say UA must not apply magic otherwise?
florian: That's the first resolution
fantasai: Spec allows magic that's not controllable by CSS like
dimming content. Need to clarify they can't change colors
Custom properties on :root
--------------------------
github: https://github.com/w3c/csswg-drafts/issues/6641#issuecomment-1404031937
fantasai: I guess this was question about can we use custom
properties on ::selection etc.
fantasai: There's 3 approaches which each have a major downside
<fantasai> https://github.com/w3c/csswg-drafts/issues/6641#issuecomment-1404031937
<fantasai> body::selection inherits from html::selection
<fantasai> not from body itself
<fantasai> :root::selection inherits from :root
fantasai: First is to have the root::selection inherit from :root.
Highlight pseudo elements inherit through their own tree.
body::selection inherits from html::selection
fantasai: Option 1 is have root highlights inherit from root.
fantasai: Second is custom prop inherit from originating element
where others inherit from highlight parent.
fantasai: Third is ignore custom prop on the highlight but when we
use var look at originating
fantasai: Downside to 1 is if custom value changes in a highlight
tree the subtrees won't know
fantasai: Downside to the second is inherit from 2 sources is hard
to implement. I remember it was hard with first-line
fantasai: Downside to 3rd is if you set a custom property on the
highlight and use it on the same property it won't look at
the value you just set
fantasai: Question to the WG is which approach if any do we want
to take
Rossen: Opinions?
florian: I'm thinking having custom and regular properties inherit
differently doesn't play nice with having custom properties
polyfill regular ones. That would argue against option 2
florian: All options seem to have author-facing downsides so can't
rule based on priority of constituency
Rossen: Is there a path forward where we can adapt option 3 to work
for highlight?
fantasai: We can make all the options work, question of which has
the least downsides
florian: Should we get author feedback and see what they'd find most
or least helpful? I'd just be guessing
Rossen: If that's what's holding us back we might
fantasai: Could be helpful to get feedback from sanketj team because
more useful for custom highlights than ::selection
sanketj: I think we'll need to look into this a little bit more. No
preference right now. We can follow-up
Rossen: That doesn't inspire confidence to resolve today. We may
have to come back to this once there are stronger opinions.
Will that work fantasai?
fantasai: I don't think it's urgent, but good to figure out
Rossen: If it's not ready for resolution let's remove the agenda+
and continue moving forward
CSS Cascade
===========
Multiple stylesheets per file
-----------------------------
github: https://github.com/w3c/csswg-drafts/issues/5629#issuecomment-1405731979
TabAtkins: There have been a few requests in this space before.
Various reasons why you might want a bunch of independent
stylesheets and ship as one file. Reduce costs, benefit
from compression. Want custom components that relate.
TabAtkins: Proposal in this thread to allow this in CSS. Initial
approach focused on JS imports but variants appeared later
TabAtkins: Proposal is a new @ rule @sheet that takes a stylesheet
and a name. Syntax inside @sheet is that of a top-level
stylesheet. If you use the top level stylesheet directly
you only get unnamed sheets. Can access named sheets with
fragment on URL
TabAtkins: When importing or @import you can use the fragment and
we'll interpret as a sheet name and grab that one sheet
from the larger sheet
TabAtkins: I think convenient and minimal way to address use case.
Thoughts, objections, questions?
plinss: What if you have top level entities that aren't @sheets
TabAtkins: They're part of the top level sheet
plinss: @sheets are just rules to top level stylesheet?
TabAtkins: Could go either way. Either OM reflects normally and
things in @sheet don't apply or a new list that exposes.
Both sound plausible
plinss: If you use a top-level sheet nested sheets are ignore?
TabAtkins: Yep
plinss: Okay. in general in favor
fantasai: Why wouldn't you apply all by default and than have an
option to not apply? I feel like if I was pulling a sheet
and it had a bunch of rule expect all to apply
TabAtkins: Could go either way. I think it makes sense if write as
independent so you don't intend them to be used together.
But I don't think anything wrong with allowing them to be
used together. not sure how parsing of namespace applies
in the same sheet
fantasai: You have ability to apply 2 already. Apply all is
extension of that
TabAtkins: namespace rules should only be sheet they're in
TabAtkins: Related, any context in the outermost sheet like
fontfaces shouldn't apply to the ones inside because
otherwise it's unpredictable. That leads me to confusing
to all apply
fantasai: I don't think so. It's like I concat a bunch of sheets.
That's the premise you started with. @fontface is not to a
single sheet. Only namespace is file scope
plinss: Concerns if we allow all by default you have rules, @sheet,
more rules and then you have conflicts where you've got same
specificity and what wins. You could end up with situations
that surprise. I'm fine to explore
TabAtkins: We have limits for that specificity reason. You need to
allow imports in @sheet and that introduces that ability
we disallowed
plinss: We'd need to give it more thought
fantasai: Could just make it invalid
fantasai: If you have a style rule or @media that's not allowed
before @import and you put an @import it's ignored. We
could put that @sheet after something is ignored. If it's
out of place it's ignored.
TabAtkins: That means you can't use @import and @sheet unless it's
the first @sheet unless you load independently
plinss: Clarification, it sounds like you're saying @import @sheet
rules @sheet and the first @sheet would be in top level but
second wouldn't?
fantasai: 2nd is invalid
plinss: Would be ignored
plinss: Second is I presume @import in the nested sheets that's a
fragment of the other sheets would work regardless of where
it shows?
TabAtkins: Inclined to say yeah. Need to do cycle checking
plinss: Then you could always say we don't by default but you can
import them into the top
TabAtkins: That makes sense. That's pretty good. Would avoid my
issues because your imports would be loaded as separate
stylesheets at top level
plinss: Right @import #foo and than #sheet foo and the sheet is
hoisted in as a separate document
<TabAtkins> @import "#foo"; @sheet foo {...}
Rossen: Is this something that we can summarize as a resolution?
TabAtkins: Resolve to accept @sheet with URL frag referencing rule.
Exact details to be in the spec
PaulG: Coming from outside I think my confusion would be with layers
and how this differs. Can layers be used instead of sheets to
achieve the import mechanic? My concern is there is two
syntaxes doing similar things
fantasai: Layers effect how rules cascade. Not so much about
organizing the style where it is in a file. They change
precedence of rules. This is equivalent of @import where
you can include rules from one file to another
TabAtkins: Solely a bunching helper as opposed to layers which
impact cascade
PaulG: Is the concern there when you bring in stylesheet 1 and 2
they can conflict between rules?
TabAtkins: They do. You can import with a layer to order them and
that works here
PaulG: Not clear on what's being solved for. Purely the addressing
of the rules by file organization?
TabAtkins: If you have need for several distinct sheets like custom
components in HTML but you don't want n different
requests, this solves that problem
PaulG: Okay, thank you
plinss: JS import would like you import one of the nested sheers
TabAtkins: Right.
Rossen: Proposal: Resolve to accept @sheet with URL frag referencing
rule. Exact details to be in the spec. Additional thoughts
or objections?
TabAtkins: I'm guessing this goes into cascade?
fantasai: That's what it feels like
RESOLVED: Accept @sheet with URL fragment referencing rule. Exact
details to be in the Cascade spec
CSS Values
==========
Specify argument range for resolution
-------------------------------------
github: https://github.com/w3c/csswg-drafts/issues/8532#issuecomment-1457136547
TabAtkins: It was noted that it is possible to write a negative
resolution and not def what that means. Proposal is the
resolution type as a general case says negative is invalid
TabAtkins: In a calc we would clamp it.
TabAtkins: Values & Units is mature spec so need resolution
TabAtkins: Resolution type is restricted to non-negative values
fantasai: sgtm
RESOLVED: negative <resolution> values are invalid
Consider removing asymptotic special-cases for tan()
----------------------------------------------------
github: https://github.com/w3c/csswg-drafts/issues/8527
TabAtkins: I don't recall where I got this behavior from. But I have
a definition for exactly what asymptotic should do
TabAtkins: Tan of 90deg you return infinity atan does reversals.
TabAtkins: Issue from emilio is that depending on internal
resolution for asymptotic may be impossible to present.
TabAtkins: He suggested remove this and call it undefined. If you're
a little above or below you get large positives or
negatives. That's what happens in JS
TabAtkins: My concern was roundtripping seemed mildly useful.
dholbert seems a bit in support of keeping current, but
don't want to speak for him
* fantasai's preferences mirror Tab's
TabAtkins: I'm weakly in favor but if browsers want to avoid having
reliance on this for an exact 90deg angle I'm fine with
that as well
Rossen: Opinions?
<dholbert> I was just talking through the problem space in the issue
<dholbert> I'm in favor of calling this un-defined
<dholbert> in the spirit of "are authors really gonna care"
Rossen: Are we wanting to call undefined or leave as-is?
TabAtkins: Leave as-is implies we'll have tests. Browsers that don't
represent angles internally with something that can do
exact 90deg will fail it
TabAtkins: Explicitly undefined allows either and calls out you
can't depend on it. You can't depend on it in JS so
likely okay in CSS.
TabAtkins: I'm okay with that since Mozilla asking
Rossen: Proposal: Spec it as undefined
Rossen: Objections?
RESOLVED: Spec it as undefined
<dholbert> (if I understood Emilio correctly, defining it would
require a somewhat ugly hack to nudge to the expected
result, if we did have to define it, I think)
<dholbert> thanks!
<TabAtkins> @dholbert right, you'd have to do an epsilon comparison
Rossen: Thank you. Thank you again for filling out F2F survey.
Expect a next quick one
Rossen: We'll chat again next week
Received on Thursday, 6 April 2023 18:07:35 UTC