- From: Dael Jackson <daelcss@gmail.com>
- Date: Thu, 3 Sep 2020 06:21:34 -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 Cascade L3
--------------
- RESOLVED: Move forward with Cascade L3 REC without retesting CSS 2
tests (Issue #5296: Publish Cascading and Inheritance 3
as a REC)
Selectors
---------
- The group is still committed to having better error recovery for
:is() and TabAtkins will get the edits into the spec (Issue
#3264: Let :is() have better error-recovery behavior than normal
Selectors)
CSS Color Adjust
----------------
- RESOLVED: forced-colors does not override border-image (Issue
#5469: Should forced-colors override `border-image`?)
CSS Images 4
------------
- TabAtkins added spec language to have image set discriminate on
format https://drafts.csswg.org/css-images-4/#image-set-notation
- The group prefers having the image-set use a type() function
and therefore be similar to HTML.
- RESOLVED: Republish Images 4
CSS Overflow L4
---------------
- RESOLVED: Do not inherit [scrollbar-gutter] by default (Issue
#5231: scrollbar-gutter should not be inherited)
Variables
---------
- RESOLVED: Disallow animation-tainted substitutions in any
non-animatable property (Issue #5341)
- RESOLVED: Using initial value as fallback of var triggers initial
value behavior assuming that the property only has that
keyword because of substitution (Issue #5325: CSS-wide
keywords in fallbacks)
- TabAtkins is compiling the changes list and will be asking for a
new publication of Variables shortly.
CSS Inline 3
------------
- RESOLVED: Accept the proposed text
(https://github.com/w3c/csswg-drafts/issues/5237#issuecomment-673312639)
(Issue #5237: leading-trim through to descendant line
boxes)
- RESOLVED: Rename the property from 'leading-trim' to
'trim-leading' (Issue #5237)
CSS Values
----------
- RESOLVED: Rename fetch() to src() (Issue #541: Add url() alias
that does not accept unquoted URLs)
===== FULL MINUTES BELOW ======
Agenda: https://lists.w3.org/Archives/Public/www-style/2020Sep/0000.html
Present:
Rossen Atanassov
Tab Atkins-Bittner
Amelia Bellamy-Royds (IRC Only)
Mike Bremford
Daniel Clark
Megan Gardner
Daniel Holbert
Dael Jackson
Brian Kardell
Daniel Libby
Peter Linss
Myles Maxfield
Alison Maher
Florian Rivoal
Devin Rousso
Miriam Suzanne
Greg Whitworth
Eric Willigers
Fuqiao Xue
Regrets:
Christian Biesinger
Rune Lillesveen
Cameron McCormack
Scribe: dael
Rossen: It seems like we have quorum
Rossen: Let's get started
Rossen: Any extra agenda items you want to cover or changes to the
current agenda?
ericwilligers: Can we do error recovery nearer to the start? Item 14?
Rossen: Yes. We'll get to it since you're here.
astearns: I have 2 things.
astearns: bkardell suggested a meeting next week on Thursday to go
over math issues. There's a thread to respond to. Please
do.
astearns: Second is WPT people are wondering if we want to meet
during join meeting week at TPAC.
astearns: If anyone has testing focused topic please raise it on the
list and we can get a meeting together.
Rossen: Thanks.
Rossen: Anyone else?
CSS Cascade 3
=============
Publish Cascading and Inheritance 3 as a REC
--------------------------------------------
github: https://github.com/w3c/csswg-drafts/issues/5396
Rossen: It'll transition to PR.
Rossen: Do we have florian, chris, or fantasai on?
fantasai: I'm here
Rossen: What is our readiness and what do we need to consider?
<fantasai> https://drafts.csswg.org/css-cascade-3/implementation-report
fantasai: Have implementation report for everything new to L3^
fantasai: 2 passes
fantasai: Went through test suite, added to that so we have full
coverage for new parts
fantasai: Do we want to transition to PR or do we need to cover
parts of spec that are CSS 2 since that's a lot more work
Rossen: Opinions?
Rossen: Anyone who thinks we should cover parts that are CSS 2?
Rossen: Not hearing any desire expressed
xfq: We can link to CSS 2 directly in the report and add CSS 2 tests
in the implementation report
Rossen: Would that be okay fantasai? Is that straightforward to link
to existing test results
fantasai: Implementations that went through CSS 2 are quite old and
not the same as the ones that passed L3. There would be 2
passes, but not the same. I also don't know where CSS 2
impl report is. Let's see if I can find it
<fantasai> http://test.csswg.org/suites/css21_dev/20110323/report/
fantasai: Looks like this is CSS 2 test suite ^
astearns: If there were up to date from wpt that would be one thing,
but we don't have CSS 2 suite in wpt
fantasai: They're in but require manual configuration so can't be
automated by wpt. Looking at wpt would give fails that are
not actual fails
astearns: You're saying it's a bunch of additional work to retest
this spec coverage in CSS 2 tests
fantasai: It would be...it won't take a lot of time but probably a
day if there are instructions on how to load the user
stylesheet for the implementations
<xfq> https://www.w3.org/Style/CSS/Test/CSS2.1/20110323/reports/
<fantasai> test results for CSS2 -
http://test.csswg.org/suites/css21_dev/20110323/report/results.html
Rossen: I'm more interested in seeing how to move it without CSS 2
retesting. Is there a reason we shouldn't? I get that this
is a can we do it, but why?
Rossen: Can we resolve without CSS 2 work?
Rossen: Any objections to that?
Rossen: Prop: Move forward with Cascade L3 REC without retesting CSS
2 tests
Rossen: Objections or reasons why we shouldn't do it?
RESOLVED: Move forward with Cascade L3 REC without retesting CSS 2
tests
Rossen: Who will handle? fantasai or florian?
fantasai: Me
CSS Selectors
=============
Let :is() have better error-recovery behavior than normal Selectors
-------------------------------------------------------------------
github: https://github.com/w3c/csswg-drafts/issues/3264
ericwilligers: We resolved to have better error recovery but WK
shipped without and FF is about to. Is it too late or
do we still want better error recovery?
TabAtkins: If possible I'd like to have it. If we have to oh well,
but it's bad behavior without
ericwilligers: Who wants to do spec update?
ericwilligers: We resolved on issue but spec isn't updated
TabAtkins: I'll do it if we agree today to proceed
Rossen: We're wanting to hold previous resolution that requires
better error recovery and make that edit into spec? Or are
we trying to relax the error recovery and not proceed with
edits?
ericwilligers: [missed]
ericwilligers: I'm proposing the first, that we go ahead and make
edit.
Rossen: You're proposing add it to spec and pester implementors to
do that
ericwilligers: Yes
<astearns> notes that Emilio says he's OK implementing it
Rossen: Alright. Any thoughts on that? Are we still committed and
have TabAtkins add edits?
TabAtkins: We'd need FF or WK dev to be okay doing change
Rossen: emilio is signaling he's fine with change. Only WK is going
to be required to update. Anyone from WK on?
smfr: If emilio is fine changing we're fine changing
Rossen: We have a resolution to do error recovery. Do we need
resolution to have TabAtkins edit it in?
Rossen: We'll close no change but to put in the required edits
Rossen: Thank you
CSS Color Adjust
================
Should forced-colors override `border-image`?
---------------------------------------------
github: https://github.com/w3c/csswg-drafts/issues/5469
Rossen: For historic point of view we did preserve border-images as
part of the forced colors
Rossen: I think it's a valid expectation that forced colors don't
override images for same reason why we fought to bring back
background images and added things like backing plate behind
text
Rossen: For similar reasons I think we can continue to allow images
that are part of decorations like borders
Rossen: Proposal is forced-colors should not override border-image
Rossen: Unless there's a new requirement or use case to provoke that
Rossen: Not hearing anything
Rossen: Proposal: forced-colors does not override border-image
RESOLVED: forced-colors does not override border-image
CSS Images 4
Queries for image support
-------------------------
github: https://github.com/w3c/csswg-drafts/issues/656
TabAtkins: This one is me
TabAtkins: This is in fact a CSS Images topic even though it's
tagged Media Queries.
TabAtkins: Some time ago had resolution to have image set
discriminate on format. I added that into spec
<TabAtkins> https://drafts.csswg.org/css-images-4/#image-set-notation
TabAtkins: Let me add a link ^
TabAtkins: Alongside resolution you can pass a type function that
spec a MIME type. Same as picture.element in html.
Skipped if invalid. Has no effect on image.
TabAtkins: Two questions; does this look good?
TabAtkins: Second question is I used type function but fontface uses
format function for similar. Should I make html or
fontface?
fantasai: fontface doesn't uses MIME types, but uses arbitrary
keywords, right?
myles: Yes
<florian> seems fine to use type()
TabAtkins: Weakens the argument. Then I guess use type.
TabAtkins: Does this look fine to everybody? This would go into
Images 4. It's a WD. If it looks good I want to republish
Images
florian: Looks good to me. One question. As we mentioned this was
tagged as MQ. Is that because initial request was to have a
MQ and you're proposing this?
TabAtkins: Separate thread I could not find. I was mistaken and
grabbed this. We have one elsewhere to do what I
explained. I found this first and didn't go find the
right issue
florian: So this resolution doesn't have any relevance to if we need
MQ
TabAtkins: Right
Rossen: So you're just looking for draft republish?
TabAtkins: Yes. General confirm this is fine and a resolution to
repub
Rossen: Anyone feel this is not in right direction?
Rossen: If not we'll resolve to republish.
RESOLVED: Republish Images 4
CSS Overflow
============
scrollbar-gutter should not be inherited
----------------------------------------
github: https://github.com/w3c/csswg-drafts/issues/5231
florian: Way back when initially drafted the property, discussed if
it should inherit. People didn't seem to feel strongly.
Argument that won is set it on page was nicer than
universal selection.
florian: Felipe noticed force value does not inherit nicely because
it creates gutter on non-scrollable elements. Setting on
whole page in general is a bad idea. You should only set on
elements where it matters.
<fantasai> +1 to non-inherited
florian: Suggestion is switch to non-inherited. Makes sense and I'd
like to do that
florian: Effects layout so inheriting things that effect layout is
good
iank: Agree florian
<miriam> +1
Rossen: Objections?
Rossen: Proposal: Do not inherit by default
RESOLVED: Do not inherit by default
CSS Variables
=============
Disallow animation-tainted substitutions in any non-animatable property
-----------------------------------------------------------------------
github: https://github.com/w3c/csswg-drafts/issues/5341
TabAtkins: Anders pointed out spec disallows putting animation
variable into animation property. Reason is circularity
and complexity avoidance.
TabAtkins: This does still allow you to put animation-tainted into
unanimated properties which makes them animatable.
Smuggles complexity of animation in. anders suggests we
further restrict to not allow in any not-animatable
property
TabAtkins: Reasonable to me
Rossen: Any feedback?
Rossen: Objections?
RESOLVED: Disallow animation-tainted substitutions in any
non-animatable property
CSS-wide keywords in fallbacks
------------------------------
github: https://github.com/w3c/csswg-drafts/issues/5325
TabAtkins: Another by Anders. Started out confused by behavior of
CSS wide keyword like initial in fallback of var. CSS
wide keywords are handled very early in process. Once
variables substitute it's later. Using initial
substitutes in the keyword initial which is usually
invalid. It's not using the initial machinery
TabAtkins: We've apparently always had behavior that if you use
css-wide keyword as a fallback we'll trigger the
appropriate behavior. emilio suggests FF has also always
had that.
TabAtkins: Reasonably useful behavior. Because everyone is already
doing it I don't see harm in specifying. Using initial
value as fallback of var triggers initial value behavior
assuming that the property only has that keyword because
of substitution
Rossen: Reasonable
Rossen: Additional thoughts or reasons why we shouldn't have
variables with initial value behave that what?
fantasai: That's implemented for revert? The rest handles at
computed but revert is cascade time
TabAtkins: No more or less than a previous item we did which also
triggered revert for forced-colors. It makes Anders a
little sad
fantasai: If we can rollback cascade why can't we treat invalid
values at declaration
TabAtkins: Big difference between doing this annoying thing when
authors ask and doing it any time a variable is invalid
fantasai: I think handling other keywords is fine, if revert is impl
it's great. Would also be nice to allow revert to previous
declaration.
fantasai: I would like to make sure all impl can handle revert
because specing it works.
TabAtkins: I believe that's not something we handle separate. Right
now none of the keywords are. All except perhaps revert
work in implementations even if revert is harder.
fantasai: Works for me. I would like revert to work but want to make
sure it does before we spec
<AmeliaBR> What happens if the keyword isn't the only value of the
property? `border: pink var(--line-width); --line-width:
inherit` Does the whole thing get the invalid / unset
behavior, or an inherit behavior?
Rossen: Sounds like fantasai is on board.
Rossen: Objections?
RESOLVED: Using initial value as fallback of var triggers initial
value behavior assuming that the property only has that
keyword because of substitution
Publication of Variables
------------------------
fantasai: Is there changes list and DoC?
TabAtkins: I will put them together
fantasai: Let's do that first and then resolve
astearns: And check to see if there are tests for changes
CSS Inline 3
============
leading-trim through to descendant line boxes
---------------------------------------------
github: https://github.com/w3c/csswg-drafts/issues/5237
fantasai: WG wanted to reconfirm
<fantasai> https://github.com/w3c/csswg-drafts/issues/5237#issuecomment-673312639
fantasai: I left it as first formatted line and no intervening
non-0 padding or borders. Whatever clarifications we take
for margin we should take here. This is the current text
dholbert: One question
dholbert: If you have an inline level span with a border sounds like
that would cause the leading trim to be excluded. I think
intent was only block level
fantasai: You're trimming the line's leading to the text of root
inline box which is by definition unstyled. We can clarify
that.
smfr: Are we stuck with name?
fantasai: no
<drousso> +1 to name change
smfr: Can we call it trim-leading? I think people will read it as
leading [leed-ing] trim not leading [led-ing] trim
<astearns> OK with name change
Rossen: Any reasons why we shouldn't do that?
<TabAtkins> We don't usually do verbs, but this is a confusing term
in the first place.
plinss: Not opposed but I think it'll have the same problem with
trim-leading
fantasai: I'm also open to other terms. That's the first one we came
up with
Rossen: We can resolve on the rename. What about proposed
definition? Can we resolve on that?
Rossen: Objections?
RESOLVED: Accept the proposed text
Rossen: Rename to trim-leading. Objections?
RESOLVED: Rename the property from leading-trim to trim-leading
CSS Pseudo Elements
===================
Add a highlight pseudo-element for find-in-page or scroll-to-text
-----------------------------------------------------------------
github: https://github.com/w3c/csswg-drafts/issues/5233
Rossen: Is chris on?
Rossen: Any of the Google folks on this?
Problems with styling ::first-letter with punctuation
-----------------------------------------------------
github: https://github.com/w3c/csswg-drafts/issues/2040
Rossen: We discussed, no resolution.
fantasai: This probably is too long
CSS Values
==========
Add url() alias that does not accept unquoted URLs
--------------------------------------------------
github: https://github.com/w3c/csswg-drafts/issues/541
<TabAtkins> https://drafts.csswg.org/css-values/#urls
TabAtkins: About 4 years ago took a resolution to add alias of url
that only accepts strings. Right now url parsing you
can't provide url via a function. Can't pull from attr
etc.
TabAtkins: Finally added it in. It's trival spec text. Identical to
url but without special parsing. Added explanation as why
it exists.
TabAtkins: Name is only question. I specced as fetch(). I don't care
what we name it as long as it's not uri(). Good to hear
other ideas or if people like fetch. Need to resolve on a
name so we can call this done
<ericwilligers> We can use href as it is used in SVG
<florian> +1 to src
fantasai: I like src. href and location aren't good. location is too
long and href it's not about hypertext
<florian> -1 to [u|i]ri
Rossen: Between fetch and src
Rossen: Which do we lean toward? fantasai votes src and florian +1
<plinss> +1 src
Rossen: Objections to name it src?
* fantasai notes -1 from leaverou on fetch()
RESOLVED: Rename fetch() to src()
Rossen: Do we need to republish?
TabAtkins: Soon, but needs review first
Rossen: We're out of short topics.
Rossen: I didn't expect to get to topic 15, but it was requested as
a delay. Unless anyone feels strongly to discuss w/o rune
let's wait. That's the end of the agenda
Rossen: Unless there's a 5min topic we can adjourn early
Rossen: 15 topics on the agenda and we end early. Thank you everyone
for calling in
Received on Thursday, 3 September 2020 10:22:20 UTC