- From: Dael Jackson <daelcss@gmail.com>
- Date: Wed, 19 Feb 2020 19:28:06 -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 Box
-------
- The group wasn't certain if the best way to solve for increasing
the pointer target size (Issue #4708: Increase pointer target
size independently of element layout) was to allow set sizes as
suggested in the issue or to expose a fixed set of values and
let the user agent do the math. astearns will reach out to the
original poster to get feedback on the two options
Constructable StyleSheets
-------------------------
- RESOLVED: Close no change to normative text but add a note about
needing implementation experience (WICG Constructable
Stylesheets Issue #120: Consider disallowing duplicate
stylesheets)
- RESOLVED: Disallow @import in all constructable stylesheet APIs
with a note that we're doing it to match current state
of modules and this might relax in future (WICG
Constructable Stylesheets Issue #119: Add a note about
the reasoning to forbid `insertRule(@import)`, or remove
the condition?)
CSS Text Decor
--------------
- RESOLVED: Change the new property to be 'all' not 'always' (Issue
#4277: Consider adding an `all` value to
`text-decoration-skip-ink`)
CSS Inline
----------
- RESOLVED: Line-height returns 'normal' in gCS for normal and all
other give absolute length (Issue #3749: A question for
the procedure to compute the resolved value of
"line-height")
CSS Color Adjust
----------------
- More research needs to be done to see exactly what value is being
overwritten on the iframe to solve issue #4772 (`color-scheme`
should affect embedded iframes)
===== FULL MINUTES BELOW ======
Agenda: https://lists.w3.org/Archives/Public/www-style/2020Feb/0015.html
Present:
Rachel Andrew
Tab Atkins
David Baron
Oriol Brufau
Tantek Çelik
Emilio Cobos Álvarez
Elika Etemad
Javier Fernandez
Simon Fraser
Megan Gardner
Chris Harrelson
Daniel Holbert
Dael Jackson
Brad Kemper
Chris Lilley
Peter Linss
Anton Prowse
Manuel Rego Casasnovas
Florian Rivoal
Christopher Schmitt
Jen Simmons
Alan Stearns
Regrets:
Rossen Atanassov
Christian Biesinger
Dave Cramer
François Remy
Scribe: dael
astearns: Any suggested changes to the agenda?
astearns: I have one
<astearns> https://github.com/w3cping/font-anti-fingerprinting
astearns: For those who did not notice and I think it was easy to
not notice. There is an explainer on font fingerprinting ^
astearns: For those in our discussion about local font access I
think this was meant as a response. Not sure if it's extra
things or a replacement
astearns: For those engaged in the discussion please look at repo.
It's under privacy interest group
<lajava> https://github.com/w3c/csswg-drafts/issues/4675
<lajava> I'd like to talk about this, if possible
astearns: I see one other request to add to agenda. lajava okay at
the end or need it as quickly as possible?
<lajava> it can be at the end
astearns: Okay. That will go to the end
CSS Box
=======
Increase pointer target size independently of element layout
------------------------------------------------------------
github: https://github.com/w3c/csswg-drafts/issues/4708
fantasai: Seemed reasonable proposal. Came from someone posting on
twitter, I said file and issue, they did with nice
diagrams. It seems to be a nice proposal and solving a
problem
fantasai: Seems simpler. Basically hit margin with a length and it
expands outward from border edge of element
astearns: Expands the not quite defined hit area
fantasai: Yep
smfr: Mobile browsers do area hit testing where if you tap browser
looks around touchpoint. So there's built in hit test area
expansion stuff. Don't know if have to define how that
interacts
chris: Would this replace or coexist?
smfr: Not sure, I guess coexist
astearns: Define what mobile browser does in UA stylesheet.
astearns: Would be good to see if what we define would suffice for
UA stylesheet. If not should fiddle
smfr: Good point. Also hit test can't leak outside iframes. Cross
origin you can't allow it to go to the parent iframe
smfr: Also slightly concerned about clickjacking. You can do a link
that covers document. Could do same with event handlers but
slightly nervous
astearns: Can't do same with slightly opaque element on everything?
smfr: Yeah, that's not new
fantasai: Could limit size, can't have margin larger then something
reasonable. Can already do the same thing as you mentioned
plinss: I haven't read it but does it define how to handle
overlapping elements?
fantasai: Already have to define. This increases border box for hit
testing without painting it
astearns: It does allow touch places to overlap where wouldn't
normally. Can do it with positioning but this is new
overlap
smfr: Complicates implementation because generally hit testing is
painting in reverse. You hit test front to back. With this you
extend elements to correct order in way that only effects hit
testing. Leads to complications
plinss: Want to make sure it's defined even if treated as
overlapping [missed]
astearns: Yeah, this would be cool to have. Need somebody to write a
proposal. Who would that be?
astearns: And spec?
fantasai: CSS UI 4
astearns: Who are editors?
florian: I am an Editor of UI-4
tantek: This is very geometry related. Related to box model. And to
hit testing which is undefined and may be worth spec on own.
tantek: Not similar to other CSS UI properties.
tantek: I don't think we should burden CSS UI 4 without florian
saying he can help
florian: I'm not opposed to idea but not committed to idea. I don't
think this is particularly hard in itself, but hit testing
in general is, so that depends on whether we open that can
of worms
tantek: And people who have tried to spec hit testing have run away
fantasai: I don't think this is too hard. I'll take the action to
make PR
myles: Question: Is the idea to inflate touch target so people can
hit with fat finger. If that's what we're trying why isn't
value a bool?
TabAtkins: Agree. You just want to make sure target is wide enough
without ensuring whole element is wide enough. So make
this target a fingerprint wide seems reasonable
tantek: Maybe 3rd state to shrink target area to avoid errant
activation. UI elements that are damaging you want to reduce
accidental compared to button they're near. Length may be
overdesign, I agree
chris: Intended to cover case where there's a button but it's not a
code button and you have text that is a link and you want if
people click in general area. Is that use case being solved?
tantek: Should be solvable with existing markup
astearns: Whole problem is solvable with markup now but as author
states it's unfortunate to change markup to get hit testing
tantek: I meant without adding more markup. Text link you can add
explicit directions. I think we should distinguish common
author errors and use cases we want to enable. Common author
errors aren't fixed with a new feature
fantasai: I don't see how existing properties solve this without
creating fake elements. Text link where you want to
increase size of link without layout impact
tantek: But it's a text link inside something that looks like a
button and the answer to that is make it a button. I agree
there are use cases for button with area around it like
example in issue. That's legit.
tantek: I like it being higher level so UA can decide based on
device. Don't need every webdev to solve what device with
which resolution...I'd hate to put that burden on webdev and
UA can solve if there's touch-target: larger
myles: Even on physical device can have larger resolution
<tantek> I'm suggesting a trinary
<tantek> per the shrinking use-case
astearns: We've had good discussion around length or bool. Let's
engage issue poster on opinion between options and work
from that?
<fantasai> +1 to astearns
tantek: I agree with sentiment
astearns: Okay, let's get back to Tyler. I'll ping
Constructable Stylesheets
=========================
Consider disallowing duplicate stylesheets
------------------------------------------
github: https://github.com/WICG/construct-stylesheets/issues/120
TabAtkins: I'm happy to talk on this because we want to port it over
TabAtkins: Don't know who poster is but they said there's no good
reason to put the same object in the list twice. Would be
useful to have a check against that to not allow
insertion if same thing shows twice
TabAtkins: Generally agree there isn't a use case to put same object
in twice. heycam pointed out webIDL to deal with array do
temporarily cause same object to show twice like reverse.
It would be confusing and bad if putting this is means we
can't reverse the array.
TabAtkins: Given a decent argument against the requirement and it
was a nice to have I think we should reject and keep it
that this uses normal array semantics.
emilio: Nice to not have the same stylesheet twice but I don't
object to argument
TabAtkins: Does it apply to same text not twice?
emilio: As of right now our system assumes same sheet doesn't appear
twice. It uses stylesheet object at rest. Constructable is
only thing that can break this
TabAtkins: Got a balance of could not putting in restriction have
its own impl work. Still concerned that this would result
in confusing errors for authors. Do you think
implementation work to handle same stylesheet multiple
times is large enough to add the restriction?
emilio: It would be fair amount. I don't know bar to justify adding
this restriction. I would like other engines to weight in. I
know blink and webkit store stylesheet locals in stylesheet.
That means same rule can allow 2 order in list of
declarations. Order is not specific to stylesheet. So I
suspect edge case in other engines.
emilio: I don't know enough to be able to justify
TabAtkins: I propose reject for now but have a note in spec that due
to this violating existing assumptions about a stylesheet
existing once there may be impl concerns and we don't
know severity so may have to change in the future
emilio: Okay with that
astearns: Having somebody using constructable stylesheet api to put
duplicate stylesheets in is edge case. Then person doing
reverse and finding error is smaller so I think edge error
case
TabAtkins: We're not. Algorithm with reverse puts same object in two
spots
astearns: Ah, so not a combo but doing a reverse on any stylesheet
TabAtkins: Yes.
astearns: Okay, I'm fine allowing with that note that we need
implementation experience
astearns: Other opinions?
astearns: Proposal: Close no change to normative text but add a note
about needing impl experience
astearns: Objections?
RESOLVED: Close no change to normative text but add a note about
needing implementation experience
<tantek> I'd like to q+ insert the meta issue of
https://github.com/w3c/csswg-drafts/issues/3433
just after the discussion of this issue if we could, hoping
we get a group consensus decision recorded to merge from
WICG into the CSSWG CSSOM spec. Seems like there is
agreement in the issue just need to get a decision recorded
AFAIK
<TabAtkins> tantek, we already have that resolution iirc
astearns: tantek the decision is recorded and I believe there's an
open PR
tantek: Sorry, wasn't obvious there's a consensus agreement from WG.
I guess minor request to get it recorded in GH
astearns: I'll take an action to find the agreement
Add a note about the reasoning to forbid `insertRule(@import)`, or
remove the condition?
------------------------------------------------------------------
github: https://github.com/WICG/construct-stylesheets/issues/119
TabAtkins: Spec has a restriction you cannot use insert to insert
@import on constructable
TabAtkins: Other reasons to not allow @import like if you're doing a
sync because it imposes some async and stylesheet won't
be ready until finish import.
TabAtkins: General case have blanket disallow of @import. Blanket
reason is we intended Constructable StyleSheet usable
across documents and there's technical details with fetch
group effecting how you would import and you don't want
to leak resources
TabAtkins: So we said kill entirely and avoid issue
TabAtkins: We no longer do that. We have explicit check that it must
be same document. No longer a good reason to disallow
TabAtkins: Suggestion is we remove that, the sync call we keep but
all other ways of putting @import should be valid now
astearns: Concerns?
TabAtkins: Prop: Remove the general disallow of @import rules in
Constructable StyleSheets. Replace sync method call will
still fail with @import rule but all other cases will
allow @import
chrishtr: And didn't do it before for consistent?
TabAtkins: No, because if share cross document fetch group depends
on document and if on different document fetch group is
unclear. Now prevent cross document use so it's fine.
chrishtr: And that was after resolve on import when shipping in
first place
TabAtkins: Yes
chrishtr: Okay
astearns: Proposal: No longer forbid @imports
astearns: Objections?
chrishtr: What happens to CSS modules?
chrishtr: People working on CSS modules where you import stylesheet
as module that doesn't have imports. I guess restriction
flows directly through.
TabAtkins: Haven't looked exactly. Generic restriction doesn't apply
since JS attached to a document. Not certain we want sync/
async to matter in JS imports. If we do should apply at
time you import. Good point to raise and I'll make sure
we handle that property
dbaron: My memory of CSS imports TAG review is they didn't want to
make design decision on if @import should build module graph
or function as normal so they punted on that and disallowed
<dbaron> The TAG review I mentioned was
https://github.com/w3ctag/design-reviews/issues/405
chrishtr: Right, it complicates JS module graph. If you have a
stylesheet and add @import when does browser fetch?
TabAtkins: Immediately after insert rule
chrishtr: Before you put in adopted array?
TabAtkins: Think so
chrishtr: When do we load images?
TabAtkins: Ill-defined but not until applied to an element.
TabAtkins: Replace call is async so delay wait for imports isn't
huge. Insert is a sync call and no way to tell except
checking if an imported stylesheet has loaded
TabAtkins: If you take a normal stylesheet and an @import rule it
immediately loads. Asynchronous in background
chrishtr: After inserted a Constructable StyleSheet you can add
rules and so similar behavior should occur
TabAtkins: Yeah. Least difference between UA and Constructable is
good
chrishtr: So shouldn't load until you stick it in because doesn't
load until it's in the DOM
TabAtkins: True. Warrants further timing discussion
TabAtkins: Regardless of timing, do you have objections to generally
allowing import?
chrishtr: Objecting because it's inconsistent and if other cases are
best practice they can't use best if authors doing @import
chrishtr: Stylesheet in a JS module is a best practice and they
can't have @import so devs would avoid it and use another
mechanism
emilio: You can add imports to regular stylesheets so I don't know
objections
chrishtr: Pre-compile StyleSheet, stick in JS module, and then they
put it into adopted stylesheet by importing module but
that doesn't allow adding @import unless have special code
where after adding JS they manually add import
emilio: You can import multiple module right?
chrishtr: Right, multiple modules to represent imports rather then
it implicit based on module dependency
emilio: Still not sure...
chrishtr: Inconsistent
emilio: I think it's inconsistent to allow rules expect @import.
Current spec wording is wrong if we're disallowing @import
chrishtr: I prefer to think more and talk to other engineers about
implications
TabAtkins: Sympathetic to that it's good for CSS modules and
Constructable StyleSheet work the same. Since punting on
modules we should punt on Constructable StyleSheets
TabAtkins: So I'm okay keeping restriction until decide on CSS
modules
emilio: Wouldn't that mean have to handle them in
cssstyle.docReplace? Constructable have @import if you use
async
TabAtkins: Yes, idea is be consistent and disallow @import in all
Constructable stylesheets with poss to change later
emilio: Means you need to change replace and such
TabAtkins: Yeah
emilio: I would rather either both or none for allowing
TabAtkins: Agree
astearns: Are we at point to resolve on disallow or do we need
research on CSS modules?
TabAtkins: I think. Proposal: Constructable stylesheets should be
same as modules and disallow @import in all cases
TabAtkins: To be consistent with modules and to deal with emilio
issue on handling constructable imports
dbaron: I'd hope to see this resolved sooner. Thing with modules
felt it was disallowing because not wanting decision on how
it should work, not because either option was bad
TabAtkins: Yes, I believe that is correct
chrishtr: True that async replace allows @import in chromium?
emilio: Yes
astearns: Proposal: Disallow @import in all constructable stylesheet
apis with a note that we're doing it to match current
state of modules and this might relax in future
emilio: Error handling? Reject, fail to load?
TabAtkins: Invalid or error?
emilio: Right
TabAtkins: What are we doing for modules?
TabAtkins: I think answer is match CSS modules. If not clear need
and answer for both
emilio: Modules should match inserting invalid @import rule. But
that's another discussion
TabAtkins: Yeah. I think calling insert rule with unknown rule
silently fails. I suspect best to match with inserting
import into import disallowed sheet.
emilio: Maybe. Don't need to decide now.
astearns: Objections to disallow @import in all constructable
stylesheet apis with a note that we're doing it to match
current state of modules and this might relax in future
RESOLVED: Disallow @import in all constructable stylesheet APIs with
a note that we're doing it to match current state of
modules and this might relax in future
astearns: If error handling is not immediately clear please raise an
issue
<dbaron> Was the resolution intended to have "for now" in it?
<dbaron> oh, I guess it does at the end
CSS Text Decor
==============
Consider adding an `all` value to `text-decoration-skip-ink`
------------------------------------------------------------
github: https://github.com/w3c/csswg-drafts/issues/4277
fantasai: Jonathan Kew had question on name and wanted to ask about
changing from always back to 'all'. Current value set is
'auto' and 'none'. Adding a new keyword, options currently
are 'always' and 'all'. Open to another ideas
myles: No preference
astearns: Given that we can't change none I see jensimmons saying
'all' works better with 'none'
smfr: Prefer 'all'
smfr: 'always' sounds more temporal. 'all' is skip all ink. It's not
sometimes or always skip ink
astearns: Anyone want to stick with 'always'?
jensimmons: Do we use 'always' anywhere?
fantasai: Page breaking controls, always and avoid
jensimmons: Do we use 'all' a lot?
TabAtkins: Transition property takes all
<tantek> is there a reverse-index of property values to property
names?
fantasai: Break-before and -after takes always. Transitions takes all
dbaron: Column-span takes all, user-select takes all
<dbaron> ... pointer-events, text-combine-upright
<dbaron> ... transition-property
astearns: Less about consistency with other properties and more to
make sense of values with this property and I'm convinced
'all' works better
astearns: Sounds like it's switch to 'all'. Objections to change new
value to 'all'?
RESOLVED: Change the new property to be 'all' not 'always'
CSS Inline
==========
A question for the procedure to compute the resolved value of
"line-height"
-------------------------------------------------------------
github: https://github.com/w3c/csswg-drafts/issues/3749
fantasai: I wanted to confirm resolution and that people were happen
given someone raised a question
florian: Tried to understand what you wanted confirmed and wasn't
sure
fantasai: I think comment in issue closes it. Nothing to do except
update specs. Anyone editing CSSOM?
emilio: That's me
fantasai: Okay. Then action on the two of us to update
fantasai: Oh, we didn't resolve. Maybe that's why it's on the agenda.
astearns: Proposed: Line-height returns normal in gCS for normal and
all other give absolute length
myles: I was dragging my feet because this is scary but Mozilla impl
and we accepted a patch so I'm willing to no longer drag feet
astearns: Objections?
RESOLVED: Line-height returns 'normal' in gCS for normal and all
other give absolute length
CSS Color Adjust
================
`color-scheme` should affect embedded iframes
---------------------------------------------
github: https://github.com/w3c/csswg-drafts/issues/4772
fantasai: Has normal and other values like dark and light. Since
iframe has change parent and it has different color scheme
then main page you can't see iframe content. Raised that
non-normal should cause iframe to have opaque BG
fantasai: Whatever webpage is in that frame assumes a different
background then has on own
chrishtr: And iframe could override it
fantasai: iframe can't choose transparent if we make not
transparent, right? Original is transparent and canvas is
color
chrishtr: Canvas behind html element should be opaque
fantasai: I think
chrishtr: Background of html element?
fantasai: Have to change computed of background color property.
initial value is transparent
chrishtr: I thought for root going to dark theme cause background of
root to change in UA stylesheet. No?
fantasai: I think it's defined as canvas changes. Could change
definition
chrishtr: Maybe needs more research
fantasai: kay
astearns: Research on whats overwritten?
chrishtr: Yeah. Need to make so dev overwrite it. Need to research
what spec says
<fantasai> https://drafts.csswg.org/css-color-adjust-1/#preferred
astearns: Okay, will leave be. I'll remove agenda tag. Once there's
a proposal please add the tag back
CSS Inline
==========
initial-letter should allow zero sink?
--------------------------------------
github: https://github.com/w3c/csswg-drafts/issues/3698
myles: astearns you think it's no?
myles: If there are use cases in print mag we should support it
jensimmons: I would say yes
tantek: I believe I have seen it in the issue. Is there a diagram in
the issue?
astearns: Examples, not diagram
jensimmons: If conversation is we think it's ugly so authors
shouldn't be able to design that way we shouldn't make
that call. Let authors decide if it's ugly or beautiful
<tantek> I'll see if I can look up some examples also
astearns: Thanks everyone for calling in and we'll talk next week
Received on Thursday, 20 February 2020 00:28:52 UTC