<scribe> ScribeNick: dael

Rossen: We've only got a few people on the line. We'll give it a few more minutes for people to join
... Let's say we'll start in 2 minutes
... One more minute and we'll go
... It's 3 minutes past. We'll try to make progress on as many issues as we can
... As usual, any additional agenda items or changes to make?

Request for a FPWD for CSS Break

<myles_> I’ll be in IRC only today

<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

<dbaron_> BTW, I was briefly on the teleconference but it was too noisy here for me to hear, so I gave up

Rossen: With that I'll call for opinions or objections
... Objections to FPWD for CSS Break L4?

RESOLUTION: FPWD for CSS Break L4

Request to publish FXTF specs under 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.
... If no, we'll resolve on each
... Filter Effects

<TabAtkins> +1 to republishing all

Rossen: Obj?

RESOLUTION: Publish Filter Effects under CSSWG

ro

Rossen: Web animations L1

RESOLUTION: Publish Web Animations under CSSWG

Rossen: Composition and Blending. Objections?

RESOLUTION: Publish Composition and Blending under CSSWG

Rossen: Fill and stroke. Objections?

<astearns> also +1 to republishing everything

RESOLUTION: Publish Fill and Stroke under CSSWG

Rossen: Masking. Objections?

RESOLUTION: Publish Masking under CSSWG

Rossen: Motion Path. Objections?

RESOLUTION: Publish Motion Path under CSSWG

Rossen: Geometry Interfaces. Objections?

RESOLUTION: Publish Geometry Interfaces under CSSWG

<fantasai> https://drafts.csswg.org/css-box-3/#margin-trim

fantasai: astearns points out we should point ^ as a WD to get margin trim published

Rossen: WD?

RESOLUTION: Republish CSS Box 3 as a WD

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 boundries 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 boundry
... Richard asked to have that changed. Asked Jonathan for his opinion and that FF does that is a problem. We're keeping current set of rules is that latest on the issue
... Wanted to ask if there's anyting 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.
... Objections?

RESOLUTION: Close issue #698 no shaping across positive margins, borders, pading

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: Then text engine heuristics might apply other features

<fantasai> * text engines have heurstics for broken stuff, spec shouldn't override

fantasai: Committed that.
... 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: Ccomments 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 [read]
... Should say optional ligatures as is in spec. Then clarify that if you set letter spacing later it disables all ligatures, not just common
... Also a suggestion there should be step 6 that says if the engine does stuff under the hood it might take precedence.
... I don't know about that, it's beyond my knowledge.
... 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.
... Making sure text doesn't conflict with font and says go look for exact details. I think that's correct.
... [reads commit]
... 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.
... Proposal to make changes to that list
... 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: I know myles_ is reading on IRC. Hoping he'll chime in
... For CSS Text L3 would any additional changes be required?
... 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?

RESOLUTION: Accept changes in https://github.com/w3c/csswg-drafts/commit/caf1e4747f2bd906bb9f671af8c463b28b97deda

<dauwhe> +1

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 tranformation dependent on east asian width. Emoji are very inconsistent in east Asian width so line break is different depending on emoji.
... florian figured out unicode we can use. Pushed that in. If people are interested they may want to look more deeply
... 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
... Obj to republish?

RESOLUTION: Publish a new WD of CSS Text L3

fantasai: That brings us to all issues closed and waiting for review from commentors
... 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?
... 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
... 19th is deadline for additional comments or issues before we transition

fantasai: I'll post an announcement

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 FF and minor for others. Turns out when I wrote syntax I didn't know scalar vs codepoints distinction
... When I wrote I said codepoints. Every algo produces only scalar except for when you assign a domstring. All other methods like decoding or escaping produce only scalar values.
... Seems like I don't want non-scalar values; would be more consistant to block the codepoints in all places.
... I propose we add a new step to codepoint filtering that says they are replaced and all entry points work on pure scalar
... FF does this already, Chrome does allow surrigate codepoints in because we're suing domstrings
... Simplifies model.
... Yea or Nay, trivial change on my part

Rossen: I'm assuming FF people will be okay. They're mostly out, but I'd be surprised if they oppose. Chrome is in favor. I don't thinkw e have Apple
... Objections to the proposed change?

<plinss> +1

RESOLUTION: Add the additional codepoint filtering

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.
... 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.
... Unclear if it means before when foo is hovered or when foo.before is hovered.

<TabAtkins> .foo:matches(::before).bar is invalid, then

fantasai: If we're going to define we have to define if a selecotr ends in a pseudo element and has same meaning as if you placed element outside of matches.

<TabAtkins> .foo:matches(::before, .baz).bar is invalid, too

fantasai: That's invalid, right.

TabAtkins: Reasonable sort of thing to define on
... 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 ^
... You want to assign a style to multiple psuedo elements. Can't do that with is/ btw ;) right now. That's annoying, I agree
... Reasonable thing. Even bikeshed stylesheet would like to do a selector like this.

<TabAtkins> .foo:matches(::before, .bar)

<TabAtkins> ^ invalid

TabAtkins: Another option is we're more limited and you can put psuedo 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 b/c 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.

TabAtkins: ericwilligers we don't support pseudo elements in matches right now, correct?

ericwilligers: Correct

<dbaron_> It seems like you might want to ensure that all branches of the :matches end in the same restriction state

TabAtkins: FF or Edge, how does this sound. Should I close no change and Safari violates spec? Or do we want?

<TabAtkins> dbaron_, I agree with that as a good restriction if we go this way

Rossen: Curious to hear from Safari folks.
... 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
... 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
... Objections to resolving no change?

fantasai: I think deferred
... Close no change means we don't want to accept. We might accept in future
... I'd prefer...if we're going to consider in the future we leave it open for selectors 5. If it's a baad idea we close no change.

Rossen: Don't disagree
... objections to defer to L5?

RESOLUTION: Defer this issue to L5

publication

fantasai: We just published. Nothing has changed since then

Rossen: Okay, that'sfine

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. Wnat 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.
... Underline typicially 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

<dbaron_> It might also be fun to define what element they're overflow from.

fantasai: I think it's fine. If you're placing the underline that low you're asking for trouble

<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.
... Objections to resolving on definition that text decoration is considered ink overflow and not layout

RESOLUTION: text decoration is considered ink overflow and not layout

font-display says it's valid in @font-feature-values but it isn't an at-rule

Rossen: Do we have people for this?
... Or defer until myles and chris are around?

TabAtkins: Let's defer

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 prop of vertical align. Vertical-align is a shorthand of baseline shift and alignement baseline
... Adding a switch to say if we care about first or last baseline. Is it a sep prop so it cascades? I'm not sure how to think through this problem

Rossen: Anyone on the call or IRC with an opinion?
... If not we can defer

github: none

Rossen: Defer to next week
... 2 issues, 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 proide baseline rather then first or last
... Similar to first/last switch. It's a prop 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

github: none

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 Align 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.
... Objections to publishing CSS Box Align L3 WD?

RESOLUTION: Publish CSS Box Align L3 WD

Rossen: Anything else?

astearns: Given we have resolutions for FXTF spec publication and taking them to CSS, should we close FXTF mailing list?

FXTF logistics

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 nec. 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?

Rossen: Okay, sounds good

<fantasai> yes, plinss said so

Rossen: Anything else?

<plinss> yes

Rossen: I'll give us 2 minutes back. Thanks for calling, next week will be a regular call. Thank you

<Rossen> trackbot, end meeting

This is scribe.perl Revision: 1.154  of Date: 2018/09/25 16:35:56  
Check for newer version at http://dev.w3.org/cvsweb/~checkout~/2002/scribe/

Guessing input format: Irssi_ISO8601_Log_Text_Format (score 1.00)

Succeeded: s/no change/no shaping across positive margins, borders, pading/
Succeeded: s/matches/is/ btw ;)/
Succeeded: s/checking/checking, even if they're all pseudo-elements/
Succeeded: s/MathML folks/math on web pages folks/
Succeeded: s/that/so/
Default Present: dael, dauwhe, zheng_xu, ericwilligers, Rossen, astearns, fantasai, plinss, TabAtkins
Present: dael dauwhe zheng_xu ericwilligers Rossen astearns fantasai plinss TabAtkins
Found ScribeNick: dael
Inferring Scribes: dael

WARNING: No meeting chair found!
You should specify the meeting chair like this:
<dbooth> Chair: dbooth

Found Date: 05 Dec 2018
People with action items: 

WARNING: Input appears to use implicit continuation lines.
You may need the "-implicitContinuations" option.


WARNING: IRC log location not specified!  (You can ignore this 
warning if you do not want the generated minutes to contain 
a link to the original IRC log.)