W3C

- DRAFT -

Cascading Style Sheets (CSS) Working Group Teleconference

06 Nov 2017

Attendees

Present
iank_, lajava, Naina_Raisinghani, Google, melanierichards, surma, ericwilligers_, Javier_Fernandez, Igalia, cbiesinger, tantek, Vlad, zcorpan, smfr, myles, eae, leaverou, EricE_(observing), nainar, flackr, bkardell_, Tomoya_Kimura, xidorn, jihye, rachelandrew, plinss, jeff, clapierre, George_Kerscher
Regrets
Chair
SV_MEETING_CHAIR
Scribe
TabAtkins, bkardell_, fantasai, dbaron, frremy, iank_, eae, gregwhitworth

Contents


<gregwhitworth> Rossen: Welcome everyone, let's start with intros

<rachelandrew> +1 we need dbaron for multicol

<Rossen> Rossen Atanassov, Microsoft

<astearns> alan stearns, adobe

<plinss> Peter Linss, Invited Expert

<florian> Florian Rivoal, Vivliostyle

<dbaron> L. David Baron, Mozilla

<xidorn> Xidorn Quan, Mozilla

<fremy> François REMY, Microsoft

<melanierichards> Melanie Richards, Microsoft

<iank_> Ian Kilpatrick, Google

<ericwilligers_> Eric Willigers, Google

<surma> Surma, Google

<gregwhitworth> Greg Whitworth, Microsoft

<flackr> Rob Flack, Google

<bkardell_> Brian Kardell, JS Foundation

<jihye> Jihye Hong, LGE

<rachelandrew> Rachel Andrew, Invited Expert

<cbiesinger> Christian Biesinger, Google

<Tomoya_Kimura> Tomoya, VOYAGER Japan

<dtapuska> dtapuska, Google

<jet> Jet Villegas, Mozilla

<gregwhitworth> fantasai, Invited Expert

<chrishtr> Chris Harrelson, Google

<bradk> Brad Kemper, Invited Expert

<dholbert> Daniel Holbert, Mozilla

Selectors

<gregwhitworth> TabAtkins: We don't need to discuss this

<gregwhitworth> ericwilligers_: I'll add a test

<gregwhitworth> Proposed Resolution: no change

<Rossen> github issue https://github.com/w3c/csswg-drafts/issues/1933

<gregwhitworth> Rossen: let's move on then

<gregwhitworth> Rossen: leaverou added this to the F2F

<gregwhitworth> Rossen: who wants to summarize this

<gregwhitworth> Rossen: let's swap and wait for leaverou

<gregwhitworth> Rossen: last issue on the list

<gregwhitworth> Rossen: target-within

<gregwhitworth> *projector being setup*

<gregwhitworth> Rossen: CSS Backgrounds

<gregwhitworth> dbaron: was there someone not wanting to miss sizing?

<gregwhitworth> *discusses timing for agenda*

Sizing

<astearns> github: https://github.com/w3c/csswg-drafts/issues/1722

<gregwhitworth> Rossen: max-content size of replaced elements

<gregwhitworth> fantasai: we discussed what to do with replaced elements that is percentage sized that has an intrinsic aspect ratio

<gregwhitworth> fantasai: *gives an example*

<gregwhitworth> fantasai: if there is a specified min-width or min-height use that rather than the intrinsic aspect ratio in that dimension

<gregwhitworth> dbaron: the effect that that would have is that if your min-width or min-height is smaller than the intrinsic size in that direction then you use that

<gregwhitworth> dholbert: if it's not min-width/height of auto?

<gregwhitworth> fantasai: yes

<gregwhitworth> dbaron: what your saying is if min-width/height are non-auto you'd use them in the aspect ratio?

<gregwhitworth> fantasai: yes

<gregwhitworth> dbaron: there are some weird interactions around this

<gregwhitworth> dbaron: it seems worth trying

<gregwhitworth> dbaron: I think someone should try it before committing

<gregwhitworth> dbaron: I'm worried about web compat

<gregwhitworth> fantasai: this scenario is not a very common case

<gregwhitworth> fantasai: I don't know why you're doing this

<gregwhitworth> dbaron: the main case I can think of is SVG

<gregwhitworth> Rossen: currently that will work

<gregwhitworth> dholbert: in FF that doesn't work

<gregwhitworth> fantasai: so it isn't interoperable right now

<gregwhitworth> fantasai: so...

<gregwhitworth> fantasai: let's give it a try

<gregwhitworth> dbaron: put it into the spec with the note to provide feedback

<gregwhitworth> tantek: we're changing a resolution right?

<gregwhitworth> fantasai: right, from a few months ago

<gregwhitworth> tantek: I'm worried about back compat

<gregwhitworth> tantek: they may have implemented

<gregwhitworth> fantasai: they haven't, that's the point

<AmeliaBR> There are some examples in this pen, if you want to look at current behavior: https://codepen.io/AmeliaBR/pen/brdBvQ

<gregwhitworth> tantek: when we had box sizing for SVG things we had all kinds of interop issues

<gregwhitworth> Rossen: who's going to write the test cases

<tantek> thank you AmeliaBR !

<gregwhitworth> Rossen: I hear some concerns about compat

<tantek> no objection, now that we have a test case to check impls

<gregwhitworth> Rossen: but also given the fact there is no interop on the issue then we should resolve on something that makes more sense

<gregwhitworth> Rossen: any objections?

<gregwhitworth> Rossen: resolved

<gregwhitworth> Rossen: please bring the test cases forward when you start working on the actual text

Auto resizing of iframes and textarea based on content size

<astearns> github: https://github.com/w3c/csswg-drafts/issues/1771

<gregwhitworth> TabAtkins: there have been many requests for textarea and iframes resize on content

<gregwhitworth> TabAtkins: we talked it over and thought, yeah probably ok

<gregwhitworth> TabAtkins: we started experimenting with this

<gregwhitworth> TabAtkins: figure our some mechanism content based sizing for textarea and iframes

<gregwhitworth> TabAtkins: we learned some issues impl seamless with iframes due to COR leaking information

<gregwhitworth> TabAtkins: we suspect we'd walk up the frame tree until we hit a fixed size to resolve the mqs

<gregwhitworth> TabAtkins: Someone from Moz impl this

<gregwhitworth> dbaron: we got the spec to say that's how media queries work, but seamless was removed

<gregwhitworth> dbaron: we have code for it - but it's not necessarily something you can write up in a spec

<gregwhitworth> dbaron: you need to figure out how to spec it

<gregwhitworth> iank_: what type of interesting things

<gregwhitworth> dbaron: I'd need to look, like it tries to do layout, and then tries again

<gregwhitworth> rossen: we used to have a technology that would allow you to do layout based on then content size and we killed it

<gregwhitworth> Rossen: performance becomes a concern for those

<tantek> The iframe use-case for me is known width (set by container), auto (preferably auto-expanding) height

<gregwhitworth> Rossen: when you consider extensions they try to size the box, and it's shrink to fit it becomes very bad for perf

<gregwhitworth> Rossen: Our experimentation for this suggests it was bad, but maybe you'll find something

<gregwhitworth> TabAtkins: they're both pretty separate features anyways

<gregwhitworth> TabAtkins: are we ok experimenting in this space

<gregwhitworth> TabAtkins: the textarea would go into sizing 4

<gregwhitworth> smfr: we've had the auto sizing of the iframe even COR

<gregwhitworth> smfr: it makes your frame layout outside in rather than inside out

<gregwhitworth> smfr: we've had quite a few media query bugs

<gregwhitworth> smfr: we ran into media query cycles

<gregwhitworth> TabAtkins: that means that you weren't doing media queries the way we defined

<gregwhitworth> smfr: it does bring about nasty things in the code

<gregwhitworth> TabAtkins: how is this different from regular layout

<gregwhitworth> smfr: you can avoid laying out the iframe, if you have to you have to dirty the other nodes

<gregwhitworth> TabAtkins: ok, let's talk about this later

<gregwhitworth> dbaron: I think the media query problems you had were due to doing what authors weren't expecting

<gregwhitworth> TabAtkins: this would be opt in

<gregwhitworth> tantek: how do you trigger behavior in iOS

<gregwhitworth> smfr: you always get it

<gregwhitworth> smfr: users don't experience nested scrollers, we always wanted page scrolling to win so you don't get trapped

<gregwhitworth> tantek: width is expected and height is auto

<gregwhitworth> smfr: yes

<gregwhitworth> Rossen: ok, so - it seems that Google wants to experiment with this - Apple has it and wants to remove it

<gregwhitworth> Rossen: do you want a resolution

<gregwhitworth> TabAtkins: The textarea one is simple enough to go into sizing 4

<gregwhitworth> TabAtkins: the iframe one can go in WICG

<gregwhitworth> Rossen: any objections to adding textareas to CSS Sizing L3

<gregwhitworth> fantasai: yes

<gregwhitworth> TabAtkins: I said 4

<gregwhitworth> Rossen: Ok, L4

<gregwhitworth> fantasai: ok - I'm ok with that

<gregwhitworth> Rossen: Changes to sizing L4

<fantasai> fantasai: we can add a note for L3

RESOLUTION: Add textarea sizing to Sizing L4

RESOLUTION: Add textarea sizing to Sizing L4

<gregwhitworth> *discuss whether to do in WICG*

<gregwhitworth> TabAtkins to spin up a WICG regarding auto sizing of iframes

<tantek> I'm a bit surprised that we're not even putting into a WD something that's been shipping in iOS for 10 years

Restricting stretch and fit-content to width and height

<astearns> github: https://github.com/w3c/csswg-drafts/issues/1913

<gregwhitworth> TabAtkins: I missed the telecon

<gregwhitworth> dbaron: I'm a bit hesitant as it exposes primitives to the system but yeah you can't use it over here

<gregwhitworth> dbaron: I don't feel that strongly though

<gregwhitworth> TabAtkins: we didn't feel that strongly either but it felt like more effort than warranted

<gregwhitworth> TabAtkins: we use min in weird ways, fit-content especially

<gregwhitworth> fantasai: it's fine but we couldn't figure out how to use the stretch as a minimum

<gregwhitworth> fantasai: do we need this?

<gregwhitworth> fantasai: if we don't we don't need to put the effort in for testing etc

<gregwhitworth> Rossen: so do we keep it

<gregwhitworth> florian: do authors have any opinions

<gregwhitworth> jensimmons: fantasai can you explain what this is

<gregwhitworth> fantasai: would you ever use min-width or min-height of 100%, it does effectively that

<gregwhitworth> jensimmons: I'm sure people do use that

<gregwhitworth> fantasai: if that seems like a reasonable thing to use

<gsnedders> I've definitely used min-height: 100%; height: 0; in some cases.

<fantasai> cbiesinger: Seems useful, might want to fill a screen but grow if more content

<gregwhitworth> dbaron: the other question is would you want to use them inside a calc() expression for min-width and min-height

<gregwhitworth> jensimmons: I am hesitant to remove it

RESOLUTION: Keep them as they are in the spec (don't remove them)

<fantasai> https://github.com/w3c/csswg-drafts/issues/1865

intrinsic size of 'overflow: auto/scroll' and its impact on auto-sized grid/flex item ancestors

<astearns> github: https://github.com/w3c/csswg-drafts/issues/1865

<gregwhitworth> fantasai: grid and flexbox show this issue, where people have an element with a scrollbar and they put it among a whole bunch of other content

<gregwhitworth> fantasai: it forces that has a min-content size which defeats the purpose of the scrolling the author defined

<gregwhitworth> fantasai: this leads to a lot of confusion for authors

<gregwhitworth> fantasai: they're already handling their overflow and it would be nice if they just worked

<gregwhitworth> fantasai: this was filed that would allow us to come up with a way for this to work

<gregwhitworth> fantasai: I was talking with cbiesinger on Saturday to try and have the min-content zero'd out

<gregwhitworth> fantasai: the min-content contribution which has overflow be 0, but not the logical height depending on its overflow. If you did this you'd have to relayout in flow content to determine it's min and max

<gregwhitworth> fantasai: it's an idea, we're looking for other ideas

<gregwhitworth> dbaron: The thing with overflow that is not visible the size is the content within it, it has to propagate through it if it's the only thing

<gregwhitworth> dbaron: I tend to think, that there is not going to be a thing that we can do to solve this with a property that allows them to choose the thing that they want

<gregwhitworth> dbaron: I think there are two different scopes

<gregwhitworth> 1. intrinsic control intrinsic width that has overflow

<gregwhitworth> 2. properties that allow assignment to the intrinsic widths

<gregwhitworth> dbaron: the advantage of the first one is it gives more room for auto behaviors that do the right thing

<gregwhitworth> dbaron: the advantage of the second is it is strictly more powerful

<gregwhitworth> fremy: I wanted to note that we had a similar issue in the table spec

<gregwhitworth> fremy: if you have a % height and you're overflowing in a non visible way we should resolve to 0

<gregwhitworth> fremy: the author intent is pretty clear here

<gregwhitworth> fremy: to me this makes sense and is generalized

<gregwhitworth> fantasai: for grid and flex items specifically the automatic minimum size is not triggered on items that are not with overflow that is not visible but it does impact content contribution

<gregwhitworth> cbiesinger: you said that the single items need the content contribution to propagate through

<gregwhitworth> dbaron: because people will use 'overflow: hidden' to hide things rather than scroll it

<gregwhitworth> fantasai: that's a good point

<gregwhitworth> dbaron: you're talking about zeroing out the min-content sizes

<gregwhitworth> fantasai: yeah, just the min-content size

<gregwhitworth> dbaron: presumably the min-content sizes don't matter

<gregwhitworth> cbiesinger: for the min size of flex and grid would make it zero in this cases

<gregwhitworth> dbaron: in many cases you want them to get smaller but not to 0

<gregwhitworth> fantasai: a lot of the cases that are here the minimum would be controlled by other content that happens to be there

<gregwhitworth> fantasai: if they don't want it to get to 0 they can set a min size on the flex or grid item

<fantasai> or on the scroller itself

<gregwhitworth> dbaron: the other thing I worry about here is compat

<gregwhitworth> cbiesinger: that is concerning

<gregwhitworth> dholbert: Chrome already does this correct?

<fantasai> This is more understandable than having a scrollable descendant of a grid or flex item several layers deep in a subsection of a subsection cause the flex/grid item's width to explode out

<gregwhitworth> cbiesinger: I don't think we do that, but we do is for nested column flexboxes we don't give it a min-height

<gregwhitworth> dholbert: I thought there was something there for overflow: scroll

<gregwhitworth> cbiesinger: I'd need to look at it

<fantasai> Proposal in two parts:

<fantasai> 1 flex/grid items with overflow != visible | hidden have min-content contribution of zero

<gregwhitworth> Rossen: I read through the post about this issue, but I'd want more use cases for this. I am not going to object, but there will be compat issues for this

<gregwhitworth> Rossen: dbaron any objections?

<jensimmons> Rossen: can you speak up? You are very quiet. Or move a mike closer to you.

<fantasai> 2 inline dimension of block with ovefow != visible | hidden has mincontent contribution of zero

<gregwhitworth> dbaron: I wouldn't object, but I'd like to discuss the compat implications

<gregwhitworth> Rossen: we can discuss this on the side - let's not rush the resolution

<gregwhitworth> dbaron: I would be hesitant to come up with something too magical

<gregwhitworth> Rossen: unless there is something else to be discussed

Define which replaced elements are affected by width: % rule zeroing min-content

<astearns> github: https://github.com/w3c/csswg-drafts/issues/1889

<gregwhitworth> fantasai: we would like to resolve on this issue

<gregwhitworth> fantasai: we would want dbaron approval

<astearns> text is: https://github.com/w3c/csswg-drafts/commit/6a3be51bdda0ccb92af0d09556d6d1f2e7d8874d

<fantasai> https://drafts.csswg.org/css-sizing-3/#min-content-zero

<Rossen> elements include: select, textarea, progress, meter.

<gregwhitworth> *explains commit up above*

<gregwhitworth> fremy: the only one I can think of is input type="color" as I think most browsers implement it as a button

<gregwhitworth> fantasai: these are things that the min-content contribution is going to be zero'd out if a %age is used on there

<gregwhitworth> fremy: I think for us it's just easier to add color to this

<gregwhitworth> dholbert: same for us

<gregwhitworth> fantasai: for things that need to remain for UX, you might want to reserve some amount of that space, the exception list should include button

<gregwhitworth> fantasai: the button gets its size from the content

<gregwhitworth> Rossen: what fremy is advocating for is so that input type color doesn't disappear

<gregwhitworth> TabAtkins: we can say some spec lang to allow anything that's like a button

<gregwhitworth> Rossen: in our case it's just a button that has the swatch

<gregwhitworth> fantasai: that makes it so that you can't go down to zero and would loose the swatch?

<gregwhitworth> Rossen: yes, which defeats the point

<gregwhitworth> fantasai: that is the same with the text input you can go down to 0 and can't type

<gregwhitworth> Rossen: what is the push back on including color

<gregwhitworth> fantasai: maybe it's that is tied to a button

<gregwhitworth> TabAtkins: that's why I suggested "button like"

<gregwhitworth> TabAtkins: everything that looks like a button

<gregwhitworth> Rossen: are you ok with this?

<gregwhitworth> fantasai: yeah

<gregwhitworth> Rossen: with the amended button like to the list, any objections?

<gregwhitworth> Rossen: ok resolved, pending dbaron opinion

<gregwhitworth> *break 15 minutes*

<tantek> side note: css-ui-4 should likely say something about "button like" per the properties it has

<TabAtkins> ScribeNick: TabAtkins

Sizing - moving min-width/height partial dfns to Sizing

<astearns> github: https://github.com/w3c/csswg-drafts/issues/1920

fantasai: Oriol pointed out the Flexbox isn't the best place to define a new initial value for min-widht/height.
... Suggested it move to the Sizing spec. Makes sense to me.
... Definition of what automatic size means in Flexbox wills tay, but move the propdef that defines the keyword to Sizing.

Rossen: Sounds reasonable.

RESOLUTION: Move definition of the min-width:auto keyword to Sizing.

Move box-sizing to Sizing

<florian> https://github.com/w3c/csswg-drafts/issues/1906

<tantek> github: https://github.com/w3c/csswg-drafts/issues/1906

florian: Width and height are defined in 2.1. Box-sizing is defined in UI as a monkey-patch on that.
... Works, but is ugly.
... Now that UI is getting to Rec, it's about time we get that into a spec of its own.
... So we should take what's in 2.1, apply the box-sizing patch, and put it into a spec, probably Sizing.
... Also need ot make sure it work for logical/etc.
... So Sizing 4 looks like a good place to have it.

Rossen: This is in UI3, already tested, right?

<tantek> Yes

[Ian Kilpatrick wins CSS Bingo]

florian: Right, it's in UI3, and staying there as it goes to Rec. It's only in there, tho, because 15 years ago we thought UI would be the first to hit Rec. Turns out to have been true, but there are better places for it.

fantasai: Happy to pull in the monkey patch, hesitant to pull in all of 2.1...

<fantasai> >_<

Rossen: No need to dive into details, just about moving box-sizing from UI4 to Sizing.

RESOLUTION: Move the box-sizing property from UI 4 to Sizing.

CSS BAckgrounds - background-flip and text-underline

<astearns> github: https://github.com/w3c/csswg-drafts/issues/900

fremy: It seems we always consider underlines as part of the text shape
... So for background-clip: text, you draw the background only under the text of th eelement. Intention is you set the text to transparent, so the background layer fills in for the text.
... In Firefox tho, the color of the text doesn' tmatter for the shape, but the transparency fo the underline is applied as an opacity on the background.
... So if people use color:transparent, the underline is too, and the background under the underline becomes transparent.

<fantasai> @___________@

fremy: I don't think this makes sense... Edge is not doing this.

TabAtkins: This sounds like accidentally over-applying an opacity filter...

fremy: I think it would be good to specify the behavior.

smfr: Related, the fill and stroke module will someday handle this, right? Should we even specify this, given that it'll be replaced?

TabAtkins: So back to François's point - settle that text color shouldn't ahve any effect on background

fremy: And that text-decoration should be included as part of the text shape.

RESOLUTION: text color has no effect on background-clip

RESOLUTION: text-decorations should be considered as part of the text shape for background-clip purposes

<AmeliaBR> I would definitely expect background-clip: text to include the underline area. Looks like browsers do that even when the underline is from a parent element: https://jsfiddle.net/yLwq77ss/2/

Transforms 3d contexts

<trchen> github issue https://github.com/w3c/csswg-drafts/issues/1944

trchen: In CSS, having a stacking context does not guarantee an element to be a containing block for every descendent element
... And being a contining block doesn't imply being a stacking context

<Rossen> github: https://github.com/w3c/csswg-drafts/issues/1944

trchen: 3d context is a stacking concept - it decides which planes need to be 3d-sorted against each other
... But at the same time we define 3d context of elements based on containing block
... Causes "3d context penetration problem"
... Element can be flattened by another element that's not part of its containing block chain
... We're working on a project in Blink to simplify compsoiting code, foudn some ill-defined corner cases
... Planning to have a breakout session tomorrow afternoon?

smfr: Would like to have a browser vendor rep from each for the breakout tomorrow.

[discuss details of the breakout]

<gregwhitworth> bingo update: all 4 rewards are gone :) Thanks for playing

<bkardell_> scribenick: bkardell_

css grid

<Rossen> github: https://github.com/w3c/csswg-drafts/issues/509

lajava: we have two different issues

<lajava> me

<lajava> :we have undefined width and height

<fantasai> all options for percentage gaps listed in https://github.com/w3c/csswg-drafts/issues/509#issuecomment-333236096

<lajava> the issue we are discussing now is for grid gaps

<lajava> fantasai listed different options after some discussion

<lajava> our discussion from blink/webkit : we prefer to keep exisitng behavior keeping, treat them as 0 for intrinsic size/layout

<fantasai> lajava: is requesting option F = contribute zero, resolve as percent for columns, resolve as zero for rows

<lajava> in the issue there is an explanation

<lajava> we think that what happens in ff is broken with that approach

<lajava> if we dont do that for margins, we should be consistent

<lajava> we have to decide from the options fantasai listed and agree to do it the same

fantasai: my concern with f) in that list is that it has been a goal of grid to have symetric behavior in both axis

<dbaron> fantasai (before previous): I think we agreed to eliminate C and E.

<dbaron> We're discussing the list in https://github.com/w3c/csswg-drafts/issues/509#issuecomment-333236096, I assume?

<lajava> related to that, we think there are issues to do that with tracks as well

<astearns> yes, dbaron

<lajava> it's not impossible, but there is no browser doing that

<lajava> all of the browsers consider cols and rows diff

<lajava> so I'm not sure that should be important in solving for gaps - perhaps we decide not to do it for the tracks

rachelandrew: there are issues teaching this to authors. generally people understand when you say this will resolve to 0, the goal of having symmetrical gaps would be nice.
... if we can't have them symmetical, having the rows go to 0 makes sense

lajava: I agree with that

dholbert: are we just talking about intrinsically resized grids

lajava: d) tries to resolve the same way in both axis

<astearns> so rachelandrew is for F, not D

rachelandrew: if we didn't have % gaps, if we changed existing behavior ...?

jensimmons: if you had that situation in the inline direction where you didn't have an explicit width those gaps would also resolve to 0, it's just not a common use case
... if you said you want this to be 100x100px - in both directions the gap would be 10

jennsimmons: i dont know if what you are describing is that the algo is doing the math diff ?

<fantasai> ScribeNick: fantasai

<dbaron> ScribeNick: dbaron

<frremy> ScribeNick: frremy

lajava: there are two reasons we don't want back compute for the gaps
... backcomputing when the percentages are close or bigger than 100% the solution isn't that great
... the second reason is that we decided not to do that for margins, and so we would like to work the same for gaps

dholbert: well, on that, I think margins are just a legacy thing

TabAtkins: I would be opposed to anything that could yield to sizes bigger than the max size a browser can allocate
... it's very easy to end up in such cases with back-computing

Rossen: +1
... for this issue, the currently listed options are on the screen, and the github

Igalia would prefer B, D, or F

lajava: yes

Rossen: Edge's preference would be to keep symmetry
... if resolving in one of the pass is not possible, though, resolving to zero as usual is fine
... F is therefore not a great solution
... between B and D, I would like to hear more opinions

TabAtkins: B is expensive, there might be fragmentation issues

Rossen: which fragmentation issue?

TabAtkins: could contribute, but we could discuss this later when this comes up

dholbert: What would happen for auto grid with percent columns?

Rossen: let's say you have a 2x2 grid that has to shrink in both dimentions
... if that grid had a size, we would compute properly and things would be symmetric
... but if the grid is floated, we will have to compute percentages has zero
... but in the second pass, we are given a choice

<gregwhitworth> here's the example Rossen is stating: http://jsbin.com/dozonezuvi/edit?html,css,output

Rossen: either add the gaps and overflow slightly

<fantasai> The float will have the width & height of 2x item size, then have choice of how to compute percentages

Rossen: or you can continue to resolve to zero
... this is the difference between B and D

<gregwhitworth> sorry - wrong snapshot: http://jsbin.com/lalayakuxe/1/edit?html,css,output

lajava: Igalia doesn't mind B but the problem is that if you are auto and overflow by default, that seems counter-intuitive

Rossen: the only con of D seems that some authors could be unhappy about this
... but I would like to make sure that is really the case
... because authors can still use other units, or give a specified size to the grid

fantasai: (reading a summary of the A-F proposals)

<fantasai> A = contribute back-computatation ratio,

<fantasai> resolve as percent

<fantasai> B = contribute zero, resolve as percent

<fantasai> NOT C = contribute auto, resolve as percent

<fantasai> D = contribute zero, resolve as zero

<fantasai> NOT E = contribute auto, resolve as auto

<fantasai> F = contribute zero, resolve cols as percent &

<fantasai> rows as zero

<fantasai> NOTE: only for intrinsically-sized grids

<fantasai> explicit / stretch-fit grids always resolve

<fantasai> Cons:

<fantasai> A = contribution can explode grid

<fantasai> B = unhappy authors with overflowing grids

<fantasai> C = super broken

<fantasai> D = unhappy authors missing % column-gap?

<fantasai> E = even more broken

<fantasai> F = B + D + asymmetrical

Rossen + florian discussing why A cannot be fixed

(aka, see previous times this was discussed)

jensimmons: Using percentages for gaps for auto-sized things is not great
... because they will see their gap change size when the content changes
... so they will realize this is not what they wanted

fantasai: yeah, I can see that happening, I'm getting convinced by D too now

Rossen: Proposed resolution: gaps expressed in percentages resolved and layouted as 0 in auto-sized directions

rachelandrew: there might be a few people that are going to hit this problem if they try to replace parts of an existing layout they cannot entirely control

fantasai: but this would apply to cases where the grid is shrinkwrapped

<fantasai> not to cases that have a definite containing block

rachelandrew: yes, but I don't know how common that would be

iank_: we are at 0.1% of all pages for grid all up
... so I guess this case wouldn't be frequent at all once you consider it has to be also using percentage gaps, in a shrink-wrapped context

Rossen: but the conversation is about porting content that currently uses percentages to grids
... though I don't really see how they can achieve this today in a way that works in all browsers

jensimmons: I think those cases are very fragile currently, they use margins/paddings on floats
... but in those cases usually, the container has a width, even if it is 100%

rachelandrew: (general feeling of doubt, but I didn't catch the exact words)

dholbert: so this would only happen about floated grids, and abspos grids
... but in a flexbox, you are suppose to layout as having a definite size after flexing, so percentages would work there right?

TabAtkins: correct

rachelandrew & jensimmons talking about author's work to port existing things, ex: new york times shipping grid inside bootstraps

Rossen: so, would your doubts be enough to raise an exception today?

rachelandrew: no, I just wanted to shed some light on this, we can come back on this if needed

Rossen: any objection?

<fantasai> D = contribute zero, resolve as zero

RESOLUTION: Option D: percentage gaps in shrink-wrapped grids contribute 0 and layout as 0

Percentage tracks

<fantasai> Github: https://github.com/w3c/csswg-drafts/issues/1921

<Rossen> github:https://github.com/w3c/csswg-drafts/issues/1921

lajava: To keep things symmetric, we tried to add cases to resolve percentages for height of rows
... But we don't have min-content phase in the block direction, like we do for width
... So we would need to duplicate a second pass to make this work
... So 1st we would like this recorded clearly in the spec if that is required
... And all browsers would have to change their implementation

florian: and why not just follow what browsers already have implemented?

Rossen: the change would be relatively straighforward, it's no big deal

florian: but we would possibly break content, right?

Rossen: everything we do ends up breaking someone's content, I don't think this would be an issue here

lajava: well, we are still unsure about what would happen in more complex cases like in orthogonal flows
... but at the very least it would require a second pass, once you know the intrinsic height

Rossen: any opinion from Mozilla?
... there is still time to fix, but window is closing

dholbert: I don't have a strong opinion, and Mats hasn't commented on the issue
... I don't like adding new layout steps usually

Rossen: but it's easy to know if you need to do it before hand
... only do it if you have percentage-sized row tracks

dholbert: but if it is an orthogonal flow, you have to relayout entirely right?

lajava: yes, but this already happens anyway

Rossen: any objection?

RESOLUTION: percentage tracks sized as percentage resolve the same way for columns and rows, which involves a second layout pass in some cases

"Equal Gutter" with justify-content

<astearns> github: https://github.com/w3c/csswg-drafts/issues/1116

fantasai: users often want row-gaps and col-gaps to be equal
... but they also want the horizontal gaps to fill the remaining space once you've put as many columns as possible in the width direction
... they can do that using justify-content
... but they cannot transfer this size in the other direction
... this is basically a request for thoughts on the topic

<fantasai> https://github.com/w3c/csswg-drafts/issues/1116#issuecomment-288472394

<fantasai> Just to summarize, the example is

<fantasai> definite width, auto height grid container

<fantasai> auto-fill columns e.g. 100px

<fantasai> auto-placed items

<fantasai> place-content: space-between

<fantasai> The spacing produced by space-between is not equal in both axes.

jensimmons: so is the idea { row-gap: as-column-gap }
... ?

TabAtkins: pretty much

(general discussion, but it was tough to minute)

fantasai: the tricky thing is that two things control the gap size
... the gap property
... and the alignment properties
... you do have to consider both to get the desired effect
... and there are interersting cases of space-evenly which creates a gap before the first column and after the last column, we will need to define what to do about that

<fantasai> the gap properties only distribute space between the columns, but alignment can do other things

florian: and the proposed syntax would allow to also define alignment in the direction in which you said to copy
... I think we should have a more restrictive syntax that doesn't allow the impossible cases would be better
... but I don't have a concrete proposal right now

jensimmons: just to clarify, the alignment do not update the gap, they add a gutter right?

fantasai: yes, but visually it looks like the same thing

jensimmons: so it looks like we want something to transfer the gutter not the gap

dholbert: maybe some align: symmetrical then?
... alignment properties already are allowed to increase a gap
... it would be possible to also shrink the gap to make it match, that doesn't sound unreasonable

<dholbert> Or possibly not shrink, but grow-or-leave-the-same (to avoid)

Rossen: alright, I think we should probably break out to lunch, and have people interested in this proposal talk with each other
... let's get back here at 1.30

<dholbert> *(to avoid violating author expectations that "grid-row-gap: 100px" should actually insert at least 100px of space)

lunch

<fantasai> xidorn: https://drafts.csswg.org/bin/issuegen.pl

<estellevw> If you're in town for TPAC, leonie, Chris and I are hosting a party on wednesday night. DM me for an invite.

<astearns> will start again at 1:45

<iank_> ScribeNick: iank_

astearns: Talked with the chair of TTWG, about CSSWG equiv things, talking with them on Friday this week.

<astearns> https://github.com/w3c/ttml2/issues/406

astearns: Looking for volunteers to go the meeting.
... Lets go to non-interop of sizing images in flexbox

Non-interop of sizing images in flexbox

<astearns> github: https://github.com/w3c/csswg-drafts/issues/1322

fantasai: <goes to project>
... Testcase in last comment
... Flex container, and has some content that shrink down to their min-content size, if you have too many items they'll start to overflow.
... Excess space starts to take up, the text starts to break, <explains the testcase>
... The item with the image starts shrinking.
... This FF behaviour is kinda nice.
... So we want to make FF follow the spec? Or make other vendors follow FF implmentation>

?

dholbert: I wrote most of the flex code in FF, and don't know whats going on here.

gregwhitworth: What is the usecase where folks would want this behaviour?

fantasai: This means that it won't overflow, where other implmentations would.

dholbert: <explains image gallery usecase> being able to shrink them is kinda nice.

<jensimmons> I just dropped this example in this codepen: https://codepen.io/jensimmons/pen/aVmogq

fantasai: The image doesn't shrink until everything else has wrapped.

cbiesinger: If you give the image a flex-basis: auto , and others a flex-basis of 0, don't you get that behaviour?

fantasai: You wouldn't be able to get them to start out at their content sizes?
... I don't think we need to resolve now, but interesting to think about.

dholbert: I'll try and figure out whats happening in our impl, and report back on the github issue.

jensimmons: I had a few questions about flexbox, lets of interop issues around squishing images, and because of those issues, they are really hard for authors to think about.

astearns: Def. want interop here, just need to agree what that behaviour is.

Rossen: It looks like we have all the impls apart from FF, having interop.
... Switching to FF, means that we might run into compat.

fantasai: We were going through interop cases, and most of them were obv., but this one seemed interesting.

jensimmons: It also seems like we could do what we want, as there seems to be such lack of interop around images.

gregwhitworth: Only about this issue?

jensimmons: No, more broadly about images as flex items.

gregwhitworth: Where are the bugs?

fantasai: Don't have them here. But this one just seemed interesting.

Image Decoding

smfr: This should be fairly short. WebKit making more of its image decoding async, to a separate thread.

<gregwhitworth> jensimmons: it would be cool to see the full list of issues for images as flex items

smfr: Browsers do this in different ways, if an image has loaded (event), there won't be a flash.
... Off main thread decoding for animated images, - fairly straight forward.
... Also tried to do this for a large images.
... A bunch of authors have assumptions about where the decode happens.
... Would like to propose a new APIs to allow us to do background image decoding.

<smfr> https://html.spec.whatwg.org/multipage/embedded-content.html#dom-img-decode

smfr: 2 things we've done so far.
... Proposed an API for decoding. promise = img.docode();
... <explains that once promise has resolved, image has decoded>

<smfr> https://github.com/whatwg/html/issues/1920

<tantek> Github: https://github.com/whatwg/html/issues/1920

smfr: The 2nd thing that we've proposed, a way for authors to tell the engine that is ok to decode these images async. (may be a flash).
... A way for authors to opt into async decoding for <img>, but no way to do this for CSS images.

<chrishtr> https://github.com/whatwg/html/issues/1920

smfr: This might be something like a new image function, or additional argument to the image function, etc.
... Nothing written up yet.

TabAtkins: We left space for an async tag, in the url() function.

<group talking about image() function>

smfr: Google images does a thing where they load a low res image, and then replace to a high res image.
... This is broken in FF, and Edge.

Thomas Wisniewski: Can authors opt into sync decoding instead?

smfr: I think we need the attribute to go both ways... might have an "auto" which is current browser behaviour.

leaverou: Whats the usecase for authors to control this?

smfr: Want to display large images, without blocking the large images.

leaverou: Why control for authors.

smfr: For compat reasons we can do this in more cases, as it introduces flashes.
... Lots of sites to this based on size of page, this case we'd always to sync decoding.

<bradk> Flash Of Asyncronous Image Loading (FAIL)

smfr: If an image is going low-high res, you really don't want a flash. The user-agent doesn't have enough information to make the best decision.

<dbaron> smfr: It's hard for a UA to tell whether the image is replacing something similar to itself (e.g., a low res version) or whether it's replacing a blank space or a placeholder.

leaverou: Is there a way to provide a fallback image.
... ?

TabAtkins: image() function has this.

<tantek> does "no loading" include something that's cached?

TabAtkins: We could have it such that the image() function will look until it can render something that can be immediately rendered.

<fantasai> leaverou: What's a data URL of an SVG considered to be?

dbaron: Isn't there one reason that you need this the fact that there is a 'load' event for images, do you need this for CSS as there isn't a load event for CSS?

<fantasai> TabAtkins (in response to lea): idk

smfr: Authors do things like load the same image with an img tag, then place the same image into CSS.
... With decode you need to have additional information like the size of the image.

<leaverou> also a remote image that has already been loaded and decoded for some other reason should probably be fair game too?

<leaverou> though then you have race conditions

chrishtr: The promise returned isn't permanent, such that the UA can evict it from the cache if needed.

<fantasai> smfr^: prefer to have a declarative solution to this problem

fremy: There are way for authors to place images on top of each other.

<dbaron> (assuming no transparency, anyway!)

smfr: We saw a bunch of different ways that people did this.
... We found that there wasn't a way to do this well unless that authors told us what they wanted.

plinss: Is there going to be an event?

smfr: No, unless we want to fire events for CSS images in general, I don't think that we should special case.

Line Clamping

<TabAtkins> GitHub: https://github.com/w3c/csswg-drafts/issues/390

TabAtkins: Ignore the topic of the github issue, basically many years ago, hyatt added some hacky code that turned the -webkit-box code, to allow it to do line clamping.
... If you have more ignore them for sizing purposes.
... The implemenation is weird, very weird behaviour, property etc.
... We'd like to address this properly.
... This is the only major part of the -webkit-box code that needs to be maintained.
... What needs to be mapped, preserved for line-clamp, and removed.
... We'd like to start up a spec to handle the line-clamping behaviour.

eae: Would like a way to eventually alias this property over.
... And would like to do this in a way that other folks can alias.

florian: I don't remember the discussion of the spec.
... Expand on what we already have?

TabAtkins: yes.

smfr: Would like to extend this feature a little.
... Mail client has a feature where it keeps some lines at the beginning, keeps osme lines at the end, and collapses in the middle of the content, with clicky in the middle to expand itall back
... Collapses in the middle of the content.
... We would like to see this as start, end, middle.

florian: max-lines as currently specified is a fragmentation thing, makes the div into a fragmentainer, that breaks after a certain number of lines.
... Drop the rest of the lines.
... Could make it such that you get additional lines.

smfr: We did consider fragmentation to implement this feature, I don't really have opinions on how to do this.
... It does interact with fragmentation possibly

leaverou: Why is this being discussed in terms of max-lines, and not max-height?

florian: images inbetween for example, typically people want to clamp lines.

<fantasai> florian: and break at a fragmentation point ,not slice partway through a line

florian: The generalized this in overflow-4 lets you deal with heights...
... And let you decide if the additonal div gets dropped.

leaverou: In most cases i've seen the clipping is visual.

florian: But you don't want to split in the middle?

leaverou: If an ellipsis isn't displayed, people won't use this.

florian: Its a separate issue...

<eae> ScribeNick: eae

<tantek> I am absolutely for postponing ellipsis discussion variants until CSS3-UI is a REC :)

iank_: One thing I'd like to stress is that we've seen a lot of demand for somehting simple like clamping the number of max-lines. Would like to keep it simple and not expand scope too much.
... Clamping both start and end adds complexity as it requires layout out all of the text. Have to think about.
... We're looking to remove support for percentage values for webkit-line-clamp. Behavior is bizare and there is essentially zero usage.

use counter for percentage values: https://www.chromestatus.com/metrics/feature/timeline/popularity/2139

fantasai: I agree that we should limit scope. A lot of thoughts are great and valid use cases. I don't want to go there right now. Want to understand actual proposal
... As I understand from proposal, treat as max lines and set height based on that. Is there more to it then that?

TabAtkins: Yon don't want the lines to still be there like with line-clamp, we want to omit the rest of the lines.
... Want to supress display of line boxes after the cut off.
... Right now they are simply considered to be of zero height for sizing but are still there

fantasai: So the ellipsis gets inserted?

<TabAtkins> https://drafts.csswg.org/css-overflow-4/#issue-6fadc074

florian: The machinery of clamping or cloning or fragmentation is invoked implicitly if set max-lines. There is an issue saying that one has to explicitly enabling the fragmentation support.

iank_: My only concern with that is that invokes a bunch of machinery that takes a lot of implementation work. A simple max-lines beahvior is potentially a lot simpler.

florian: Concerned that it would require a lot of reinvention.

Rossen: Want to reemphasis fantasais question. In my mind we keep going back and forth between two different things:
... 1) Fragmentation and stop layout at some boundary. should thing of this in css4
... 2) Existing pane, what tab is taking about. We have a a lot of requests for webkit-line-clamp support.
... My point here again. This is different. If we want to be compatible with -webkit-line-clamp then the behavior is different. Not fragmenting, consumes space differently.
... Not that different to implement as long as it doesn't involve fragmentation.

fantasai: Would like to see a concrete proposal.

TabAtkins: The goal of this was to start up something that at the bare minimum addresses the "I want n of something".
... All resonable things that I'd like to see addressed. Should resolve whether we want to do or not.

fantasai: line-clamp can be made to support a subset of uses cases but if you want support for more complex use cases then the problem gets a lot harder.
... Should try to tackle the problems one at a time. Have something basic that isn't quite 0webkit-ine-clamp, but without eventually supporting everything.

TabAtkins: I would like to explore the space. Replace -webkit-line-clamp first and then, maybe, extend it later.

<fantasai> What I'm saying is I don't want to expand line-clamp, I would rather it stayed as some minimally simple property that could be used to build other things. not be expanded to do other things.

florian: responding to ian/rossen. When I was talking about invoking the machinery not walking about ..., to deal with fragmentation. I think we sort of have to, if not then we'd have to resolve what to do about text shadow, intruding floats etc. Would rather refer to the fragmentation spec.
... Would also be compatible with the rest of the spec in the future.
... css overflow invokes css break, max-lines already speced there.

<fantasai> https://www.w3.org/TR/css-break-3/#possible-breaks

<TabAtkins> ScribeNick: TabAtkins

Cleaning up OWNERS files

gregwhitworth: I got put on a review for Syntax (which shoudl never occur, I don't know it)
... That exposed a problem - I submitted some tests, those people should be in owners.
... When I add a flexbox test, 9 or 10 owners are added, but geoffrey ends up always reviewing them
... So if we could go thru and review the oWNERS files and make sur eit's actually the QA owners
... Whoever is actually going to be the person that will review a given spec.

astearns: I think >1 person is good, but yeah, if you're on an OWNERS file and not willing to review, is it just a PR to remove yourself?

gregwhitworth: Yeah, just asking everyone to do it for themselves. ^_^

astearns: And adding yourself to oWNERS where appropriate.

gsnedders: There has historically been some habit of using that like a cc flag, rather than a test-owners thing.

foolip: This ties into triage - we can mess with OWNERS files, but we also need to ntoice when people in those files aren't doing reviews.
... Also helps us discover where we need to add people.
... What do people who are submitting tests want? Immediate review, I guess, but how do you deal with spec issues when things go unnoticed for a while?

florian: For spec issues we eventually had to do a DoC, so we go thru and make sure nothing was dropped.
... That helps with specs that are worked on, even if slowly. But it doesn't help specs that aren't worked on.

foolip: So that's like every quarter or so?

[laughter]

florian: Usually much slower. Sometimes every few years.

foolip: So any prefs on how this should work? A bot emailing the list when things go unnoticed?

florian: If we sent something every *year* when things were reviewed, it would be a massive improvement. 2 days would be crazy fast.

gregwhitworth: Related: if you've ever committed to a spec, go to w-p-t repo and check the OWNERS files. If you're not actually relevant for that spec, remove yourself.

dbaron: Or if you notice yourself getting reviews for something you feel like you shouldn't be reviewing.

Feedback on testing policy

zcorpan: I made a PR in Sep to add a testing policy for the CSSWG for specs in CR.
... + CSSOM and CSSOM-view
... I wanted to get feedback from the WG on how this has been going - if policy is working, what benefits, what might need changing.

chris: In other groups that do this, editors do PRs and then the WG approves and merges.
... IN there, adding a test in is really easy.
...
... In our group we don't do that, editors push to master. that makes this hard.
... *Some* editors seem to be doing tests and specs together, it's useful.

florian: I've tried to be more systematic about writing tests with changes, and linking to the tests from the changes.
... What I haven't noticed is a significant difference in reviewer activity; I was worried it would be the bottleneck, and it still is.
... We haven't been doing this long enough for my anecdotes to become data, but it doesn't seem improved from the past.

Chris: The spec-readiness things that go out every week, I've been guilty of using that to push people on reviewing things.

<zcorpan> (issues with "Needs Testcase" label https://github.com/w3c/csswg-drafts/issues?utf8=✓&q=label%3A"Needs%20Testcase%20(WPT)"%20 )

gregwhitworth: I'm gonna be a pain - I agree with florian from last discussion. I desire a world where everything modern - I run flex, grid, vars, etc - I'm running daily our build system, and if it turns red I know we regressed or the spec changed.
... This is very important, I can't keep track of everything.
... I'd like to start giving teeth to this.
... I don't think we'll ever get to the interop goals us browsers want without tests added for every change.

foolip: What teeth would you like to add?

gregwhitworth: There's words that it's CR.
... I feel like it should be more universal.
... Every other WG MS is in has this policy - every spec change has tests along with it. We're the only WG that doesn't.

<tantek> I would be ok with WD + impls

<tantek> = require test case to make normative change

<tantek> not just WD

gregwhitworth: Just spent a lot of time reviewing flexbox tests, finding a lot of old redundant tests, a huge waste of time.

florian: Even tho this is somewhat informal, this group sometimes does internal incubation, and forcing tests then seems counter-intuitive.

<foolip> TabAtkins: I wanna talk, do I q+

<foolip> ?

<fantasai> yes

florian: Once we reach the point we're no longer brainstorming, actually refining...

<fantasai> foolip, it's not required always, but when things get crowded it's helpful :)

foolip: Most other groups don't have a CR req, it's jsut a matter of "if it makes sense at this point, let's do that".
... That's a problem for immature stuff.
... So the criteria I propose is: anything with one or more impl has tests.

<tantek> +1

foolip: Means you can punt on testing until someone tries to implement.
... And first implementor is in a good position to write tests. Shouldn't always be editor's task; it's not that in the WHATWG.

dbaron: Same - when you ahve impls.
... Also it's very dangerous to write tests without impls.
... You write a whole bunch of tests, try to execute spec in your head, and it turns out that people are worse at that than software.
... So you end up with lots of tests that are wrong in subtle ways.

<tantek> +1

<bkardell_> +1

dbaron: We also have a general problem of losing track of things like spec changes, edits, and figuring out the state of things.
... Part of that is that we tend to resolve to change things, and then nothing happens.
... I feel like we should try to use GH issues more for this.

<foolip> for people reading the logs, https://github.com/foolip/testing-in-standards/blob/master/lifecycle.md is my whole thinking about when it makes sense to start caring about testing.

dbaron: If we ahve a thing we agree to do and it's not done yet, we should be tracking it in GH as an open issue.

<tantek> resolutions for normative changes MUST be in a github issue

florian: ARen't we already doing that?

dbaron: I feel like we're not.
... This includes us agreeing to some resolution, and there isn't an issue for it.

<fantasai> TabAtkins: After F2F, make sure everything is in an issue or tracked otherwise

dbaron: Even in a meeting - should have an issue as soon as we discuss something.

astearns: Going back a bit, question of teeth.
... Whether we should apply this rule to CR+, or bring it back to things with impls.
... What are the teeth?
... We haven't been consistent about it even with CR+

TabAtkins: For anything in testing stage, only do edits via PR-merging.
... Only push to master for incubation-stage stuff.

<tantek> for normative changes

<tantek> editorial should not require that

astearns: Agree

agree with tantek

florian: If we agree to enforce it that way, we need to be careful about how to process the giant backlog, and if elika and tab create 25 PRs per week, still problem with processing them
... So going from "a bunch of specs not tested" to "most of the spec is in hanging PRs" isn't an improvement.

fantasai: That's my point - "why don't you block edits on writing tests", I think it's better to publish things where they can see them, instead of seeing a diff.
... Some things will only require one test, others will need 200. I don't want to be on the hook for all of those.

astearns: That's not the request - SOME tests, not a full test-suite.

<tantek> also important to drop or update existing tests that are affected!

florian: Not full test suite, just full tests *for the feature being tested*.

astearns: I'm saying just "at least one".

fantasai: Like, if I change an orthogonal flow thing, I need to write like 500 tests.
... That's an extreme example

<fantasai> fantasai: but 30+ test isn't uncommon

florian: REgardless of the rules we set up, we won't solve this until some companies set up a budget to pay for QA.
... If we don't get that, we'll rely on the goodwill of people like me, and that doesn't scale.

zcorpan: PR model in the whatwg - every change has a PR, someone needs to review, someone needs a testcase.
... Without that, the PR is left open, we never commit to master.
... Sounds like there's some issue with the workmode - edits get made, we forget about testcases, or resolution are made and we forget about edits, that sort of thing.
... So what workmode do we need to not lose track of things.

fantasai: I think GH is helping a ton with that, to the extent that things are in GH.
... resolutions get in there from gh-bot
... And we have a needs-testcase flag.

zcorpan: Responding to fantasai's point, about changes with a big testcase burden.
... The policy in CONTRIBUTING.md is that in such cases, instead of writing the tests, you file an issue with wpt explaining that this change needs testcases.
... Or something is blocking writing the testcases.
... So documenting that testcases are missing, and why.

<gsnedders> s/The whatwg poicy/The policy in CONTRIBUTING.md/

florian: So this sounds like a variant of our needs-testcases flag; not sure which is better if nobody looks at them?

zcorpan: If it's straightforward but a lot of work, then needs-testcases in CSSWG seems like it's sufficient.
... But sometimes there's toolin gmissing to write it at all, in wpt, so that needs a separate fallback.
... So then we need an issue in wpt, saying that the current tooling makes it impossible to write a case for.

gregwhitworth: I agree with the once-one-impl thing.
... I know internally we're focusing more on testing.
... I think it's worthwhile, as much as we'd all love to solve every problem in spec form, we all depend on interop.
... Doesn't matter if we all implement some new thing if it doesn't work properly in every browser.
... So go with PR, say it doesn't land without at least one test.
... And with gh issues, often there are already testcases, just informal, need to be wrapped up in testharness
... I don't think it's a monumental task to get this working.
... And when we go implement it, we'll create more testcases, and implement that.

fantasai: Yeah, one or two testcases is way more manageable than "please fully test this change in all permutations".

gregwhitworth: I'd love when we go to CR we already have a testcase working.
... To hammer home the point - I'd like to get some reoslution that's beyond CR.
... I think we need teeth or else nothing will happen.

gsnedders: I have 2 viewpoints.
... I don't think there's any point in testsuites before impl, same as others.
... But when there is an impl, the vendors who impl'd will have written tests, to land the feature.
... So inherently there's already a testsuite.

florian: It might not be shared, or shareable.

gsnedders: Tho now we have 2-way sync from Gecko and Blink, so hopefully more and more tests are in wpt from the get-go.
... The other thing is getting tests per edit.
... So presumably, when someone impls the edit, there's a test for it.

TabAtkins: We don't want to hold up PRs until someone impls something.

fantasai: Yeah, anything that forces us to hold a PR for 2 weeks is a failure.
... In 2.1, we had that errata list, and if you wanted to impl something you had to check the spec and the errata.
... This got super unwieldy s,o we eventually merged it in.
... I don't want to get into that same state, except way worse because instead of an errata list you have a disorganized pile of diffs in GH PRs.
... But if we're withholding edits from being published for too long, that's a failure state.

gsnedders: When it comes blocking things on PRs, the experience from the other groups that have done this is that we don't end up blocking on PRs.

florian: How?

<dbaron> the point of changing the process is to change the way people spend their time

gsnedders: Someone comes along and actually looks at it.
... Sometimes someone wanted ot impl it, so they want the PR landed. Sometimes because someone is watching and reviewing the changes.
... Generally there's far less problem getting review.

dbaron: The point of changing the process is ot change how people spend their time.
... I think if we're changing the process ot make people spend more time writing tests, people will spend more time writing tests.

<tantek> also the point is to reduce information loss (e.g. decisions)

florian: And we might distinguish between "everybody" and "tab and elika". If we don't want tab and elika to spend less time writing specs, we nee dmore people to write tests.
... Their plate is already more than full being the catch-all editors. That's why I suggested someone funding the QA work.

foolip: I don't think it's a matter of decreasing thruput.
... Ultimately everything needs to be implemented.
... It's a matter of closing the feedback cycle, so the thing being written is closer to time of test being written and tine of implementation.
... So getting impls more involved in writing tests and keeping track of changes to the spec.
... It would be a failure if it ends up with the editor writing all the tests.

florian: My earlier point here - either we decrease tab and elika's thru-put, or we move test burden.

foolip: IN Blink, soon to actually ship something we'll require it to have wpt. So that's a forcing function.
... Can't go on indefinitely without it being on a Chromium engineer's plate to get the work done.

fantasai: So that bug - made edits, made a PR, then engineer is leave of absence for months, then doe sa perf push, then a yEAR LATER someone finally impls it... the PR has been there for a year
... The spec needs to be reliably up-to-date with what we decided.

<jensimmons> +1. We can’t have secret spec updates living in pull requests, invisible to people.

dbaron: If you make a spec change and *nobody* tries to implement it for a year, we'll just wait and change it again anyway.

fantasai: But if it hangs, and I need to change something about it, I can't see those edits.
... I can't deal with a pile of PRs like that.

<tantek> hey when's the break?

fantasai: If we wait for impls to make the change, it'll always be months.

<jensimmons> as a person who’s worked in git code repos for years, with teams, you cannot leave things lying around in pull requests. That’s a terrible way to work.

<dbaron> I don't think the implementors have to be the ones who make the change

???: I was gonna suggest we start with something simple, like have gh hooks that say when there's open requests in the spec. Someone will be annoyed and poke people.

<fantasai> dbaron, right, which brings us back to the eidtor has to make the test change

twisniewski: And there's a push for people to go fix it up.

<fantasai> basically I'm saying foolip's idea that implementors will take up the responsibility to write tests for all spec changes is unworkable

<gsnedders> jensimmons: the experience in other groups hasn't been things lying around in PRs; if this WG can't get things reviewed that implies something is going wrong within this WG

Chris: Echoing fantasai, it's hard to review spec changes and tests with a bunch of diffs.
... When I was doing the fonts 3 review, I put them in the w3c repo just so people could see them execute.

plh_: We have a mechanism for that in wpt.

astearns: I suggest we take out of this discussion to tighten up what we resolved on.

<jensimmons> gsnedders: but that is the experience of *this* working group

astearns: Already resolved on tests for CR+
... I suggest we try out the PR for CR-level specs model.

<plh_> --> http://w3c-test.org/submissions/ pull requests for WPT

astearns: With the caveat that we want to see how we deal with those PRs, so they don't just pile up.

<gsnedders> jensimmons: yes, indeed; the question is why are participants, most of whom work for vendors, act differently to their colleagues in other WGs

florian: We'll still have stuff piling up.
... Nobody's been reviewing tests, even tho I'm blocked.

<jensimmons> this is has been sitting here for 2 months: https://github.com/w3c/web-platform-tests/pull/7364

astearns: I don't see a way of solving that issue before break.

florian: I don't have a solution without money.

gregwhitworth: Or down the thru-put.

fantasai: So say we're like "you need tests for the PR, nobody else will do it, editors have to write the tests".
... So 50% of my time goes to tests or whatever.

<gsnedders> jensimmons: and this is something we see relatively rarely for other testsuites, which implies for whatever reason the layout developers behave differently to e.g. the DOM developers, and it's not clear why

fantasai: Then people complain "why isn't this in the spec, I want to ship it yesterday"

<jensimmons> gsnedders: struggling with getting people to write tests is *insanely* common in the industry of people who make websites. It’s not the CSSWG.

<tantek> thank you astearns

<gsnedders> jensimmons: yes, that's true; but it's not an issue we see around most of WPT

TabAtkins: The earlier faiure mode was "no impl happens for al ong while, so no urgency on the test, and the PR hangs". Here you're positing someone wanting to implement. They'll produce a test, then.

<br dur=20min>

<eae> We might need to recalibrate our definition of a minute...

<gregwhitworth> ^ lol

<tantek> isn't that in Units?

<eae> Units and values, clearly.

<Tomoya_Kimura> A minute contains sixty seconds. Maybe , or maybe not.

<rachelandrew> wonders what happened to http://testthewebforward.org/ seems to fade out in 2014

<gsnedders> rachelandrew: basically we got no recurring contributions as a result of it so it basically fizzled out

<gsnedders> rachelandrew: and it was Adobe people leading it and when the Adobe web platform team got laid off…

testing negative calc() clamping

astearns: I wrote some tests, and modified them before I checked them in, and now they're bad tests.
... As far as I can tell, we have no interop at all. EVery browser clamps at a different time, depending on whether the animation goes up or down...
... So I want impls to check on it.

<fantasai> ScribeNick: fantasai

Contains

<astearns> github: https://github.com/w3c/csswg-drafts/issues/1809

TabAtkins: Whenever element generates more than one box?
... which box do we clip to?
... suggestion is principal box, that sounds great to me

fantasai: The principal box is the box that contains the content, seems like the right call

florian: list markers?

TabAtkins: They get clipped if they're outside markers

fantasai: just like for 'overflow: hidden'

dbaron: Table captions?

fantasai: Table wrapper box is principal

RESOLUTION: use principal box

clarify style containment

Github: https://github.com/w3c/csswg-drafts/issues/1872

TabAtkins: question is, why does style containment restrict break properties?
... Reason why I have these things set is I want to ignore a style tree for style computation purposes
... Should be able to completely ignore that subtree
... break property if allowed to work would violate that
... break properties propagate up

fantasai: They don't affect computation tho

TabAtkins: but they affect layout further up the tree

fantasai: break-inside doesn't propagate up, only forced breaks do
... Also sounds pretty bad in terms of fragmentation if you can't honor 'break-before: avoid'

TabAtkins: Avoiding breaks should work, yeah...

fantasai: ...

florian: Since contain property is ahead of css-content, should put the bookmark-* / string-set prose into the css-content spec

dbaron: I'm trying to understnand model of possible optimizations here
... I don't see anything for which this is relevant
... Still doesn't feel like style containment tome

fantasai: Also if disallowing break-*, then why not margin-*?

dbaron: It seems like you're trying to introduce soemething but not really worked out what
... Maybe write out what that optimization is to make that clear
... and discuss others

fantasai: also pretty sure if break-* needs to be disallowed the margin-* collapsing should also... but that sounds more like layout containment

Scoped Counters

<astearns> github: https://github.com/w3c/csswg-drafts/issues/1887

TabAtkins: If you have a style scoped element, which says counters are scoped to the subtree
... does counter-increment create a new counter?

<fremy> +1 on this one

TabAtkins: or does it increment the existing counter from the outside
... I think it should implicitly create a new counter scope at the style scoping root

fantasai: And so counters() would reveal a new level of counter?

TabAtkins: yes
... Don't want to fuss with the subtree when calculating counters further down in the document

fantasai: so you're disagreeing with Oriol's comment?

TabAtkins: yes

astearns: Write a test?
... So proposed to implicitly create new counter scopes at style scoping root for style containment

RESOLUTION: create new counter scopes at style scoping root for style containment

becoming a formatting context root

<astearns> github: https://github.com/w3c/csswg-drafts/issues/1457

TabAtkins: we addressed this a bit in the past, text we had was bad
... layout containment needs a formatting context root
... wanted to say that the element ends up being an FC root somehow
... only a few places where that's difficult
... Some are easy
... flow root, table, flex, grid, all satisfy condition
... for display: flow, becomes flow-root
... Next issue is with ruby
... ruby is effectively inline element
... wanted to create a ruby inline block thing

florian: we don't have that yet. If it's not useful, do we really want to add it?

TabAtkins: Better to fill the boxes, so this is consistent and defined

fantasai: How about saying layout containment doesn't apply to inlines. If you want it to apply, turn it into an inline block

Xidorn: create a wrapper box?

TabAtkins: wrapper boxes are scary and bad

fantasai: We have block ruby, it just creates a wrapper

TabAtkins: Make something block-like, either inline-block or block or somehting

fantasai: For most of these layout modes, the FCR-ification doesn't have much effect. Layout is fundamentally the same
... but for inlines and ruby, it's a very significant change to layout
... I'd rather say that layout containment just doesn't apply here, so the author is making an explicit decision about the layout change they're getting

TabAtkins: My two constraints for this problem is that contain should work on ruby because it works on inline, and that whatever effect it has should be possible to get without using 'contain' for its side-effect

florian: Suggestion is to apply contain to neither inline nor ruby

fantasai: that is my suggestion, yes

astearns: We don't have contain and inline ruby
... is there a use case for contain on inlines?

fantasai: You can't get that. It turns into inline-block

astearns: So if we choose not to apply contain to inlines, what do we lose?

TabAtkins: Just that authors have to take an extra step of declaring inline-block

fantasai: I'm arguing that's a feature, not a bug
... If the author wants to have an inline block, should be explicit about it. if they didn't, then they're not going to be happy anyway

TabAtkins: internal table elements?

florian: We already resolved they don't apply

Calling Koji

<scribe> ScribeNick: eae

line height / line spacing related

https://lists.w3.org/Archives/Public/www-style/2017Oct/0013.html

<dbaron> https://github.com/dbaron/css-line-spacing/blob/master/explainer.md

<Rossen> waiting for koji on webex

<koji> says "connecting..." for a long time...

dbaron: Based on the discussions we had in paris. We were talking about rhythmic sizing and the connecitons to line box contain. We've also had the line grid module which was designed to address many of the same issues and rhythmic sizing.
... What I've been trying to do is look at the two and come up with a minimal viable product for line spacing in css and address existing concerns about line spacing.
... I've tried to separate out the important pieces, as described in doc linked above.
... Some people have raised concernes that I have addressed in the doc, others have raised concerns that I did not address
... Not interested in talking about naming. More interested in important use cases and what developers and designers really need form line spacing.
... That requires distinguishing what existing tools actually do versus what developers actually want.
... Figuring out what we need for line-spacing in css requires more knowledge about what these requirements are than I know. I think we have people in this room that know more about this than I do.
... People are welcome to read and comment on the doc. There is also a github page.
... More importantly, I want to determine what the requirmeents are

florian: I'm not the ultimate expert but have thought a bout it a fair bit. All use cases I want to address are equally addressed by your proposal.

<koji> I can't connect voice

florian: If it is a simplification I'm all for switching to it. There are tweaks that might make it better but lets leave that to the side for now.

<koji> and phone doesn't accept the mtg number

florian: FUndeamental problem shared width line grid.
... From my point of view, if it helps implementation I'm in favor of this proposal over line grid.

dbaron: I don't now what the key differences are. I don't think implementability was a key factor.

florian: I didn't notice anything I missed during the remvoval proces

iank_: is a line grid shared between formating contexts?

dbaron: think it is shared

<koji> yes, I think so...let me try again

florian: issue I want to tackle later.

dbaron: I think a lot of the key use cases are driven by things that are pretty separate.

fantasai: One think that was dropped which we might be able to readd later. Was to have every other or every third line snap to the line grid.
... Not super important right now but is issue that comes up.
... For instance if you have different font sizes, i.e. line with smaller text size that takes up 1/3 the space.

dbaron: I think of that as establishing a new grid.

florian: Don't think it is epeicaly critical.

myles: You're totally right, making an inner line grid that has a size of 1/2 is common and somehting we should eventaully support.

dbaron: some ways to approximate it. You could establish a new line grid.
... In order to snap baselines oyu need to be careful in how it relates to the other grid.

myles: Voicing weak support for your proposal. We haven't seen broad adoption of existing line grid spec. If this can get better support I like it

florian: Reverse question. Does switching to this increase the chance of getting it? What are we gaining?

dbaron: One thing we're gaining is the changing of the line hight model itself.

florian: I'd argue we should add that as a seprate thing as people might want it without the grid.

dbaron: Agree but syntax will be tricky.

fantasai: From what I understand from prev. discussion: there are a variety of different levels of strictness re aligning to grid behavior. 1) I want a sane inline model, no grid.
... concept of really strict line grid, like physical pages where you can see things from the other side or facing pages. Multi-col in general. Where you want text to align across columns. Being stricter about grid in those cases is more important,.
... If you gave a large single block of text and an intrusion then a strict set of margins is more important than having an integral number of grid items. Reading might not see that it aligns to a grid. Width of margins might be more noticable. In those cases having a strict grid isn't desirable.
... We might need both approaches

fremy: Wheteher we'll be more likely ti implement. Questions around BFC. Flexible columns snap to grid, how would that work? Needs to be cleared before we proceed

florian: On agenda for later

iank_: Echo your concerns. As it stands I can't say whether we're happy with this proposal. Seems okay but we'd want to limit it with regards to bfc, flexbox etc. When line hight changes etc. Lots of remaining issues.

koji: I agree with fantasi that it should be avaliabl without grid. I also agree that we need a strict grid model.
... I think dbaron's proposal is a little different. We need a less strict model as well. I think the flow model works better.

astearns: any other concerns or comments on David's proposal?

nmccully: I also agree that it seems like a good propsal. I have concerns about baselines defined in other specs and how they relate. You mentioned dominant baselines being used to align, other specs talk about other baselines and flow. I have use cases that need support for setting different baselines. Being able to specify the baseline to snap to the grid.

astearns: Those use cases are next on the agenda.

<nmccully> me

fantasai: I think that David's proposal can handle this. Allows use of first or last baseline, you also have the option to use hanging baseline, etc using alignment-baseline property. You can not have it align the alphanumeric baeline with the cap height though, for instance.

koji: Question to David. The item 4 in your proposal looks like a possible solution to double spacing?

dbaron: I think the changes to the line height calculation reduces the double spacing problem depending on ... hard to say if it fully solves it but in many cases when used well it'll solve it.
... E.x if you're going to set a large line height it'll solve it more than a small line height. You're now applying the height on the line as a whole rather than the little pieces thus less likely to exceed height. If small line height more risk.

florian: If you're setting the size of the grid independently from the size of the font then it increases the risk. The problem isn't there in your proposal,

koji: That item 4 can then be applied to line-grid or rhythmic sizing? It's a general approach?

fantasai: Yes.
... No syntax for it in the proposal but the feature could be generic.

koji: Thanks

astearns: I think it would be interesting to try to apply that to the rhythm model and see what comes from it.

<fantasai> It's listed as the first Open issue

astearns: More comments or should we go on to use cases?

*silence*

astearns: Both the line rid and the rhythm proposals should take David's explainer into account.

fantasai: We should a) ty to fix the inline layout problem, helps everyone regardless of grid. No 1 priority in relation to fixing inconsitent line heights in a paragraph.
... We should continue to work on line-grid and ??? and both have come up as use cases that people want.
... block step size is probably easier, would work on that first, before line grid.
... We should go through use cases and get a clear idea.

florian: Question. Do we want to try to resolve on replacing exisitng line grid with David's proposal? Or should we postpone that decition until after.

fantasai: Should put note in spec to point to the alternative.

myles: We shouldn't resolve to replace existing spec without first going through fixing to exisintg spec.

fantasai: We need to fix the inline model, need a loose grid and a strict grid.
... We have a step sizing proposal and a line grid proposal. Would work on step sizing next as it is better understood. Then to line-grid later.

koji: ok

nmccully: Have a couple of use cases for grid snapping. I looked at the baseline spec and there are a couple of overloaded terms. There is center but it is not obvious whether which opentype baseline it maps to.
... Depending on the font and the font design are going to be quite different.
... Projecting, for CJK layout the relevant metrics are the em box. Differ from bounding top/bottom.
... Mapping between latin and CJK font metrics are overloaded and the interaciton between western and cjk content is not up to designer. Would like to see more baselines or explicit ones for japanese fonts to allow pairing between CJK and latin with layout as expected. Would like these baselines to be avalible for all fonts.
... These baselines are critical for aligning. The metrics top center and bottom are then snapped to a grid.
... There are different snapping ebahvior begining to be supported in css. The possibilities where you snap lines, whether body grid with 14pt and letting with 21pt and a title between two paragrapghs where it is larger. You want to center that on two grid lines. The options of how you position glyphs within that tall line, whether you consider the taller one to be the line-hight or the large one.
... You're aligning glyphs within a line and the taking the line and aligning it to the grid. Each visible in different types of design. All possible variations might not be possible with the proposal.
... Snapping the firts line of a paragpgh, two use cases. 1) Body text paragrapgh followed by smaller size one, first line is snapped to grid smaller ttype one is not. Fllowing one is re-snapped to grid. Subtleties around what you do with the smaller line. Whether it is centered or
... ...two examples. First one is snapping to the top. Second one snapping to center.
... Is not an even letting amount in first case.
... Both cases have adjacent flow that is top aligned in main column.
... This type of snapping, two flows snapping to grid, is one of the goals of this proposal

florian: Would this be solved using a line grid on the larger block and disabling it for the smaller one?

fantasai: If you know the relative sizes of the fonts you can make that work.
... In the first case you'd have a zero margin or line gap as needed, the second case you'd have that plus half the difference.

florian: You alig the stepped block on the dominant baseline

fantasai: If you're able to align baselines that is easay to do. If you are in a conetxt without relationship and UA can't do baselines alugnment you'd have to compute the margin.

myles: Are everything you've shown here is common and valuable and are things the css spec need to support?

nmccully: Yes, I don't thinok any are edge cases.

koji: I agree that em top/bottom are important. Can't comment on line grid at the moment. em top and em bottom are not well defined today.
... I wish we defined it better and how it relates to dominant baselines.
... When we tried to do underlines for CJK there was no font metrics we could use for it. We computed em top and em bottom. Are not defined.
... This might be a good oppertunity to finally define them clearly.

nmccully: I agree. One of the things we did in OpenType was to add metrics like this. ICF box top/bottom and em top/bottom to allow type designers to specifying them for layout engines.
... Agree that having the metrics available is essential for layout engines.

<fantasai> myles: If you don't have them, you synthesize?

koji: It's great to have the metrics, is ill defined.

<fantasai> nmccully: Yes, have synthesized in engines I've worked on.

myles: It seems that none of the three proposals have anywhere near enough details to explain the difference between the grids.

nmccully: Would greatly improve matters if line-heights and glyph placement were more controllable.

<koji> The OpenType algorithm to synthesize em box is here https://www.microsoft.com/typography/otspec/baselinetags.htm#ideoembox

nmccully: The existing baselines aren't sufficient, glyphs can shift today, being more explicit is important even if that requires adding more baselines.
... Defining how layout engines should use these baselines to position glyphs needs better definition. Smaller group should discuss this.

https://github.com/w3c/csswg-drafts/issues/1796

<astearns> github: https://github.com/w3c/csswg-drafts/issues/1796

florian: This is a meta issues, many issues linked from it. Want to work on that css 2.1 doesn't define how line height is calculated. It tries to but contradicts with itself.
... I've written a bunch of tests to see what browsers actually do. Much more interop between browsers than expected.
... I'm not talking about which font metrics are used. Separate discussion,
... I'm also not talking about when we have multiple inline elements within a line. Several fonts with different glyphs within a line, how are they algned? That is what I'm talking about.
... There are two general cases where line height is normal or has a value, resolves to specific size. Then there is normal.
... In case where it is a size, you get exactly that size. Not clear from spec. Some spec text suggest it shoud be union of that per font, no browser does that.
... The baselines from the first font is used and everyhting else is aligned from there. Not what the spec says but it is what all UAs do. That is good.

astearns: Is it worth resolving to change spec to match that?

florian: Yes.
... Have proposed wording. If enough people have looked at my tests to verify them I'd be happy to resolve.
... We have to be very specific when patching css 2.1
... Happy to craft detailed diff if we agree on the high level issue

eae: Matches our behavior

myles: We should just make the change and revisit if it causes problems.

florian: The specific proposal is listed in issue 1801 at the bottom.

<florian> https://drafts.csswg.org/css2/visudet.html#leading

dbaron: I was still looking at the previous issue.

florian: One is about size, the other about alignment.
... "When the value of the line-height property is something other than normal, determine the leading L to add, where L = 'line-height' - AD of the first available font. Half the leading is added above A of first available font and the other half below D of first available font, giving the glyph and its leading a total height above the baseline of A' = A + L/2 and a total depth of D' = D + L/2. Glyphs from fonts other that the first available font do

not impact the height of the inline box."

dbaron: I think that seems resoanble. You might even want to say height or baseline of the inline box.
... There might be some cases where that is not what we do but think that is for normal line height. Seems reasonable to me.

astearns: Next step would be?

florian: Resolve if we agree.

astearns: and then we can review that pull request?

RESOLUTION: Take florians proposed change to definitive line heights.

florian: CSS 2.1, in some cases, claims that line height normal behaves the same way as defined with a specific value. Probably between 1 and 1.5. Not what browsers do. What UAs do is take all fonts that are used, plus the first font, even if not used. That is what everybody does. Not what CSS 2.1 clains.

github issue: https://github.com/w3c/csswg-drafts/issues/1802

dbaron: I have a vague memory of gecko doing this in some cases. If there is a simpler impl I'd be happy to change.

florian: Only case I could find that skipped first font if unicode range is used for the first font. Chrome and Gecko have different behaviors. Other then that and the case where the first font' doesn't have the space glyph there is full interop.

astearns: Has anyone reviewed these tests?

florian: frenemy said he did.

astearns: Is Edge fine with taking this change? And Chrome?

eae: Yes

myles: Let's do it!

dbaron: Go ahead, trying to figure it out will take awhile.

astearns: Any objections?

dbaron: I'm pretty sure the gecko behavior is too weird. Might be worth having test coverage.

florian: There is 2.5 browsers doing one thing, 1.5 the other.

RESOLUTION: Take florians proposed change for line-height normal.

github issue: https://github.com/w3c/csswg-drafts/issues/1798

github issue: none

dbaron: Want to go back to line height normal. In some cases we use different font metrics.
... The text in the proposal was very specific about the metric.

florian: Will update it to be more clear about the specifics and that the font metrics in question isn't defined.

dbaron: What metrics are used should be looked at separately. Will add comment.

github issue: https://github.com/w3c/csswg-drafts/issues/1798

florian: We discussed whether the first font in the fallback list should count as the first available font even if it doens't have a space glyph. We did not specify whether it should also apply to line height.
... Safari, Edge, and FF half the time consideres it even if it doesn't have a space glyph.
... Safari and Chrome does not.

fantasai: The first available font should have a strict consistent definition across specs.

florian: Is not consistent across implementations.
... Happy to change if implementations are willing to change.
... I don't really care strongly, arguments on both sides.
... Are edge and safari ok with that?

fremy: I didn't run all of the tests but I think we do the same thing?

florian: So there are three compat implementations?
... The first available font wording is used in 2.1 just not defined.

astearns: Might be acceptable to not test the presence of space in 2.1

florian: Define it in fonts3 and then have that definition apply to all cases where we mention first available font

Proposed Resolution: To define first available font more strictly in the fonts model and leave it undefined in 2.1

RESOLUTION: To define first available font more strictly in the fonts model and leave it undefined in 2.1

github issue: none

florian: All browsers agree that the size of the content area depends on the size of the primary font, even if no characters from the primary font are used.
... The specification doesn't define the behavior, say "may do A or B".
... Should remove "may do A" as no browser does that.
... Suggest we remove suggestion saying that one may do something that nobody does.

dbaron: Would argue it should be a SHOULD rather than MUST instead of a MAY.

myles: Content area also depends on the line-gap property

florian: Just depends on font metrics.
... Spec says "do whatever you want, here are two suggestions". Doesn't mandate a specific metric.

myles: Shouldn't say ascent or decent, have specific meaning.

dbaron: I don't think this ones includes line gap, only asc+dsc.

github issue: https://github.com/w3c/csswg-drafts/issues/1804

florian: There is a paragraph saying that if more fonts are used the height of the area isn't defined but we suggest... I propose we remove that.

Rossen: What about overflow?

florian: People don't do that for background I think.

Rossen: I'll follow up with a test case.

<dbaron> FYI, I did figure out the crazy Gecko behavior I was trying to remember: https://github.com/w3c/csswg-drafts/issues/1802#issuecomment-342349505

astearns: Let's continue making tests given the number of questions raised.

fantasai: This is about where the backgorund is painted for inline elements, very specifically about backgrounds.

Rossen: I might be miss-reading the issue.

<myles> dauwhe: don't worry, computers are fast

fantasai: The question is how tall is the background painted behind the text, can't set overflow on that element. Has to be set on containing block.

florian: I'm not an editor for any of these specs, there will be pull requests not in spec.
... Would like to move forward.

Proposed resolution: Change the wording such that 2.1 is saying you should define the content area based on the first available font and only that font.

RESOLUTION: Change the wording such that 2.1 is saying you should define the content area based on the first available font and only that font.

</day>

end

<astearns> trackbot, start meeting

<trackbot> Meeting: Cascading Style Sheets (CSS) Working Group Teleconference

<trackbot> Date: 07 November 2017

<gregwhitworth> scribenick: gregwhitworth

Interop on List-item outside marker

<astearns> github: https://github.com/w3c/csswg-drafts/issues/1934

*francois works on getting projector setup*

<astearns> github: none

logical/physical property cascade and the .style API

<astearns> github: https://github.com/w3c/csswg-drafts/issues/1898

TabAtkins: someone pointed out that there are problems with the way logical properties are defined when trying to use the DOM APIs
... they get resolved in the normal order and then go through the cascade and we deal with the physical and logical based on ordering and writing mode
... when you set a property it gets appended to the list of properties in the style attribute
... and if you set one that's already there it just replaces it
... so this can cause it to be out of sync with what would happen in the cascade
... the proposal is to amend the CSSOM that if something is there it is always appended
... related to this
... we had an issue with !important and we resolved to append to make this work

dbaron: I'm happy to make that change
... we had a long discussion and resolved the opposite way
... a setter should append
... at the time implementations were inconsistent due to optimizations
... for existing properties in the fast path they would replace and others they would append
... one question, would having to do that mess up optimizations?

TabAtkins: when we discussed it internally we were fine making the change

dbaron: I found the minutes from 2013 but I'm looking for the other one

astearns: so I'm clear, the suggestion to append or remove and then append?

TabAtkins: those are equivelant

dbaron: I think it may turn out that it's not equivelant in the future

TabAtkins: we should figure out which one we want, it will need to have a note to determine this

dholbert: you could inspect the style attr and determine that way

TabAtkins: the current model limits to only one

astearns: I'm hearing two engines happy to change
... any compat concerns?

dbaron: possibly

astearns: the compat issue would be limited to logical props shorthands?

TabAtkins: no

fantasai: it would only affect people looking at .style expecting a particular order
... which doesn't make much sense, so it's probably not very common

florian: I doubt it's common

Rossen: tools and editors might be doing this

TabAtkins: I'd be surprised if the editor was reading the style and writing to .style

Rossen: they could

astearns: The proposed resolution is to change CSSOM to append values via the .style API and add a note

TabAtkins: yeah, and try to figure that out in the future

<dbaron> Things I found were https://lists.w3.org/Archives/Public/www-style/2013Sep/0469.html and https://lists.w3.org/Archives/Public/www-style/2013Oct/0007.html but I think there was further followup after the latter

astearns: any other opinions? objections?

RESOLVED

RESOLUTION: Make it so that setters to the .style api are appended rather than put in place

Interop on List-item outside marker

<astearns> github: https://github.com/w3c/csswg-drafts/issues/1934

<astearns> fremy projects

fremy: more precisely the positioning of the marker
... you can center things, but it's 2017 and we still don't know where to put the bullets
... got a bug to put the bullet in the right place
... shows bug in Edge

fantasai: wait it is spec conformant?

dbaron: yes it is

fremy: shows Chrome
... let's fix it
... so I started to look at the spec and it's missing
... spec isn't ready to implement
... put the 2.1 spec text and technically Edge is matching but the spec is very vague

dbaron: I think I may have been responsible for that note

fremy: I get the impression that nothing is defined

dbaron: in Chrome it is inside the principal box so it violates the 2.1 text

fremy: we want to fix this issue, but we want to spec it

fantasai: yes

tantek: all of those sentences come from long discussions and not agreeing

fremy: so I'll describe how Edge is implementing this

*fremy shows slides and he will post them a bit later*

<leaverou> since we're talking about weird bullet positioning, I'll quietly drop this Chrome & Edge issue here, in case it's relevant… http://dabblet.com/gist/3731c920fa0ee56efe3ec24a33a88964

fremy: there are two different steps, find out which line box do you need to affect with the bullet
... then horizontally position the bullet

fantasai: how we end up describing this, we'll need to really think about the markers - what they need to do and what they're trying to achieve typographically
... we shouldn't need to switch the model

TabAtkins: attaching it to the first LI, and the first item may be overflow: hidden and the marker can disappear

dbaron: that doesn't happen in Gecko because we position it to the align but it's not actually contained in that
... back when Gecko did what was in fremy feedback and when we fixed it we don't get bugs

iank_: we're looking at re-implementing markers, our current list marker behavior is not nice
... we're doing something very similar to what you described

<TabAtkins> <li><div style="overflow:hidden">...</div> <= list marker is clipped in Chrome!

iank_: I'll need to check with Koji, we're doing something very similar to what you described, so if you could specify it that sounds great

fremy: that's what we want

eae: now is the right time for us to spec this

fremy: to reply to Tab, to have overflow: hidden we can't put it inside of a non-bfc and this is would not happen

astearns: so what is the action?

fremy: I wanted to know if there was interest, it seems like there is
... Sure I'll be a co-editor but I care more about interop

RESOLUTION: Add Francois to the Lists spec

<dbaron> some links to previous discussion:https://bugzilla.mozilla.org/show_bug.cgi?id=172073 https://lists.w3.org/Archives/Public/www-style/2008Feb/0116.html https://lists.w3.org/Archives/Public/www-style/2008Feb/0118.html

<dbaron> (and there's more that I haven't found yet)

Interaction of scroll-snap and JS scrolling APIs

<astearns> github: https://github.com/w3c/csswg-drafts/issues/1707

<leaverou> TabAtkins: A bit late but bullet is not clipped in Chrome in your example, it just inserts a line, see here: http://dabblet.com/gist/07b894c9f6c1bbc3237c422172d0e5b9

TabAtkins: the scroll snap spec defines that if you do a fragment nav and it defines margin or something, you should pay attention to those
... it doesn't have any guidance on similar scrollIntoView APIs rather than just target scrolling
... we have the API opt into that
... the API has other properties of its own

<Rossen> leaverou, add the <ul>

florian: when you say some properties what are those

fantasai: the things we were consider the scroll snap margin that's the indication that there should be additional space

<leaverou> Rossen: oops, added. Same result.

fantasai: if it has a snap position that's an indication that you should snap that position

<Rossen> leaverou, there is a bullet, right?

<leaverou> Rossen: yes. Tab said there wouldn't be.

fantasai: the third thing, the UA could opt into using the snap position even if snapping is not turned on because the UA is trying to determine this and they may utilize this info from the author for the best end user behavior

<Rossen> leaverou: good, we have interop then :)

astearns: it's a bit vague, but you're going for a must to consider the padding and positioning

smfr: if it an element is in scrolled to it but look at it's container's scroll margin?

fantasai: usually you're looking at the border box for SIV and it will then take scroll margin into account

florian: the other aspect about snap position, if snapping is not turned on but it has position you may use that to position

smfr: would you only look at the targeted item or the ancestor chain?

fantasai: just the one that's being targeted

smfr: it seems weird that your taking a property that's meant solely for scroll snapping and you're adding it to the SIV

fantasai: this is adding author intent to the SIV

smfr: you could add props to SIV

fantasai: this makes it so that you don't have to track it all though

smfr: is the UA allowed to override scroll snap margins?

florian: is it implied that we should take scroll padding?

fantasai: yes

florian: I recall doing it in general, but wasn't aware we did it for this API

fantasai: that was intentional, you shouldn't be able to get in a state in JS that you can't get to as a user

astearns: the two of you smfr and Rossen showed some concern

myles: we have to make sure that websites that turn off scroll snapping, with this change the margin will now have effect

fantasai: usually this will get you a better experience

myles: I'll be for implementing this and seeing if this has a web compat issue

fantasai: I don't think we should have a web compat issue

myles: I think we can resolve on this

astearns: I'm hearing some movement to resolving
... anyone object?

RESOLUTION: When using SIV you should take scroll snap margin into account

<fantasai> scroll-into-view must use element's snap position if it has one and snapping is on

RESOLUTION: SIV must use the element position if it has one and snapping is on

RESOLUTION: Implementation may use the snap position if snapping is off

florian: should this change intersection observer?

TabAtkins: I don't think we should bring this in?

Scroll Into View options

<astearns> github: https://github.com/w3c/csswg-drafts/issues/1708

fantasai: there are several different options that target an element, such as scroll into view
... then there is the focus api
... this takes a bunch of args for smooth scrolling or not, how that element should be aligned within the viewport
... the default behavior you should be following the scroll snap if the scroll snap says something
... the second question is, are those options even necessary if there are scroll snap options

TabAtkins: we discussed this internally, there may be areas where you want to do one off alignment

fantasai: do you have a usecase

eae: one is up and down arrows, you may want to align to the top or the bottom

iank_: if you have a news feed you may want to use one or the either based on direction

dbaron: we had a discussion about these options a few weeks ago
... in that discussion I pasted the link to our internal code and if we want use cases where we use it

smfr: is scrollIntoView default the same as SIV false

<dbaron> The Gecko internal API is documented here: https://searchfox.org/mozilla-central/source/layout/base/nsIPresShell.h#669-763

<dbaron> er, better permalink: https://searchfox.org/mozilla-central/rev/7e090b227f7a0ec44d4ded604823d48823158c51/layout/base/nsIPresShell.h#669-763

smfr: we may scroll it into the top or the bottom, just as long as it's in the view

TabAtkins: this became a weird api for legacy issues

eae: our default is either true or false based on distance

florian: your usecase of the newsfeed I think we should solve that in CSS scroll snapping

myles: but that criteria of direction could be a bunch of different criteria, I don't think we should do that

dbaron: some of the complicated ones come from the a11y code

iank_: it looks like scrollIntoView args might be different than scrollIntoView with bool
... if it's bool we set the block to start

TabAtkins: that isn't per spec

iank_: ok

eae: ours is completely broken

TabAtkins: I may open an issue on this

astearns: I'm hearing at least 4 threads of convo
... do we need to have any more discussion about scrolling the least amount?

TabAtkins: that's a separate thing to consider for scroll snap

astearns: 1. The argument at the end should be dropped - sounds like they should not be

2. Should scroll snap win when there are no args in SIV - that sounds like there are no arguments against that

fantasai: the two specs conflict
... the OM spec doesn't ack scroll snap

<dbaron> there seem to be different behaviors for: various a11y things, going to named anchors, focus changes, caret position changes, dom apis to scroll element into view, and some other things (e.g., things related to form autofill popups or devtools)

astearns: does anyone have any objection to making those changes

RESOLUTION: We will make the changes to specs as necessary to ack scroll snap when no arguments are provided to ScrollIntoView

fantasai: anything that does scrolling needs to be evaluated

astearns: any objections with not mucking with the ScrollIntoView() args?

RESOLUTION: To keep scrollIntoView() options as they are

Spatial Navigation

<astearns> https://github.com/lgeweb/spatial-navigation/blob/master/explainer.md

jihye: Spatial navigation is the ability to focus elements based on their position on the screen
... the focus key can be changed with tab or shift tab key

<astearns> going through https://github.com/lgeweb/spatial-navigation

jihye: two way remote control and with four way keys and a11y it is becoming more and more important for input mechanism
... it is interesting for a11y for explaining the layout of the page
... to support this, we need to consider the following three steps
... *reads from explainer*
... the heuristic will be built for navigation, tab and arrow keys in Opera/Vivaldi allow for spatial navigation
... Blink it moves the scroll bar but you can enable it via a flag
... *shows a testcase*
... It isn't perfect but we need to improve the mechanisms in blink
... shows that when you press arrow keys it goes to the focusable elements
... shows the heuristic on scrollable regions that allow it scroll until a focusable element is in view that element is then given focus
... In CSS UI there are left, right, up, down properties

<tantek> I wrote code to do this (user-friendly spatial navigation) automatically in Tasman for WebTV/MSTV back in the day but cannot remember exactly how I solved all these problems.

<astearns> https://drafts.csswg.org/css-ui-4/#nav-dir

jihye: it is quite inconvenient because it needs to be defined on each element
... I want to solve this problem
... *shows page with proposed API page from explainer*

<astearns> nav-rule: auto | projection | direction | nearest

jihye: there is a rule that can customize spacial navigation

<astearns> (describes nav-loop)

jihye: when the page is too long and a lot of scroll, when the focus reaches the bottom of the page, the focus can go to the next thing and when you want to go up you need to press the up key so many times, but loop can go directly back up by going to first focusable element in the tree
... does the WG have any feedback?

fantasai: the first question I have is, some of these things seem like as a user preference rather than an author preference

florian: which ones

fantasai: like the loop

florian: there is a tv program, being able to move the left to the right is dependent on layout
... the person that knows how this is laid out is the author
... and that's why it should be on the author, but that's the general state of CSS

myles: so I think in general, I think it's a good area of investigation
... woooo
... there are many devices out there that use spatial navigation
... the heuristic for arrow keys there isn't a lot of interop, that would be valuable, but I also think there is a place for the web author to override the default
... I think there is definitely a case for author tweaks to the heuristics

florian: I think there are three: 1. Leave it up by the UA 2.) Picking the bit that you want to override
... I do think we'll need some specifically selectable method, and I don't think today we can define this - we need to take some type of extensible web approach here
... send an event when the user tries spatial navigation
... then a little bit down the road we can enable it based on usage
... having worked a little bit, there all sorts of corner cases
... transforms, opacity, etcs
... I don't think we should dictate the heuristics right now will be very hard, not the whole problem

fantasai: what would be the difference between javascript and events
... you're saying we should have an event handler and then do that live, we already have that the JS could set the nav properties
... a page that has too many JS

tantek: I have some experience working on this, there are a couple things worth looking at
... the first of - what are the real world layouts that authors have used
... where automatic algos haven't done a great job
... if any of you were at jensimmons talk laid out in a circle they expect the focus to go in the circle

<tantek> https://lists.w3.org/Archives/Public/www-style/2013May/0076.html

tantek: we've tried to solve this before, it's very hard and this is beyond CSS and brain storming here isn't going to be a good use of time
... if you want to pursue this, make it a platform effort
... I'd hate to see you spend a lot of time on that and hit a lot of the same issues we've hit before

fantasai: the key thing to point out from the email is being able to group elements rather than just one thing after another

astearns: any other points you'd like to make jihye?

jihye: I'm looking for general interest?

<tantek> I think spatial navigation would be better pursued in a new WICG draft

astearns: I think this should start in the WICG and get wider interactions

florian: the thing is, what do we mean by "THIS"
... this an entire area of features

iank_: that's what WICG is for, find the problem and then start identifying and beginning to solve the problem

astearns: taking this to WICG, doesn't preclude us from making changes to things that are already in CSSUI

tantek: we'll definitely help out here in what makes sense being in CSSWG

florian: as long WICG doesn't preclude us, I'm ok

jihye: I'm on discource

astearns: we should take it from Discourse and make an official WICG repo

<bkardell_> +1 to jcraig's comment

<tantek> +1 to jcraig's comments

jcraig: we should solve this in WICG but with everyone, CSS is part of it but we should include solutions to tabindex, etc

https://github.com/w3c/csswg-drafts/issues/1910

jcraig: this will fail on its own in the weeds

<astearns> github: https://github.com/w3c/csswg-drafts/issues/1910

florian: one of the weird things that we have with arrow keys, it lets you define where you should focus to
... what happens if the element where you want to go to isn't focusable
... what is currently defined is that if the user wants to go there we should make it focusable
... these days many/most are built are out of components
... this may allow the browser to go the "right" and then seek for the first focusable element
... if you're the author you can point to what's there, if your using a component and you don't know what's there maybe a heuristic is better

tantek: as an author you may want to use a seamless iframe but you don't know what's on the other side. I don't think we can determine the best behavior
... since you mentioned components, I think we shouldn't be solving this in isolation

florian: I'm not disagreeing with what you state, I'm not sure how that answers my question

tantek: I'm saying this discussion doesn't belong in CSSWG

smfr: so are you saying these props don't belong in CSSUI
... to me, it sounds like spacial navigation would be in its own spec rather than here in its own naïve form

florian: do you think there is a potential case where the focusable behavior is what you would want?

tantek: very unlikely

florian: I think searching inside of that makes sense and is uncontroversial

tantek: you're asking about something n the weeds and I'm not sure it helps/hurts and I think we should move this to a different arena

astearns: is anyone lining up to implement this improvement, then I think there would be a case to make a change to the spec
... if this is just an academic change, what's the point?

<robdodson> (sorry for speaking out of turn) but the notion of creating focus "groups" seems to already exist today with Shadow DOM. jsbin.com/lidaguf/edit?html,output

florian: the fact that, it works poorly when you have blackbox component which was mentioned by Blink

tantek: I don't think it's experimental

astearns: *reads rob's comment*

robdodson: the notion of focus groups kind of exists already, that will allow once focus is within that shadow root boundary
... the notion of the grouping kind of exists if you're willing to use shadow dom

<tomalec> AFAIK, Shadow DOM also propagates, kind of scoped focus, to elements distributed via `<slot>`

<tantek> issue filed: https://github.com/w3c/csswg-drafts/issues/1948

florian: what I was thinking of trying to specify if you focus that non-focusable element - if there is tabindex, etc use that

<tantek> I mean GH issue filed https://github.com/w3c/csswg-drafts/issues/1948

<tantek> " [css-ui-4] Spatial Navigation needs a new home in WICG #1948 "

florian: since we don't seem to have consensus can I suggest a lighter one to make a change to what we agree is stupid"

???: What do we all agree is stupid?

bradk: Currently you only seem to say that you should look for tabindex

florian: or is a button, etc
... it seems very weird to me that something is focusable will take you to something that isn't focusable but with a tab key you can't
... that's weird

astearns: since we're not closing, let's table the issue for now

end

Accessbility joint meeting

<TabAtkins> janina: We've been lsiting some issues with CSS for severl years, and tried several ways to get traction.

<TabAtkins> janina: Had some wonderful conversation; some issues are on our end.

Summary of Action Items

Summary of Resolutions

  1. Add textarea sizing to Sizing L4
  2. Add textarea sizing to Sizing L4
  3. Keep them as they are in the spec (don't remove them)
  4. Move definition of the min-width:auto keyword to Sizing.
  5. Move the box-sizing property from UI 4 to Sizing.
  6. text color has no effect on background-clip
  7. text-decorations should be considered as part of the text shape for background-clip purposes
  8. Option D: percentage gaps in shrink-wrapped grids contribute 0 and layout as 0
  9. percentage tracks sized as percentage resolve the same way for columns and rows, which involves a second layout pass in some cases
  10. use principal box
  11. create new counter scopes at style scoping root for style containment
  12. Take florians proposed change to definitive line heights.
  13. Take florians proposed change for line-height normal.
  14. To define first available font more strictly in the fonts model and leave it undefined in 2.1
  15. Change the wording such that 2.1 is saying you should define the content area based on the first available font and only that font.
  16. Make it so that setters to the .style api are appended rather than put in place
  17. Add Francois to the Lists spec
  18. When using SIV you should take scroll snap margin into account
  19. SIV must use the element position if it has one and snapping is on
  20. Implementation may use the snap position if snapping is off
  21. We will make the changes to specs as necessary to ack scroll snap when no arguments are provided to ScrollIntoView
  22. To keep scrollIntoView() options as they are
[End of minutes]

Minutes formatted by David Booth's scribe.perl version 1.152 (CVS log)
$Date: 2017/11/07 19:09:33 $

Scribe.perl diagnostic output

[Delete this section before finalizing the minutes.]
This is scribe.perl Revision: 1.152  of Date: 2017/02/06 11:04:15  
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/auto sizing/box sizing/
Succeeded: s/do layout/do layout, and then tries again/
Succeeded: s/use it/use 'overflow: hidden'/
Succeeded: s/zering/zeroing/
Succeeded: s/column flex/nested column flexboxes/
Succeeded: s/??/lajava/
Succeeded: s/??/dholbert/
Succeeded: s/auto-sized/shrinkwrapped/
Succeeded: s/at all/at all once you consider it has to be also using percentage gaps, in a shrink-wrapped context/
Succeeded: s/min-size as/contribute/
Succeeded: s/Matt/Mats/
Succeeded: s/thought/tough/
Succeeded: s/Moz/Wisniewski/
Succeeded: s/Collapses quoted text.../Mail client has a feature where it keeps some lines at the beginning, keeps osme lines at the end, and collapses in the middle of the content, with clicky in the middle to expand itall back/
Succeeded: s/want/won't/
Succeeded: s/postponining/postponing/
FAILED: s/The whatwg poicy/The policy in CONTRIBUTING.md/
Succeeded: s/The whatwg policy/The policy in CONTRIBUTING.md/
Succeeded: s/same state/same state, except way worse because instead of an errata list you have a disorganized pile of diffs in GH PRs/
Succeeded: s/specs/tests/
Succeeded: s/dbaron:/dbaron,/
Succeeded: s/???/twisniewski/
Succeeded: s/fissiled/fizzled/
Succeeded: s/that/counter-increment/
Succeeded: s/.../yes/
Succeeded: s/if we do this/if we choose not to apply contain to inlines/
Succeeded: s/???/nmcully/
Succeeded: s/nmcully/nmccully/
Succeeded: s/Davis/David's/
Succeeded: s/align-baseline/alignment-baseline/
Succeeded: s/would/could/
Succeeded: s/for it/for it in the proposal/
Succeeded: s/first/first, before line grid/
Succeeded: s/lose/loose/
Succeeded: s/???/nmccully/
Succeeded: s/???/nmccully/
Succeeded: s/most/some/
Succeeded: s/I think mostly this would be used for tweaks/I think there is definitely a case for author tweaks to the heuristics/
Succeeded: s/???/bradk/
Present: iank_ lajava Naina_Raisinghani Google melanierichards surma ericwilligers_ Javier_Fernandez Igalia cbiesinger tantek Vlad zcorpan smfr myles eae leaverou EricE_(observing) nainar flackr bkardell_ Tomoya_Kimura xidorn jihye rachelandrew plinss jeff clapierre George_Kerscher
Found ScribeNick: TabAtkins
Found ScribeNick: bkardell_
Found ScribeNick: fantasai
WARNING: No scribe lines found matching ScribeNick pattern: <fantasai> ...
Found ScribeNick: dbaron
WARNING: No scribe lines found matching ScribeNick pattern: <dbaron> ...
Found ScribeNick: frremy
Found ScribeNick: iank_
Found ScribeNick: eae
Found ScribeNick: TabAtkins
Found ScribeNick: fantasai
Found ScribeNick: eae
Found ScribeNick: gregwhitworth
Inferring Scribes: TabAtkins, bkardell_, fantasai, dbaron, frremy, iank_, eae, gregwhitworth
Scribes: TabAtkins, bkardell_, fantasai, dbaron, frremy, iank_, eae, gregwhitworth
ScribeNicks: TabAtkins, bkardell_, fantasai, dbaron, frremy, iank_, eae, gregwhitworth

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

Found Date: 06 Nov 2017
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.)


[End of scribe.perl diagnostic output]