<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
<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*
<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
<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
<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
<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
<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
<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.
<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.
<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/
<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_
<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
<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
<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)
<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
<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.
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.
<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
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.
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…
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
<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
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
<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
<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
<scribe> ScribeNick: eae
<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.
<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
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>
<astearns> trackbot, start meeting
<trackbot> Meeting: Cascading Style Sheets (CSS) Working Group Teleconference
<trackbot> Date: 07 November 2017
<gregwhitworth> scribenick: gregwhitworth
<astearns> github: https://github.com/w3c/csswg-drafts/issues/1934
*francois works on getting projector setup*
<astearns> github: none
<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
<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)
<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?
<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
<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
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
<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.
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]