00:46:54 jfkthame has joined #css 01:44:47 dauwhe has joined #css 03:28:31 dauwhe has joined #css 03:38:25 Karen has joined #css 04:16:36 drousso has joined #css 04:58:44 dauwhe has joined #css 05:02:41 aja has joined #css 05:09:03 dauwhe has joined #css 05:47:05 dauwhe has joined #css 06:41:54 drousso has joined #css 07:47:57 dauwhe has joined #css 07:58:45 dauwhe has joined #css 08:00:20 jfkthame has joined #css 08:11:32 rego has joined #css 08:16:29 svillar_ has joined #css 08:30:40 jfkthame has joined #css 08:56:13 jfkthame has joined #css 08:57:09 myles has joined #css 08:59:00 igalia has joined #css 09:00:39 lajava has joined #css 09:00:53 dauwhe has joined #css 09:05:58 Zakim has joined #css 09:06:03 zakim, start meeting 09:06:03 RRSAgent, make logs Public 09:06:04 Meeting: Cascading Style Sheets (CSS) Working Group Teleconference 09:06:33 (still waiting for people to arrive, just setting up the bot stuff so I don't forget later) 09:07:11 oriol has joined #css 09:09:39 RossenF2F has joined #css 09:10:13 Zakim, start meeting 09:10:13 RRSAgent, make logs Public 09:10:14 Meeting: Cascading Style Sheets (CSS) Working Group Teleconference 09:11:41 dauwhe has joined #css 09:13:01 RossenF2F_ has joined #css 09:13:06 present+ 09:13:36 present+ 09:13:46 present+ 09:13:47 bkardell_ has joined #css 09:13:48 present+ 09:13:53 present+ 09:13:59 present+ 09:14:02 present+ 09:14:44 stantonm has joined #css 09:14:49 faceless has joined #css 09:14:49 present+ 09:14:52 present+ 09:15:00 scribenick faceless2 09:15:03 present_ 09:15:06 present+ 09:15:54 present+ 09:16:03 topic: limit local fonts 09:16:09 github: https://github.com/w3c/csswg-drafts/issues/4497 09:17:07 Rossen__ has joined #css 09:17:42 pete: is taling about font fingerprinting by identifying the computer based on which fonts are installed on the computer 09:18:28 pete on suggestion is to list a document which describes a list of specific onts 09:18:31 s/onts/fonts 09:18:47 myles asked about what pete wanted to discuss that wsn't on a previous call 09:18:49 fremy has joined #css 09:18:57 present+ 09:19:08 present+ 09:19:16 (from the last discussion: astearns: I think we should go back to GH and hammer out exact proposal and level of requirements. I think there's quite a bit of work before there's something to put in spec, but we should get to that. Maybe checkpoint in a month) 09:19:30 dbaron one of the questions was to what extent this would be allowed vs recommended vs mandatory. is comfortable with recommended not sure about mandatory partly because we don't know exactly what we're trying to do. open questions. 09:19:42 dbaron thinks we should allow this 09:19:44 myles at already does 09:20:23 dbaron ... to recommednd this, and work on addding detail to the recommendation. when we're comfortable with the level of detail there, we can mandate this, but there are lots of open questions 09:20:31 dbaron eg. effects on minorities etc. 09:20:37 myles has joined #css 09:20:50 s/minorities/linguistic minorities, across OSes,/ 09:20:54 myles if we don't make mandatory but do make recommended, would be good to hear from all present if we should change behaviour 09:21:27 pete webkit is even safer than this, webkit won't load some fonts off disk 09:21:32 jensimmons has joined #css 09:21:38 present+ 09:21:46 chris has joined #css 09:21:47 present+ 09:21:58 q? 09:21:59 present+ myles 09:22:00 present+ 09:22:01 present+ 09:22:03 q? 09:22:04 dbaron maybe jonathon can speak more authoritively on this but thinks maybe this might be more difficult to do on some platforms than others 09:22:11 present+ 09:22:13 ack faceless 09:22:20 ack fantasai 09:22:20 fantasai, you wanted to mention CSS2PDF renderers 09:22:39 fantasai wanted to say there are classes of user agents where this makes no sense. eg css-pdf renderers, which need to access all fonts on the system 09:23:24 chrisL: localhost could have access to all of thm 09:23:31 svgeesus css to pdf renderers have the ability to opt in to lists of fonts per site, which makes it more possible to opt out 09:23:42 (as in opt out of fonts per domain) 09:23:46 s/dbaron maybe/dbaron: maybe/ 09:23:57 pes has joined #css 09:23:59 +q 09:24:07 although I wasn't just speaking of css to pdf renderers 09:24:18 myles: as an engineer I am always thinking about how we can test this, but if there's going to be no changes to the file system this will be untestable 09:24:32 s/thinks maybe this might/we support a larger number of platforms and on some of those this might/ 09:24:36 ack pes 09:24:51 pete: initial proposal was all this should be dealt with by the browser opting in 09:25:19 pete: if the takeway is that the idea is useful but nothing is required at this point, I don't think that's any change from the status quo 09:25:28 fantasai: a should requirement is not a no-op 09:25:32 tantek has joined #css 09:25:38 present+ 09:25:44 fantasi: it recommends action and it may be appropriate in this case. 09:25:59 present+ 09:26:00 myles: but if no-one acts on that recommendation what's the point of it? 09:26:25 fantasai: users agents don't always act on hard recommendations either. 09:26:28 q? 09:26:46 If necessary I can state this at some point, but I believe Chrome's position is that we extremely want to stop fingerprinting as an identification vector, but I don't think that designing a solution in a committee with this skill set is appropriate. (There are groups in W3C (or elsewhere?) that are more appropriate and contain people with the right set of skills.) 09:26:52 3. SHOULD This word, or the adjective "RECOMMENDED", mean that there may exist valid reasons in particular circumstances to ignore a particular item, but the full implications must be understood and carefully weighed before choosing a different course. 09:26:52 https://tools.ietf.org/html/rfc2119 09:26:56 fantasai: should means if you have a good reason not to do it, you don't have to do it. But you need a good reason 09:27:02 https://tools.ietf.org/html/rfc2119 09:27:21 myles: to paraphrase fantasai : we can put a should and say all browsers should do this, or we can make a partition and say some browsers should, some shouldn't 09:27:36 myeles: pete said first option was a thumbs down 09:27:52 pete: if there's an option that is available to the user-agent to do this that's ok 09:28:15 fantasai: I would imagine you would object to this being turned on by default. but cs-spdf renderers would have to turn this on by default 09:28:17 skk has joined #css 09:28:27 pete: doesn't have to be that way. if you're sefving documents off disk, for example, it could be off 09:28:55 svgeesus: could you explain the harm of the status quo where someone on their own disk converts a file locally 09:29:03 pete: that's not what I mean 09:29:08 q? 09:29:18 floriank: so if we don't mean everyone has to do this, then lets not say everyone 09:29:20 +q 09:29:37 ack pes 09:29:53 s/say some browsers should, some shouldn't/say some browsers must, some must not/ 09:30:06 pete: its seems like this must not be a new idea - there are cases where apps using hTML renderers have one set of rules, browsers have others 09:30:19 heycam: we do 09:30:50 different conformance classes for selectors (fast profile) 09:30:58 florian: should means you have to do it unless there is a good reason, but good reasons do exist and if you have them you won't be arrested for not doing it 09:31:00 (Im very sorry to be tedious, but could people identify themselves when speaking for a bit?) 09:31:01 present+ 09:31:23 +q 09:31:28 s/for not doing it/for not doing it, but neither would you if we wrote must/ 09:32:01 s/if you have them you won't be/if you have them you won't be non-conformant. You won't be/ 09:32:09 pete: who's planning on doing what? 09:32:14 s/for not doing it/for not doing it under SHOULD, but neither would you be under MUST/ 09:32:32 q+ 09:32:32 pete: it's pretty important we get this sorted out so we can get the cross-browser expectations to users 09:32:36 -q 09:33:24 q+ 09:33:57 tab: especially gven recent info. fingerprinting in side channels is a very tricky thing to do and we don't have the expertises in this committee so i'd object to putting a "must" on this as i don't think we have the ability to do it ourselves 09:34:23 tab: while it's very important and needs doing, I don't want to put anything binding on this committee 09:34:24 ack florian 09:34:30 q+ 09:34:33 and a 'should' allows all non-Chrome browsers to do the thing and eventually make it more likely for them to bend 09:34:51 note that "print formatters" are also "normal browsers" in Print Preview mode 09:35:03 ack pes 09:35:06 florian: we could put a note on this clarifying the intent to explain why a should recommendation is there and who shuodl follwo it 09:35:20 +1 to tantek 09:35:38 pete: surely we do have the expertises 09:36:20 tab: lI'm talking specifically about the CSSWG - the goal of reducing fingerprinting is 100% our goal, but Chrome doesn't want to bind themselves to a MUST resolution 09:36:35 tpete: if you aren't hte people to ask, who is? 09:36:40 s/tpete/pete/ 09:36:57 we really need to capture as much as we can in the issue, and then reach out more broadly than the WG 09:37:01 tab: we have engineers who are working on this and hav ethe expertise on this, but none of this in this group have the expertise 09:37:02 ack hober 09:37:02 sounds like this discussion is going in circles 09:37:03 q+ 09:38:18 hober: you have co-chairs of ping and the privacy cg in this room, and pete is not coming to us as an individual - this is a concern from a number of people in this area. as a member consortium it's the responsibilty of this group that we have people who can speak on these issues. so it's disheartening to hear you don't want to consider this because we don't have the expertise. that's our role 09:38:53 tab: yes I understand but this is the only privacy issues on this point, it's not approriate to invite the security team to be here 09:38:56 q+ 09:39:05 tab: i'm on the write person, none of here are. 09:39:15 s/on the write/not the right/ 09:39:25 rossen: calls order 09:39:34 ack dbaron 09:39:34 LOL: one-line S&P section in css-fonts 4: "The system-ui keyword exposes the operating system’s default system UI font to fingerprinting mechanisms." 09:39:39 I think the PING/etc are the right venues for this discussion, not the CSSWG. 09:39:50 did I write that? 09:39:52 TabAtkins: PING came to us with this! 09:40:01 s/did I write that?// 09:40:05 presumably we are talking about more than just system fonts 09:40:07 dbaron: pete asked who are the right people. i think sort of a weird question, given the response we're trying for. I think we are the right people, but the misunderstanding that leads pete to ask this question is that it's not a short process 09:40:08 This needs to be "privacy teams, with a font-related engineer on call", not "a bunch of layout/etc engineers, with a privacy engineer on call" 09:40:31 (i cannot hear anyone speaking…) 09:40:43 dbaron: we're trying to make a substantial change to the way this works on the web platform. It's a process that requires proposal, iteration, requirements 09:41:07 dbaron: (is more emphatic) 09:41:47 dbaron: we're trying to do this thing that requires iteration and refinement of a proposal, and what we're saying is "yes, we're accepting that this is the next stage of the process and it's woth pursuing" 09:42:05 hober, Sure, and I'm saying that looking to this group for binding resolutions on this topic isn't appropriate. We own a spec with a feature that will be impacted; that doesn't mean we should be designing the change, just ensuring that it's integrated and well-explained when it's finished. 09:42:33 dbaron: but pete is saying that's not the right thing - we need to have a solution now. But we haven't had the conversation that we need to have first. So we're basically saying yes to it, but we have to begin the process 09:42:41 dbaron: I think that disconnect is why we're stuck 09:42:50 q+ 09:42:53 pete: with respect this was filed in june. there's been on counter-proposal since then 09:43:00 pete: this is the #1 privacy issues on the web 09:43:14 rossen: we understand and we recognise the urgency but the reality is there is a backlog 09:43:25 q? 09:43:29 rossen: the fact it was filed a while back does't mean it's not important to us 09:43:31 s/there's been on counter-proposal/has not been a counter-proposal/g 09:43:37 See, for example, how we were just spitballing about how to design a font list and how to segregate it. We don't have the expertise to do that; we can't get "close enough". It has to be done *right*, and we're not the group to do that. 09:43:38 s/pete/pes 09:43:59 ack pes 09:44:15 pes: i want to know what the next steps are. If there's a process, what is it, what is the timeline? 09:44:37 rossen: one of the proposals is to resolve with accepting this as a SHOULD statement. 09:44:53 alan: the spec has this currently as a MAY? 09:45:04 q- 09:45:05 myles: yes, what pete is aiming for is different 09:45:14 q? 09:45:26 the current "MYA" has a lot less detail 09:45:30 q+ 09:45:34 s/MYA/MAY 09:45:34 rossen: can we take the resolution now that changing the current definition to a SHOULD and live with that? 09:45:53 myles: not unless someone can state what the SHOULD should say. 09:45:54 agreed I want to see the full statement here in the minutes 09:46:01 florian: agrees with myles 09:46:03 +1 myles 09:46:29 florian: you asked about next steps, the relevant user agents will attempt to do it once the SHOULD has been framed properly 09:46:47 florian: after that, one the user-agents implement, we'll get feedback and see what to do then 09:47:01 q+ 09:47:22 florian: maybe we will find a line to draw to mkae a distinction, i.e. user agents loading from the file system. but we don't have that information onw 09:47:26 s/onw/now 09:47:29 q? 09:47:50 svgeesus: pete if you're happy to make a first draft of the SHOULD recommendation I'm very happy to work with you on this 09:48:13 pes: happy to, but is there a rough timeline, and also the current proposal points to a list maintained elsewhere. Is that the way we want to keep things? 09:48:26 rossen: ok first issue. Do we ant to stick with a list that is maintained elsewhere 09:48:34 dbaron: a list of what? 09:48:50 TabAtkins: local fonts that are allowed 09:48:52 florian: the current spec is a list of things which are ok, - fonts 09:49:20 +1 don't think where the list lives is the first thing to worry about here 09:49:31 q+ 09:49:32 floain: i think we should write the list down, put it wherever, once we have figured it out we can worry about where to put it later 09:50:08 johnq: it's not clear where this this group maintaining a list is the right approach or whether we should look into platform APIs exist to determine which fonts are platform installed vs user installed. 09:50:19 s/johnq/jkew/ 09:50:55 jkew: it seems like maintaining a list is a never-ending nightmare. maybe OS vendors should maintain the list? I'm not sure it's realiistic that we maintain it. 09:51:18 q- 09:51:22 q+ 09:51:26 florian: no macOS API will give you that list. We should start with a list and once we've tried it out, we may find it's not the best option 09:51:34 q? 09:51:44 rossen: lets try to find something actionable 09:52:13 s/once we've tried it out, , we may find it's not the best option/once we've written it, we can debate the proposal/ 09:52:31 pes: i understand the reticence against a list and wanting something easier to maintain. 09:52:35 ack pes 09:52:37 ack dbaron 09:53:19 a ruberic 09:53:33 dbaron: to respond to jkew and pes - list is maybe to specific a term. we shoould be describing what we want to do and on each platform there may be a different approach - an API, a list, it's the intent that matters. 09:53:39 +1 dbaron 09:53:44 dbaron: the main thing is that we try this and see what works. 09:54:01 what is the road to get to the right answer then? 09:54:10 pes, where's the proposal? can you link it? 09:54:14 start with that 09:54:18 dbaron: I don't think we know what the best thing to do is yes. We can't specify this with the right level of detail on each platfrom, we need to allow for feedback from ach platform to find the best solution 09:54:24 ack myles 09:54:44 this is not a new issue / problem. An outcome that is “vendors will look into it”, this is not progress 09:55:09 myles: first, responding to florian: feels florian was assuming that there was a single set of fonts common to everyone. we don't do that - we have different sets for different parts of the world. 09:55:18 myles: seo even just for us, we can't have a single list that is uniform. 09:55:21 [tantek : initial issue / concern https://github.com/w3c/csswg-drafts/issues/4055, follow up proposal: https://github.com/w3c/csswg-drafts/issues/4497] 09:55:29 myles: so we certainly can't across all OSes 09:55:32 Github: https://github.com/w3c/csswg-drafts/issues/4497 09:56:00 florian: I was saying the current proposal specifies a single list, but that's probably not ideal. But that's our start point as it's in the spec. 09:56:28 q? 09:56:34 myles: there is no list for our platforms about what the currently available fonts are - we use an API. 09:56:59 rossen: next steps. Pete is going to take a stab at moving the current statement from a MAY to a more stict version of SHOULD 09:57:09 pes, I think we're at the point where we need sample spec text proposed in the issue. Just reviewed the proposal bits and looks a bit scattered TBH 09:57:29 rossen: and the technical recommendations of how to reference those fonts, dbaron said this well - referring to this as a list is not the full picture. But it is a start 09:57:51 rossen: once we have the actual proposal we can try to narrow down the technical soution 09:57:53 pes, I'm not disagreeing with the issue. I read through 4497 and the proposal there is more of an outline of desired outcome 09:57:55 s/soution/solution/ 09:58:00 rossen: anything else? 09:58:42 tantek: this might be clsoer to what you’re looking for https://github.com/w3c/csswg-drafts/issues/4497#issuecomment-565832611 09:58:43 rossen: pete, we're not trying to sandbag this - it's a normal process. we are interested in this and that might not be clear. Bear with us and once you have the actionable definition we'll go from there 09:59:06 rossen: I suggest we end this and move on and will come back to it once pete has acted? on the next call? 09:59:08 pes: when is that? 09:59:15 rossen: probably two weeks 09:59:27 pes, that's a very good summary start. Now, where in the spec would you put that, and can you reword it procedurally as a set of steps that browser should/must follow? 09:59:27 roseen: thanks for your engagement 09:59:33 s/roseen/rossen 09:59:38 The calls are Wednesdays at 9am California time / noon Boston time / etc. 09:59:42 tantek: on it :) 09:59:53 pes, related, you may be interested in contributing to https://github.com/w3c/csswg-drafts/issues/4697 09:59:58 rossen: ok, lets get on with it. a few text related topics. clarifying skip ink auto is related to CJK 10:00:11 myles: no this was opened by jkew 10:01:05 Topic: [css-text-decor] Clarifying skip-ink:auto behavior in relation to CJK text 10:01:13 github: https://github.com/w3c/csswg-drafts/issues/4276 10:02:10 jkewL the issue is that text-decoration-skip-ink, browser have chosen generally not to apply this to CJK text because in practice it clases with most of the glyphs and looks terrible. 10:02:16 s/jkewL/jkew 10:02:56 jkew: what troubles me is that the webkit/chrome have chosen to skip this for a particular set of glyphs, but there's a disconnect as to which glyphs are skipped. In particular Blink has chosen to skip a number of punctuation chararacters 10:03:28 jkew: I was hoping to the spec could pin this down to work on a sequence of script characters, so that punctuation surrounded by CJK is CJK. 10:03:49 jkew: I'd like to settle on what we do in Firefox, which is better. At the moment the spec doesn't define it 10:03:50 q? 10:04:03 myles: consistancy is good but what the motivation? bug reports? 10:04:17 jkew: I'm sure we did have reports 10:04:46 myles: when you started implementing? Or was it issues around the specific characters? 10:05:21 jkew: initially we simply implemented and found the same issues in CJK as everyone else 10:05:25 q+ 10:05:40 myles: in the absence of specific bug reports and users are not complaining, maybe we should leave it as it is? 10:06:16 q+ 10:06:25 jensimmons: can we perhaps specify it and see what comes form that? 10:06:47 ack koji 10:07:02 koji: i"m generally with myles on this. we had reports that our slashes looked quite bad. when looking at gecko they don't look bad 10:07:06 jensimmons: is the desire of one browser to not put in the effort a reason to not spec interop. If interop on this is ideal, we can spec it and then each browser can make decisions about prioritization. (is the point I was making) 10:07:46 kohi: so I believe we shuold add slashes to the list. So this is a heuristic. It's not testable. But I understand that if gecko gets reports that says the inconsistancy is troubling then this is an issue 10:07:49 ack florian 10:08:07 s/kohi/koji 10:08:43 florian: the spec is very vague, it says you can skip but not why. Even if we don't go all the way to defining a list, we may want to clarify the intent of this. That will not help with the immediate concern about interop, but it will help for anyone trying to understand or implement this 10:08:52 myles: I can add some text about that 10:08:56 ack dbaron 10:09:29 dbaron: I think the situation today is if we don't define things, everyone will just copy what chrome does. So if what Chrome does is right, lets put that in the spec as we're going to copy it anyway. If not, put in the spec what is right. 10:09:35 I feel like that needs to be repeated at the start of every CSSWG meeting 10:09:38 myles: is not keen on that idea 10:09:43 fremy has joined #css 10:10:07 q? 10:10:09 tab: if we do whatever chrome does, it should be an choice made because chroms is doing the right thing. I want' something written down because it will be a compat issue 10:10:31 myles: if no-one has bug reports, it's not a compat issue yet. maybe we wait until the first report 10:10:53 tab: we have enough issues to know that's not the best aproach 10:11:00 s/aproach/approach 10:11:17 q? 10:11:27 ack dbaron 10:12:12 dbaron: we've found that compat constraints get stricter over time. The longer things are out on the web, they require interop and expect it to get better over time. So if we find things that aren't we should fix that early 10:12:47 dbaron: with the lack of bug reports, we have a cultural bias - filing them requires that you speak english and this is not the sort of bug report that english speakers will file 10:13:04 ^^^ great FAQ answer for "Did you get a bug report?" 10:13:14 q+ 10:13:36 myles: I'm not going to push back on this. I would prefer that the approach taken is that text describing this is a reference to another spec, not a list of characters. 10:14:38 koji: I'm fine to have some text added that allows the UA to have some heuristics. Our bug report was opposite. We had strong opinions. people said "don't just disable skipping because slashes look bad" 10:15:06 myles: how would you formulate that in a spec? a list that need to be skipped and the rest are undefined? something else? 10:15:34 koji: not strong on specifics, but if we got reports on a specific code point we could add that, but leave others undefined. 10:15:44 rossen: who's going to write this up? 10:15:53 myles: I volunteer jkew 10:16:45 rossen: next action, jkew to modify the spec which - as myles suggests, references unicode - with a suggested approach that allows flexibility: 10:17:34 ACTION: add specifics into ink-skipping details TBD. And that it's done by reference. 10:18:17 ACTION: fully specify an algorithm that specifies ink skipping that references other specifications that isn't codepoint-by-codepoint 10:18:39 RESOLVED: fully specify an algorithm that specifies ink skipping that references other specifications that isn't codepoint-by-codepoint 10:18:40 fantasai: who's doing this? 10:18:45 rossen: jkew 10:19:02 Topic: [css-ruby-1] ruby overhang control 10:19:10 github: https://github.com/w3c/csswg-drafts/issues/4492 10:19:48 I see https://github.com/w3c/csswg-drafts/issues/4419 on Text part 1 and Text part 2. Is this intentional? 10:20:25 stanton: I'll introduce this 10:20:58 s/stanton/stantonm/ 10:21:03 stanton: bit of background - in japanese text, in normal text all the characters are solid text - there is no space between the characters. Ruby allows this to change - if the ruby is longer than the base text, it can push spaces between the text. 10:21:44 stanton: we've had feedback from authors that they don't always want to allow for this overhang. The overhang can cause confusion. We had feedback from JL task force and from younger users 10:21:57 q+ 10:22:20 stanton: proposal is to add a new property to disallow overhang. default we be auto which is the current behaviour. New value would be none which would disallow overhang outside the containing box? 10:22:38 -q 10:22:39 ack koji 10:22:45 ack myles 10:22:50 myles: question - which element do you apply this property to? 10:22:56 timeless has joined #css 10:23:07 stanton: you could apply to document root but the one it would take effect on is the ruby tag 10:23:21 myles: the proposal give the value a length? 10:23:46 q+ 10:23:47 stanton: the initial proposal was to be a bit more firm in the value of the value of overjang JLREQ and JIS recommend a value of 1, but none of the browsers actually do this 10:23:57 stanton: the suggestion of auto was to allow more flxibility 10:24:30 myles: a length seems to fine grained. florian suggests auto with none, I agree. Second best option maybe large/small. Third best is multiple of font-size. All better than a length 10:24:41 stanton: auto and none fits the user cases we see from authors 10:25:01 fantasai: agrees with myles. auto vs none. length would resolve against the root elements length 10:25:11 ack florian 10:25:21 florian: we may well have different approaches later, maybe clarify this later but for now, auto 10:25:40 s/clarify this/clarify this or add more values/ 10:25:56 rossen: so we are comfortable with auto and not-auto? any objections? NOne? Result. 10:26:01 s/NOne/None/ 10:26:37 RESOLVED: ruby-overhang auto | none on ruby container 10:26:45 jensimmons has joined #css 10:27:25 Topic: [css-text] Line breaking for ambiguous characters; e.g., U+2010, U+2013 10:27:34 projector has joined #css 10:27:39 github: https://github.com/w3c/csswg-drafts/issues/4419 10:28:04 Rossen has joined #css 10:28:14 ScribeNick: fantasai 10:28:18 ojan has joined #css 10:28:30 ScribeNick: emilio 10:28:34 shans has joined #css 10:28:54 koji: the current CSS spec says that if the language is japanese and line-break: normal there should be a break opportunity before 2010 and 2013 10:29:04 sylvaing has joined #css 10:29:15 ... it can break strangely for english words within japanese text 10:29:28 ... gecko fixed it by not breaking if the previous character is a latin character 10:29:33 ... but I want to fix this in the spec 10:29:35 leaverou has joined #css 10:29:36 JonathanNeal has joined #css 10:29:40 ... and make sure all browsers agree 10:30:05 plinss_ has joined #css 10:30:26 fantasai: we got together yesterday and concluded in all langs you want to disallow breaks before hyphens in normal breaking mode but japanese wants to allow it in loose mode 10:30:56 https://github.com/w3c/csswg-drafts/issues/4419#issuecomment-577700150 10:30:57 ... so word-break break-all would allow between the latin letter and the hyphen 10:30:59 q? 10:31:14 ... so that's the solution outlined in the last comment (above) 10:31:22 myles: are we going to contact ICU 10:31:27 surma has joined #css 10:31:27 koji: if we agree I'll do 10:31:30 florian: I support this 10:31:33 s/ICU/ICU and CLDR? 10:31:37 s/ICU/ICU and CLDR?/ 10:31:38 Rossen__: objections? 10:32:01 RESOLVED: Adopt the suggestion in https://github.com/w3c/csswg-drafts/issues/4419#issuecomment-577700150 10:32:36 RESOLVED: Disallow before hyphen in normal and strict. Allow break between ID and hyphen in loose. This means Kanji+Hyphen breaks; and Alphabetic+Hyphen doesn't break, unless word-break: break-all makes Alphabetic behave like ID. 10:32:40 topic: end 10:36:03 cbiesinger has joined #css 10:38:42 the video I showed was https://www.youtube.com/watch?v=wIbZqqLra9k 10:39:33 TabAtkins has joined #css 10:42:23 sangwhan has joined #css 10:52:02 hayato has joined #css 10:56:07 fremy has joined #css 10:56:40 jensimmons has joined #css 10:56:44 stantonm has joined #css 10:57:05 RossenF2F has joined #css 10:57:24 Topic: make text of leading-trim interoperable? 10:57:31 github:https://github.com/w3c/csswg-drafts/issues/3978 10:57:35 https://drafts.csswg.org/css-inline-3/#leading-trim-property 10:58:24 fantasai: we have some proposals in the early-brainstorming phases, and one of them is leading-trim which allows you to visually align some text so that it's aligned with the top of an image or such 10:58:38 ... there's several values like cap-height x-height etc 10:58:53 ... and the normal one which is laying out the text and then add the half-leading 10:59:10 ... but there's also leading-trim which doesn't add the half-leading 10:59:46 ... koji pointed out that these metrics don't have interop 10:59:53 ... so if we did trim out the half-leading above and below the text we'd probably get no interop 11:00:15 florian: can you clarify what's not interoperable? I think unless you use line-height normal stuff should mostly match 11:00:23 fantasai: different browsers use different font-metrics 11:00:46 ... I don't have a solution and don't understand the full issue from koji, but I hope we can close it somehow 11:01:25 koji: in the current implementation stuff is not interoperable. I'd like to ask about jfkthame and myles' opinion if any 11:02:10 jfkthame: I don't have an answer here, it's not clear to me there'd be any useful metric for text-top value because the metrics in font vary considerably across fonts 11:02:53 ... so the ascender in a font may or may not what you actually want. It may correspond to the ascenders of some glyphs, but it may instead have been defined to allow for accents are such 11:03:01 ... so that's probably not what you want as a designer 11:03:19 ... not clear there's a good answer 11:03:42 fantasai: there's vertical-align: text-{top,bottom}, we should probably be consistent with them 11:03:54 jfkthame: I'd bet that's not interoperable 11:04:29 q? 11:04:31 koji: jfkthame is right, even with the same font Chrome peeks different ascent behavior in mac / windows to match platform behavior 11:04:51 q+ 11:04:55 s/even/but even/ 11:05:01 ... I'd like browsers to match at least given the same font binary 11:05:19 faceless: we've been trying to figure out what browsers do 11:05:40 ... we find different behavior between FF and Chrome when a font specifies a zero line-gap in OS/2 11:05:54 ... not sure if this is about 11:06:18 fantasai: that's probably the answer for why line-height is not interoperable. But this feature should probably not use line-gap 11:06:27 ack myles 11:06:28 s/line-height/line-height: normal/ 11:07:20 myles: there's content out there that places elements so that they match up what the browser does... Whatever we do, let's say we add some switch to have an interoperable metric. It probably can't be default behavior 11:07:24 fantasai: this is opt-in 11:07:52 initial value is auto, which just does the usual thing with half-leading and whatever 11:07:56 s/auto/normal/ 11:08:04 stantonm: I think if you give authors the ability to do this even for a particular case of having a font it'd be nice 11:08:21 myles: there are three ascent/descend pairs in fonts, I don't think we want three options 11:08:32 koji: I agree... Any specific set you can accept? 11:09:07 myles: not particularly, I just have like a general aversion to parsing font files, and any interoperable solution requires code that parses font files, and that makes me sad myles 11:09:39 hober: in terms of a general principle I think there's a good thing that browser engines can rely on other platform frameworks 11:10:00 ... the job of parsing fonts is the job of the font library not the browsers 11:10:21 fantasai: can you pull out the cap height and such metrics? 11:10:36 myles: I think the best answer is we work very closely with coretext 11:11:27 fantasai: one of the goals of these features is exposing the values the font author has chosen, the remaining issue is that which metrics are not interoperably chosen across platforms, so we'd hit the issue of authors hitting different results on different platforms 11:12:26 ... I have two related concerns here: Can we give authors an interoperable way to strip the half-leading? If not, can we strip the half leading without stripping down all the way to the cap height? 11:12:33 dauwhe has joined #css 11:12:53 myles: Not 100% sure about the question but I don't think we can change default text rendering 11:12:58 fantasai: we're not proposing that 11:13:26 ... one of the features that we drafted is that you remove the half leading so that you get to align with the specified line-height 11:13:40 ... I think we have two options, either figure out an interoperable metric 11:13:45 ... or drop this value 11:13:57 https://drafts.csswg.org/css-inline-3/#propdef-leading-trim-over 11:14:43 florian: right now, the total size you add after the leading is well defined, but the leading itself is not interoperable so we don't know the starting point 11:15:04 fantasai: there's several places where the top and bottom edge of the text comes into play 11:15:25 ... one is vertical alignment 11:15:35 ... the other is when we're trying to draw backgrounds and borders 11:15:51 ... so the content box edges of the inline 11:15:56 ... I don't think that's well defined 11:16:10 koji: canvas exposes this but I don't think it's interoperable 11:16:20 s/canvas/canvas TextMetrics/ 11:16:21 fantasai: the last one is vertical-align text-{top,bottom} 11:16:35 ... but I don't know what they do 11:16:42 ... so I don't know what to put in the spec 11:17:17 myles: so if text layout is different between browsers, is it so bad that these new properties are also different between browsers? we're already in this world 11:17:45 fantasai: I think authors want a little bit more control / consistency about what's happening in the documents 11:17:57 q? 11:18:02 ack dbaron 11:18:04 ... the other thing is that I'm supposed to write the spec for these things, and I don't know what to put in them right now 11:18:32 dbaron: myles has asked about the lack of interop. I think that causes real bugs for minority browsers 11:18:58 ... like cases where a minimal amount of space perturbs the whole layout 11:19:46 ... we do hit these things occasionally, probably a bit less during the last few years, probably because of the choice of layout techniques people are using lately is changing 11:19:56 RossenF2F: but that's not true for the long tail of the web 11:19:58 +1 to dbaron 11:20:24 dbaron: there's another source of lack of interop about how you deal with all these sizes for text / inlines when these things have multiple fonts in them 11:20:39 q? 11:20:39 ... sort of the same points fantasai mentions but even more complicated and less interoperable 11:20:44 ... so probably worth separating it 11:21:04 fantasai: we can also drop the feature of leading-trim that allows you to drop the half-leading 11:21:16 ... but I'd still have the issue of text-top/text-bottom 11:21:18 s/perturbs the whole layout/perturbs the whole layout (e.g., if going from 20px high to 21px high bumps into a float and moves it to a totally different position)/ 11:22:17 florian: with flex / grid people can do more robust design and they're more likely to start trying improve typography, and then these interop differences are more likely to come up 11:22:22 s/another source of lack of interop/another source of lack of interop (which we discussed when we last met at Keio University in Tokyo)/ 11:22:35 fantasai: what do people do for text-top / text-bottom 11:22:38 ? 11:23:20 hober: myles described a simple way to do this with information you already have in the engine. Can we specify that as a baseline? 11:23:21 dauwhe has joined #css 11:23:22 RossenF2F: what's that? 11:23:43 myles: that's using the ascent / descent that you already have during text layout 11:24:03 RossenF2F: that feels like "keep doing what you're doing", which may be fine but I want to clarify what you're trying to say 11:24:12 myles: I agree that interoperability is good 11:24:25 ... but I think there are constraints that make that difficult 11:24:44 ... I also think that this is worth a warning on the spec given this is a new feature 11:25:09 florian: so this is about using text-top/text-bottom, whatever they're currently doing right? 11:25:18 ... but that's exactly about what this issue is about 11:25:20 s/I also think that this is worth a warning on the spec given this is a new feature// 11:25:34 koji: I think we need at least one interoperable value 11:25:43 ... so that authors can have control 11:26:03 myles: in some other issue I proposed somewhere else is additional descriptors in @font-face 11:26:09 ... that the browser could use 11:26:23 faceless: for fonts that have incorrect info that'd be of huge help 11:26:40 myles: and that also allows avoiding to parse font files 11:26:48 hober: that is a good idea, I think 11:26:55 koji: I'm fine with that 11:27:49 florian: so you'd add descriptors for where the text-top / text-bottom are and the browser would use these values 11:27:55 ... everywhere 11:28:12 ... seems worth looking into 11:28:23 myles: it's in some comment of some issue a long time ago, can dig it up 11:28:40 testcase for content-edge vs vertical-align: text-top http://software.hixie.ch/utilities/js/live-dom-viewer/?saved=7710 11:28:56 florian: if we manage to characterize how these behaviors differ we could let authors choose 11:29:08 myles: that'd reintroduce the problem of parsing font files 11:29:37 fantasai: so we should open an issue about this against fonts-5, and that'd get rid of the interoperability 11:29:46 ... the other thing is how we define how to use these metrics 11:30:24 ... at least in Firefox on Linux the text-top edge seems to be the same as the background of the inline, so if that happens in other platforms we can specify that they have to match 11:30:41 fremy: they don't seem to match in Chrome 11:31:00 florian: It matches here 11:31:14 koji: I think it can change across OSes 11:31:27 jyc has joined #css 11:31:27 fantasai: does it match on Safari? 11:31:34 florian: yeah, looks like 11:32:19 dbaron: they don't see to match by a pixel in Firefox here, but might be a pixel-snapping issue 11:32:36 fantasai: I'd like to resolve that text-top and the background-box of inlines use the same metrics 11:32:37 (I want to clarify, that neither Chrome nor Firefox do match on my Windows device) 11:32:46 (I see a 1px mismatch for the serif example.) 11:32:51 ... can we resolve that they ought to match 11:33:21 florian: so the non-matching behavior is something we want to fix? 11:33:55 dbaron: we could try to understand why they don't match first 11:34:07 RossenF2F: but the intent is pretty good modulo bugs/rounding issues 11:34:28 RESOLVED: Spec that text-top/bottom and background boxes of inlines ought to match 11:35:52 RESOLVED: make leading-trim's text value match the same value for text-top/text-bottom/etc 11:36:39 both really hoping this works / happy to see this from a web author perspective, and frankly a bit suspicious about odd pixel compat issues that will show up when this stuff gets tweaked in implementations 11:37:23 fantasai: we should try to request vendors to describe what's happening to have better spec text 11:37:29 topic: end 11:38:06 Topic: Apply leading-trim to inlines? #3955 11:38:10 github: https://github.com/w3c/csswg-drafts/issues/3955 11:38:47 fantasai: the purpose of leading-trim is to change the bottom edge of a block so that you can make more useful alignment of block 11:38:57 ... may be useful to make it apply to inlines 11:39:14 ... so that you can change the edge of the background boxes of inlines 11:39:35 ... right now people try to find padding values to make text look centered 11:40:05 ... this property allows to control the edge of blocks, but we could make it apply to inlines too 11:40:29 myles: I think it was a mistake to make line-height apply to inlines and this feels similar 11:40:40 fantasai: this doesn't really need to affect layout 11:41:02 ... right now when you add padding / borders to an inline it doesn't affect the position of the inline 11:41:13 ack dbaron 11:41:40 dbaron: feels like making this apply to inlines make people use backgrounds on inlines reliably, so it seems good to me 11:41:42 +1 11:41:52 ... particularly noting that it doesn't affect the line-height calculations, only the content-box 11:42:41 koji: this proposal looks like we're trying to change text-top based on something which sounds like a circular dependency 11:42:47 ... with leading-trim 11:43:18 fantasai: well not really this allows to override the content edge of backgrounds, I don't think it's inconsistent or circular 11:43:44 koji: so leading-trim: cap will only affect the background? 11:44:09 fantasai: if set on a block it sets changes the position of the line 11:44:38 ... but I propose that when you're using it on an inline it only changes the edge of the background 11:44:55 q? 11:49:53 [[ blackboard time ]] 11:50:21 koji: I want to ship the block part first so I'd prefer this to be a separate property 11:50:38 ... so that authors can detect support for it with @support 11:50:58 fantasai: we have the same issue with alignment properties 11:51:12 ... it's not great 11:51:27 dbaron: I think it's a little risky to do that 11:51:30 q? 11:51:40 s/that/that, but it's allowed/ 11:51:51 s/I think it was a mistake to make line-height apply to inlines and this feels similar// 11:52:03 ... but I think once you have it working for one type it shouldn't be a lot of work to have it working for inlines too 11:52:27 Image of blackboard at https://lists.w3.org/Archives/Public/www-archive/2020Jan/0009.html 11:52:27 koji: if the WG is fine with use shipping the block part first that's fine for me 11:52:56 fantasai: yeah seems better to have an awkward transition than needing a property per box type 11:53:12 koji: it's a bit risky... 11:53:22 fantasai: backgrounds on inlines are fairly uncommon 11:53:43 iank_: I don't think you could detect this via script 11:53:51 fantasai: I think it'd change getBoundingClientRecT() 11:54:19 ... it wouldn't change layout because the layout of an inline doesn't depend on the content area 11:54:32 ... but you can observe it via script 11:54:55 jyasskin has joined #css 11:55:36 RESOLVED: leading-trim applies to inlines by changing the content box edges 11:57:13 Topic: [css-inline-3] initial-letters; feedback from implementation 11:57:22 github: https://github.com/w3c/csswg-drafts/issues/4171 11:58:27 faceless: we implemented initial-letters, it works broadly 11:58:46 ... I think it should be simplified to work in non-latin baselines 11:59:12 ... the way it's currently defined is that you specify the number of lines that is supposed to cover and the amount that it's supposed to shift 11:59:17 ... the second parameter is redundant 11:59:21 which was the non-Safari implementation mentioned in passing? I couldn't hear 11:59:32 ... we already got the ability to shifts baselines up / down using baseline-shift 11:59:48 fantasai: I think there are a bunch of issues in this issue and we should take one at a time 12:00:32 faceless: Sure. you can't add margins around the initial-letter... You can add some padding to the right 12:00:54 ... but it's not great with varying shapes 12:01:29 fantasai: so proposal would be to apply shape-margin only when wrapping around the glyph shape 12:01:41 sounds reasonable 12:02:05 astearns: so for the rest we apply shape-outside 12:02:37 fantasai: interaction between shape-outside and initial-letter is tbd 12:03:01 ... but you can wrap around the glyph 12:03:10 Karen has joined #css 12:03:43 astearns: makes sense to use shape-margin when shape-outside is none and `initial-letters-wrap: all` 12:04:14 sounds good to me 12:04:44 RESOLVED: Use shape-margin on initial letter when shape-outside is none and `inlitial-letters-wrap: all` 12:04:56 (we're skipping issue 2 in the issue, because it's covered in https://github.com/w3c/csswg-drafts/issues/719 ) 12:04:59 s/all/all and first/ 12:05:26 faceless: (describes issue 3 in #719) 12:06:39 faceless: I think the text about the alignment points is not relevant 12:07:07 stantonm has joined #css 12:07:08 ... once you drop the letter on the first-line it fits right 12:07:23 fantasai: you need that for shifting caps, that's what it's for 12:07:40 s/shifting/raised or sunk/ 12:07:56 I think this doesn't work both because it's hard to match the correct size, and because you need to control which lines wrap around the initial letter. 12:08:03 s/that/the second value of `initial-letters`/ 12:08:21 faceless: I can try to demonstrate you can achieve the same effects without that value 12:09:03 hober: I'd really love it if didn't file giant issues like this so that we can clear where the discussion is separately 12:09:04 +1 hober 12:09:13 ... this style of bug-filing is very hard to follow 12:09:29 RossenF2F: That being said all the detail is awesome 12:10:42 faceless: Let's move to issue 4... You can have atomic inlines as an initial letter, is that allowed? Otherwise it needs to be clarified how to align these 12:10:46 q+ 12:10:57 ... we discussed about having baselines on svg which would solve this problem, probably 12:11:12 fantasai: we have an attempt to synthesize baselines for boxes 12:11:23 ... so cap-height corresponds to top-height of the box 12:11:30 q? 12:11:33 ack chris 12:11:38 chris: this has come up before for images 12:11:49 https://drafts.csswg.org/css-inline-3/#initial-letter-box-size 12:11:51 myles: #4116 is the baselines in images 12:11:55 For atomic initial letters, sizing follows the usual rules for that type of atomic inline. However, if the box has an automatic block size (auto), then its block size is determined as for an inline initial letter with border-box alignment, and is definite. 12:11:57 ... issue I filed a bug 12:12:10 s/a bug/ a while ago 12:12:13 https://github.com/w3c/csswg-drafts/issues/4116 12:12:26 iank_: this is not only for images right? Only atomic inlines 12:12:33 other atomic inlines too* 12:12:49 fantasai: I think the spec says how to size the box 12:13:02 ... so if you set an explicit size on an atomic inline you get that size 12:13:21 ... if the size doesn't match the amount of space you use the alignment properties to align it in that space 12:13:40 faceless: I suspect that'd probably do it for now but probably should be explicit about how baselines work 12:13:42 fantasai: agreed 12:13:47 faceless: issue 5 12:13:57 ... the spec allows for inlines as initial-letter 12:14:32 ... the initial letter uses font-size not the computed size 12:14:37 shane has joined #css 12:14:47 ... so if you use superscripts or what not it produces really odd result 12:14:50 *results 12:15:49 scribenick: fantasai 12:16:02 on issue 6 12:16:31 faceless: If you have inlines as part of inial leter, e.g. a superscript in 1st, it doesn't scale up with the rest of the initial letter 12:16:49 emilio: what you're proposing is some weird inheritance behavior in first-lin 12:17:05 emilio: if you have span in first-line, it inherits from ::first-line 12:17:58 fantasai: There's regular element initial letters, and ::first-letter first-letters 12:18:08 fantasai: If can't have element in ::first-letter, then it's not a prolem there 12:18:36 fantasai: but for regular elements, shouldn't be a problem to inherit like usual 12:18:51 faceless: Should set the computed font size based on initial-letter, so that it will inherit as usual and affect the children 12:19:01 emilio: Not great, because a lot of stuff depends on font-size right now 12:19:09 emilio: would need t compute based on initial-letter 12:19:19 dbaron: Might be able to specify the desired results wihtout changing computed value of font-size 12:19:29 dbaron: might be more difficult to specify, but more realistic to implement 12:19:37 emilio: Can you set the initial-letter size in em units 12:19:51 faceless: no, it's derived from the algorithm 12:20:18 florian: The algorithm gives you the siz eof the glyph, if we say therefore this must affect the font size, do browsers agree on which font size you get from that 12:20:28 fantasai: you have requirements for that calculation, to use specific metrics 12:20:46 ... like, my line-height is X or Y, and the alphabetic-baseline 12:20:50 ... that's all deterministic 12:21:19 ... assuming everyone pulls the same metrics 12:21:46 florian: is there a really a single font-size that gets you the right size? 12:22:01 fantasai: yes 12:22:07 fantasai: there's only one cap height metric 12:22:15 emilio: But the computed line height depends on the computed font size? 12:22:15 dbaron: modulo rounding issues 12:22:32 emilio: think it's more reasonable to not affect the computed value and then do something, but... 12:23:05 florian: Don't need the line-height/font-size of the initial letter, but of the paragraph 12:23:06 q? 12:23:21 emilio: but not easy to find that value at the time you're doing style computation 12:23:23 https://wiki.csswg.org/spec/property-dependencies 12:23:43 emilio: You cannot get to the containing block, you can get to the nearest display: contents thing... 12:23:52 non-display: contents thing 12:23:55 dbaron: It's not super clear to me whether what you're proposing would make the computed value of font size on layout 12:24:05 dbaron: but even if it's not, still refer you to this dependency chart 12:24:21 dbaron: if you're proposing to add something, make sure it doesn't create a cycle 12:24:29 dbaron: font-size is one of the most basic dependencies 12:24:36 faceless: It definitely doesn't depend on layout 12:25:06 florian: Computed font size of initial-letter would not affect the lineh height of the parent paragraph, so no circularity 12:25:20 florian: The computed line-height of the initial letter affects nothing, so the loop stops here 12:25:29 emilio: affects nothing if you don't add lh units or other things that are proposed 12:25:45 florian: If you're trying to set the border of your initial-letter to 0.1lh, you can use it, but won't have ripple effects that mess up everything 12:25:56 emilio: I still think getting to the right parent paragraph's line-height is not trivial 12:26:17 florian: The alternative would be to say that within the initial-letter, a specific set of things do math against the used font-size instead? 12:26:23 emilio: You would need some kind of multiplier, which seems OK 12:26:51 emilio: You need to multiply by the ratio of the font-size of the initial letter to the computed font-size 12:27:05 florian: I'm not concerned about having the ratio, I'm concerned about the whitelist of what it applies to 12:27:24 florian: Not understanding the difficulty of inheriting through... 12:27:31 fantasai: DIscuss at break? 12:27:45 issue 7 12:28:13 faceless: inline boxes don't take width/height anywhere else, doesn't seem like a good idea here 12:28:43 fantasai: the reason we did this is that you can't make an atomic inline into an initial letter it doesn't resize the font 12:28:58 ... the content of the inline-block that is an initial letter are not affected by that 12:29:12 ... what this does is you do the resizing of the glyph as usual 12:29:25 ... but then you also define the size of the box 12:29:32 ... this was requested by tantek 12:29:46 faceless: alright, scratch that then 12:29:56 astearns: it'd be nice to have a note/example in the spec 12:29:57 s/tantek/tantek, to handle the case of colored boxes with initial letters in them, wnat the boxes to all be the same size/ 12:30:20 faceless: number 8 12:30:59 faceless: I'm ok dropping this 12:31:22 dbaron: can I suggest that the issues that are viable after this discussion should become separate issues? 12:32:10 ACTION: fantasai to go through the issues after doing the spec work and split the remaining issues 12:32:19 (or mentor faceless into doing so) 12:32:59 Topic: [css-text] Atomic inlines being equivalent to ID for line breaking is not web-compatible 12:33:05 github: https://github.com/w3c/csswg-drafts/issues/4576 12:33:15 github:https://github.com/w3c/csswg-drafts/issues/4576 12:34:05 florian: it's specified in CSS text that atomic inlines are equivalent to ideograph 12:34:34 ... but apparently authors expect that there would be a break where breaks would usually be forbidden between a break and an ideograph 12:34:52 ... (See https://bugs.chromium.org/p/chromium/issues/detail?id=1025715) 12:35:12 fantasai: I'm sad about this 12:35:28 ... there's a number of cases where images should behave more like characters 12:36:05 ... and if we always break stuff like gagii 12:36:11 s/gagii/gaiji/ 12:36:14 ... will typeset badly 12:36:39 hober: if it's possible for authors to write content to do the right thing and we have consistent behavior 12:37:02 ... then we should put that on the spec and indicate how to tweak it 12:37:25 fantasai: the current spec behavior doesn't match implementations but it's easy to tweak 12:37:35 ... into solving all the different use cases 12:38:08 florian: if we treat images like ID then you can use standard properties to allow it to break 12:38:10 q? 12:38:44 ... otherwise we can't 12:38:58 myles: well I agree we should solve it but we can't solve this this way because it's not web-compatible 12:39:03 q? 12:39:15 fantasai: we could reuse the line-break property 12:39:48 ... and make the strict value make atomic inlines 12:40:27 faceless: so this seems like the breakness depends on the image 12:40:40 q+ 12:40:41 ... can we set a property on an image? 12:40:56 florian: line-break on the image would tweak this 12:41:39 q+ 12:41:40 q+ 12:42:01 fantasai: The `line-break` property is exactly about the interactions between breaks and punctuation so I think it makes sense to reuse the strict value here. 12:42:39 there are wrap-* properties in css-text-4 that allow control over breaking, to forbid or allow unconditionally, but they're not context-dependent on surrounding punctuation, so they're not appropriate for this situation 12:42:55 ack hober 12:43:17 hober: I like the shape of fantasai's compromise here... I think there are a couple open questions but I think that's the right direction 12:43:31 ... I'm still kinda leaning for it to be a different property, but mostly for aesthetic reasons 12:43:36 q+ 12:43:48 ... I'm concerned with the compat effect of reusing strict 12:44:03 ... I'd be willing to agree that we should do something like this 12:44:24 ... but whether it's the strict keyword or a new keyword should probably have some kind of research 12:44:39 fantasai: I think not a lot of pages use line-break strict 12:44:59 ack koji 12:45:00 ... and they're likely CJK which are more likely to use this behavior 12:45:10 koji: I'd like to combine line-break normal with this behavior 12:45:39 fantasai: you can have your paragraph with line-break: normal, but the images with line-break: strict 12:45:58 koji: what about inline-block? Those are a block inside 12:46:13 fantasai: I suspect those are much less likely to want this behavior 12:46:14 q+ 12:46:33 ack florian 12:46:57 florian: I think we could make the loosey image breaking behavior if we use `line-break` != `auto` 12:47:09 ... that way it'd just work... non-default line-break is weird 12:47:59 ack fremy 12:48:03 ... widening the scope of the issue a bit, is that there's another issue with breaking around images, which is that ` ` around it behave like normal spaces 12:48:35 fremy: when I try to solve this myself is just putting a span on the break elements, but doesn't seem to be interoperable 12:48:49 RossenF2F: also there's a lot CJK elements 12:48:55 q? 12:49:02 ack myles 12:49:03 myles: I like that you can select the gaiji with a selector 12:49:19 ... koji makes a really good point 12:49:40 ... when I think about line-break values I think about text and paragraphs 12:49:45 ... not images and inline-blocks 12:50:07 fantasai: I think we can go with florian's proposal 12:50:27 I'm less enthusiastic about having a text property modify the behavior of images as a side-effect 12:50:29 myles: some people may want the break on the left of the image 12:50:36 astearns++ 12:50:52 zcorpan has joined #css 12:50:54 fantasai: we have controls for that in level 4 12:51:05 myles: can this use them instead? 12:51:14 fantasai: no you can't, because those are not contextual 12:51:54 ... but opting in to treat this as an ideographic character is good 12:52:05 ... the level 4 properties are unconditional 12:52:25 ... emojis, small kana and such things these images should be treated like this 12:52:34 ... which is why it fits with line-break 12:52:45 myles: I'd like some more time to think about this 12:53:06 ... maybe a way to tell an image which kind of text it wants to be 12:53:35 ... I also think it's important to get the default behavior in the spec agreement with implementations 12:53:56 RESOLVED: Atomic inlines by default always introduce a break opportunity, regardless of context 12:54:25 ACTION: Investigate using the line-break property to tweak this behavior 12:54:57 Topic: [css-text] Writing System prose is currently unimplementable on ICU 12:55:10 github: https://github.com/w3c/csswg-drafts/issues/4445 12:55:41 florian: so css-text that says that line-breaking can be changed language behavior 12:55:53 line-breaking behavior can be changed by language* 12:55:59 ... most impls use ICU 12:56:15 ... but the spec says it should depend on the writing-system, not just language 12:56:22 ... and nobody does it 12:56:38 ... my feeling it's we'll get there slowly, and it's just not implemented yet 12:56:49 dauwhe has joined #css 12:57:05 ... unless we have an objection against it I think we should keep it in the spec 12:57:22 hober: do you think ICU has a bug? 12:57:33 florian: whether it's a bug or a feature is fuzzy but sure 12:58:20 fantasai: I think we don't want to remove that restriction just because ICU doesn't implement it 12:58:23 q+ 12:58:39 q+ 12:58:43 hober: I think we should file an ICU bug and if they wontfix remove this from the spec because everybody uses ICU 12:58:46 florian: seems reasonable 12:58:56 stantonm: I thought ICU took the language tag as an input 12:59:02 fantasai: they do but they ignore the script part 12:59:12 q? 12:59:19 astearns: should we mark this at risk pointing to the bug? 12:59:31 Zakim, close queue 12:59:31 ok, RossenF2F, the speaker queue is closed 12:59:41 hober: given we're dependent on ICU here I agree 13:00:09 q? 13:00:18 koji: is there any use case for this? 13:00:35 ... I see the spec point of view but don't see any 13:00:36 ack koji 13:01:09 fantasai: there are different languages that can be written in multiple writing systems like japanese or chinese text books 13:01:29 plh has joined #css 13:01:34 ... they use latin letters, but you don't want to format them as english 13:01:56 koji: but justification / font-selection / etc don't change by writing system 13:02:00 ... it probably should change 13:02:28 florian: justification does change in the arabic / cyrillic languages sometimes 13:02:32 s/I thought ICU took the language tag as an input/I thought ICU took the BCP-47 language tag as an input, which includes script/ 13:03:06 ... if you have a book that's written in japanese-latin you shouldn't use a japanese font 13:03:16 koji: that seems fine to me 13:03:39 q? 13:03:40 chris: a better example, turkish used to be written in the arabic alphabet 13:04:08 jfkthame: I'm totally in agreement about filing a bug against ICU 13:04:13 some other examples might be Mongolian, Tajik, or Uzbek 13:04:28 i/jfkthame/chris: wouldn't you want to use an Arabic font for old turkish? 13:04:34 ... but I disagree with the idea of ripping it of the spec if the bug is wontfix 13:04:53 (Tajik and Uzbek, according to Wikipedia, have had 3 scripts at different times: Arabic, Latin, and Cyrillic.) 13:04:57 ... I think this is correct behavior and browsers could implement it with additional processing on top of ICU 13:05:22 hober: goal of the spec is interoperability, if it's wontfix it'd be science fiction 13:05:42 ACTION: florian file a bug with ICU on this 13:06:12 s/if it's/if the ICU bug is/ 13:06:38 jfkthame: Firefox is not using ICU 13:06:47 ... and we'd like to fix this 13:07:17 faceless: We implement this correctly 13:07:28 RESOLVED: Mark this section at risk 13:07:39 s/risk/risk, and close the issue/ 13:07:44 topic: lunch 13:08:01 hober: I think that when we mark things at risk, we should note why in the spec, but i can live with it just being marked at risk 13:11:23 dauwhe has joined #css 13:24:49 I have updated the schedule for the afternoon. We will break at 4:45 and start the 5pm topics after. 13:27:21 philipwalton has joined #css 13:34:09 astearns: which of the sub-issues 1-8 of https://github.com/w3c/csswg-drafts/issues/4171 were accepted as still "viable" and there are plans to create sub-issues? 13:34:21 do I need to provide an example for #7 13:35:58 tantek: faceless and fantasai will be breaking this up into separate issues. You could post an example for #7 in the big issue as input for that, or wait to post in the new issue 13:36:41 I am not clear which sub-issues will and will not turn into new issues yet 13:39:01 huh, I thought which sub-issues was a part of the resolution, and just didn't see which ones actually made it 14:00:58 jensimmons has joined #css 14:01:22 jfkthame has joined #css 14:01:58 nainar has joined #css 14:03:38 lajava has joined #css 14:05:44 tantek, example would be appreciated! 14:06:15 tantek, for that one I think I'll probably just resolve it against the existing open issue, just thinking to split out the things that didn't get resolved 14:08:56 Karen has joined #css 14:09:20 stantonm has joined #css 14:10:06 fremy has joined #css 14:10:11 ScribeNick: fremy 14:10:23 Topic: Color-Adjust 14:10:24 github: https://github.com/w3c/csswg-drafts/issues/4608 14:11:09 fantasai, my use-case is one I tried to make work but couldn't. I was trying to make the initial letters in a blog post of A-Z that resembled classic wooden building blocks and couldn't :( 14:11:18 RossenF2F has joined #css 14:11:19 TabAtkins: the spec says that color-scheme on the root element affects the initial value of the color property 14:11:29 TabAtkins: in addition to a couple of other things 14:11:50 TabAtkins: the argument is that we should instead change the color of the root in the UA, but not the initial color value 14:12:11 TabAtkins: I am not sure why this was proposed, but I see more value in our current spec 14:12:23 TabAtkins: because I don't see a value to get black as color when you're in the dark theme 14:13:09 TabAtkins: if we changed the initial value, a weird thing I do currently in Bikeshed would work better though 14:13:26 ack jfkthame 14:13:42 TabAtkins: a detail of this, is that the actual used color in chrome and safari is that it's actually a color that switches its value at computed value time 14:14:00 TabAtkins: in safari it's system-color and in blink a custom ua value 14:14:11 TabAtkins: and I think that this is a useful behavior 14:14:22 TabAtkins: so I tried to find an alternative behavior 14:14:48 q+ 14:14:49 TabAtkins: we say the initial value of color is "text", and "initial" would work as usual 14:14:54 q? 14:15:20 TabAtkins: I think it's ok because all uses of "color" is in property that require to return the used value at getComputedStyle so I'm unsure this would be observable 14:15:23 except for scrollbar-color, which has keywords that are returned 14:15:26 TabAtkins: but it would be visible in TypedOM 14:15:57 TabAtkins: can we get an agreement to match what Safari does in this case? 14:16:00 ack fantasai 14:16:00 fantasai, you wanted to ask about SVG 14:16:12 fantasai: A question I have is that this could cause issues in SVG, right? 14:16:19 TabAtkins: by default, it is, yeah 14:16:31 TabAtkins: but I'm not sure what the expectation what would be 14:16:41 heycam: it's more common to use black as the default value 14:16:53 TabAtkins: and it's mostly relevant for text, for which you usually you would want to switch 14:16:57 q+ 14:17:06 emilio: you use currentColor in SVG to get that effect 14:17:11 emilio: not the default 14:17:27 TabAtkins: the initial value is black, and also fill is black 14:17:41 TabAtkins: so that change wouldn't affect anything by default in SVG 14:17:46 ack heycam 14:17:57 Rossen: if it did break SVG, we would notice and backtrack 14:18:13 heycam: if you don't reset the property value, and inherit 14:18:32 heycam: does the value switch for the children that inherited that complex value? 14:18:45 fantasai: keywords inherit as a keyword, it's gonna be ok 14:18:51 heycam: really? 14:19:09 fantasai: yes, the keyword is inherited and behave per the element 14:19:18 ack hober 14:19:26 fantasai: but getComputedStyle returns a resolved value which is a color 14:19:48 hober: if the change is compatible with what we already do, and we allow the ua stylesheet to use that paradigm for the color 14:19:56 Rossen: so if you animate between `CanvasText` and `Canvas`, for example... How is that supposed to work? Does it become a discrete animation? 14:19:58 TabAtkins: I haven't verified that myself 14:20:11 q+ 14:20:12 s/Rossen:/Rossen, 14:20:18 (safari team is checking) 14:20:32 emilio: I would like to question the interpolation between keyword values 14:20:53 Rossen: you interpolate between the values 14:21:05 emilio: but we can't write that value anywhere 14:21:15 TabAtkins: I guess right now we cheat 14:21:38 TabAtkins: we resolve the keyword, then interpolate, even though we inherit the keyword 14:21:49 TabAtkins: just like currentColor since we switched the value 14:22:26 emilio: we use some hack to make it work 14:22:37 emilio: which relies on a bit to know how to do that 14:22:46 emilio: but we don't want to add a bit for each system color 14:22:57 TabAtkins: we are going to add interpolate() eventually to fix this 14:23:14 s/a bit/a hack/ 14:23:24 s/a bit/a hack/ 14:23:37 hober: the UA stylesheet when the color scheme is built-in sets the color property to the value Text on the root element 14:23:55 ack heycam 14:23:56 TabAtkins: so what I am proposing is virtually the same as what I am proposing 14:23:57 hober: right 14:24:04 from hober: WebKit's UA stylesheet sets html { color: text; } if the color scheme feature flag is on 14:24:09 https://www.w3.org/TR/css-color-4/#css-system-colors 14:24:16 System colors that are not deprecated ^ 14:24:16 heycam: in color-4 we say what to do with the undeprecated values 14:24:22 s/as what I am proposing/as what you're currently doing/ 14:24:27 Rossen: before I formally say yes, let me check 14:24:34 fantasai: it's definitely there 14:24:38 Rossen: ok then 14:24:44 heycam: also for background colors? 14:24:47 fantasai: yes 14:25:00 Rossen: so we want to resolve on this proposal? 14:25:03 astearns: no objection? 14:25:23 RESOLVED: use "canvastext" as the initial value of color 14:25:53 Topic: mod() mode 14:25:54 github: https://github.com/w3c/csswg-drafts/issues/2513 14:26:03 https://en.wikipedia.org/wiki/Modulo_operation#In_programming_languages 14:26:13 TabAtkins: I was thinking about this, and looking at the wikipedia article... 14:26:19 TabAtkins: there is a lot of divergence 14:26:26 TabAtkins: but there is one constant 14:26:43 TabAtkins: if a language has a pair, mod works like Math and % works like JS 14:26:57 s/%/rem/ 14:26:59 TabAtkins: in particular, <<<<>>>> language does this, because they came to the same conclusion 14:27:16 q+ 14:27:17 TabAtkins: so my proposal, is to add the two functions 14:27:20 s/<<<>>>>/Web Assembly/ 14:27:41 leaverou: why are we adding functions and not an operator 14:27:44 TabAtkins: more complex 14:27:57 s/why are we adding functions and not an operator/why are these functions and not operators?/ 14:28:13 TabAtkins: and also it's not an operator in all languages anyway 14:29:02 I support Tab's proposal fwiw 14:29:09 myles: why dont' we want mod to be like js? 14:29:11 +1 14:29:13 Karen has joined #css 14:29:25 s/+1/+1 to tab's proposal/ 14:29:31 TabAtkins: javascript doesn't have a function, just an operator that works like rem 14:30:02 myles: but then we make CSS more powerful than JS, while JS was intended to be math-complete while CSS is not 14:30:31 hober: I think the point of this exercise was to reduce differences in differences between the platform languages 14:30:42 hober: I'm confused why we want to introduce inconsistencies 14:30:44 q? 14:31:05 hober: It might be reasonable to ask somebody from TC39 to consider adding the other function, and mimick their response 14:31:29 TabAtkins: I don't believe it's correct to say that we want to minimize the difference between the two languages 14:31:49 TabAtkins: our goal is to give designers the functions they need to get the layouts they want 14:32:07 TabAtkins: which is why we didn't add the hyperbolic functions because there are no known use case 14:32:21 TabAtkins: and to reply to the "more powerful question", we already do that 14:32:45 TabAtkins: for instance, we have a more complex round function, and that is useful because rouding is important to us 14:32:57 TabAtkins: so I don't want to say we should not innovate beyond JS 14:33:08 TabAtkins: but we should only do it if there's an use case 14:33:12 ack heycam 14:33:29 Zakim, close queue 14:33:29 ok, astearns, the speaker queue is closed 14:33:35 heycam: If we really wanted to match JS, we would do an operator, not a mod function in the first place 14:33:47 heycam: but I was on the queue to say something else 14:33:58 heycam: it's confusing to have an unit called rem, and a function called rem 14:34:02 heycam: I would like to avoid it 14:34:12 myles: an author might think it gives you the size of a rem 14:34:25 TabAtkins: it would not work, and authors would realize that 14:34:26 ack fantasai 14:34:26 fantasai, you wanted to point out that JS doesn't have a mod function, it has a % operator, so either way we have to pick a name, picking rem() as that name is perfectly fine 14:34:39 fantasai: also, I want to point out that log doesn't do console.log 14:34:57 innovati has joined #css 14:35:04 fantasai: also, I agree, % is not a function in JS, not a function 14:35:16 q? 14:35:20 fantasai: so, if we add a mod() function we don't have to match JS, we can do something useful 14:35:33 myles: log is a very different example, because we just cannot console.log in JS 14:35:38 myles: but here we are doing the same thing 14:35:56 TabAtkins: we have functions that can absorb css timing resolutions from houdini 14:36:15 TabAtkins: the paint api when it gets called gives you timing information 14:36:30 astearns: I don't think this is gonna get narrowed down today 14:36:48 TabAtkins: but, we want to check if we can ship this 14:37:06 TabAtkins: so can we strawpoll or record objections? 14:37:45 14:38:14 RossenF2F: the new option is that we have both mod and rem 14:38:31 florian: I think we should just have a decision yes or no on the adoption of this approval 14:38:37 astearns: yeah, let's do this 14:38:56 hober: I am worried about the form of this strawpol 14:39:19 hober: because we are not agreeing on an alternative 14:39:29 astearns: yes, but if we say no, we don't do anything and defer for another day 14:39:33 1. Resolve to add mod() (math behavior) and rem() (JS behavior) 14:39:49 2. Continue thinking about the desired mod-ish behavior in the issue, resolve sometime later. 14:39:54 1 14:39:56 1 14:39:56 1 14:39:56 1 14:39:58 1 14:39:58 2 14:40:00 1 14:40:04 1 14:40:05 1 14:40:06 1 because YOLO 14:40:11 1 14:40:12 1 14:40:13 abstain 14:40:13 1 14:40:19 1 14:40:40 15/22 said 1 14:41:00 mod(15/22) 14:41:13 jfkthame has joined #css 14:41:22 astearns: proposed resolution is thus to add both mod() and rem() 14:41:29 astearns: does anybody object? 14:41:42 It's 13 for option 1, 1 for option 2 14:41:59 RESOLVED: the mod() and rem() functions are to be added to CSS, one with math behavor, the other with JS behavior 14:42:12 ScribeNick: TabAtkins 14:42:13 Chris can't vote due to lack of connectivity, but he votes 1 14:42:29 chris_ has joined #css 14:42:51 Topic: all-neutral lines 14:42:56 github: https://github.com/w3c/csswg-drafts/issues/4405 14:43:35 fantasai: Issue raised by Aharon 14:43:53 fantasai: When you have a plaintext block, like a 
 with unicode-bidi:plaintext
14:44:15  fantasai: It resolves the para base direction of each "paragraph" (things separated by forced line breaks) according ot the first strong character in the paragraph.
14:44:27  fantasai: This is a heuristic, not always accurate, but it's what the plaintext bidi algo does.
14:44:33  fantasai: Interesting to Aharon is alignment
14:44:54  fantasai: We take advantage of a para-based direction, that's not 'direction' proper, but we use that direction per-line to decide what "start" text-alignment means.
14:45:22  fantasai: Problem arises if you ahve a paragraph that's completely neutral chars, like punctuation.
14:45:25  fantasai: Or numbers.
14:45:46  fantasai: What he noticed is that you have a document that's entirely arabic, but it has a line of text with no letters in it, it ends up being aligned to the left (wrong side for arabic)
14:46:25  fantasai: We already make an exception for empty line boxes; we take the direction from preceding line. Suggestion is to apply that exception to all-neutral lines too.
14:46:38  florian: Currently it's udnefined?
14:46:46  fantasai: Currently the defualt is ltr if you can't find a direction.
14:47:01  jfkthame: I think the terminology is a little wrong; numbers are weak, not neutral.
14:47:14  fantasai: Sure. I don't recall the exact spec wording, it's probably more accurate.
14:47:15  lajava has joined #css
14:47:27  fantasai: So if you have arabic text and underlined it with a line of hyphens, for example
14:47:33  s/fantasai/faceless/
14:47:40  fantasai: Yeah, that's a case here
14:48:03  koji: So I guess options are previous paragraph, or 'direction' property. Any reason you chose preivous para?
14:48:15  fantasai: That was the suggestion from Aharon.
14:48:31  fantasai: We're specifically in a unicode-bidi:plaintext context, which imlpies the 'direction' doesn't know what it should be.
14:48:49  koji: But then 'direction' should specify the ui or document direction, so it's a more natural fallback to me.
14:49:27  florian: Not necessarily - if writing content like an email, the UI might be in English but the context is Arabic. Using 'unicode-bidi:plaintext' on the email textarea because you know the lang direction is unknown.
14:49:36  koji: Agree, this is heuristic, we could argue both cases.
14:49:45  koji: I just think author intention is more natural fallback.
14:49:49  myles: Not sure I agree with that.
14:50:18  myles: If there's a quote snippet, you might want to remove some middle paragraphs, replacing with [...] to indicate it's been snipped
14:50:28  myles: If you do that as currently described, it'll be on the other side of the screen and look wrong.
14:50:46  koji: If you have English quote in arabic text, and there's underline, you want it on arabic direction
14:51:34  koji: If you ahve hyphens *above*, it'll be arabic-aligned; if you ahve hyphens *below*, it'll be English-aligned.
14:51:47  koji: So it's a question of which is better heuristic.
14:51:55  fantasai: I think you're both making good points.
14:52:04  fantasai: It's not clear which is clearly better.
14:52:21  fantasai: I think what is clear is that we shouldn't use ltr as the generic default.
14:52:35  koji: Have you tested what browsers do today?
14:53:11  faceless: My understanding of "plaintext" is that you really can't rely on the direction property.
14:54:09  testcase - http://software.hixie.ch/utilities/js/live-dom-viewer/?%3C!DOCTYPE%20html%3E%0A%3Cpre%20dir%3Dauto%20style%3D%22direction%3A%20rtl%22%3E%0A%5E__%24%0A%D9%84%D8%B9%D8%B1%D8%A8%D9%8A%D8%A9%0A%5E__%24%0Aabcde%0A%5E__%24%0A%3C%2Fpre%3E%0A
14:55:04  TabAtkins: My intution says that most of the time you'll be looking at single-language text, so the neutral para should align with that, and the heuristic will work. When you ahve mixed text, Koji's argument that it's uncleaer and might be wrong is valid, but the "previous para" heuristic should be right about half the time. So that's not bad!
14:55:38  fantasai: Testcase shows that each paragraph is handled individually; if it's all neutral, it's treated as ltr even if "direction:rtl" (this is exacty what the spec currently specifies).
14:56:21  fantasai: Interesting case - neutral text like ASCII art in a "plaintext" context, and there's some rtl preceding it, you don't want it swapped direction.
14:56:31  myles: ASCII art is pretty niche. I don't think it should affect this decision.
14:57:13  fantasai: So I think if the *entire paragraph* is neutral, we shouldn't look at previous para; we should just use the "previous line".
14:57:22  koji: What do you do at the beginning of the block?
14:57:30  fantasai: Probably just default to what unicode says, which is ltr
14:57:59  myles: I'm sure we're not the first ot have this idea. Do we know why Unicode gives this advice?
14:58:05  fantasai: Unicode doesn't define alignment.
14:58:25  fantasai: They do require that the *base diretion* is ltr (affecting bidi reordering); we don't want to touch that. This is just about alignment.
15:00:21  koji: Unicode bidi l1 requires applying reordering to trailing spaces; without bidi l1 and l0 affects reordering.
15:00:47  q?
15:00:49  q+
15:00:49  fantasai: We can tweak the alignment; I don't think we should be making tweaks to the ordering of characters.
15:00:58  Zakim, open queue
15:00:58  ok, astearns, the speaker queue is open
15:01:05  q+
15:01:11  koji: I'd rather fix paragraph level rather than fix text-align
15:01:20  fantasai: So that would be to close this issue no-change?
15:01:36  fantasai: The issue is just about text-alignment; saying it's wrong for these cases.
15:01:46  fantasai: You're saying let's not do that. Taht's an okay proposal!
15:02:14  koji: No, just say that text-align uses base direction, and CSS can just say that if there's no strong characters we inherit from the previous line.
15:02:28  fantasai: bidi reordering relies on base direction, that'll change the ordering of characters.
15:02:56  fantasai: Like base direction determines where your period goes at the end of your sentence.
15:03:18  jfkthame: Not sure I'm totally comfortable with changing base direction for reordering purposes and for alignment.
15:03:24  fantasai: I'm just relaying fro mthe issue
15:03:31  fantasai: We can decide to reject the proposal.
15:03:37  ack florian
15:04:11  florian: Originally I was enthusiastic, and maybe given it's from Aharon my concerns are unfounded; in Unicode there of course is no alignment, it comes from *somewhere*. Currently in plaintext applications everything is effectively start-aligned.
15:04:28  florian: So aren't those apps already effectively doing the same for alignment and base direction?
15:04:48  stantonm has joined #css
15:04:58  koji: The feedback is from 2016, mind checking with Aharon again?
15:05:11  koji: He's been responsive to me more recently.
15:05:18  fantasai: Ok, I'll summarize and take it back to himl
15:05:30  fantasai: I'm opening some plaintext editors, and it looks like alignment is based on the whole file.
15:05:42  fantasai: Even having differing-direction entire paragraphs doesn't affect it.
15:06:11  Topic: hanging spaces
15:06:15  GITHUB: https://github.com/w3c/csswg-drafts/issues/4297
15:06:32  florian: We've discussed this before - should hanging spaces be scrollable or ink overflow?
15:06:54  florian: Conclusion last time was use-cases for both. Generally they're invisible and unnoticeable, invisible things triggering overflow is bad, so generally it should be ink overflow.
15:07:14  florian: But when text-editing, it's bad to move your caret into spaces and not see where you are, because there's no scrollbar and the caret is off the viewport.
15:07:30  florian: So I think when not-editing always ink, when editing always scrolalble.
15:07:35  Karen has joined #css
15:07:53  florian: Some people objected that when not editting, selection still has value for scrollable overflow so you can see the bounds of your selection.
15:08:15  florian: So one possibility is to make that simple distinction. Another is to make a switch for it.
15:08:34  florian: I think we had general consensus that the switch is useful, but some, maybe emilio, were uncomfortable with this.
15:08:40  emilio: I still think it's weird, but...
15:09:03  florian: I think my preference is an automatic behavior that switches based on edittability.
15:09:23  florian: If we later think there are more situations, we can always add a proeprty *then* that defaults to "auto". I suspect we won't need it, but we're not locked out.
15:09:51  fantasai: I think we should define it as ink overflow, but UA *may* treat it as scrollable when the content is editable or UA thinks user would otherwise like to see it.
15:09:57  fantasai: So on static pages it'll never make scrollbars.
15:10:06  fantasai: But there's an allowance to improve usability on interactive.
15:10:12  koji: Do you remember what we did for hanging punctuation?
15:10:20  florian: Don't remember, but I think this should apply to both.
15:10:37  stantonm: I think we defined hanging punctuation as ink overflow, but I could be wrong.
15:10:46  jfkthame: It says "scrollable" at the top of the issue...
15:10:55  "A hanging glyph is still enclosed inside its parent inline box, is still counted as part of the scrollable overflow region [CSS-OVERFLOW-3], and still participates in text justification"
15:11:26  florian: Turns out the spec currently says hanging-punct is always scrollable, and there's a Chrome bug showing this is bad (too much scrollbars).
15:11:48  astearns: We might want to say it's ink overflow all the time, and respond to editting as we get bugs.
15:12:14  florian: For hanging punct, you don't have more than one punct sitting there, it doesn't overflow much anyway. But spaces, you can have a bunch.
15:12:41  dauwhe has joined #css
15:12:42  heycam: When you're editting text, and ws is collapsed, you also don't get the cursor thru those.
15:12:52  heycam: So why is it important to cursor thru these?
15:13:14  florian: You can still see your caret in that case, it's not offscreen and invisible.
15:13:39  heycam: Why not just move the caret to the next line when it would overflow?
15:13:49  astearns: It breaks selection, you want to be able to select those.
15:13:58  heycam: You can select them, just not in the middle of them.
15:14:08  florian: So, scrollable-always breaks things.
15:14:12  florian: One option is "always ink"
15:14:23  florian: Second is "ink by defalt, UAs can determine when it shoudl be scrollable"
15:14:34  florian: Third is "ink when not editable, scrollable when editable"
15:14:39  fantasai: I like the second
15:14:45  florian: Hard to test, but maybe doesn't need to be tested.
15:14:58  florian: I can live with that.
15:15:41  astearns: So proposal is "hanging spaces are ink overflow by default, UAs can choose to make them scrollable overflow when it's useful"
15:15:54  [discussion about hanging punct]
15:16:12  stantonm: Are there implications about underlines?
15:16:44  stantonm: In our world (Kindle) we want puncts to hang outside the box, overlap is fine
15:16:49  fantasai: They'll still do that, yes.
15:16:59  astearns: Objections?
15:17:20  RESOLVED: Hanging spaces are ink overflow by default. UAs may make them scrollable overflow when they think that would be useful.
15:17:42  Topic: Removing collapsible linebreaks"
15:17:44  github: https://github.com/w3c/csswg-drafts/issues/3481
15:17:49  fantasai: Proposal is to defer to level 4
15:17:58  astearns: Anyone concerned about punting?
15:18:35  astearns: reading thru the issue, lots of words I don't know...
15:18:41  astearns: We discussed previously and didn't get a conclusion
15:18:47  fantasai: Looks like it'll need more research and digging.
15:18:56  fantasai: I think we should get the spec done and defer this.
15:19:19  RESOLVED: Punt "removing collapsible linebreaks adjacent to work separators" to level 4
15:19:40  Topic: segment-break rules
15:19:50  github: https://github.com/w3c/csswg-drafts/issues/337
15:20:00  fantasai: Close it somehow...?
15:20:17  myles: I think this is worth some discussion.
15:20:38  astearns: Did you find anyone at Apple to talk to?
15:20:39  Section under discussion https://drafts.csswg.org/css-text-3/#line-break-transform
15:21:00  myles: I started a discussion; same story happened, we tried to describe it to Ken and then he had no opinions, same thing happened with me.
15:21:12  myles: So in light of that I'm willing to somewhat amend my previous position
15:21:33  myles: The spec lists a collection of segment-break rules, writing-system rules, general category rules, and the word "hangul"...
15:21:41  myles: I'd like the criteria of this to be listed somewhere that isn't CSS.
15:21:49  myles: I'd ultimately like this to go into Unicode somehow.
15:22:03  myles: Ultimately I don't think browsers should be in the business of making these sorts of character decisions.
15:22:08  myles: If we can do that, I'm willing to accept it.
15:22:14  florian: I don't have a problem with that in theory.
15:22:34  florian: To the extent I've tried to discuss this with unicode, I didn't sense any interest on their side that this is a problem worth solving.
15:22:44  florian: Or maybe not even a willingness to understand the problem.
15:23:04  florian: If we were doing codepoint-by-codepoint I'd be concerned, but this is category based.
15:23:14  myles: I'm an implementor here; we have different ideas about "complicated".
15:23:31  myles: Also their lack of interest is a signal. We're not the only language that uses text.
15:23:39  fantasai: We're one of the only that takes broken lines and unbreaks them.
15:24:01  myles: Unicode has taken on work to describe all the linebreaking in CSS. So if they don't care abuot this, that's a signal!
15:24:07  fantasai: They have no spec for line unbreaking.
15:24:53  koji: We've tried to combine multiple proeprties, the WG rejected the idea, unicode started the spec for CSS. So I think I agree with Myles; we either convince Unicode, or stick with what we had before and not combine multiple proeprties.
15:25:17  astearns: What's the current state of the spec?
15:25:29  fantasai: There's a bunch of rules in the spec based around East-Asign Width property and General category.
15:25:47  fantasai: Started with EAW, made an exception for Hangul because it's wide, and I think that's what's implemented in Gecko right now.
15:25:58  fantasai: This issue was opened on "I want you to handle ambiguous characters better"
15:26:22  fantasai: So in response we added "if the ambiguous character is in a context we know is wide, like Chinese, treat it as wide; otherwise as narrow".
15:26:39  fantasai: Then Unicode redefined some characters that were previously narrow/ambiguous into wide, because of emoji.
15:26:51  fantasai: Then we reopened the issue to treat emojis as ambiguous.
15:27:11  florian: When we complained to Unicode about that change, they said this property is for terminal rendering, nobody should use it.
15:27:28  koji: I agree the emoji issue is bad.
15:27:59  koji: So my preference is from before, take behavior based on encoded block. That might be slightly less accurate than your current proposal, but as long as it's consistent across browsers authors will be happy enough.
15:28:29  fantasai: So instead of using EAW/General properties (or others), we should evaluate unicode blocks and declare how to treat each?
15:29:07  [discussion of how unicode blocks work]
15:29:50  fantasai: That would probably work.
15:29:54  astearns: That sounds great.
15:30:22  myles: So somebody in this group, not me, should come up with a list of blocks. If it's very large, we can revisit, but if it's small, then ok.
15:30:37  myles: My criteria here is maintainability.
15:30:41  fantasai: I can take that action.
15:30:46  myles: Ok, we can discuss it then.
15:31:15  jfkthame: For maintainability, you'd have to recheck each version, approximately yearly.
15:31:44  fantasai: Sure. General criteria is like "if it's more than 80% han characters, it's on the list", easy.
15:32:11  koji: As the editor of UAX 50, I'm doing that every year. We will assume VerticalOrientation to U for CJK characters, you can check that.
15:32:17  $ grep ';' Blocks.txt | grep -v "^#" | wc -l
15:32:18  291
15:32:41  fantasai: The set of chars we want here are pretty much exactly Chinese and Japanese characters.
15:32:47  jfkthame: Base it on Script, then?
15:32:58  fantasai: We do that today, but we have to remove punctuation, etc, thus the current complexity.
15:33:03  s/remove/add/
15:33:09  astearns: So proposal is fantasai looks at the blocks, and comes back later.
15:33:28  myles: Parting word, text started elegant, got full of exceptions over time. If that happens again, we should just cut it off.
15:33:45  smfr has joined #css
15:34:49  Topic: vertical align:middle in vertical text
15:34:50  github: https://github.com/w3c/csswg-drafts/issues/4495
15:35:32  fantasai: Afaict from dbaron's description, issue is that v-a:middle has you find the point between the alphabetic baseline and the x-height, and call that "the middle", then use that for alignment
15:36:03  fantasai: Apparently there's some impls that, in vertical modes, instead of doing that in a sideways fashion, take the central baseline.
15:36:29  dbaron: I think Gecko does vertical-align:middle based on, not a font-derived central baseline, but a synthesized central baseline.
15:36:52  fantasai: So I think we should clarify the spec to say you're using the alphabetic baseline even in vertical text.
15:37:06  fantasai: *Not* the central or hanging or whatever the dominatn baseline is.
15:37:11  fantasai: So you'll always find the same point.
15:38:22  fantasai: But when text-orientation is upright, the x-height doesn't have a meaning in the transverse axis, so maybe use central then.
15:38:29  jfkthame: What about when text orientation is mixed?
15:38:44  fantasai: Then you're rotating the text, you can still get a meaningful x-height and align there.
15:39:00  jfkthame: I disagree, this is mostly useful for CJK text and we should be centering.
15:39:06  AmeliaBR has joined #css
15:39:11  fantasai: Then just use the central baseline explicitly.
15:39:28  fantasai: If that's what you want to change to, tho, we can do that.
15:39:59  fantasai: So we have severa ldistinctions we make in vertical text.s
15:40:18  fantasai: First is whether you're in horizontal or vertical typesetting.
15:40:30  s/typesetting/typographic mode/
15:40:40  fantasai: Horizontal mode is trigger by w-m: sideways-rl
15:40:52  fantasai: In that case we should ensure the conventions are a rotation from horizontal text
15:41:06  fantasai: Within the vertical typographic modes (vertical-rl/lr modes), we have three text-orientation values.
15:41:10  fantasai: uprgiht, sideways, mixed
15:41:49  fantasai: If we want this "Middle" alignment to be avaible for a paragraph in vertical typographic mode, we need to define it the same was as in horiz mode, at the very least when t-o is sideways
15:42:03  fantasai: But when t-o is upright, that definition is nonsensical. It'll have to be the central baselie.
15:42:14  fantasai: For mixed, it's a question of do we want to match upright or sideways.
15:42:16  bkardell_ has joined #css
15:43:00  fantasai: Since "middle" is this weird thing tailored to latin text, I say we should match it to how latin text works, which is the alphabetic/x-height thing.
15:43:26  fantasai: If someone wants to use actually centrally-baselined stuff, they should say v-a:central;
15:43:32  fantasai: Open to other opinions tho
15:43:55  heycam: Kinda feel like I agree with jfkthame, where mixed is for primarily vertical with little bits of rotated horizontal text. So I think you want to align based on majority text.
15:44:05  fantasai: This isn't a default keyword, you ahve to specifically request middle
15:44:16  heycam: I see what you're saying, there's no other way to get that before.
15:44:42  fantasai: So yeah, you'll get the correct (central-aligned) behavior by default. You have to explicitly say "middle" to get this behavior; I agree it's usually weird.
15:44:59  dbaron: What I'm concerned about is that we don't add half the x-height to anything but the alphabetic baseline.
15:45:13  dbaron: I think fantasai makes sense; this is something you'd use for a small image you want to line up with the text.
15:45:33  dbaron: Since there's already a "central" value, and if there *is* an alphabetic baseline around to use, I think we should do fantasai's proposal.
15:45:40  dbaron: The name is unfortnate, but we're stuck with it.
15:45:48  jfkthame: 'central' keyword is new, right?
15:45:54  fantasai: Yeah, we added it for CJK specifically here.
15:46:10  dbaron: We don't implement it yet, I didn't realize it was there. But its existence influences my opinion here.
15:46:28  jfkthame: So we're going to have to tell people to stop using middle for their cJK?
15:46:39  dbaron: It doesn't really work there anyway, it's only good for bicameral scripts.
15:47:24  astearns: So proposed resolution is to make the middle spot always be what middle uses, as long as the alphabetic baseline and x-height are in the relevant axis.
15:47:30  middle should have been called x-middle
15:48:17  RESOLVED: "vertical-align: middle" always uses halfway between alphabetic baseline and x-height, except in modes where the x-height is meaningless (vertical writing modes with upright text orientation)
15:48:38  The followup question is whether the alphabetic | ideographic | central values are stable enough to implement.
15:48:41  RESOLVED: In such "meaningless" cases, "middle" means the same as "central".
15:53:34  Karen has joined #css
16:00:05  topic: break
16:06:26  stantonm has joined #css
16:12:21  RRSAgent, pointer?
16:12:21  See https://www.w3.org/2020/01/24-css-irc#T16-12-21
16:17:33  tantek has joined #css
16:21:42  I've never gotten vertical-align to actually work in any use-case in any meaningful way related to the apparent semantics of any of its named values
16:21:51  it's one of the most broken properties in CSS
16:21:56  good luck on fixing it
16:25:42  jfkthame has joined #css
16:28:54  Topic: ink or scrollable overflow for leading-trim
16:29:04  github: https://github.com/w3c/csswg-drafts/issues/4010
16:29:24  fremy has joined #css
16:29:50  koji: leading-trim trims upper or lower half of linebox
16:29:59  koji: Is the area it overflows considered ink or scrollable?
16:30:06  koji: No strong opinion from me
16:30:16  myles: Would it be overflow at all? Woudln't it just make the box shorter?
16:30:32  florian: It makes the box smaller. But the content of the box might stick out of that.
16:30:43  florian: So is that poking ink or scrollable?
16:30:55  myles: So that's not the stuff that's got trimmed.
16:31:20  florian: Right. The box got smaller, so theoretically it might slightly overflow.
16:31:51  astearns: No wrap differences, it's just the stuff sticking out.
16:32:00  TabAtkins: If you write in Zapfino, that's just ink overflow, right?
16:32:11  myles: Yes, it is. We're in agreement.
16:32:29  myles: fantasai says "overflow is whatever it would have been", that's unchanged. I agree with that.
16:32:45  florian: Ah yes, I misread.
16:32:54  astearns: So no change, do we need a clarification?
16:33:15  koji: We might want to clarify that it's ink overflow, then.
16:33:35  florian: Rather, things that today would be ink when they stick out, stay ink. Things that would be scrollable, stay scrollable. leading-trim doesn't hcange that.
16:33:40  astearns: Objections?
16:33:57  RESOLVED: leading-trim doesn't change the overflow state of anything sticking out of the linebox.
16:34:14  Topic: leading-trim and descendant inlines
16:34:15  github: https://github.com/w3c/csswg-drafts/issues/3956
16:34:34  myles: The definition right now says "when you got your root box, look at the primary font's metrics, subtract some stuff from the top or bottom"
16:34:56  myles: But if there are children in the box, that might be the wrong value. There might be a span with a larger font size, that's now sticking out.
16:35:04  myles: One way to solve it is look at all the descendants and find a good value.
16:35:14  myles: I think my feelings about this are obvious.
16:35:37  [the feelings were not obvious; he doesn't like that idea]
16:35:58  florian: So one is do the simple, based on root; another is to look at all descendants and use the tallest one.
16:36:08  myles: Coule different evidence
16:36:20  myles: Issue was originally phrased to sound like fantasai was just thinking thru it
16:36:24  myles: Rather than real complaints.
16:36:33  myles: That makes me less inclined to solve this with elaborate solution.
16:36:55  myles: Next is that, for the use-cases it was designed for, was simple flowing text in paras. Those don't need this.
16:37:01  myles: Finally, the "safe" thing sounds hard and slow to spec
16:37:30  dbaron: One thought I had that might work is that what you trim is pieces of inlines.
16:37:49  dbaron: If leading-trim is set to trim stuff, you trim all the inlines in the first line, and then do the linebox layout from there.
16:37:56  florian: You trim the linebox itself tho.
16:38:14  dbaron: Right, I'm asking, why not do it this way? Rather than a fancy calculation about the linebox, it's a simple calculation about each inline's contribution to the linebox.
16:38:25  dbaron: In the simple case it works the same, but it produces something pretty logical in more interesting cases.
16:38:45  Hi!
16:38:48  myles: I think that's similar to line-ehgith on an inline; linebox amalgamates those
16:39:06  dbaron: It's not quite similar; you still set it on the block, but you trim on each inline
16:39:11  myles: I think that's a mistake ot repeat that model
16:39:24  florian: The line isn't just sized by the stuff inside; an empty line still gets trimmed
16:39:34  dbaron: Right, that's the root inline box, which can get trimmed.
16:39:41  dbaron: I'm not as convinced as myles that that model is a mistake
16:40:02  dbaron: I think it makes sense in the world of CSS where th eperson writing stuff doesn't know how the content will render: wrapping, fonts, etc.
16:40:08  dbaron: The model we have is better at dealing with unknowns.
16:40:16  dbaron: That said, it could have been looking at different pieces of data.
16:40:26  dbaron: The idea that that's how we apply *line-height* specifically, probably broken.
16:40:39  dbaron: But the idea that we look at what's in the line individually, that seems fine.
16:40:51  jfkthame: dbaron's idea would handle superscript and subscripts for free
16:40:58  myles: Not for free, yuo still need to iterate things
16:41:37  florian: Do we want to try and sketch out dbaron's proposal, and rethink once we have it in detail and some time to think?
16:41:42  jfkthame: Would be interesting to consider.
16:41:50  +1
16:41:57  jfkthame: I'm not even sure if taking superscripts into account is desirable.
16:42:12  dbaron: Partly this is veering into a separate discussion about wnating a better line-height calculation.
16:42:15  dbaron: Had a lot of discussion about that
16:42:23  dbaron: Buildling a better model, tho, is separate from leading-trim
16:42:53  faceless: If goal is nice presentation text, not inconceivable you might be using baseline-shift to mess with position around th eline.
16:43:17  astearns: So should we leave the discussion there, and action david to flesh out the proposal?
16:43:26  One consideration could be to split leading-trim into "what I want to trim to" and "whether I am trimming this line", and could use the former metric as a way of measuring whether something leaks outside the root inline's leading boundaries
16:43:31  dbaron: You could, tho someone else might get to it faster.
16:43:43  dbaron: I'll bug fantasai about it if she could do it first
16:43:56  It would probably also cascade a little more conveniently, as one usually wants to think about which metric once, but whether to trim per element
16:43:58  astearns: So let's do that
16:44:17  Topic: intrinsic-size
16:44:18  RossenF2F has joined #css
16:44:29  github: https://github.com/w3c/csswg-drafts/issues/4531
16:44:56  ScribeNick: emilio
16:45:41  chrishtr: in december we discussed and concluded that if we couldn't find other use cases we should add a property specific to the size-contained case
16:46:02  ... since then dbaron has come up with some use-cases related to scrolling
16:46:14  ... so now the question is what to do with this information
16:46:25  ... whether adding two separate properties (which I'd recommend), or just one
16:46:55  dbaron: I would've preferred one property, but if you found a decent name for the contain-specific one I'm ok with two
16:47:02  astearns: what's the name of that?
16:47:17  chrishtr: contain-intrinsic-size, credit to fantasai
16:47:21  If there are two properties, what's the interaction?
16:47:32  TabAtkins: none or two lengths
16:47:42  (or one)
16:47:48  should be a shorthand for the various sizing longhands
16:48:22  TabAtkins: re. interaction: This only interact iff the element is size-contained
16:48:30  right, but that could happen
16:49:11  ... so I think the most consistent behavior would be that the contain-specific one wins, as contain: size already prevents a lot of other sizing-related calculations
16:49:27  it doesn't prevent 'width' and 'height' from doing things
16:49:30  astearns: fantasai also asked about it being a shorthand for the sizing props
16:49:31  so I'm not convinced about that
16:49:45  TabAtkins: definitely disagree with it being a shorthand
16:49:51  e.g. contain-intrinsic-width
16:49:52  specifically, since our use-cases want the "general" to do things like cause scrollbars, which is similar to it having a big child, and contain:size alreayd ignores children, I think it's most consistent to have contain:size cause that to be ignored.
16:50:40  TabAtkins: ah, ok, sure...
16:50:51  ?
16:51:00  fantasai: (about the shorthand thing)
16:51:16  do we need contain-intrinsic-aspect-ratio too?
16:51:18  dbaron: do we also want logical versions?
16:51:26  smfr, no
16:51:35  TabAtkins: I guess so, we'd all all of them
16:51:45  smfr, aspect-ratio already exists, why would we need contain-intrinsic-aspect-ratio?
16:51:50  chrishtr: what happens if you only specify one of them? The current proposal doesn't allow that
16:51:52  Rossen: auto?
16:51:57  TabAtkins: there's no auto
16:52:17  chrishtr, same in that dimension as if you didn't specify the property?
16:53:10  TabAtkins: given we need 4 longhands and such, can we skip it for now and see if it's necessary later?
16:53:21  chrishtr: I don't see downsides with that
16:53:27  as long as the shorthand is consistent with the size shorthand ...
16:53:29  which we still don't have
16:53:31  TabAtkins: we have good behavior turning something into a longhand later
16:53:38  into a shorthand*
16:53:50  There's also an issue around what order the values go in, if there are two of them
16:53:54  astearns: issues, concerns?
16:53:59  fantasai, yes, I imagine it'll be consistent.
16:54:06  @page { size: width height; } is currently the order there
16:54:15  fantasai: and yes indeed, we'll discuss which order to put the things in
16:54:24  which puts us inconsistent with grid shorthand and alignment ...
16:54:34  RESOLVED: add a property called contain-intrinsic-size
16:54:41  which is a mess, because we didn't listen to bradkemper
16:55:26  rrsagent, here
16:55:26  See https://www.w3.org/2020/01/24-css-irc#T16-55-26
16:55:33  TabAtkins: we should try to decide the order between the values
16:55:39  ... I think we should do block/inline
16:55:46  I think we should do width/height
16:55:54  because all of our shorthands are physical
16:56:13  because 'size' is already physical in paged media
16:56:16  and it's width/height
16:56:32  and physical shorthands with two axes are width/height
16:56:34  not height/width
16:56:58  emilio: I think I agree with fantasai
16:57:00  TabAtkins: we're going to be inconsistent with some amount of properties regardless
16:57:06  ... because we have examples of both
16:57:12  Not really
16:57:19  Everything with physical longhands is consistent
16:57:23  everything that doesn't is consistent
16:57:29  the two sets are inconsistent
16:57:35  and size has physical longhands
16:57:46  so it goes in the first category
16:57:48  TabAtkins: we can defer this to the next meeting and discuss in the issue with now
16:59:02  emilio: should we discuss now the other use cases that dbaron brought?
16:59:10  TabAtkins: if dbaron wants, sure
16:59:12  My 2nd worst mistake in CSS is definitely the ordering of the grid shorthand
16:59:15  dbaron: not sure we need to right now
16:59:36  TabAtkins: ok, we mostly wanted to see whether these concepts were separable
16:59:48  topic: font-display: optional
16:59:55  github: https://github.com/w3c/csswg-drafts/issues/4108
17:00:47  TabAtkins: I think we probably have a plan even if WebKit disagrees with this
17:00:54  ... I don't think we will get into a deadlock
17:01:11  ... As I said, the main goal of optional was to avoid layout shift
17:01:31  ... layout shift is really annoying and font-display: optional aims to solve that
17:01:40  ... another is performance
17:02:35  ... turns out that our data is that our the extra style and layout that the font load triggers delays stable layout significantly
17:03:03  ... and if you waited one or two frames you'd just get the final layout faster than if you did everything eagerly
17:03:26  ... and getting reasonable assurance about getting local fonts or downloaded fonts getting caches in getting the details of this right
17:03:51  xiaochengh has joined #css
17:04:15  ... and interesting quirk I found yesterday, some of our internal teams are using font-display: optional on iOS because caches there are usually faster than most android phone
17:04:39  ... so it usually hits the cache faster and if so... that's great
17:04:46  myles: I see your strategy :P
17:05:39  TabAtkins: Proposal is that for preloaded fonts, as soon as you see the preload tag, or as soon as you see the font-face rule that would refer to them, pull them be into the memory cache
17:05:53  ... for normal pages you should be able to get all the fonts you're using
17:06:20  ... when you start loading, if any of the loads triggered not from the cache, you're allowed to delay rendering before starting your first layout
17:06:41  ... and if you can't (too slow / whatever), then you discard the load and never use them again for the lifetime of the page
17:06:55  myles: I don't think any of those changes require any changes to any spec
17:07:10  ... the distinction between memory / disk cache is not something that should be on any spec
17:07:24  ... and if you use fuzzy words I don't think they would mean anything
17:07:44  ... specs doesn't forbid Chrome to delay rendering
17:07:57  ... so it's untestable, doesn't need to be in any spec, I'd be ok with no change
17:08:31  TabAtkins: I don't think I disagree with you, but it'd be good to hint to other implementations about how you can achieve a high quality implementation for this feature
17:08:46  myles: yeah that's good, but shouldn't be normative
17:09:30  Karen has joined #css
17:09:36  TabAtkins: ok, compromise proposal: We remove normative text about delaying rendering or what not, and we only state that optional fonts must not cause layout jank
17:09:44  ... and then provide notes to implementations
17:10:08  chrishtr: I think the spec must be clear that it's acceptable to delay rendering rather to do partial rendering
17:10:13  TabAtkins: yeah I'll put that in
17:10:17  myles: in the notes
17:10:19  TabAtkins: in the notes
17:10:35  myles: you can totally describe the intended use case in the spec
17:10:53  chrishtr: right now our implementation of font-display: optional can cause two layouts. I don't think it show
17:10:59  Zakim has left #css
17:11:04  TabAtkins: yeah that's the normative text described above means
17:11:13  Zakim has joined #css
17:11:37  ... well as long as pixels don't move you're fine
17:11:45  myles: I think that's an important distinction
17:12:03  ... if you want you can do layout every frame
17:12:10  chrishtr: agreed
17:12:54  fremy: when you have sheets in a document you never render before they load right?
17:13:03  TabAtkins: if you see them early enough or such
17:13:30  fremy: what I want to say is that there is a precedent for this
17:14:11  TabAtkins: proposed text is to change normative text for font-display optional to say that the font should never change rendering of the page
17:14:36  ... if it would you'd still just treat the load as failed and don't use it again
17:15:15  fremy: I don't really understand what's the difference between the font-face behavior and the stylesheet behavior
17:16:36  emilio: the main difference is that for stylesheets you statically know it applies, but to determine the fonts you need is that you need to do layout and styling
17:17:13  chrishtr: I think the main proposal to web devs is to add a  for important fonts and then use the font-display: optional to avoid the jank
17:17:35  I think it's important to distinguish it from the block behavior
17:17:46  astearns: objections to the proposed resolution
17:17:48  ?
17:17:56  You don't want to make the user wait more than a brief, mostly-unnoticeable moment in the case of font-display: optional
17:18:01  otherwise it's not really "optional"
17:18:16  fantasai, oh yes it's distinguished already; i'm just gonna remove a bit of semi-normative text
17:18:28  ok
17:18:44  RESOLVED: change normative text for font-display optional to say that the font should never change rendering of the page if it would you'd still just treat the load as failed and don't use it again
17:19:38  jfkthame: the phrasing about the suggestion about  about an important font seems a bit off to me
17:19:55  ... because tagging it as font-display: optional means that it is _not_ an important font
17:20:47  TabAtkins: you'd get the desired thing most of the time assuming a high-quality implementation
17:21:05  astearns: there are a couple more assumptions there, like fast network,  fast disk, no contention...
17:21:30  chrishtr: we could probably add the  bit separate from font-display: optional
17:21:39  RESOLVED: Add notes for implementors and authors to the spec, specific contents TBD
17:22:10  topic: end
17:23:59  zakim, end meeting
17:23:59  As of this point the attendees have been (no one)
17:24:01  RRSAgent, please draft minutes
17:24:01  I have made the request to generate https://www.w3.org/2020/01/24-css-minutes.html Zakim
17:24:04  I am happy to have been of service, astearns; please remember to excuse RRSAgent.  Goodbye
17:24:08  Zakim has left #css
17:24:39  Thanks everyone!
17:25:42  chris_, were you able to build css-color-5?
17:27:15  nope, I still get the sam error after rebuilding that branch
17:27:36  rrsagent, bye
17:27:36  I see 6 open action items saved in https://www.w3.org/2020/01/22-css-actions.rdf :
17:27:36  ACTION: fantasai fix animation types of CSS Backgrounds [1]
17:27:36    recorded in https://www.w3.org/2020/01/22-css-irc#T15-47-11
17:27:36  ACTION: add specifics into ink-skipping details TBD. And that it's done by reference. [2]
17:27:36    recorded in https://www.w3.org/2020/01/24-css-irc#T10-17-34
17:27:36  ACTION: fully specify an algorithm that specifies ink skipping that references other specifications that isn't codepoint-by-codepoint [3]
17:27:36    recorded in https://www.w3.org/2020/01/24-css-irc#T10-18-17
17:27:36  ACTION: fantasai to go through the issues after doing the spec work and split the remaining issues [4]
17:27:36    recorded in https://www.w3.org/2020/01/24-css-irc#T12-32-10
17:27:36  ACTION: Investigate using the line-break property to tweak this behavior [5]
17:27:36    recorded in https://www.w3.org/2020/01/24-css-irc#T12-54-25
17:27:36  ACTION: florian file a bug with ICU on this [6]
17:27:36    recorded in https://www.w3.org/2020/01/24-css-irc#T13-05-42