<astearns> need volunteers for scribing today
<scribe> scribenick: gregwhitworth
astearns: anyone have any extra
agenda items?
... one change, we're going to skip item 8
astearns: we discussed this at the f2f, but didn't get there - quite a few issues have been worked on since then.
<bradk> https://github.com/w3c/csswg-drafts/labels/css-scrollbars-1
astearns: fantasai - you wanted some things working on, are you ok with it going to fpwd?
fantasai: it looks like there is an outstanding pr that should be merged first, but probably it's fine
astearns: any other concerns?
<chris> please let me know when that merge has happened
chris: I'll put in the transition request now and wait until that PR is merged
astearns: that sounds fine
Proposed Resolution: FPWD of scrollbars
RESOLUTION: Request publication of FPWD of scrollbars
<bradk> https://github.com/w3c/csswg-drafts/issues/3091
<astearns> github: https://github.com/w3c/csswg-drafts/issues/3091
<astearns> github: https://github.com/w3c/csswg-drafts/issues/3091
chris: it's about the slant axis
and the range of values that are supported
... the opentype spec takes negative values that it slants in
an odd direction
... every single example I've seen uses a positive angle
... when you're using high level things, like font-style you
need to use positive integers
... but we also need to take into account the lower level
things and you have to pass in specifically what the font is
asking for
<fantasai> wfm
chris: for font-style a positive angle will make a forward slant and under the hood it will map to what the font needs
astearns: the lower level will just pass through what is written by the author
<bradk> +1
fantasai: it makes sense to me. It is what we would do if OpenType was only one of multiple font formats, and the others matched expectations and OpenType didn't. Of course we translate from CSS syntax to the correct font settings, and values in font-variation-settings of course get passed directly to the font.
<florian> sounds good to me. let's make things sane for people
myles: this is similiar to how we handled optical sizing
Proposed Resolution: Higher level properties a positive angle will be a forward leaning slant, lower level properties will be what is written by the author
Resolved
astearns: fonts level 4
... we had an update to l3 this week, does anyone have an
objection to updating a regular WD for L4
<fantasai> +1 to publishing
astearns: hearing none
<fantasai> \^_^/
RESOLUTION: Publish fonts L4
<astearns> github: https://github.com/w3c/csswg-drafts/issues/1706#issuecomment-420474809
astearns: describes what is in the issue
fantasai: do we want to allow box-decoration-break to close the fragments similiar to what would occur when there is a forced line break?
astearns: it describes non-contiguous fragments
fantasai: I could possibly make
that a little bit clearer with regards to bidi
... the two fragments may end up ajacent to each other, the way
the inline happens to break
... the rule for bidi, on an infinitely long line you end up
with something in the middle of the inline box to split into
two. The intruder are meant to be two seperate fragments even
though they end up next to each other it provides us with the
information we need
... in that case if you did, box-decoration: clone you would
end up with text in between them because the bidi algo
... I think I can try to make it slightly clearer
... the part about non-contiguous is an example - it's not
exhaustive
astearns: that's fair
fantasai: I think the wording is ok
dbaron: one about the bidi
thing
... where implementations would create a seperate fragment
logically but they can never be seperate
fantasai: or if you have an inline which has english text, a little bit, there is nothing that lets the user know there are multiple fragments
dbaron: what you're saying is
that it's on a visual perspective of whether it has the
capability of breaking
... that seems complicated to implement
fantasai: this is about where
it's defined to have a fragmenetation break
... from a rendering perspective, the user can't tell that it's
doing that
... the only case this should be known, is where there is text
outside of the inline is intruding on the inline
dbaron: I'm a little worried
about.... <garbled>
... this section has a lot of mays in it, we should have an
issue for better definition
fantasai: for sure
dbaron: please open an issue
fantasai: I can open one
astearns: just open an issue for defining it better and leave the may out of this draft
fantasai: we don't have any implementations so the may is there
dbaron: if it's actually what you want implementations to do - then I would say that whether it's a should, with a may it's not clear it's what you want an implementor to do
fantasai: ok, that's fair
... how would the WG prefer, a may with a note - or a must
astearns: I'm thinking a note that states that a future level will completely specify what occurs in this situation
florian: I think that's what
should is for
... should implies the note that astearns described
dbaron: I support should as well
Proposed Resolution: Take the patch substituting should for may
astearns: objections?
RESOLUTION: Take the proposed patch
RESOLUTION: use should in the patch
^ what astearns said
<fantasai> https://drafts.csswg.org/css-break-3/issues-cr-2016
astearns: add florian as an editor to text L 3
Resolved add florian as an editor
<astearns> github: https://github.com/w3c/csswg-drafts/issues/2951#issuecomment-421705003
florian: we tried to have
break-word affect intrinsic sizing
... we had some hope that changes int he UA stylesheet would be
sufficient, but it is not true unfortunately
... so the only option it seems is to revert the previous
resolution where it does not affect intrinsic sizing
astearns: is that seperate issue somewhere?
fantasai: yeah we re-opened the issue
astearns: objections?
RESOLUTION: Revert the previous resolution
<astearns> github: https://github.com/w3c/csswg-drafts/issues/2883#issuecomment-421733978
florian: when you have tab stops,
if you have a tab - you're supposed to go forward in the
line
... if your text is coming extremely close to the next tab
stop, should there be a minimum size?
... Chrome, it jumps to the next one at a specific size and it
seems reasonable in a monospaced font
... I was thinking about going with 1 space, but maybe we
should go smaller than a space
... in a proportional font, spaces are already really small -
0.5ch
... I'm wanting to take this normative as makes sense
<emilio> astearns: Any comments from the non-chrome team?
<fantasai> +1 from me anyway
<emilio> astearns: proposal is minimum spacing is 0.5ch
<emilio> astearns: objections?
<emilio> astearns: RESOLVED: Make the normative change
<emilio> myles: Should link to the primary font concept
<fantasai> https://www.w3.org/TR/css-values-3/#ch
<emilio> fantasai: it already does via the ch value, though it's not actually the primary font
<emilio> fantasai: it's ch, it's not ambiguous
<emilio> emilio: is it what Blink implements?
<emilio> myles: if the code is the same as WK it's not exactly the same, but we can say ch on the spec
<emilio> astearns: the test for this is not going to test this exactly
<emilio> fantasai: why not?
<emilio> astearns: flaky tests / pixel differences
<emilio> fantasai: fine
<tantek> FYI chris, I reviewed and merged the one outstanding pull-request on https://github.com/w3c/csswg-drafts/labels/css-scrollbars-1
<emilio> astearns: both text-3 and text-3 are working drafts, proposal is publishing a new WD as text-3
<emilio> astearns: no objections?
RESOLUTION: publish a new working draft as text-3
<emilio> astearns: any objections for text-4?
RESOLUTION: publish a new WD for text-4
<astearns> github: https://github.com/w3c/csswg-drafts/issues/2882
<emilio> florian: so the issue is about whether their interaction is well-defined. There's only one case where it's not defined.
<emilio> florian: if you have a break opportunity during the line we'll insert the ellipsis after that break opportunity and block-overflow doesn't have the chance to apply
<emilio> florian: the only case where it's not defined is where the ellipsis is longer than the whole line, right now the spec doesn't define it
<emilio> florian: seems like we don't want the ellipsis to climb the line back up, so for now I think we should go for 'when the ellipsis is longer than the line then it does overflow, and text-overflow must apply'
<emilio> tantek: I think we need an example that we could look up
<emilio> florian: it's something like a very narrow paragraph with a very long block-overflow ellipsis
<emilio> florian: the spec says that if block-overflow ellipsis overflows then it may overflow to the next line, but it's undefined
<emilio> tantek: any implementation experience?
<emilio> tantek: we should construct some examples and experiment, keeping the issue open for now
<emilio> tantek: rather than spec something that is not easy to implement
<dbaron> It seems like "use multiple lines for the block-overflow indicator" is probably the better behavior from a user perspective, but it does seem hard to implement.
<emilio> fantasai: seems fine to leave it open as people implement it
<emilio> florian: so I'd expand on the proposal with examples in the issue
<emilio> florian: I'm ok with that
<emilio> dbaron: [what he wrote above]
<emilio> dbaron: saying that it needs to fit on one line definitely makes implementation easier, but it's not clear how much
<emilio> tantek: I'd prefer to specify the better behavior for the user, and we don't know how much harder it is
<emilio> fantasai: so what we're hearing is that we should the issue open to wait for block ellipsis breaking across multiple lines, but we probably should say that if the block-overflow string still doesn't fit withing the block then text-overflow applies in that case as it would to any other text
<emilio> astearns: I like the idea of working out concrete examples so that people get better idea, but also so that we can put them in the spec
<emilio> florian: does it sound reasonable to resolve on what fantasai said and add examples for the block-ellipsis on multiple lines?
<emilio> fantasai: I think we should resolve that text-overflow applies to the overflow string if there's an unbreakable string on it like it does to the rest
<emilio> fantasai: also that we should put some example in the spec about this interaction, and also on the issue about what happens if the block-overflow string can break
<emilio> fantasai: we could narrow down the behavior as 'either you treat is as unbreakable' or 'treat it as breakable and grab space from previous lines'
<emilio> astearns: so the first bit is to resolve that text-overflow affects overflowing, unbreakable portions of the block-overflow string. objections?
RESOLUTION: text-overflow affects non-breakable portions of the block-overflow string
<emilio> astearns: probably the examples doesn't need a resolution
<emilio> astearns: we're going to work on those to put them on the spec
<emilio> florian: I'm going to put examples in the spec on what we just resolved, and then in the issue about the wrapping
<emilio> astearns: should that be a different issue?
<emilio> florian: maybe, sounds reasonable
<emilio> astearns: we'll leave it to your discretion
<emilio> florian: should we resolve on the breaking to narrow it down to the two discussed options?
<emilio> astearns: don't care
<emilio> florian: I think I prefer to leave as-is for now
<emilio> florian: then we can narrow if we don't resolve soon
<emilio> astearns: I think that's reasonable, I prefer to resolve soon, the examples would be really helpful
<emilio> astearns: ahá, end was the magic word, thanks
<astearns> trackbot, end meeting
This is scribe.perl Revision: 1.153 of Date: 2018/09/19 14:40:21 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/makes sense to me/makes sense to me. It is what we would do if OpenType was only one of multiple font formats, and the others matched expectations and OpenType didn't. Of course we translate from CSS syntax to the correct font settings, and values in font-variation-settings of course get passed directly to the font./ Succeeded: s/add a note/should implies the note that astearns described/ Succeeded: s/Resolved:/RESOLVED:/g Default Present: florian, bdc, astearns, gregwhitworth, plinss, chris, tgraham, leaverou, Nigel_Megitt, dino, antenna, bradk, emilio, dbaron, tmichel, jensimmons, melanierichards, tantek Present: florian bdc astearns gregwhitworth plinss chris tgraham leaverou Nigel_Megitt dino antenna bradk emilio dbaron tmichel jensimmons melanierichards tantek Found ScribeNick: gregwhitworth Inferring Scribes: gregwhitworth WARNING: No meeting chair found! You should specify the meeting chair like this: <dbooth> Chair: dbooth Found Date: 19 Sep 2018 People with action items: WARNING: Input appears to use implicit continuation lines. You may need the "-implicitContinuations" option. WARNING: IRC log location not specified! (You can ignore this warning if you do not want the generated minutes to contain a link to the original IRC log.)[End of scribe.perl diagnostic output]