- From: Dael Jackson <daelcss@gmail.com>
- Date: Wed, 7 Nov 2018 21:14:26 -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.
=========================================
Geometry API
------------
- RESOLVED: Republish CR of Geometry API spec
Sizing
------
- RESOLVED: Add jensimmons as co-editor of Sizing spec
- jensimmons requested review of her proposal to prevent overflow in
a container with an explicit aspect ratio (Issue #3268)
Shadow Parts
------------
- RESOLVED: FPWD for Shadow Parts spec
CSS Images
----------
- RESOLVED: optimizeQuality behaves the same as smooth (Issue #3283)
CSS Grid
--------
- RESOLVED: Serialize grid-template-areas as simplified computed
value for both specified and computed value (Issue #3261)
Fragmentation
-------------
- RESOLVED: Define that margin collapsing between first or last
child behaves same as between sibling children (Issue
#3073)
- RESOLVED: Republish CR of Break L3.
- RESOLVED: FPWD of CSS Break L4
Selectors
---------
- The discussion on :blank (Issue #1967) was reopened to confirm
that the group no longer saw the compat risk that they
originally sited when not making the change 3 years before. The
members on the call generally believed someone needed to commit
to implementing first or the decision should be reversed however
there weren't enough members on the call to decide on their path.
Call Times & Agendas
--------------------
- New tags will be added to github to help indicate which agenda+
items should happen on an APAC time call and which should only
happen during a normal timed call.
===== FULL MINUTES BELOW ======
Agenda: https://lists.w3.org/Archives/Public/www-style/2018Nov/0001.html
Present:
Rossen Atanassov
Tab Atkins (IRC Only)
David Baron
Dave Cramer
Elika Etemad
Dael Jackson
Cameron McCormack
Manuel Rego Casasnovas
Florian Rivoal
Jen Simmons
Markus Stange
Alan Stearns
Eric Willigers
Regrets:
Rachel Andrew
Fergal Daly
Tony Graham
Chris Harrelson
Chris Lilley
Niget Megitt
Michael Miller
François Remy
Geoffrey Sneddon
Lea Verou
Scribe: dael
Rossen: First I wanted to apologize for the mix up during today's
conference call. I sent by mistake an agenda with the
regular call information. Only 4 people read the email and
showed up. Obviously we intended APAC friendly, sorry about
the mess up
Rossen: Are there any additional agenda requests or anything we want
to change?
Publications & Editors
======================
Selectors 3
-----------
Rossen: First is recognition and congrats to authors of Selectors 3
which is now a recommendation.
Rossen: Thank you for all the hard work and getting spec to rec.
Rossen: We also have CRs that were published and those deserve
congrats
* florian yeah! publications :)
Geometry API
------------
Rossen: Speaking of CR are any Geometry API authors on the call?
Chris and Dirk are currently editing
Rossen: Is there a rule that suggests we can't do CR update without
editors on?
florian: I don't think so. If they're in disagreement it's bad form
Rossen: They're both asking for updated CR
<TabAtkins> Heh, yeah, don't publish above their objections, but
fine to approve without them.
Rossen: Objections to republish CR of Geometry API spec?
<TabAtkins> No objection.
RESOLVED: Republish CR of Geometry API spec
Sizing
------
Rossen: There was interest from jensimmons to start co-editing
Sizing spec. That's related to intrinsic ratio feature
Rossen: I'd like to ask WG if there are objections to adding
jensimmons as co-editor
<florian> +1
<astearns> +1
RESOLVED: Add jensimmons as co-editor of Sizing spec
* dauwhe_ hooray!
Rossen: This is awesome.
<jensimmons> :)
Shadow Parts
------------
Rossen: Requested as FPWD. We discussed it during TPAC. Since the
editor addressed all feedback provided
Rossen: Are there any objections or does anyone want additional time
to review?
RESOLVED: FPWD for Shadow Parts spec
Rossen: Congrats to fergal and others that worked on the draft
CSS Images
==========
image-rendering should support SVG 1.1 values
---------------------------------------------
github: https://github.com/w3c/csswg-drafts/issues/3283
Rossen: Who can represent this?
ericwilligers: I'm here
ericwilligers: This was my mistake. I missed that it says optimize
was deprecated. Coming out of that we fix
optimizeQuality should go to smooth rather than auto.
Right now we're throwing away information
Rossen: Is the value set auto | smooth ?
<TabAtkins> auto | smooth | pixelated |
<other-thing-i-forget-not-relevant>
<TabAtkins> crisp-edges
<TabAtkins> I'm happy to do "smooth"
ericwilligers: SVG optimizeQuality will become smooth instead of auto
ericwilligers: I wanted other thoughts. Current CSS images says
optimizeQuality is meaningless
<TabAtkins> "auto" === "smooth" in practice
Rossen: Any others on the call that know or care about this?
dbaron: What is the proposed change?
Rossen: ericwilligers can you summarize?
ericwilligers: I'll type it
<ericwilligers> This property previously accepted the values
optimizeSpeed and optimizeQuality. Was These are now
deprecated; a user agent must accept them as valid
values but must treat them as having the same
behavior as pixelated and auto respectively, and
authors must not use them. Now These are now
deprecated; a user agent must accept them as valid
values but must treat them as having the same
behavior as pixelated and smooth respectively, and
authors mus[CUT]
<ericwilligers> optimizeQuality will now map to smooth instead of
auto.
<Rossen> property is image-rendering
ericwilligers: What we're saying is that optimizeSpeed and
optimizeQuality are changing
Rossen: Auto otherwise was sometimes pixelated?
<TabAtkins> auto is "whatever you want", but in practice it's
"smooth"
ericwilligers: Auto was default. Previously images spec said
optimizeQuality was equivalent to not setting it at
all
dbaron: Seems reasonable. Unless there's an incompatibility I'm not
thinking about
Rossen: Other opinions?
<TabAtkins> optimizeQualtiy being equal to "auto" is because, at the
time I wrote those mappings, we just had auto and
pixelated
<TabAtkins> I'd map it to "smooth" today
ericwilligers: No implementor ships smooth. They all ship
optimizeQuality. So we should say people can ship
smooth
ericwilligers: Smooth should be cleared for shipping
Rossen: Well shipping is a UA business decision. But we can say
value smooth is initial value for
ericwilligers: Initial value is auto
Rossen: Auto remains as initial.
Rossen: optimizeQuality becomes smooth
Rossen: Proposal: optimizeQuality is replaced by smooth
ericwilligers: [missed]
<ericwilligers> optimizeQuality behaves the same as smooth, instead
of behaving the same as auto.
<ericwilligers> (Just like the existing spec text that optimizeSpeed
behaves the same as pixelated)
florian: Parallel we do have a thing to clear for shipping. In some
cases pre-CR we say a feature is safe to ship. Browsers can
still decide after that
<dbaron> yeah, +1 to Florian, I was going to raise the same thing
once we got the resolutions down
Rossen: For sure. but this is a technical decision for a particular
property
<TabAtkins> "clear for shipping" means that we're approving it for
shipping despite the spec not being CR. It has nothing
to do with impls deciding to ship or not
* rego thinks about https://drafts.csswg.org/css-logical/#issue-3d880eb1
as an example
rossen: Objections to optimizeQuality behaves the same as smooth ?
RESOLVED: optimizeQuality behaves the same as smooth
CSS Grid
========
How to serialize the strings in grid-template-areas?
----------------------------------------------------
github: https://github.com/w3c/csswg-drafts/issues/3261
Rossen: TabAtkins is IRC only. fantasai are you on?
ericwilligers: I can give background
<TabAtkins> Firefox preserves strings exactly. (as normal for
strings) Other browsers serialize in simplified form.
ericwilligers: I wrote a wpt so serialization was similar to blink/
edge/safari. FF was acting correctly from spec,
though, and the wpt was wrong.
ericwilligers: Question is what does group believe. I think spec is
unclear.
ericwilligers: We can defer if no one thought it though.
heycam: If spec doesn't say something else it's natural for strings
to retain exact values. normalization inside string value
feels a bit weird to me
ericwilligers: Other argument is 3 of 4 browsers normalize
florian: We have a micro language in the strings. It's not
monolithic. normalization isn't crazy.
heycam: Did we consider if we want normalization only for computed
values?
Rossen: For computed values we're going to do simplified and for
specified return actual string?
heycam: Feels more consistent with CSS
ericwilligers: I had same suggestion
Rossen: This would require from current impl FF would need to
change. I guess it's up to you if you're okay to change
heycam: Not a big deal to change. More about what makes sense
ericwilligers: If only computed value normalizes all browsers have
to change. Everyone except FF changes specified
heycam: I'm arguing for what makes more sense rather from impl
Rossen: I don't think anyone is arguing that we want to return
simplified for specified.
ericwilligers: That's what 3 browsers do
Rossen: For both specified and computed?
ericwilligers: Yes
Rossen: So minimum implementation cost would be FF to return
specified
ericwilligers: That was my original suggestion and original WPT
Rossen: dbaron or heycam? What do you think?
dbaron: I think heycam had different opinion. From changing
implementation I think it's doable either way. For what
behavior ought to be I think I'm more okay than heycam since
it seems we're defining a different data type. And I'm okay
saying this data type normalizes
heycam: I'm not feeling strongly. Maybe even CSSOM guidelines about
shortest values we can squint and make this fall under that
guideline
Rossen: Objections to serialize grid-template-areas as simplified
computed value for both specified and computed value?
RESOLVED: serialize grid-template-areas as simplified computed value
for both specified and computed value
Selectors 4
===========
Rename :matches() to :is()
--------------------------
github: https://github.com/w3c/csswg-drafts/issues/3258
ericwilligers: Is is now free because a different discussion we had
at TPAC. Some people thought that better than
:matches()
Rossen: So drop :matches() and replace with :is()
ericwilligers: Or it's a depreciated alias
Rossen: Anyone from Safari on the call?
Rossen: Doesn't sound like. They're ones effected by change in terms
of implementation. We can call for consensus and if anything
is raised by webkit folks we can revisit
florian: We have low attendance. I'm not sure if this is good time
to rename things.
Rossen: Are you saying to could have webcompat issues?
florian: A bit, maybe
Rossen: Also okay to defer to next week
florian: I support the change, but doing this w/o impl sounds...I
don't know
Rossen: Does anyone on the call feel strongly about resolving now?
If not we'll postpone
Rossen: Let's postpone until next week
Fragmentation
=============
What happens to block margins that aren't between block-level boxes?
--------------------------------------------------------------------
github: https://github.com/w3c/csswg-drafts/issues/3073
fantasai: This was the one issue open on fragmentation. dbaron
suggested we can resolve
fantasai: What happens to margins...we have defined when breaking
between siblings, but not if you break before the first
sibling or after the last.
fantasai: Typically you don't break there, you break before or after
parent. You're only allowed to break there if there's a
gap. If there's just extra space after layout you can break
fantasai: Proposed is do same as break at siblings. Truncate margins
if forced, don't if unforced.
fantasai: Where that shows up is if you are in a multicol and you
have a bunch of stuff that breaks. You can tell if you
truncated margin b/c height of multicol will be different
if margin is there
Rossen: Behavior sounds reasonable. This is what dbaron is proposing.
Rossen: Other opinions?
fantasai: He just wanted a definition. Not sure if he wanted a
specific one
<dbaron> yeah, sounds good to me... though not sure that it's what I
was proposing
dbaron: I don't think I was proposing something. sgtm
Rossen: Objections to define that margin collapsing between first or
last child behaves same as between sibling children ?
RESOLVED: Define that margin collapsing between first or last child
behaves same as between sibling children
Publication
-----------
fantasai: That's in L4, I'll edit into L3 then republish with that
Rossen: Yes
florian: L3 is CR
fantasai: We resolved to publish already. There's just this one
issue made sense to close it
Rossen: Objections to republish CR of Break L3 with this change?
RESOLVED: republish CR of Break L3 with this change
Selectors
=========
:valid-within / :invalid-within pseudo-classes
----------------------------------------------
github: https://github.com/w3c/csswg-drafts/issues/3072
Rossen: Discussed between a few folks. I think only heycam is on the
call of that group
Rossen: Is this worth discussing now heycam or should we wait?
heycam: I don't have a strong opinion. I defer to emilio and amelia
Shadow Parts
============
Confirm browser support
-----------------------
github: https://github.com/w3c/csswg-drafts/issues/2368
Rossen: This was pushed out of F2F agenda and back into the call
Rossen: I'm not sure what discussion is needed.
astearns: May be we didn't take the label off a month ago
Rossen: It was re-added by fergo after we discussed
Rossen: He asked for fpwd which we approved. Not sure this is valid
anymore
Rossen: I'll remove F2F+ and agenda+
Selectors
=========
Case-sensitive attribute selectors
----------------------------------
github: https://github.com/w3c/csswg-drafts/issues/2101
Rossen: Anyone to represent this?
[silence]
decide on :blank
----------------
github: https://github.com/w3c/csswg-drafts/issues/1967
Rossen: Added last by fantasai
fantasai: Added the flag because annevk wanted to know why we
decided to change :empty behavior though 3 years ago we
thought it maybe was not possible
fantasai: Rather than making edits to spec I decided to re-raise to
WG
Rossen: dbaron can you perhaps remember why we did what we did?
dbaron: Trying to understand this issue
florian: I think we just thought it was a compat risk we weren't
willing to take. When we discussed last we thought the
cases this would impact don't exist much. Had to say if we
were right
dbaron: Has someone volunteered to be first impl to change?
Rossen: I'm not volunteering Edge for this one
dbaron: I think if group makes changes like this but no one is happy
to be first impl to ship it won't happen
Rossen: Agree. Also, if Chrome changed first given their market
share everything becomes easier.
Rossen: Curious is Chrome is willing to change first
Rossen: I know TabAtkins is IRC only but maybe he can answer
<TabAtkins> ???
<TabAtkins> Dunno.
ericwilligers: Defer for a week?
Rossen: Curious if there's anything we need to do. We have a
resolution. Are we trying to undo it? Or is anyone going to
impl it?
Rossen: Those are the choices on the table
Rossen: Doesn't look like any impl is stepping up. Not sure if
there's enough people on call to revert previous resolution
Rossen: So I agree to ericwilligers to defer to next week.
Call Times & Agendas
====================
Rossen: There were some multicol, but RachelAndrew couldn't make the
call.
Rossen: We've got 13 minutes.
* fantasai looking for review on
https://lists.w3.org/Archives/Public/www-style/2018Oct/0014.html
Rossen: One question from me: given low attendance of APAC calls and
we deferred half agenda I'm questioning if we should
continue keeping first week as APAC or stick to one regular
time.
florian: We've got a few people from China who joined so we should
give them time to find their way in. It's a valid question
to ask though
Rossen: Not intending to cancel next month. Generally surveying this
audience
Rossen: We might start adding a different tag for APAC agenda+
florian: Good idea
* fantasai proposed Agenda+ APAC last year, for some reason it
wasn't wanted
Rossen: We can tally up if we have enough agenda for people who need
APAC time
florian: Changing meeting time from week to week doesn't sound good
Rossen: We'd have a week
florian: Personally for me APAC time is nicer. but I'll attend the
middle of the night ones too. Not sure which tag I'd use
Rossen: You're an exception because you're always on the call. I
think we have folks that dial in only on APAC so this is for
them
heycam: This time of year might be able to find a time acceptable
for everything. Not as simple for 6 months of the year.
<dbaron> heycam, that depends on which places in APAC you want to
accommodate...
Rossen: Let's end here. astearns and I will walk through calendar
and figure out if there's an intersection of time that works
for everyone. And we'll figure out if agenda+ APAC label is
needed
fantasai: We have at least one person with a strong preference...2
members that are APAC only: heycam and birtles
fantasai: I think agenda+ APAC makes sense so they can flag issues.
And if we think there's an issue for their radar we can
flag. And they can swap an agenda+ to an agenda+ APAC
Rossen: That was my point too. Wanted it easier for someone to say
I'm APAC only
florian: Makes sense. I think we should not skip the APAC call even
if we don't have any topics. We should keep having the
call. It's significantly more convenient for many people
fantasai: We should have agenda+ non APAC since some people can't
make APAC call.
Rossen: Let's figure out tagging and go from there. Perhaps we can
add strongly prefer APAC tag that people can add to an
agenda+. We'll work it offline
Rossen: Any other topics?
Sizing
======
<jensimmons> https://github.com/w3c/csswg-drafts/issues/3268
jensimmons: There's...in thinking about aspect ratios occurred we
might not need as much complexity in giving authors way
to define the aspect ratio and let box grow to content
jensimmons: Wrote an issue [irc link] it would be great for folks to
look and comment, especially those that understand
min-height well
Fragmentation
=============
<fantasai> https://drafts.csswg.org/css-break-4/#break-margins
fantasai: I drafted fragmentation L4 which is where margin-break was
going
fantasai: It's looking for FPWD. If anyone thinks it's good it's one
property. Or take a week or two to review.
Rossen: Just this one property?
fantasai: Yep.
Rossen: I'm for going forward. I want to hear others.
Rossen: Anyone want an additional work to go over margin-break
property added for Break L4?
florian: Good to me.
Rossen: Objections to FPWD of CSS Break L4?
RESOLVED: FPWD of CSS Break L4
Rossen: yay!
<fantasai> https://lists.w3.org/Archives/Public/www-style/2018Oct/0014.html
fantasai: Here's margin-trim status^
fantasai: Rough draft in box 3, I wanted WG for review. Once that's
concluded update the WD.
fantasai: Don't need to resolve today.
fantasai: Or we can.
Rossen: Call to action for people to read. Then we can resolve
Rossen: Anything else?
Rossen: Thanks for calling and we'll talk next week
Received on Thursday, 8 November 2018 02:15:23 UTC