- From: Dael Jackson <daelcss@gmail.com>
- Date: Thu, 6 Dec 2018 19:32:05 -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 Break
---------
- RESOLVED: FPWD for CSS Break L4
FXTF Specs move to CSSWG
------------------------
- RESOLVED: Publish Filter Effects under CSSWG
- RESOLVED: Publish Web Animations under CSSWG
- RESOLVED: Publish Composition and Blending under CSSWG
- RESOLVED: Publish Fill and Stroke under CSSWG
- RESOLVED: Publish Masking under CSSWG
- RESOLVED: Publish Motion Path under CSSWG
- RESOLVED: Publish Geometry Interfaces under CSSWG
CSS Box 3
---------
- RESOLVED: Republish CSS Box 3 as a WD
CSS Text
--------
- RESOLVED: Close issue #698: (Cursive shaping breaks needs better
scoping) no shaping across positive margins, borders,
padding
- RESOLVED: Accept changes in
https://github.com/w3c/csswg-drafts/commit/caf1e4747f2bd906bb9f671af8c463b28b97deda
- RESOLVED: Publish a new WD of CSS Text L3
- The group will target 19 December to request a CR transition.
Anyone wishing to review or add comments should do so in advance.
CSS Syntax
----------
- RESOLVED: Add the additional codepoint filtering
Selectors 4
-----------
- RESOLVED: Defer this issue (Issue #2284: Why \"Pseudo-elements
cannot be represented by the matches-any
pseudo-class\"?) to L5
Text Decor 4
------------
- RESOLVED: Text decoration is considered ink overflow and not
layout (Issue #3272)
CSS Alignment
-------------
- RESOLVED: Publish CSS Box Align L3 WD
===== FULL MINUTES BELOW ======
Agenda: https://lists.w3.org/Archives/Public/www-style/2018Dec/0005.html
Present:
Rossen Atanassov
Tab Atkins
David Baron (IRC Only)
Dave Cramer
Elika Etemad
Dael Jackson
Peter Linss
Alan Stearns
Eric Willigers
Jeff Xu
Regrets:
Rachel Andrew
Angelo Cano
Emilio Cobos Álvarez
Tony Graham
Chris Harrelson
Chris Lilley
Myles Maxfield
Nigel Megitt
Michael Miller
François Remy
Florian Rivoal
Jen Simmons
Lea Verou
Sean Voisen
Greg Whitworth
Scribe: dael
Rossen: It's 3 minutes past. We'll try to make progress on as many
issues as we can.
Rossen: As usual, any additional agenda items or changes to make?
CSS Break
=========
Request for a FPWD for CSS Break
--------------------------------
<fantasai> https://drafts.csswg.org/css-break-4/#changes-level-4
Rossen: Fragmentation L4. Only 2 changes from L3- margin break
property and the always and all values added
Rossen: With that I'll call for opinions or objections
Rossen: Objections to FPWD for CSS Break L4?
RESOLVED: FPWD for CSS Break L4
FXTF Specs move to CSSWG
========================
Rossen: We have already recorded resolutions to take over and get
this under CSSWG. I wanted to know if anyone had reasons to
object to this.
Rossen: If no, we'll resolve on each
<TabAtkins> +1 to republishing all
<astearns> also +1 to republishing everything
Rossen: Filter Effects
Rossen: Obj?
RESOLVED: Publish Filter Effects under CSSWG
Rossen: Web animations L1
RESOLVED: Publish Web Animations under CSSWG
Rossen: Composition and Blending. Objections?
RESOLVED: Publish Composition and Blending under CSSWG
Rossen: Fill and stroke. Objections?
RESOLVED: Publish Fill and Stroke under CSSWG
Rossen: Masking. Objections?
RESOLVED: Publish Masking under CSSWG
Rossen: Motion Path. Objections?
RESOLVED: Publish Motion Path under CSSWG
Rossen: Geometry Interfaces. Objections?
RESOLVED: Publish Geometry Interfaces under CSSWG
CSS Box 3
=========
<fantasai> https://drafts.csswg.org/css-box-3/#margin-trim
fantasai: astearns points out we should publish ^ as a WD to get
margin trim published
Rossen: WD?
RESOLVED: Republish CSS Box 3 as a WD
CSS Text
========
Cursive shaping breaks needs better scoping
-------------------------------------------
github: https://github.com/w3c/csswg-drafts/issues/698#issuecomment-437944436
Rossen: Reopened a couple weeks ago.
fantasai: This was an issue where Richard asked us to clarify or
change where we have breaks across element boundaries or
not. I think he was asking for it to not break when
there's a border. There's a span mid-word. Current spec
requires if you have border, margin, or padding we don't
shape across that boundary
fantasai: Richard asked to have that changed. Asked Jonathan for his
opinion and it was that Firefox does that is a problem.
We're keeping current set of rules is that latest on the
issue
fantasai: Wanted to ask if there's anything to add. If not I'll
close editorial for clarifications, but no change
Rossen: I support the no change. Change would be nontrivial and I'm
not sure how it would impact web compat.
Rossen: Objections?
RESOLVED: Close issue #698: no shaping across positive margins,
borders, padding
Clarify what ligatures are optional
-----------------------------------
github: https://github.com/w3c/csswg-drafts/issues/2644#issuecomment-432774658
<fantasai> https://github.com/w3c/csswg-drafts/issues/2644#issuecomment-422075536
fantasai: This one I committed some changes to CSS Text to define
what myles_ suggested is correct. myles_ posted ^
<fantasai> * rlig is required, no other ligatures are required
<fantasai> * text engines have heuristics for broken stuff, spec
shouldn't override
fantasai: Committed that.
fantasai: There was discussion about needing update to font
<fantasai> https://github.com/w3c/csswg-drafts/commit/caf1e4747f2bd906bb9f671af8c463b28b97deda
fantasai: Commit for CSS 3 Text ^
<fantasai> https://github.com/w3c/csswg-drafts/issues/2644#issuecomment-437085666
fantasai: Comments about changing fonts to clarify interactions.
Wanted WG to discuss. Changes are largely that the section
that defines how font features interact. There's a section
that says [reads]
fantasai: Should say optional ligatures as is in spec. Then clarify
that if you set letter spacing later it disables all
ligatures, not just common
fantasai: Also a suggestion there should be step 6 that says if the
engine does stuff under the hood it might take precedence.
fantasai: I don't know about that, it's beyond my knowledge.
fantasai: Clarification to which ligatures are disabled should go in.
Rossen: What's in the PR of the 6?
fantasai: Changes made to text are committed. Basically clarifies
optional ligature. I didn't think that text should spec
what that means.
fantasai: Making sure text doesn't conflict with font and says go
look for exact details. I think that's correct.
* fantasai reads
https://github.com/w3c/csswg-drafts/commit/caf1e4747f2bd906bb9f671af8c463b28b97deda
fantasai: I'm guessing no issues with this one. Need to figure out
font spec and if there should be a step 6
<fantasai> https://github.com/w3c/csswg-drafts/issues/2644#issuecomment-437085666
fantasai: If you look at ^ there's a list of precedence of parts of
CSS that inject font feature settings.
fantasai: Proposal to make changes to that list
fantasai: Wanted to bring that up to see if we should make those
changes to font. If so it should be fonts 3 as well as 4
Rossen: 3? Isn't that too late?
fantasai: Clarification to what's happening.
Rossen: For CSS Text L3 would any additional changes be required?
Rossen: I know we need to take to font 3 and/or 4. What about Text 3?
fantasai: Nothing more. The commit went in.
Rossen: To close CSS Text discussion, are there any objections to
proposed changes in the commit
https://github.com/w3c/csswg-drafts/commit/caf1e4747f2bd906bb9f671af8c463b28b97deda
?
<dauwhe> +1
RESOLVED: Accept changes in
https://github.com/w3c/csswg-drafts/commit/caf1e4747f2bd906bb9f671af8c463b28b97deda
Publish an updated WD of css-text-3
-----------------------------------
Rossen: Anything else before we republish?
<fantasai> https://github.com/w3c/csswg-drafts/issues/337#issuecomment-444316214
fantasai: There's another issue florian and I tried to figure out.
Ran into a problem with emoji. Line break transformation
is dependent on east Asian width. Emoji are very
inconsistent in east Asian width so line break is
different depending on emoji.
fantasai: florian figured out unicode we can use. Pushed that in. If
people are interested they may want to look more deeply.
fantasai: Might want to review, but if people need more time we can
give it.
Rossen: florian isn't on, but I'm assuming you support his point.
fantasai: Yeah
Rossen: I would rather have koji and others look
fantasai: Yeah
Rossen: We can republish again
Rossen: Objections to republish?
RESOLVED: Publish a new WD of CSS Text L3
fantasai: That brings us to all issues closed and waiting for review
from commenters
fantasai: I wanted to set a target for transition to CR.
Rossen: Awesome
fantasai: When I post that we published, what date should we set as
deadline for review?
Rossen: Given holidays are upon us I expect less people will review.
What would be normal time frame. I think a couple weeks. Do
we have actual target dates that we set before asking for
transition?
Rossen: I don't recall us setting a precedent for 2 weeks.
fantasai: Usually post an announcement saying we plan on going to CR
soon, please send comments. Usually a case of what day do
we want to say
Rossen: Last call of this year is likely 19th. Is that a good target?
fantasai: Enough for me, don't know anyone else
Rossen: Let's try. If there's pushback we extend
Rossen: 19th is deadline for additional comments or issues before we
transition
fantasai: I'll post an announcement
CSS Syntax
==========
The tokenizer input should probably be a stream of scalar values,
not codepoints
-----------------------------------------------------------------
github: https://github.com/w3c/csswg-drafts/issues/3307
TabAtkins: This is a small change, no change for Firefox and minor
for others. Turns out when I wrote syntax I didn't know
scalar vs codepoints distinction
TabAtkins: When I wrote I said codepoints. Every algorithm produces
only scalar except for when you assign a DOMstring. All
other methods like decoding or escaping produce only
scalar values.
TabAtkins: Seems like I don't want non-scalar values; would be more
consistent to block the codepoints in all places.
TabAtkins: I propose we add a new step to codepoint filtering that
says they are replaced and all entry points work on pure
scalar
TabAtkins: Firefox does this already, Chrome does allow surrogate
codepoints in because we're using DOMstrings
TabAtkins: Simplifies model.
TabAtkins: Yea or Nay, trivial change on my part
Rossen: I'm assuming Firefox people will be okay. They're mostly
out, but I'd be surprised if they oppose. Chrome is in
favor. I don't think we have Apple
Rossen: Objections to the proposed change?
<plinss> +1
RESOLVED: Add the additional codepoint filtering
Selectors 4
===========
Why \"Pseudo-elements cannot be represented by the matches-any
pseudo-class\"?
--------------------------------------------------------------
github: https://github.com/w3c/csswg-drafts/issues/2284
fantasai: I wanted to ask if this is something we should try and
define or close as no change
TabAtkins: Valid.
TabAtkins: I know that safari allows pseudo elements, but it doesn't
make sense and I don't know why
<TabAtkins> .foo:matches(::before):hover
TabAtkins: This selector ^ bothers me.
TabAtkins: Unclear if it means before when foo is hovered or when
foo.before is hovered.
fantasai: If we're going to define we have to define if a selector
ends in a pseudo element and has same meaning as if you
placed element outside of matches.
<TabAtkins> .foo:matches(::before).bar is invalid, then
<TabAtkins> .foo:matches(::before, .baz).bar is invalid, too
fantasai: That's invalid, right.
TabAtkins: Reasonable sort of thing to define on
TabAtkins: It's weird and I don't like it, but if it's what we want
I'm okay
ericwilligers: What's the need for this?
<TabAtkins> .foo:matches(::before, ::after)
TabAtkins: Safari does it for selectors like ^
TabAtkins: You want to assign a style to multiple pseudo elements.
Can't do that with matches right now. That's annoying, I
agree
TabAtkins: Reasonable thing. Even bikeshed stylesheet would like to
do a selector like this.
<fantasai> s/matches/is/ btw ;)
<TabAtkins> .foo:matches(::before, .bar)
<TabAtkins> ^ invalid
TabAtkins: Another option is we're more limited and you can put
pseudo elements in if they're the only thing in the
selector. All options have to be pseudo elements
<TabAtkins> .foo:matches(::before:hover) is valid
TabAtkins: That would be okay way to deal
<plinss> .foo:matches(::before):matches(:hover) ?
<TabAtkins> Would be valid by my rule I think
fantasai: Thing that's tricky is different pseudo elements can be
followed by different things. No need to make first
example invalid because each branch is valid. If any
branch is invalid whole is invalid.
<dbaron> Pseudo elements seem like they might differ in what is
allowed after them
fantasai: More restrictive I'm not sure that gains us a whole lot.
You'll still need contextual checking, even if they're all
pseudo-elements.
<dbaron> It seems like you might want to ensure that all branches of
the :matches end in the same restriction state
<TabAtkins> dbaron, I agree with that as a good restriction if we go
this way
TabAtkins: ericwilligers we don't support pseudo elements in matches
right now, correct?
ericwilligers: Correct
TabAtkins: Firefox or Edge, how does this sound. Should I close no
change and Safari violates spec? Or do we want?
Rossen: Curious to hear from Safari folks.
* smfr we’re all in a meeting and can’t follow, sorry
Rossen: dbaron is on IRC [reads]
<dbaron> (where we need to be conservative about what is the same,
e.g. before and after OK but not selection)
<TabAtkins> :matches(::before, ::spelling-error) would be invalid
TabAtkins: before and after are fine, but before and spelling
wouldn't work because allow different things
ericwilligers: Safari uses different selector name. So it doesn't
matter too much.
TabAtkins: Not a backwards compat concern. It's what we want to do
for the future
TabAtkins: I'm perfectly fine saying close no change.
<dbaron> Still have mixed feelings about whether to allow pseudos in
v1
TabAtkins: dbaron is unsure. We can relax restriction later
<dbaron> (typing on phone, BTW)
Rossen: smfr said Safari folks can't follow because they're in a
meeting
Rossen: Objections to resolving no change?
fantasai: I think deferred
fantasai: Close no change means we don't want to accept. We might
accept in future
fantasai: I'd prefer...if we're going to consider in the future we
leave it open for selectors 5. If it's a bad idea we close
no change.
Rossen: Don't disagree
Rossen: Objections to defer to L5?
RESOLVED: Defer this issue to L5
publication
-----------
fantasai: We just published. Nothing has changed since then
Rossen: Okay, that's fine
Text Decor 4
============
Are text decorations visual overflow or layout overflow?
--------------------------------------------------------
github: https://github.com/w3c/csswg-drafts/issues/3272
Rossen: Raised by myles, fantasai added
fantasai: myles and I agree it should be ink overflow. Want to
confirm with WG. I think add to L3 and L4
Rossen: Implication is if you're editing and at the end of a
scrollable paragraph and what I type in becomes underlined
because syntax I won't be able to see that by scrollbar.
fantasai: If you choose and offset that places underline outside of
linebox.
fantasai: Underline typically in linebox and that's within
scrollable. You'd have to place the underline below the
line height before it disappears
Rossen: Trying to understand if we're okay with that
fantasai: I think it's fine. If you're placing the underline that
low you're asking for trouble
<dbaron> It might also be fun to define what element they're
overflow from.
<dbaron> But happy with ink overflow, I think
Rossen: [Reads dbaron ]
fantasai: Given painted at same layer as text, should overflow from
element painting the text
Rossen: Certainly content layer of the scroller...let's see
<fantasai> https://www.w3.org/TR/CSS2/zindex.html#each-box
Rossen: Should be container of element with text.
Rossen: Objections to resolving on definition that text decoration
is considered ink overflow and not layout?
RESOLVED: text decoration is considered ink overflow and not layout
CSS Fonts 4
===========
font-display says it's valid in @font-feature-values but it isn't
an at-rule
-----------------------------------------------------------------
Rossen: Do we have people for this?
Rossen: Or defer until myles and chris are around?
TabAtkins: Let's defer
CSS Inline
==========
Should first/last baseline values of `vertical-align` belong to
`alignment-baseline` or separate longhand?
---------------------------------------------------------------
github: https://github.com/w3c/csswg-drafts/issues/861
Rossen: fantasai can you summarize?
fantasai: There is a question of if these values should be
incorporated into alignment baseline or a sub property of
vertical align. Vertical-align is a shorthand of baseline
shift and alignment baseline
fantasai: Adding a switch to say if we care about first or last
baseline. Is it a separate property so it cascades? I'm
not sure how to think through this problem
Rossen: Anyone on the call or IRC with an opinion?
Rossen: If not we can defer
Rossen: Defer to next week
Rossen: 2 issues left, seems like 1st we can discuss
vertically align to nth-child
-----------------------------
github: https://github.com/w3c/csswg-drafts/issues/1339
fantasai: Top ask from math on web pages folks to say this element
will provide baseline rather then first or last
fantasai: Similar to first/last switch. It's a property so element
says "I'm providing baseline". Needs a more concrete
proposal then what's in issue
Rossen: Okay. If we can't make progress here, not going to be able
to do next one either
Rossen: We can wrap up early unless there's something else we can
discuss
fantasai: Trying to think if there's anything to publish. We can do
CSS Align- it is only minor change to it.
CSS Alignment
=============
Publication
-----------
Rossen: What's the change? Looking at changes section
<fantasai> https://github.com/w3c/csswg-drafts/commit/52f193c852b19616019df8f30d67cf2d67146a8a#diff-fe8d087fed2ccda3bdf57954b3ac8d75
fantasai: Minor clarifications. Mainly ^
Rossen: Okay.
Rossen: Objections to publishing CSS Box Align L3 WD?
RESOLVED: Publish CSS Box Align L3 WD
Rossen: Anything else?
FXTF logistics
==============
astearns: Given we have resolutions for FXTF spec publication and
taking them to CSS, should we close FXTF mailing list?
Rossen: Anything remaining between new SVG and CSSWG that needs to
be FXTF?
astearns: Only part of charter I'm aware of is working on the bits
of SVG that map to our properties
Rossen: Don't necessarily need FXTF for that, do we?
astearns: Nope
Rossen: Anyone on the call with a reason to keep FXTF ML going? If
no we can reach out to SVG.
[silence]
Rossen: Sounds like no one wants to hold onto it
plinss: Shut down FXTF server too?
Rossen: Yes
plinss: Whoever migrates ping me when you're done
<smfr> can we keep redirects alive?
<fantasai> yes, plinss said so
<plinss> yes
Rossen: Okay, sounds good
Rossen: Anything else?
Rossen: I'll give us 2 minutes back. Thanks for calling, next week
will be a regular call. Thank you
Received on Friday, 7 December 2018 00:32:57 UTC