IRC log of css on 2018-09-19

Timestamps are in UTC.

15:57:41 [RRSAgent]: RRSAgent has joined #css
15:57:41 [RRSAgent]: logging to https://www.w3.org/2018/09/19-css-irc
15:57:43 [trackbot]: RRSAgent, make logs public
15:57:43 [Zakim]: Zakim has joined #css
15:57:45 [trackbot]: Meeting: Cascading Style Sheets (CSS) Working Group Teleconference
15:57:45 [trackbot]: Date: 19 September 2018
15:57:45 [florian]: present+
15:58:39 [bdc]: present+
15:59:03 [astearns]: present+
15:59:48 [gregwhitworth]: present+
15:59:59 [tmichel]: tmichel has joined #css
16:00:21 [plinss]: present+
16:00:51 [chris]: chris has joined #css
16:01:03 [chris]: present+
16:01:41 [tgraham]: present+
16:01:48 [nigel]: nigel has joined #css
16:01:58 [antenna]: antenna has joined #css
16:02:16 [leaverou]: present+
16:02:49 [bradk]: bradk has joined #css
16:02:56 [astearns]: need volunteers for scribing today
16:03:23 [gregwhitworth]: scribenick: gregwhitworth
16:03:25 [nigel]: Present+ Nigel_Megitt
16:03:30 [dino]: dino has joined #css
16:03:42 [dino]: present+
16:03:46 [antenna]: present+
16:03:51 [bradk]: Present+
16:05:10 [gregwhitworth]: astearns: anyone have any extra agenda items?
16:05:23 [gregwhitworth]: astearns: one change, we're going to skip item 8
16:05:40 [gregwhitworth]: Topic: Publishing FPWD of scrollbars
16:06:03 [gregwhitworth]: astearns: we discussed this at the f2f, but didn't get there - quite a few issues have been worked on since then.
16:06:19 [bradk]: https://github.com/w3c/csswg-drafts/labels/css-scrollbars-1
16:06:23 [gregwhitworth]: astearns: fantasai - you wanted some things working on, are you ok with it going to fpwd?
16:06:54 [gregwhitworth]: fantasai: it looks like there is an outstanding pr that should be merged first, but probably it's fine
16:06:58 [emilio]: present+
16:07:02 [gregwhitworth]: astearns: any other concerns?
16:07:05 [chris]: please let me know when that merge has happened
16:07:27 [gregwhitworth]: chris: I'll put in the transition request now and wait until that PR is merged
16:07:31 [gregwhitworth]: astearns: that sounds fine
16:07:50 [gregwhitworth]: Proposed Resolution: FPWD of scrollbars
16:08:01 [gregwhitworth]: Resolved: Request publication of FPWD of scrollbars
16:08:02 [dbaron]: present+
16:08:07 [astearns]: topic: Angle direction of font-style
16:08:10 [bradk]: https://github.com/w3c/csswg-drafts/issues/3091
16:08:10 [astearns]: github: https://github.com/w3c/csswg-drafts/issues/3091
16:08:20 [gregwhitworth]: Topic: Variable Fonts - Angle direciton of font-style
16:08:36 [astearns]: github: https://github.com/w3c/csswg-drafts/issues/3091
16:08:38 [gregwhitworth]: chris: it's about the slant axis and the range of values that are supported
16:09:00 [gregwhitworth]: chris: the opentype spec takes negative values that it slants in an odd direction
16:09:11 [gregwhitworth]: chris: every single example I've seen uses a positive angle
16:09:36 [gregwhitworth]: chris: when you're using high level things, like font-style you need to use positive integers
16:09:57 [gregwhitworth]: chris: 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
16:10:04 [fantasai]: wfm
16:10:29 [fremy]: fremy has joined #css
16:11:16 [gregwhitworth]: chris: for font-style a positive angle will make a forward slant and under the hood it will map to what the font needs
16:11:47 [gregwhitworth]: astearns: the lower level will just pass through what is written by the author
16:11:55 [bradk]: +1
16:11:57 [gregwhitworth]: fantasai: it makes sense to me
16:11:59 [florian]: sounds good to me. let's make things sane for people
16:12:18 [tmichel]: present+
16:12:30 [jensimmons]: jensimmons has joined #css
16:13:03 [jensimmons]: present+
16:13:12 [gregwhitworth]: myles: this is similiar to how we handled optical sizing
16:13:51 [gregwhitworth]: 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
16:13:56 [gregwhitworth]: Resolved
16:14:05 [astearns]: topic: publication
16:14:13 [gregwhitworth]: astearns: fonts level 4
16:14:32 [fantasai]: 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./
16:14:32 [gregwhitworth]: astearns: we had an update to l3 this week, does anyone have an objection to updating a regular WD for L4
16:14:37 [fantasai]: +1 to publishing
16:14:39 [gregwhitworth]: astearns: hearing none
16:14:41 [fantasai]: \^_^/
16:14:47 [gregwhitworth]: Resolved: Publish fonts L4
16:14:59 [gregwhitworth]: Topic: box-decoration-break and multi-box inline elements
16:15:04 [astearns]: github: https://github.com/w3c/csswg-drafts/issues/1706#issuecomment-420474809
16:15:28 [gregwhitworth]: astearns: describes what is in the issue
16:16:36 [gregwhitworth]: 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?
16:17:11 [gregwhitworth]: astearns: it describes non-contiguous fragments
16:17:22 [gregwhitworth]: fantasai: I could possibly make that a little bit clearer with regards to bidi
16:17:31 [melanierichards]: present+
16:17:38 [gregwhitworth]: fantasai: the two fragments may end up ajacent to each other, the way the inline happens to break
16:18:27 [gregwhitworth]: fantasai: 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
16:18:52 [gregwhitworth]: fantasai: in that case if you did, box-decoration: clone you would end up with text in between them because the bidi algo
16:19:04 [zcorpan]: zcorpan has joined #css
16:19:25 [gregwhitworth]: fantasai: I think I can try to make it slightly clearer
16:19:40 [gregwhitworth]: fantasai: the part about non-contiguous is an example - it's not exhaustive
16:19:44 [gregwhitworth]: astearns: that's fair
16:19:51 [gregwhitworth]: fantasai: I think the wording is ok
16:19:56 [gregwhitworth]: dbaron: one about the bidi thing
16:20:14 [gregwhitworth]: dbaron: where implementations would create a seperate fragment logically but they can never be seperate
16:20:50 [gregwhitworth]: 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
16:21:06 [chris]: rrsagent, here
16:21:06 [RRSAgent]: See https://www.w3.org/2018/09/19-css-irc#T16-21-06
16:21:16 [gregwhitworth]: dbaron: what you're saying is that it's on a visual perspective of whether it has the capability of breaking
16:21:23 [gregwhitworth]: dbaron: that seems complicated to implement
16:21:42 [gregwhitworth]: fantasai: this is about where it's defined to have a fragmenetation break
16:22:08 [gregwhitworth]: fantasai: from a rendering perspective, the user can't tell that it's doing that
16:22:31 [gregwhitworth]: fantasai: the only case this should be known, is where there is text outside of the inline is intruding on the inline
16:22:45 [gregwhitworth]: dbaron: I'm a little worried about.... <garbled>
16:23:22 [gregwhitworth]: dbaron: this section has a lot of mays in it, we should have an issue for better definition
16:23:25 [gregwhitworth]: fantasai: for sure
16:23:31 [gregwhitworth]: dbaron: please open an issue
16:23:34 [gregwhitworth]: fantasai: I can open one
16:24:08 [gregwhitworth]: astearns: just open an issue for defining it better and leave the may out of this draft
16:24:21 [gregwhitworth]: fantasai: we don't have any implementations so the may is there
16:24:56 [gregwhitworth]: 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
16:25:03 [gregwhitworth]: fantasai: ok, that's fair
16:25:15 [Karen]: Karen has joined #css
16:25:17 [gregwhitworth]: fantasai: how would the WG prefer, a may with a note - or a must
16:25:56 [gregwhitworth]: astearns: I'm thinking a note that states that a future level will completely specify what occurs in this situation
16:26:10 [gregwhitworth]: florian: I think that's what should is for
16:26:16 [gregwhitworth]: florian: add a note
16:26:23 [gregwhitworth]: dbaron: I support should as well
16:26:42 [gregwhitworth]: Proposed Resolution: Take the patch substituting should for may
16:26:44 [florian]: s/add a note/should implies the note that astearns described/
16:26:46 [gregwhitworth]: astearns: objections?
16:26:52 [gregwhitworth]: Resolved: Take the proposed patch
16:27:16 [tantek]: tantek has joined #css
16:27:32 [astearns]: resolved: use should in the patch
16:27:43 [gregwhitworth]: ^ what astearns said
16:27:56 [astearns]: topic: editor for text
16:28:00 [fantasai]: https://drafts.csswg.org/css-break-3/issues-cr-2016
16:29:05 [tantek]: present+
16:29:07 [gregwhitworth]: astearns: add florian as an editor to text L 3
16:29:14 [gregwhitworth]: Resolved add florian as an editor
16:29:32 [gregwhitworth]: Topic: Reverting resolution about overflow wrap break word
16:29:37 [astearns]: github: https://github.com/w3c/csswg-drafts/issues/2951#issuecomment-421705003
16:29:59 [gregwhitworth]: florian: we tried to have break-word affect intrinsic sizing
16:30:26 [gregwhitworth]: florian: we had some hope that changes int he UA stylesheet would be sufficient, but it is not true unfortunately
16:30:51 [gregwhitworth]: florian: so the only option it seems is to revert the previous resolution where it does not affect intrinsic sizing
16:30:58 [gregwhitworth]: astearns: is that seperate issue somewhere?
16:31:05 [gregwhitworth]: fantasai: yeah we re-opened the issue
16:31:12 [gregwhitworth]: astearns: objections?
16:31:28 [gregwhitworth]: Resolved: Revert the previous resolution
16:31:39 [gregwhitworth]: Topic: Applying a min width to rendered tabs
16:31:42 [astearns]: github: https://github.com/w3c/csswg-drafts/issues/2883#issuecomment-421733978
16:32:09 [gregwhitworth]: florian: when you have tab stops, if you have a tab - you're supposed to go forward in the line
16:32:38 [gregwhitworth]: florian: if your text is coming extremely close to the next tab stop, should there be a minimum size?
16:33:15 [gregwhitworth]: florian: Chrome, it jumps to the next one at a specific size and it seems reasonable in a monospaced font
16:33:21 [fantasai]: s/Resolved:/RESOLVED:/g
16:33:49 [gregwhitworth]: florian: I was thinking about going with 1 space, but maybe we should go smaller than a space
16:34:29 [gregwhitworth]: florian: in a proportional font, spaces are already really small - 0.5ch
16:35:15 [gregwhitworth]: florian: I'm wanting to take this normative as makes sense
16:35:46 [emilio]: astearns: Any comments from the non-chrome team?
16:35:57 [fantasai]: +1 from me anyway
16:36:15 [emilio]: astearns: proposal is minimum spacing is 0.5ch
16:36:25 [emilio]: astearns: objections?
16:36:38 [emilio]: astearns: RESOLVED: Make the normative change
16:36:57 [emilio]: myles: Should link to the primary font concept
16:37:04 [fantasai]: https://www.w3.org/TR/css-values-3/#ch
16:37:20 [emilio]: fantasai: it already does via the ch value, though it's not actually the primary font
16:38:22 [emilio]: fantasai: it's ch, it's not ambiguous
16:38:27 [emilio]: emilio: is it what Blink implements?
16:38:45 [emilio]: myles: if the code is the same as WK it's not exactly the same, but we can say ch on the spec
16:39:01 [emilio]: astearns: the test for this is not going to test this exactly
16:39:04 [emilio]: fantasai: why not?
16:39:23 [emilio]: astearns: flaky tests / pixel differences
16:39:29 [emilio]: fantasai: fine
16:39:41 [astearns]: topic: publication of text 3/4
16:39:51 [tantek]: FYI chris, I reviewed and merged the one outstanding pull-request on https://github.com/w3c/csswg-drafts/labels/css-scrollbars-1
16:40:06 [emilio]: astearns: both text-3 and text-3 are working drafts, proposal is publishing a new WD as text-3
16:40:11 [emilio]: astearns: no objections?
16:40:25 [emilio]: RESOLVED: publish a new working draft as text-3
16:40:32 [emilio]: astearns: any objections for text-4?
16:40:40 [emilio]: RESOLVED: publish a new WD for text-4
16:40:55 [AmeliaBR]: AmeliaBR has joined #css
16:41:13 [astearns]: topic: block-overflow and text-overflow
16:41:15 [astearns]: github: https://github.com/w3c/csswg-drafts/issues/2882
16:41:51 [emilio]: florian: so the issue is about whether their interaction is well-defined. There's only one case where it's not defined.
16:42:35 [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
16:43:09 [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
16:44:05 [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'
16:44:13 [emilio]: tantek: I think we need an example that we could look up
16:44:51 [emilio]: florian: it's something like a very narrow paragraph with a very long block-overflow ellipsis
16:46:04 [emilio]: florian: the spec says that if block-overflow ellipsis overflows then it may overflow to the next line, but it's undefined
16:46:10 [emilio]: tantek: any implementation experience?
16:46:23 [emilio]: tantek: we should construct some examples and experiment, keeping the issue open for now
16:46:35 [emilio]: tantek: rather than spec something that is not easy to implement
16:46:46 [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.
16:47:33 [emilio]: fantasai: seems fine to leave it open as people implement it
16:47:57 [emilio]: florian: so I'd expand on the proposal with examples in the issue
16:48:09 [emilio]: florian: I'm ok with that
16:48:28 [emilio]: dbaron: [what he wrote above]
16:49:05 [emilio]: dbaron: saying that it needs to fit on one line definitely makes implementation easier, but it's not clear how much
16:49:35 [emilio]: tantek: I'd prefer to specify the better behavior for the user, and we don't know how much harder it is
16:51:45 [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
16:52:16 [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
16:52:43 [emilio]: florian: does it sound reasonable to resolve on what fantasai said and add examples for the block-ellipsis on multiple lines?
16:53:12 [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
16:53:40 [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
16:54:19 [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'
16:54:43 [emilio]: astearns: so the first bit is to resolve that text-overflow affects overflowing, unbreakable portions of the block-overflow string. objections?
16:54:59 [emilio]: RESOLVED: text-overflow affects non-breakable portions of the block-overflow string
16:55:12 [emilio]: astearns: probably the examples doesn't need a resolution
16:55:29 [emilio]: astearns: we're going to work on those to put them on the spec
16:55:47 [emilio]: florian: I'm going to put examples in the spec on what we just resolved, and then in the issue about the wrapping
16:55:51 [emilio]: astearns: should that be a different issue?
16:55:57 [emilio]: florian: maybe, sounds reasonable
16:56:12 [emilio]: astearns: we'll leave it to your discretion
16:56:44 [emilio]: florian: should we resolve on the breaking to narrow it down to the two discussed options?
16:56:58 [emilio]: astearns: don't care
16:57:09 [emilio]: florian: I think I prefer to leave as-is for now
16:57:24 [emilio]: florian: then we can narrow if we don't resolve soon
16:57:39 [emilio]: astearns: I think that's reasonable, I prefer to resolve soon, the examples would be really helpful
16:58:34 [astearns]: topic: end
16:58:51 [emilio]: astearns: ahá, end was the magic word, thanks
16:58:51 [astearns]: trackbot, end meeting
16:58:51 [trackbot]: Zakim, list attendees
16:58:51 [Zakim]: As of this point the attendees have been florian, bdc, astearns, gregwhitworth, plinss, chris, tgraham, leaverou, Nigel_Megitt, dino, antenna, bradk, emilio, dbaron, tmichel,
16:58:54 [Zakim]: ... jensimmons, melanierichards, tantek
16:58:59 [trackbot]: RRSAgent, please draft minutes
16:58:59 [RRSAgent]: I have made the request to generate https://www.w3.org/2018/09/19-css-minutes.html trackbot
16:59:00 [trackbot]: RRSAgent, bye
16:59:00 [RRSAgent]: I see no action items