00:09:44 RRSAgent has joined #css 00:09:44 logging to http://www.w3.org/2017/04/19-css-irc 00:09:46 RRSAgent, make logs public 00:09:46 Zakim has joined #css 00:09:48 Zakim, this will be Style_CSS FP 00:09:48 ok, trackbot 00:09:49 BogdanBrinza has joined #css 00:09:49 Meeting: Cascading Style Sheets (CSS) Working Group Teleconference 00:09:49 Date: 19 April 2017 00:10:04 Rossen has changed the topic to: CSSWG F2F Tokyo 2017 - day 1 00:10:45 Rossen has changed the topic to: CSSWG F2F Tokyo 2017 - agenda at: https://wiki.csswg.org/planning/tokyo-2017#topics 00:11:08 present+ myles 00:11:43 skk has joined #css 00:11:54 flackr has joined #css 00:12:49 present+ myles_ 00:14:05 present+ 00:14:12 prensent+ 00:14:14 present+ 00:14:23 present+ 00:14:38 present+ 00:14:42 scribenick: iank_ 00:14:45 present+ 00:14:52 present+ 00:14:54 For topics, I think Grid, Flexbox, and Alignment would go well together. 00:15:01 🎁+ 00:15:23 present+ 00:15:28 Rossen: Lets start with introductions 00:15:32 present+ 00:15:32 present+ 00:15:34 present+ 00:15:35 present+ 00:15:44 present+ 00:15:46 fantasai aka Elika Etemad, Invited Expert 00:15:47 present+ 00:15:47 Rossen Atanassov, Microsoft 00:15:49 Dean Jackson, Apple 00:15:53 present+ Jack Moffitt, Mozilla 00:15:55 present+ 00:15:56 Bogdan Brinza, Microsoft 00:15:59 Rob Flack, Google 00:16:01 Rick Byers, Google 00:16:13 Florian Rivoal, Vivliostyle 00:16:14 Alan Stearns, Adobe 00:16:14 Emil A Eklund, Google 00:16:16 Simon Fraser, Apple 00:16:17 Jet Villegas, Mozilla 00:16:17 L. David Baron, Mozilla 00:16:23 Vlad has joined #css 00:16:23 Brian Birtles, Mozilla 00:16:23 Xidorn Quan, Mozilla 00:16:24 Ian Kilpatrick, Google 00:16:25 Shane Stephens, Google 00:16:31 Shinyu Murakami, Vivliostyle 00:16:33 present+ 00:16:54 Guest87 has joined #css 00:16:58 Vladimir Levantovsky, Monotype 00:17:01 Rossen: Thanks for hosting us and the wonderful venue. 00:17:12 Hiroshi Sakakibara, BPS 00:17:15 present+ 00:17:18 present+ 00:17:19 tantek has joined #css 00:17:26 dbaron: I wrote a new IRC bot known as minute-man 00:17:35 dbaron: It's job is to comment in github when we discuss a github issue 00:17:37 dbaron: I wrote a new irc bot, "minuteman", its job is to comment it github when we comment it github issues. 00:17:53 dbaron: "Github Topic: " 00:18:07 s/minuteman/minute-man 00:18:13 dbaron: Topic is concluded with new Github Topic line or Topic line. 00:18:16 dbaron: It will log the resolution, and have an expanded irc log. 00:18:38 an example of a bot comment: https://github.com/w3c/css-houdini-drafts/issues/393#issuecomment-294706386 00:18:44 dbaron: It will also remove the "agenda+" issue if it has write access. 00:19:07 astearns: I think we'll need to add the bot to the w3c github org. 00:19:09 minute-man, intro 00:19:09 My job is to leave comments in github when the group discusses github issues and takes minutes in IRC. 00:19:09 I separate discussions by the "Topic:" lines, and I know what github issues to use only by lines of the form "GitHub topic: | none". 00:19:09 I'm only allowed to comment on issues in the repositories: dbaron/wgmeeting-github-ircbot w3c/csswg-drafts w3c/fxtf-drafts w3c/css-houdini-drafts. 00:19:09 My source code is at https://github.com/dbaron/wgmeeting-github-ircbot and I'm run by dbaron. 00:19:25 all: Much applause. 00:19:44 fantasai: Feature request, link to the irc logs within the github issue. 00:19:53 dbaron: Yes, need to refactor the bot to do that. 00:20:05 Rossen: Thanks dbaron, this is awesome. 00:20:31 ChrisL has joined #css 00:20:32 Topic: Resolve on dates for F2F meeting in SYD 00:20:40 dgrogan_cloud has joined #css 00:21:03 Rossen: What are we thinking, there are 3 weeks proposed. 00:21:21 shane: I have a hold on all three weeks at the moment, outside those weeks is going to be hard. 00:21:27 present+ Simon Sapin, Mozilla 00:21:28 January 22 - January 25 00:21:28 January 29 - February 1 00:21:28 February 5 - February 9 00:21:32 any of these three weeks is equally good for me 00:21:41 Rossen: So, previously we've always picked the first week of feb, or around that. 00:21:50 Rossen: What works best for people 00:22:13 present+ David Grogan, Google 00:22:14 dbaron: One thing we ran into before, the first week of school in AU, flights were expensive around that time. 00:22:25 dino: 26th Jan is a holiday 00:22:32 shane: It's a friday. 00:22:37 dino: That will be a long weekend. 00:22:38 tantek_ has joined #css 00:22:50 dino: I think that is also school holidays there. 00:23:16 dino: The safest to avoid holidays is the Feb week. 00:23:29 A quick flights search shows all flights to be equally expensive. Though it is too early to estimate 00:23:30 shane: Term starts Jan 30th. 00:24:00 Rossen: Feb 5-9 would that work? 00:24:23 kwkbtr has joined #css 00:24:51 Rossen: Lets agree on Feb 5-9, shane&dino unless we have more info about school holidays 00:25:07 Rossen: It seems that back of the week has been working better. 00:25:23 fantasai: Last year we had a discussion about 3 vs. 4 meetings per year 00:25:43 fantasai: If we want 3 we should resolve on that first, then resolve on dates. 00:26:18 astearns: We have google for the first meetings, and then the next proposal is April in Berlin near TYPO 00:26:39 astearns: wheather we have 3/4 meetings next year we have 2 meeting slots already 00:26:46 dbaron: Jan/Apr are close 00:26:54 Rossen: When is TPAC? 00:27:03 dbaron: 2nd week of November. 00:27:36 TabAtkins: NovTPAC/Jan/Apr/ are too close together 00:27:44 kudo has joined #css 00:27:49 dbaron: The second meeting by april is too close 00:28:11 TabAtkins: NovTPAC + EarlyJan is way too close. 00:28:25 TabAtkins: THINGS NEED TO MOVE 00:28:32 Rossen: TYPO is set at the moment. 00:28:54 ???: It's going to be April but no firm dates yet. 00:29:06 s/???/Vlad/ 00:29:09 ???: The conf schedule depends on the availability of the venue. 00:29:18 s/???/Vlad/ 00:29:24 Rossen: When is TPAC 2018? 00:29:35 Rossen: Is it going to be an early TPAC? 00:29:46 dbaron: I'm not aware of it being announced yet. 00:29:52 fantasai: Can we ping bert? 00:29:54 Bert: Do you know when TPAC is in 2018? 00:30:53 TPAC 2017 is Nov 6-10 https://www.w3.org/wiki/TPAC/2017 00:30:59 Rossen: SO, assuming that TPAC next year is going to be around Nov... fantasai points out that we need to decide on 3vs.4 meetings, if we want to be near TYPO that places a time constraint, Google hosting in SYD also places a time constraint. 00:31:11 Rossen: April to TPAC Nov is 6 months. 00:31:45 fantasai: If we are limited to April + Nov, we need 4 meetings, or have a 6 month gap. 00:32:28 shane: We could look at Google SYD hosting between Apr, and Nov TPAC. 00:32:44 shane & TabAtkins argue about relative niceness of summers. 00:33:22 dbaron: Mozilla toronto could be a good place as well. 00:33:34 Rossen: TPAC 2018 will probably be asia or EU. 00:34:14 fantasai: 00:34:33 Rossen: We need to decide if we want to forfeit the early SYD meeting. 00:35:10 Rossen: As TabAtkins pointed out there is a slow month between Nov & Feb. 00:35:22 fantasai: I might get a lot done. 00:35:29 Rossen: Lets try and wrap up. 00:35:46 Rossen: At this point is the April meeting not an option to move at this point? 00:35:54 Rossen: Can we move that meeting to Jun? 00:36:22 Rossen: I.e. Feb / Jun / Nov 00:36:46 fantasai: Do we don't 3 vs. 4 meetings? If 3 we can't do April. 00:37:03 TabAtkins: Disagrees. 00:37:18 Rossen: Lets to a quick straw-poll 00:37:24 Rossen: Based on that we'll decide dates. 00:37:42 abstain 00:37:43 3 00:37:50 3 00:37:51 3 00:37:51 abstain 00:37:53 till has joined #css 00:37:55 4 00:37:55 abstain 00:38:01 3 00:38:03 3 00:38:04 4 00:38:07 abstain 00:38:08 4 00:38:10 3 (weakly) 00:38:12 4 00:38:12 3 or 4 00:38:13 abstain 00:38:16 3 00:38:17 Math.PI 00:38:43 abstain 00:38:45 myles_ has joined #css 00:38:49 3 00:38:49 4 00:38:49 3 00:38:51 3 00:38:52 4 00:38:55 3 00:38:58 abstain 00:39:45 plh has joined #css 00:40:09 plh, do you know when tpac 2018 is? 00:40:21 average is 3.375 00:40:53 Rossen: So google is pretty strongly in favour of 3 00:41:07 Rossen: If we are going to stick we three. Jan/Feb is out of the question. 00:41:20 eae: We can't really do Feb and Apr. 00:41:35 Rossen: This discussion is more for shane + google if hosting in SYD 00:42:20 fantasai: Do we peg to typo in april? If not we can do goog in feb/mar, if we do one in (northern) hemisphere summer. 00:42:45 Rossen: I'm personally not aware of the TYPO constraint and being close to it. 00:43:57 Vlad: The motivation that people may want to attend both (CSS & TYPO) lots of people learning about CSS/TYPO 00:44:14 Vlad: Good if CSS participants could attend TYPO 00:45:12 astearns: I have a slight perference for TYPO and then a (northern) hemisphere summer meeting 00:45:32 Rossen: Ok if thats what we want to do, lets decide that and allow shane to release hold of the rooms. 00:45:49 shane: Can we first make sure that everyone can make a timeslot there? 00:46:03 Vlad: where is typo? 00:46:28 fantasai: 00:46:33 myles_: Berlin 00:46:34 dbaron: which months? 00:46:40 fantasai: Jun/Jul/Aug 00:46:45 everybody from Mozilla likely has a problem with June 11-16, 2018 00:46:47 first two weeks of July are probably not good for Googlers 00:46:47 Google is out Jul 3 - 14 00:47:14 first two weeks of June are problematic for me 00:47:29 early june is often bad for apple folks 00:47:34 fantasai: Maybe we pull all the constraints now, and decide tomorrow 00:47:42 fantasai: after interrogating ChrisL 00:48:01 US summer holidays basically all of July and August? 00:48:07 yeah 00:48:08 June is not good for Microsoft 00:48:08 plus late june if you're in high school 00:48:28 iank_: June looks out. 00:48:39 Rossen: So Jul/Aug? TPAC in Sept would be bad... 00:49:16 Rossen: Mid-Jul & Aug is what we are looking at in terms of dates. 00:50:04 Vlad_ has joined #css 00:50:04 Rossen: We'll figure out when TPAC is, then decide. 00:50:25 Rossen: Lets end with that. 00:50:54 I think TPAC 2016 worked really well in September. If you thought so as well, please ask your AC representative to tell the W3C Team (and AB) accordingly 00:51:04 ACTION: w3c staff please get back to us about TPAC 2018 00:51:05 Error finding 'w3c'. You can review and register nicknames at . 00:52:15 Topic: Conditional Rules 00:52:16 ChrisL_ has joined #css 00:52:35 dbaron: I was hoping zcorpan would be here, but he's given regrets. We should delay or take it offline. 00:52:41 πŸ‘‹ ChrisL_! 00:52:42 dbaron: who was driving the issue? 00:52:51 scribenick: dino 00:53:04 Rossen: It came from the driving specs to REC. You said we need to resolve some things with zcorpan. 00:53:09 dbaron: push it offline. 00:53:38 Topic: UA-defined variables 00:53:42 scribenick: ChrisL 00:53:46 Vlad has joined #css 00:54:23 dino: want to expose values that are UA specific, like the range of text sizes for accessibility 00:54:46 .. nice to expose them as variables but the user can'rt change them but can use them 00:54:56 ... no concrete proposal or list 00:55:17 iank_: --safari-- stuff? 00:55:20 dino: no 00:55:31 tab: like a keyword 00:55:43 dino: variables is a nice way to expose them 00:55:48 s/like a keyword/a user-agent variable is otherwise known as a keyword in CSS/ 00:55:58 TabAtkins: can be used anywhere which is nice 00:56:14 shane: want to see a const construct, users often have const variables too 00:56:28 dino: conflicts with const in JS 00:56:43 shane: seeing people in the wild use a ton of variables 00:56:49 Kitahara_ has joined #css 00:56:55 trabwe special case vars defined on the root 00:57:21 s/trabwe/TabAtkins: 00:57:36 Rossen: seen people want that for colors, fonts 00:57:44 dino: scroll-bar width 00:58:29 TabAtkins: uas can insert this 00:58:53 eae: expose selection color as well 00:59:13 leaverou: existing fallback mechanism on vars would help here 00:59:23 --- 00:59:29 TomoyaKIMURA_ has joined #css 00:59:30 - 00:59:31 TabAtkins: use a normal keyword for the ua defined ones 00:59:40 (--- is a valid var, try again) 00:59:43 ... keep variables for users 00:59:44 -foo 00:59:54 two em-dashes 01:00:01 ascii!! 01:00:02 ~~foo 01:00:04 (We promised to keep CSS syntax within ASCII.) 01:00:05 dino: don't want vendor specific ones 01:00:18 leaverou: benefit of variables over keywords? 01:00:52 TabAtkins: messes with the grammar if they are allowed literally anywhere. eg in calc 01:01:09 Florian: var like things but not keywords 01:01:16 or units 01:01:35 dino: if they are -- it gives authors a way to provide default values 01:01:49 s/selection color/ui value keywords such as selectioncolor or default fonts/ 01:01:55 astearns: especialy for uas that don't support it yet 01:02:16 `--foo: whatever !const;` <== only allow on a root element (document or shadow tree)? 01:02:26 Florian: parsing of var function, can we define ones without -- but for legacy reasons no 01:02:40 dino@supports can't be used with var 01:02:53 dbaron: can use @supports display: var(foo) 01:03:13 dino: like to keep the var function and not require the dashes 01:03:26 shane: and allow them tobe marked as const 01:03:42 iank_: a non changing variable 01:04:02 shane: 100+ const-like variables in many stylesheets. if const would be a lot cheaper 01:04:16 dino: okay, but need a sysntax proposal. 01:04:23 ... you special-case root? 01:04:37 shane: as a cache, only. they can still change 01:04:42 jdaggett has joined #css 01:04:51 TabAtkins: anything starting with a ! is open, we could use that 01:05:22 ... vars are syntax checked so can set a custom property and give it the value of the var kw which will syntax fail on... 01:05:26 --foo: my-fallback; --foo: var(UA-keyword); 01:05:42 TabAtkins: second one fails at parse time 01:05:58 ... so usual fallback mechanism 01:06:29 should probably do "--foo: my-fallback; --foo: var(UA-keyword, my-fallback);" 01:06:29 xidorn: why does the second one fail 01:06:41 TabAtkins: should invalidate the property at parse time 01:06:53 Florian: also fallback inside the var function 01:07:06 dino: will open a GH issue to bikeshed the syntax 01:07:32 topic: caniuse 01:07:38 (Expanded explanation: syntax is `var( )`, where is a --name. Thus, per spec, using a non-dashed keyword is syntactically invalid and should be rejected at parse time. 01:07:39 ) 01:07:52 Github topic: https://github.com/w3c/csswg-drafts/issues/1219 01:07:52 OK, I'll post this discussion to https://github.com/w3c/csswg-drafts/issues/1219 01:07:58 fantasai: we were asked to add these to our specs, bs supports 01:08:13 filed as an issue on individual specs? do it on all or none 01:08:19 Florian: seems useful 01:08:35 fantasai: main reason not ot is that it is unofficial 01:08:44 leaverou: better than nothing and they use tests 01:08:57 Florian: editors drafts or TR? 01:09:01 ChrisL_: There was this thing about using scripts on our own site 01:09:19 ChrisL_ talks about w3c publishing policy 01:09:24 TabAtkins: It's just the images that aren't local 01:09:32 ChrisL_: It's a static snapshot? 01:09:43 TabAtkins: Based on current state of database when you generate it 01:10:01 ChrisL_: Then it needs to be very careful to be labelled as such 01:10:07 Do any other specs on /TR have it? 01:10:09 leaverou: Could we make it live? 01:10:17 TabAtkins: But then you have more live dependencies 01:10:23 TabAtkins: I don't like having lots of live dependencies 01:10:31 ChrisL_: We have live dependencies for tests, it's great 01:10:45 leaverou: It's extremely misleading for ppl, especially because we take years to publish a new spec 01:10:53 TabAtkins: Which is a reason to keep it for EDs only 01:10:56 tantek: What's being asked for? 01:11:03 Florian: Our specs don't have it, others doo 01:11:08 tantek: whatwg uses them 01:11:09 tantek: do any s[ecs on /TR have this now? 01:11:30 tantek: no-one else at w3c has done this, is that a blocker? 01:11:51 fantasai: want us to have an updated /TR rather than ED and what stops us is the process of publishing 01:12:12 ... now we have echidna, no readon why an editor can't get a resolution and push to /TR 01:12:23 tantek: lots of reasons why thwat doesn't happen 01:12:52 fantasai: once it is resilved no reason not to push to /TR.. want them to be a s useful as ED so ED can be the scratch space 01:13:06 tantek: agree but out of scope for this issue 01:13:21 fantasai: having useful stuff in ED and not TR stops us publishing 01:13:26 tantek: way out of scope 01:13:38 Kitahara has joined #css 01:13:56 fantasai: want them to be equivalently useful 01:14:05 tantek: blocking on this is not reasonable 01:14:22 leaverou: idf we add them on ED then we should add on TR as well and live, not stale 01:14:55 q? 01:15:02 fantasai: even ED can go for a time without being updated, like scroll snap where there are no edits but impl data updates 01:15:42 plinss: (explains multiple pass database regeneration) 01:16:05 astearns: want these to be in /TR and as that is not regwnerated we need it to be live. tab can we do that/ 01:16:17 TabAtkins: annoying duplicate paths but can do 01:16:41 astearns: updated from spec 01:16:57 leaverou: how about bs does it and then a script updates 01:17:00 TabAtkins: sure 01:17:08 ... plins wil write it 01:17:29 leaverou: what about features behind a flag hides vendor interest 01:18:17 TabAtkins: decided that behind a prefix is hidden because wanting to see what can be used. explaining what is available with what prefixes is .... 01:18:49 ??: canisue can be updated very slowly 01:19:36 rachelandrew: fins caniuse often out of date 01:19:45 Rossen: microsoft updates mdn 01:19:59 till: we could make an api to get that easily from mdn 01:20:16 ScribeNick: fantasai 01:20:34 s/??/rbyers 01:20:36 rbyers: MDN doesn't have a nice API like caniuse does 01:21:06 s/we could/Mozilla could 01:21:10 rbyers: We've talked with MDN folks about that before 01:21:19 rbyers: For case of developers, they're already going to caniuse 01:21:32 till: If that's what it takes to get us all to agree on updating this data, then it's a stron greason to do this 01:21:46 Florian: There's also no reason for caniuse to not use that data, if it's available through an API 01:21:56 leaverou: Even if purpose is not for implementor nterest, but for developers 01:22:14 leaverou: But it makes a difference between not implemented at all maybe not arriving, or whether it's implemented behind a flag and coming up 01:22:25 leaverou: Recently I solved an issue in images 4 where there was a table, everything was gry, no implementations 01:22:43 leaverou: I clicked thorugh a link, and it was a wall of green. Why trust the tables if discrepency is so big 01:23:03 TabAtkins: No guarantee that stuff behind flag or prefix is anything similar to what's in the spec 01:23:17 rachelandrew: We need to expose things behind a flag so we can get feedback from developers 01:23:34 Florian: Cna we sort of resolve on this and file bugs on Tab and Peter or? 01:23:36 ... 01:23:56 eae: It's only really useful if there's a reasonable expectation that it's at least somewhat recen tor up to date 01:24:11 rbyers: Devs find caniuse very useful even though not up to date, 01:24:19 Florian: But it's not 3-4 years out of date 01:24:32 rbyers: If what you really wnat is behind a flagg use case, the only wayt ot get that is an automated system 01:24:36 rbyers: W... 01:25:19 rbyers: We're going to make a tool available later, called API Confluence Dashboard, similar to Edge API Catalog, but it's an automated tool that lists all fo the APIs available in every browser and how they've changed over time. 01:25:40 rbyers: This is furhter out, but if we want to tackle what things are under development, this might be more practical way to tackle long term. It'll always be fresh 01:25:43 s/I clicked thorugh a link/I clicked through the caniuse link/ 01:25:46 smfr: geneated by software? 01:25:51 rbyers: Yes, used by walking ? graph 01:25:58 rbyers: Not good for all features, but somethings 01:26:10 rbyers: Depends on browser being available on browser stack 01:26:18 ... 01:26:30 ChrisL_: Safari Tech Preview, I was using it in browser stack yesterday 01:27:07 fantasai: sounds like we have lots of ideas but haven't documented how/where to do it 01:27:10 rbyers: maybe 2 outcomes from this, use Tab's caniuse for now 01:27:18 rbyers: And have a small group to discuss making btter 01:27:31 tantek: Yeah, have something that works today, let's go with that, experiment on ED 01:27:37 tantek: and then solve in /TR later 01:27:46 eae: Risk of bad data being propagated 01:27:51 tantek: Yeah, so try out on EDs 01:27:59 tantek: Don't wait for perfect being enemy of the good 01:28:42 fantasai: So, plan is enable caniuse panels on EDs, and investigate better ways of exposing data and putting on /TR 01:29:04 RESOLVED: Add caniuse panels to CSS EDs 01:29:21 Rossen: Further fallout is to discuss better ways of exposing the data 01:29:34 Rossen: in useful and more predictable ways 01:29:39 Rossen: Don't have to decide on this now. 01:30:07 fantasai: people who are interested in figuring out how to collect/expose data should have a side discussion 01:30:13 tantek: drop it into a github issue? 01:30:45 s/walking ? graph/walking the object graph/ 01:30:54 fantasai: sure, side discussion while we're here, but keep things someplace where others can participate 01:30:57 Topic: break 01:31:02
> 01:31:27 github-bot has joined #css 01:31:54 github-bot, intro 01:31:54 My job is to leave comments in github when the group discusses github issues and takes minutes in IRC. 01:31:54 I separate discussions by the "Topic:" lines, and I know what github issues to use only by lines of the form "GitHub topic: | none". 01:31:54 I'm only allowed to comment on issues in the repositories: dbaron/wgmeeting-github-ircbot w3c/csswg-drafts w3c/fxtf-drafts w3c/css-houdini-drafts. 01:31:54 My source code is at https://github.com/dbaron/wgmeeting-github-ircbot and I'm run by dbaron. 01:34:20 myles_ has joined #css 01:42:21 Guest87 has joined #css 01:48:06 smfr has joined #css 01:49:29 bgirard has joined #css 01:53:11 tantek has joined #css 01:53:14 ScribeNick: TabAtkins 01:53:20 Topic: Writing Modes implementation report 01:53:28 myles_ has joined #css 01:53:37 Hello 01:54:25 koji: The current status of WM is tha twe have an impl report. 01:54:27 present+ 01:54:28 koji: In the topic. 01:54:32 koji: And a DoC update. 01:54:39 koji: One open issue from Boris. 01:54:43 Sorry, tantek, I don't understand 'trackbot, where are we'. Please refer to for help. 01:54:49 Sorry, tantek, I don't understand 'trackbot, pointer'. Please refer to for help. 01:54:55 rrsagent, here 01:54:55 See http://www.w3.org/2017/04/19-css-irc#T01-54-55 01:55:03 https://wiki.csswg.org/planning/tokyo-2017#topics 01:55:21 koji: If there are any comments on the impl report or DoC... 01:55:32 koji: Hopefully solve the last open issue, and get the resolution to publish 01:55:41 koji: If anyone has feedback, please let me know 01:55:46 Florian: I have on both. 01:55:54 Florian: Some detailed feedback, but first... 01:56:07 Florian: I think we should indeed go to PR with this module; it's in a good shape. 01:56:12 myakura has joined #css 01:56:21 Florian: The impls are coming along, and there are political reasons to take a stand and say this has made progress. 01:56:35 Florian: But we should do it with the understanding that we are stretching a little the dfn of what a REC is. 01:56:48 Florian: Our charter says "2 indep.. impls of each feature", and that's fuzzy - what's a feature? 01:57:07 Florian: We don't need 2 impls of the entire spec as a block; I think we have two impls of each testable statement. 01:57:11 ChrisL_: That's correct. 01:57:27 fantasai: For example, WM in table cells. Impls do slightly different things. 01:57:40 fantasai: It's a fairly signficant use-case for vertical text, but it flat-out doesn't work. 01:57:52 Florian: So it rotating a table cell is a feature, we ahve it, but we don't ahve sizing in the same browser. 01:57:58 http://jsbin.com/vubeti/edit?html,css,output 01:58:02 fantasai: So it's more of a weird way the test got split out. 01:58:22 Florian: Haven't tried this test-case in the latest everything, but recentyl, not a single browser does everything. 01:58:40 Florian: Enough browsers pass each aspect that we can pass all the tests, but none pass it meaningfully. 01:58:48 Rossen: What do you think should do? 01:58:56 Florian: [details that I missed] 01:58:58 estellevw has joined #css 01:59:35 Florian: With that said, I think we should still go to PR. 01:59:56 Florian: This is a large enough spec with fingers everywhere; we'll find issues for years. If we wait for it being 100% complete, we'll never go to rec. 02:00:10 Florian: Just want to make it clear that just having unit tests passing doesn't mean the job is done. 02:00:15 q? 02:00:22 koji: as far as I understand. 02:01:01 TabAtkins: Passing all unit testsisn't enough to say you implement the feature, you do need integration tests 02:01:01 koji: ...w3c process means you ahve to pass unit tests 02:01:18 (If you can pass all the tests but not implement the feature correctly, there aren't enough tests.) 02:01:39 Rossen: That's fine. People will find bugs, they'll file, we'll become more interoperable... 02:01:53 iank_: We'll be doing a revamp of our table code probably 9-12 months from now. 02:02:00 iank_: Expect we'll have more feedback at that time. 02:02:25 Florian: To be clear, I didn't take tables as the sole thing; it's representative, and I was putting together a talk for the AC. 02:02:39 Florian: I was doing some example coding and saw we didn't have interop. 02:02:58 dbaron: I'm worried about how this interacts with intrinsic sizes. Much is not in WM, some is in Sizing, some I think is not defined. 02:03:17 dbaron: I think when you say something "doesn't work", it's because it doesn't do what you expect, but the obvious way you can fix the spec might not be something we're willing to do. 02:03:31 dbaron: So it might take changes to the spec to get to the point where we agree on an intrinsic sizing behavior. Maybe substantial. 02:03:44 dbaron: So this makes me worried to take this to PR right now. 02:04:03 Florian: Agree. I still think PR is useful for political reasons. 02:04:28 iank_: Intrinsic sizing isn't well-defined for WM, right? 02:04:31 fantasai: It is, I think. 02:04:35 dbaron: I disagree. 02:04:36 This sounds to me like 1) we don't have actual interop (use cases), 2) if we don't know what features are features, we are underspecified CR exit criteria, and need to fix that with a new CR that specifies it, 3) if we have disagreement among browsers on how these features work right now, it is likely we will need normative changes to fix it, which means we need a new CR 02:04:40 fantasai: It requires doing layout. 02:04:45 dbaron: Which I don't ever want to do. 02:04:58 fantasai: ...which Firefox and Chrome don't have the architecture for, yes. 02:05:27 fantasai: but Edge does, IIRC 02:05:32 Florian: For this spec, we'll find issues for a ver long time. I'm not sure it would be a good mov epolitically to delay the spec for 5-10 years. 02:05:34 dbaron: I don't think that it requires not addressing those use cases 02:05:34 "will find problems a very long time" is just normal maintenance expectations and must not be used as an excuse for any decision 02:05:43 Florian: HTML has gone with some holes and vagueness. 02:05:51 Florian: We have a fairly comprehensive test suite. 02:06:18 fantasai^: Solving vertical text in table cells requires doing intrinsic sizing after layout, and I don't think it's reasonable to say that we will never solve what is a major use case of vertical text 02:06:23 TabAtkins: Mentioning HTML in this regard isn't meaningful. 02:06:26 (that line goes beore dbaron's comment) 02:06:50 Florian: There's been substantial push from Japanese gov to get this to a more stable level. 02:06:54 present+ Surma, Google 02:06:55 bobbytung has joined #css 02:06:56 Florian: As a milestone. 02:07:11 Florian: Maybe we wouldn't ideally want to call it Rec, but that's the name we have; we can still ahve things to fix. 02:07:28 koji: Ignoring the JP community, Rec always to me means there can still be work to do. 02:07:53 tantek: That's false. "There's always maintenance" is true for everything. But it's a difference of degrees - there's a difference between holes and interop. 02:08:15 fantasai: There's always going to be interop - CSS2.1 still does. There's a threshold you can hit. 02:08:36 s/interop/interop issues/ 02:08:36 fantasai: It's always a judgement call, and a reflection of the issues we have going in. 02:08:54 fantasai: I think there's still some issues to edit in, but there's not much issues coming in for the spec itself, just minor details. 02:09:13 fantasai: There are a lot of impl bugs - this spec affects *every* layout system - and there will be forever. 02:09:28 tantek: You're using incoming issues as a metric - Florian, did you file issues for these? 02:09:41 Florian: No, because they're not spec bugs as far as I can see. I could be wrong. 02:09:50 tantek: If you can't make a judgement call, file an issue. 02:09:56 tantek: So someone else can decide. 02:10:23 fantasai: A large part of the ocmplexity of the spec is its interaction with all of CSS 2.1. 02:10:40 fantasai: There's no error in how the interaction is described, there's just a lot of details that can get wrong. 02:10:51 tantek: A particular issue that bothered me - behavior in table cells. 02:10:52 s/wrong/wrong in implementations/ 02:11:12 tantek: In 2.1, how properteies worked in/out of table cells was one of our biggest sources of interop problems. 02:11:22 tantek: So if we can't even do that, we have major problems. 02:11:40 s/In 2.1/In CSS 1/ 02:11:43 Florian: I don't know if it's a spec problem - my reading isn't showing a problem - but are impls wrong because they don't know it's wrong, or they know it but can't fix it? 02:11:54 rbyers: That's waht tests are for. 02:12:07 Florian: I don't have budget for detailed investigation work. I'm just raising the flag. 02:12:32 Florian: So being aware of that, do we do that and go to Rec in a year or five, or go to Rec for political reasons and still fix it. 02:12:50 dbaron: A third possibility is that the impls *are* doing what's specified... there's plenty of holes. 02:13:12 fantasai: There's bits where things are defined "analogously to 2.1" - if you don't make that translation correctly, you get some bugs. 02:13:33 fantasai: That's where most of our issues come from - people not applyign the analogy fully and correctly. 02:13:57 fantasai: Different from Flexbox or the like, where interop issues are a problem directly in the spec. 02:14:14 tantek: I see that; we had similar with box-sizing, and we had to go into more detail. Maybe that's the solution. 02:14:26 fantasai: That means rewriting the 2.1 block/inline layout specs, which isn't happening right now. 02:14:47 tantek: Sure. But currently our features just don't pass the interop guidelines. 02:15:07 Rossen: I don't believe this is true. I agree with fantasai that WM is a horizontal feature that cross-cuts, like intrinsic sizes. 02:15:10 Fundamental problem is: do use-cases have interop or not? 02:15:33 fantasai: Like logical properties; we don't define each individual property, we just describe the mapping and the names. 02:16:32 Rossen: Counter-example to get away form WM for a second - when we started defining fragmentation, another horizontal feature, we had a choice - start defining how fragmentation works for everything, and put all of this into one single spec, or define the basic rules and what it is and how it's supposed to be applied, then every other layout module defines 02:16:32 how it happens. 02:16:38 Rossen: WM is not that different. 02:16:46 Rossen: Going thru the WM spec, the WM part is pretty well-defined. 02:17:14 Rossen: There are interactions with every layout module, there will be integration issues - a flexbox isnide a table inside a grid, all with different WMs, there will be issues that impls have to work thru, and we do. 02:17:22 Rossen: That's not a WM problem, that's an integration problem. 02:17:42 Rossen: So for horizontal features, I don't want us to have to pull all of CSS into the feature and blaming all the buggy integrations on this particular spec. 02:18:08 tantek: I get that, but a bit of a strawman - inside a table cell or not, or inside an abspos or not. Those seem simple circumstances, that an author would expect to work. 02:18:20 tantek: If we don't ahve tests that demonstrate interop on that, I find it hard to believe we have interop. 02:18:43 koji: We have those tests, but only some are passed in each browsers. 02:18:59 Florian: Worse, each layout mode not only has to work in other WMs, it has to work in orthogonal flows. 02:19:23 Florian: We have only 1k tests - it can't cover everything. 02:19:34 Florian: But if we cover everything that exists today, we'll never finish. 02:20:01 tantek: Still strawman. If tehe simple examples you came up with, just to show something at the AC meeting, that's stuff we shoudl look into. 02:20:16 tantek: You're not making a newspaper, just simple examples. If you don't ahve interop there, something's broken. 02:20:28 tantek: Maybe spec, maybe impls, but we have to investigate. 02:20:32 tantek: I"m not asking for perfection. 02:20:43 koji: So what do you say when two impls pass? 02:20:48 http://jsbin.com/vubeti/edit?html,css,output 02:21:16 TabAtkins: He's saying that we have a theoretical integration test passing, even though unit tests pass 02:21:31 tantek: Not even a complicated one - no deep nesting - just simple "in a table cell". 02:21:50 Rossen: So there are impls that are behind, and it's up to them to catch up. 02:21:58 koji: Blink and Webkit don't implement it in table cells, but we plan to implement it 02:22:05 Florian: And the two that have it, MS and Moz, behave differently, and neither is good. 02:22:22 Florian: Moz doesn't implement sizing - your table cell will be rotated but sized wrong. 02:22:32 Rossen: So it's an impl problem, file a bug. 02:22:48 Florian: Unless MOz won't fix it - then it's a spec problem. 02:23:09 rbyers: Sounds like we should have a more integration-y test. 02:23:24 fantasai^: Koji said that Chrome/Blink will fix it though 02:23:28 Rossen: So currently 98% passes in two impls. 02:23:38 Rossen: Which means it works in a lot of major cases. 02:23:46 Rossen: I can find you float bugs today, and we've had floats for 15 years. 02:24:00 Rossen: It would be a little unfair to blow it up and say 2.1 can't go to Rec. 02:24:16 Rossen: At the same time, there's plenty of content that's depending on vertical WM that works well. 02:24:20 Rossen: epub, etc. 02:24:27 Rossen: Even tho it's not as interoperable as it should be. 02:24:36 Rossen: But WM today, for 90% of use-cases, is usable as-is. 02:24:50 Rossen: It would be a little unfair to over-index on one thing and let it skew whether we go to Rec. 02:25:06 tantek: I'd call into question your 90% assertion. 02:25:17 tantek: If every example Florian tried to show is faililng interop... 02:25:52 Florian: I haven't tried comprehensive testing, so maybe I was just very unlucky to run right into the problems. 02:26:12 koji: And table cells are a known issue for two browsers, so you'd have to pass both fo the two remaining. 02:26:50 koji: Pages ahve really changed today in using WM. Nowadays, many pages are using WM in real pages, I see this supporting Rossen's idea. 02:27:10 astearns: And jensimmons started writing up tons of WM examples a few months ago, and she's not been reporting spec bugs. 02:27:44 Florian: So the devil is in the details here. It's def not done and tied up, there are problems, but they're probably not that bad - it's used int he wild - and probably not that good - we find some problems. 02:27:50 tantek: Are people testing in one browser? 02:28:14 rbyers: 1 in 200 pageviews in Chrome are using WM. We rarely see features that popular for Chrome-specific code. 02:28:34 koji: And people end up knowing that WM doesn't work on table cells; they instead put a in there as a workaround. 02:28:49 good to know koji, thank you 02:29:04 q? 02:29:05 Rossen: Koji, you had some questions/issues to go over, can we get back to that? 02:29:40 here's what we see in terms of usage 02:29:41 https://developer.microsoft.com/en-us/microsoft-edge/platform/usage/css/writing-mode/ 02:29:50 Florian: I have some ocmments, but they don't matter if we decide to go ahead with publishing. 02:29:53 And here's Chrome usage: https://www.chromestatus.com/metrics/css/timeline/popularity/394 02:30:52 Florian: There's some places in your report that lists tests that fail, but it's okay because they're cross-spec tests for specs not in Rec, but for some I can find what the other spec is. 02:31:04 fantasai: Some are the unicode specs; if you have bad unicode data, some of these will fail. 02:31:23 Florian: But isn't Unicode REC-equivalent? 02:31:39 fantasai: Yeah. But if you just miss some cases in scripts, it's more of a Unicode bug than a WM bug. 02:32:07 Florian: So do we want to go that level of detail, or do we just say "eh, we're going to Rec, don't bother". 02:32:30 astearns: The # is so small, that removing them doesn't change the % passing (at integer courseness). 02:33:18 Florian: I think we shouldn't mislead ourselves that this is DoneΒ©, but as long as we're aware of that, I think we can move. 02:33:32 https://github.com/w3c/csswg-drafts/issues/1212 02:33:44 koji: We we discuss bz's issue? 02:33:55 koji: When WM is different from parents, the spec says it blockifies. 02:34:26 estellevw has joined #css 02:34:52 koji: bz is saying that "blockifies" can't compute containing block before layout 02:35:09 koji: It says "parent element", should be "parent box", but parent box isn't well-defined. 02:35:28 dbaron: Historically containing block depends on styles, but this is trying to make styles depend on containing block. 02:35:43 fantasai: We can change it to parent box, that's defined in Display. 02:35:50 fantasai: ONly important case is when display is inline. 02:36:12 fantasai: If any parent of an inline, which is also an ilnine, has a different WM, it will have become an inline-block, which makes it the containing block. 02:36:29 fantasai: An inline can't have a different WM from its containing block anyway, it becomes an inline-block. 02:36:46 fantasai: The different between parent box and parent element is only really relevant for display:contents afaict. 02:36:46 For my understanding, WM is huge spec, and it affects lots of other specs. And it looks difficult to satisfy interoperability with other specs. As Florian said, "being aware" might be important. So, WM L4 or L3.1 (it doesn't exist now. This might be bug-fix spec for WM L3) is needed for "being aware". 02:36:51 fantasai: You look "past" a display:contents. 02:37:06 fantasai: There are other cases where this clause doesn't apply anyway.. 02:37:31 fantasai: I'm in the process of trying to figur eout the wording with bz, but I think we cna just change to "parent box" as long as people are okay with walking up display:contents. 02:38:19 dbaron: You can come up with a new term that is "parent element, walking thru display:contents". 02:38:24 fantasai: That's jsut "parent box", no? 02:38:31 dbaron: Box tree isn't defined yet. 02:38:43 [fantasai and tabatkins bicker over whether it's sufficiently defined] 02:38:55 koji: [provides some example that I missed] 02:39:02 fantasai: I think I can fix this over lunch. 02:39:29 Florian: So we're looking for "parent element, but walk up display:contents". 02:39:44 koji: So shoud we define this in WM? 02:39:55 fantasai: It's in Display; if it doesn't quite exist yet, I'll define it. 02:40:10 Florian: So it sounds like we agree on behavior, if not on terminology. Can we resolve to that? 02:40:19 Rossen: Sounds like nothing to change in WM? 02:40:27 fantasai: There's a mention of "containing block" that needs to change to th enew thing. 02:40:39 koji: So proposal is to change "containing block" to "parent box", and define that. 02:41:10 Florian: And we can define "parent box" without needing the whole box tree. 02:41:20 TabAtkins: "Closest ancestor element that generates a principle box." 02:41:37 RESOLVED: Change "containing block" to "parent box", and define that. 02:42:02 koji: So with the last open issue resolved, I wonder from the last discussion if we're fine to resolve to publish or what. 02:42:14 tantek: Didn't we just make a normative change? 02:42:27 astearns: We need to make the update, get bz's approval, *then* we can ask for PR. 02:42:43 Florian: Do we have to cycle CRs since it's a normative change? 02:42:47 tantek: Technically yes. 02:43:13 tantek: Any excess features to drop? 02:43:16 fantasai: We already did. 02:43:24 Rossen: So we can resolve to repub CR with that change? 02:43:43 RESOLVED: Republish WM as CR, after making the normative change for the current open issue. 02:43:53 Rossen: Response period? 02:44:06 Florian: 4 weeks, shortest time, we're not looking for any particular input here. 02:44:19 just bzbarsky's input :) 02:44:54 Topic: Consider using USVString instead of DOMString 02:45:10 ScribeNick: fantasai 02:45:23 SimonSapin: In JS, strings are made of a sequence of 16-bit integers 02:45:27 SimonSapin: Can be arbitrary sequence 02:45:35 SimonSapin: Usually interpreted as UTF-16 02:45:40 SimonSapin: But don't have to be well-formed UTF-16 02:45:51 SimonSapin: In particular, range of values that are called surrogates 02:46:10 SimonSapin: If you have a leading surrogate plus trailing surrogate, i.e. 2 UTF-16 ints, that forms a single Unicode codepoint 02:46:31 SimonSapin: But in JS, nothing stops surrogates from appearing in the wrong order, or a single one by itself 02:46:35 SimonSapin: This is invalid Unicode 02:46:48 SimonSapin: But you can do it in JS 02:47:09 SimonSapin: If you want to convert that string to UTF-8, UTF-8 is designed to exclude surrogate codepoints to align with set of valid UTF-16 strings 02:47:24 SimonSapin: So not all JS strings can be represented in UTF-8 without losing data or using escaping mechanism 02:47:37 SimonSapin: Wasn't an issue, because every browser internally uses same type of string as JS 02:47:37 Github topic: https://github.com/w3c/csswg-drafts/issues/1217 02:47:37 OK, I'll post this discussion to https://github.com/w3c/csswg-drafts/issues/1217 02:47:54 SimonSapin: So if ou have CSSOM string that has unpaired surrogate, e.g. in an ident or content property string 02:47:57 SimonSapin: it's ok 02:48:26 SimonSapin: What's changing now is that in Firefox, we have a project called Stylo, which is to import Servo style system into Gecko 02:48:37 SimonSapin: That style system is using Rust str type for all strings 02:48:46 SimonSapin: which is based on UTF-8, so it cannot represent unpaired surrogates 02:49:17 SimonSapin: what that means is in practice, whenever a string comes from CSSOM and goes into the style system in Servo and in the future in Firefox, we convert to UTF-8 and in that process, any unpaired surrogate is replaced with U+FFFD REPLACEMENT CHARACTER 02:49:21 SimonSapin: So there is some data loss 02:49:32 SimonSapin: However, I think this kind of situation only happens accidentally 02:49:44 SimonSapin: Fact that JS strings are this way is not a feature, it's a historical accident 02:49:54 SimonSapin: I don't think there is a real compat risk with shipping Firefox this way 02:50:05 SimonSapin: Still, it's a deviation from current interoperable behavior, so wanted to bring it up 02:50:08 Florian: Proposal? 02:50:32 SimonSapin: In WebIDL which we use to define itnerfaces for JS, there is two string types. DOMString corresponds to JS strings with aribtrary 16-bit 02:50:54 SimonSapin: There is USVString, Unicode Scalara Value String, which has no unpaired surrogates, only well-formed unicode 02:51:14 SimonSapin: When you convert DOMString to that, you get the same behavior as in Servo, replacing lone surrogates with UFFFD 02:51:31 SimonSapin: If we want to keep this interoperable, then I propse to use USVString for all of CSSOM 02:51:45 ChrisL_: Seems like a good idea, since unpaired surrogates are only an error 02:52:00 ChrisL_: Only used for binary data, and cna't imagine that in CSSOM 02:52:30 TabAtkins: USVString is supposed to be avoided in WebIDL 02:52:45 TabAtkins: Currently only used in networking protocols that use scalar values 02:52:54 TabAtkins: Requires extra processing compared to UTF-16 strings 02:52:57 ChrisL_: maybe in custom properties though, people would want to store binary data; they should encode it to avoid syntax issues though so no big deal 02:53:05 dbaron: Anne disagrees with advice in WebIDl spec, btw 02:53:15 s/Anne/Annevk 02:53:19 dbaron: There's a github issue against WebIDL spec to give coherent advice, but ppl disagree on what that should be 02:53:35 dino: Appreciate that you want to use rust string type, but we all have to use our own string types 02:53:42 dino: Maybe resolution is all DOM strings should be that way 02:53:47 TabAtkins: No, that would break a lot of things 02:53:55 TabAtkins: ppl smuggle binary date in JS strings 02:54:00 TabAtkins: But for things that talk text, coudl do it 02:54:06 dino: Everything, not just CSSOM 02:54:15 Florian: Would it be reasonable for implementations that don't do rust strings internally 02:54:29 myles_: If we don't know perf impact, can't agree to do this 02:54:40 myles_: so somebody somewhere has to try it first before we agree to it 02:54:41 SimonSapin: Tab, ? 02:54:42 q+ 02:54:56 TabAtkins: Some DOM Apis have to be 16-bit, e.g. Fetch ... 02:55:00 rbyers: It's not in Chrome 02:55:04 TabAtkins muses 02:55:29 s/?/did you mean changing JS or DOM would break things?/ 02:55:43 till: It's not entirely out of the question that it would be Web-compatible enough that we could change it in JS itself 02:56:16 fantasai: For JS itself, Tab was saying it's not doable, but for DOM Apis more likely to be possible 02:56:23 iank_: Need to check with architecture folks about this 02:56:36 iank_: our architectue folks in charge of bindings and stirng types and stuff 02:56:52 iank_: Looked for code where we switch to USVStrings, and that's very expensive for us it looks like 02:56:55 iank_: Might be perf problems 02:57:38 fantasai: My take is that this is a veyr weird edge case with no real use... lone surrogates in the CSSOM. 02:57:49 fantasai: So I would say, let's spec you can use either, and we don't care. 02:58:29 myles_: Every string would have to get transcoded, that's crazy 02:58:41 TabAtkins: .... 02:58:49 iank_: Would have to guarantee that htat block internally is clean 02:59:01 TabAtkins: Move to UTF-8 clean internally 02:59:06 iank_: Sounds non-triial 02:59:15 Florian: Spec that either is Okay then it's not any work 02:59:27 Florian: If we can't spec that, then it means web depends on it, so Servo will have to bite the bullet 02:59:38 TabAtkins: I'm okay with doing that, put a note that we'd like to move th USVString 02:59:46 shane: If there's a webb compat problem, then it's a problem 03:00:00 TabAtkins: That means someone is injecting lone surrogates into the CSSOM. Can't come out of the parser 03:00:08 TabAtkins: In that case probably buggy anyway 03:00:25 shane: If ppl notice a problem, they'll file bugs 03:00:34 eae: It's very hard to get into the situation except intentionally 03:00:58 myles_: Does Servo have to translate between JS string and USVString all the time? 03:01:00 SimonSapin: Yes 03:01:15 SimonSapin: We have optimizations, e.g. if ascii then stord in one byte per uit, skip UTF-8 conversion 03:01:26 s/USVString/UTF-8 String/ 03:01:39 Florian: Can we just resolve on both and if it's a problem, come back and we'll change hte spec? 03:02:27 fantasai: I think interop in this very very weird case is not worth any effort, so it should allow both 03:02:35 till: It's not servo-specific, others might want UTF-8 codepaths 03:02:45 myles_: I believe that you believe that. 03:02:52 Rossen: Anyy objections? 03:03:00 rbyers: We should rediscuss if we find web compat issues 03:03:23 myles_ has joined #css 03:03:40 RESOLVED: CSSOM can use either USVString or DOMString 03:04:04 fantasai: We can alwasy raise issues if they're found later. 03:04:22 SimonSapin: This also affects other specs with WebIDL interfaces, e.g. CSS Fonts defines @font-face interfaces 03:04:29 Florian: Should we define a CSSString? 03:05:13 ... 03:05:19 iank_: But if we do this later.. 03:05:40 fantasai: We are literally deciding that you can do either, forever. Unless someone comes back and says "lone surrogates in CSSOm are an important use case and I need them" 03:06:40 Rossen discusses agenda items 03:08:25 Topic: last baseline alignment of scrollable boxes 03:08:29 Github topic: https://github.com/w3c/csswg-drafts/issues/766 03:08:29 OK, I'll post this discussion to https://github.com/w3c/csswg-drafts/issues/766 03:08:48 ScribeNick: shane 03:09:02 if you have a scrollable box with content 03:09:14 fantasai: if you have a scrollable box with content 03:09:22 ... last baseline, once content is higher than box 03:10:09 ... most recent resolution was that if last baseline is above the fold then use that, if below the fold then floor at bottom margin edge 03:10:17 ... previously just used bottom margin edge regardless 03:11:07 myles__ has joined #css 03:12:13 ... tab and I want to suggest that once scrolling offscreen, scroll whole box to the bottom and pick last baseline at final scroll position. 03:12:35 myles: in order to know where baseline is then you need to do a scroll, look at baseline, unscroll? 03:12:56 fantasai: just need to figure out bottom scroll position then find last baseline's position then subtract bottom scroll position from it 03:13:42 dbaron: what if there's a bunch of whitespace and when you scroll to the bottom your last baseline is way up? 03:13:56 smfr: does this apply to overflow: hidden as well as overflow: scroll? 03:14:08 ... an alternative is to align to the baseline of the last visible line (i.e. the one you can see) 03:14:19 dbaron: that's weird because different font metrics could make it pop differently 03:14:29 smfr: won't you get popping with this too? 03:14:55 iank_: can we just consider this an edge case? 03:15:16 Florian: what's the use case? 03:15:34 Rossen: DIY form controls 03:15:57 iank_: if you've got a eula at the bottom of a form, e.g. 03:16:11 myles_ has joined #css 03:16:21 Rossen: in the non-overflowing case it makes sense to align to the bottom line, I think we all agree to that much 03:16:42 dbaron: I agree it's abstractly sensible. But we have interop on the opposite right now. 03:16:56 fantasai: WebKit implements the proposed behavior and has for many years. So no interop. 03:17:08 Rossen: which means nobody cares? 03:17:26 tantek: so we have interop except for WebKit 03:17:35 bobbytung_ has joined #css 03:17:39 fantasai: yes, WebKit's behavior is higher quality than the specced behavior 03:17:51 Florian: and this means there isn't evidence that there's dependence on either behavior 03:18:37 myles: So are there other use cases than a select box? 03:19:38 flackr: proposed behavior is has discontinuity - if baseline falls below margin then it might suddenly jump upward 03:20:11 fantasai: no 03:20:26 Rossen: do you have the problem of baselines above box today? 03:20:38 myles: we just take the ??? 03:20:51 dbaron: people often put a page of blank text below scrollable areas 03:21:07 s/blank text/blank space/ 03:21:27 myles: ??? 03:21:40 Rossen: which is less than optimal for when there's no overflow 03:22:02 myles: resolution was 3 years ago, hasn't been any movement so far 03:22:15 fantasai: it is in CSS Box alignment module which is about to hit CR 03:22:39 Rossen: when you changed this were there use case motivations? 03:23:10 myles: from what I remember it wasn't use case based. I was working on some site compatibility problem 03:23:24 ... something like a row of icons and we were shifting them vertically 03:23:53 Rossen: which was dbaron's concern - that we might start breaking such content 03:23:56 ... I share that 03:24:30 iank_: reiterating: currently 3 impls just do the end margin edge. Current resolution is to do last baseline if no overflow, otherwise end margin edge. 03:24:42 myles: logic was that if text shorter than block, putting overflow: hidden on should have no effect. 03:24:52 iank_: that's different to no overflow though, right? 03:25:46 myles: nope, *draws* 03:26:08 iank_: but if you have a massive box with no text and it triggers overflow, then last baseline would go to end margin edge? 03:26:14 smfr: I posted a codepen with examples 03:26:25 ... (https://codepen.io/anon/pen/Wjreqe) 03:26:59 fantasai: that's not clear. 03:27:50 ... if the last baseline is above the bottom edge and there's no overflow, why would you jump if there was overflow? 03:28:27 ... baseline should be the bottom edge only if it would otherwise be below 03:28:34 myles: that describes what we currently do 03:28:44 iank_: OK so if there's overflow you still look at the last baseline of the text 03:29:22 fantasai: seems weird we're clamping to the margin edge rather than something where the text stops being visible like border box 03:29:37 Rossen: OK so back to myles' comment, is anyone actually going to change this? 03:29:51 smfr: I can't see any difference between browsers in this codepen. I think I've captured the behavior. 03:31:27 [divers alarum] 03:31:48 smfr: OK I've updated the codepen and the 3rd box now has a different baseline in browsers 03:31:55 ... Safari differs from everyone esle 03:31:59 s/esle/else 03:32:17 fantasai: and Safari's behavior is what we resolved on 03:32:25 Rossen: so this is what's defined in the alignment spec? 03:32:27 fantasai: yup 03:32:33 Rossen: do we need to resolve anything further? 03:32:48 fantasai: only if we want to change it, e.g. what we proposed or change margin-box to padding-box 03:32:52 Rossen: border?! 03:32:54 fantasai: padding!? 03:33:35 Rossen: don't need to decide on border vs. padding right now 03:33:52 fantasai: trying to take spec to CR, need to close off the issues. Could maybe decide after lunch though? 03:33:55 Kitahara_ has joined #css 03:34:04
03:38:49 Kitahara has joined #css 03:50:40 myles has joined #css 04:07:56 Florian has joined #css 04:14:11 github-bot, status 04:14:11 dbaron, I currently have data for the following channels: 04:14:11 #css (72 lines buffered on "last baseline alignment of scrollable boxes") 04:14:11 will comment on https://github.com/w3c/csswg-drafts/issues/766 04:14:24 Topic: lunch 04:14:27 smfr has joined #css 04:29:51 bobbytung has joined #css 04:35:40 Guest87 has joined #css 04:35:50 bobbytung has joined #css 04:36:38 i put some subgrid notes here https://4075834c10a34498ade2a927666cc81a.codepen.website 04:40:59 ScribeNick: fantasai 04:41:01 Topic: Grid 04:41:02 bobbytung has joined #css 04:41:25 idea for using web-animation API to create effect in AnimationWorklet: https://gist.github.com/majido/7e542e5af9ef090ba0ab7584316f235d#file-aw-ideas-js 04:41:26 Rossen reviews what a grid is 04:41:35 majidvp, post into #houdini? 04:41:52 (also great to have the link into here but they'r discussing over there :) 04:42:03 Rossen: Also good to have a way to group things in a grid 04:42:09 Rossen: Don't remember subgrid idscussions 04:42:25 Rossen: We started discussing subgrid and how it coudl work, but wasn't until later it made it in the spec 04:42:47 Rossen: I believe first version had ability of snapping of grid items in only columns and not rows or vice versa 04:42:58 Rossen: So allowing subgrid to allow overriding one of the two dimensions of grid 04:43:20 tantek has joined #css 04:43:20 fantasai: I think first version was both axes together, and then we split it out later 04:43:23 (and then merged it later) 04:44:02 Rossen describes weird overflow columns cases 04:44:44 (history lesson) 04:44:58 (merged vs split axis versions) 04:45:22 jdaggett has joined #css 04:45:24 jet: Feedback from mats isn't that A is better than B, but that current version is written to get to CR 04:45:38 jet: and some normative text was lost there 04:45:42 scribenick: tantek 04:45:50 fantasai: we didn't lose any normative text 04:46:02 ... there were some changes to simplify things, like changing how overflow was handled 04:46:10 ... changing one case to see what implementations picked up on 04:46:18 ... we didn't lose any interesting aspects of subgrid 04:46:29 ... the main thing that was dropped was ... 04:46:49 ... the thing that was confusing was a subgrid that had more rows & columns than the # of rows or columns it spanned in the parent grid 04:46:56 ... I don't consider that to be significant feature 04:47:04 ... in terms of significant use-cases 04:47:20 ... it was more like we need to deal with this case so we defined something 04:47:23 ... and people were like this is scary 04:47:32 ... (flippy window use-case) 04:48:13 fantasai: we didn't lose anything except independent axis subgridding (that was significant) 04:48:28 TomoyaKIMURA has joined #css 04:48:28 Rossen: if we look at the current version that is in the draft, it snaps to areas of the parent grid 04:48:28 [A: split axis; B: current version] 04:48:40 ... it does not affect any of the area of the columns or rows 04:48:45 ... it acts as a grouping mechanism 04:49:00 ... in a sense you can draw a paralell between subgrid and non-BFC blocks in a block layout 04:49:06 ... they are there to just group things nicely 04:49:18 ... like document layout defines paragraphs, and divs can put borders around them 04:49:26 fantasai: it doesn't establish a new grid formatting context 04:49:38 ... it continues with the old [it's parents] grid formatting context 04:49:46 Rossen: I took a look at scenarios in the office 04:49:50 smfr has joined #css 04:50:04 ... at some point this is something that has to be done by every engine 04:50:10 ... measuring the sizes of things inside 04:50:15 ... arranging things, align things 04:50:21 ... (stages) 04:50:27 Rossen: if we take those stages 04:50:32 ... how does subgrid affect measuring? 04:50:39 ... if we assume all rows and columns are auto 04:50:42 ... they have to snap to content 04:50:51 ... Extreme case: one subridg, no items, but has border 04:51:14 ... I'm trying to highlight the fact that subgrid contributes to measuring rows and columns by its MBP 04:51:21 https://www.w3.org/TR/2017/CR-css-grid-1-20170209/#subgrids defined in item c 04:51:41 ... the width height min-width max-width and other sizing related properties are forfeit because it snaps / stretches to the areas of the grid that were defined 04:52:05 ... however if everything was empty and the parent grid was auto, then it will be the size of the subgrid's borderbox 04:52:11 fantasai: then what's not perfect 04:52:15 ... if it's perfect we publish it 04:52:26 Rossen: first we have to define min & max widths are not applied 04:52:32 ... currently spec only talks about height and width 04:52:36 ... the other thing that is not covered is overlow 04:52:42 s/overlow/overflow 04:52:46 fantasai: that's specified item h 04:52:55 ... width and max-width etc. are item f 04:53:07 ... any specified width and height constraints 04:53:13 TabAtkins: that includes min and max 04:53:17 Rossen: and there are no gaps 04:53:34 Florian: the overflow is defined as you may do it so... 04:53:42 TabAtkins: but it is defined in terms of layout effects 04:54:00 ... it is still well defined how it and the parent grid get laid out accordingly 04:54:04 Rossen: do we honor position relative? 04:54:10 fantasai: i don't see why not 04:54:15 Rossen: can that be a container ... 04:54:19 fantasai: yeah 04:54:24 Rossen: what about position absolute 04:54:35 fantasai: then it is no longer a subgrid, it is a grid 04:54:44 TabAtkins: it is no longer participating in the grid's layout 04:54:57 fantasai: if it is not iself a grid item then it becomes a grid 04:55:01 s/iself/itself 04:55:14 many: it's still not a grid item 04:55:33 Rossen: so then, when we go to auto flow all the grid items as well as the items of the subgrid 04:55:39 ... what order are we taking? 04:55:44 ... my assumption is depth first search 04:55:52 fantasai: auto placement happens inside subgrid 04:56:08 ... the subgrid has an explicit position by its start end and grid-position properties 04:56:21 ... before you even look at its contents you know how many grid areas it takes up 04:56:28 Rossen: that's not what i was asking 04:56:36 ... now that we have positioned the subgrid 04:56:46 ... then we position the items of the grid 04:56:51 TabAtkins: no the subgrid items 04:56:53 Rossen: hold on 04:57:16 ... let's say that I have in the parent grid G, I1, SG has I2 and I3 04:57:40 ... so let's say I1 is placed at 2,2 where it overlaps the subgrid 04:57:55 ... so now I'm doing auto placement of items 04:58:03 ... I've come in here, processed everything else 04:58:10 ... then the first item outside the subgrid has to be place 04:58:23 fantasai: the subgrid is taking up that spot, so you can't place it there with auto 04:58:35 TabAtkins: the subgrid is also a grid item so it takes up space like any item 04:58:44 Rossen: why not do depth first? so we can auto place? 04:59:02 fantasai: a lot of the time you want to place stuff inside the subgrid, then auto place others 04:59:13 TabAtkins: subgrid sometimes because you want a border around that area 04:59:23 ... you are yourself an indpeendent chunk of content 04:59:37 fantasai: you have to treat the subgrid as a nested grid 04:59:53 Rossen: we could consider placing the subgrid more transparent 04:59:57 ... and place other items 05:00:19 (unparseable from Rossen) 05:00:26 fantasai: it should behave like a nested grid 05:00:40 ... the only difference is instead of an explicit set of lines, you are aligning to the lines of the parent grid 05:00:52 ... they want alignment but they want that subgrid item to be an atomic thing 05:00:56 Rossen: I can live with either of those 05:01:09 TabAtkins: subgrid is just a nested grid, and ... 05:01:17 Florian: you placed your block analogy too far 05:01:34 TabAtkins: another interestin question, your subgrid has auto-placed items, your parent grid places an item on top of the subgrid, what happens? 05:01:46 Rossen: what I heard is that you can place two grid items on the same area 05:02:07 TabAtkins: even if the parent grid places an item explicitly, you can still auto place the subgrid on top of it 05:02:16 Rossen: so, writing modes 05:02:34 .. if this was a LtR grid and the grid inside here says RtL that should just work 05:02:43 ... for vertical / orthogonal changes, where the subgrid changes 05:02:52 ... so let's say the subgrid was not square, like 2x3 05:03:08 ... if I change the subgrid so that it is orthogonal to the parent, what happens 05:03:14 fantasai: we need to add that 05:03:25 Rossen: in other words i would be surprised that in tables we do that 05:03:31 ... so that to me is the same 05:03:31 ACTION fantasai clarify that subgrids with orthogonal flows have rows and column axes flipped within the subgrid 05:03:34 Created ACTION-842 - Clarify that subgrids with orthogonal flows have rows and column axes flipped within the subgrid [on Elika Etemad - due 2017-04-26]. 05:03:50 Rossen: so if I say an item is at 1,2 then it is here and not here 05:03:58 TabAtkins: that always works 05:04:12 ... what is not defined is your horizontal span becomes your row count 05:04:18 fantasai: we can clarify it 05:04:24 Rossen: alignment should work fine 05:04:30 ... what about align-self on the subgrid 05:04:33 fantasai: that's also in item f 05:04:42 ... because we ignore all sizing stuff 05:04:48 ... alignment triggers shrink to fit 05:05:10 Rossen: in terms of drawing, any implications to stacking context? 05:05:16 fantasai: same as a nested grid 05:05:18 Rossen: so none 05:05:24 Rossen: can we allow repeat on a subgrid 05:05:31 fantasai: no because you are taking your rows and columns from the parent 05:05:35 Rossen: do we need to be explicit? 05:05:45 fantasai: we already say ignore grid template properties, that's item a. 05:06:03 (discussion clarification) 05:06:26 Rossen: with all of that, we are happy with how subgrid is specified currently, and I would like to hear from others 05:06:37 rachelandrew: I think mats concern is locking it to both dimension, and I have a concern with that too 05:06:58 ... what I'm seeing people expect what subgrid to do, is columns locked to the grid, and not the rows because they'll be adding content there 05:07:07 TabAtkins: there are use-cases but it makes the algorithm so complicated 05:07:16 fantasai: I don't think we tried (to write it down) 05:07:22 rachelandrew: I think that's what mats was asking for 05:07:27 TabAtkins: I couldn't figure it out 05:07:35 ... the egalia folks were like LOL no we can't do this 05:07:40 ... plus my French co-worker 05:07:47 ... our original grid implementer 05:07:50 ... julien 05:08:01 ... he was also like no 05:08:08 fantasai: we are creating a new FPWD here 05:08:26 ... if it helps I'm happy to take a try at defining a one-axis grid, just so we can see what that looks like 05:08:31 ... if that would make Mozilla happier 05:08:38 ... it might not be as scary once defined 05:08:48 rachelandrew: what I'm hearing is that people expect that subgrid will work that way 05:09:11 Rossen: what is the use-case? 05:09:32 rachelandrew: people are thinking grid like bootstrap 12 column grid 05:09:36 .... and then things on that top level are using that 05:09:58 ... like a bunch of products 05:10:02 ... you know how many columns you want 05:10:12 ... but you don't know how many rows you'll use because that depends on content 05:10:47 rachelandrew: there's also like the BBC home page 05:10:55 Rossen: is it the case where you start with a subgrid 05:11:04 ... I have one item, it goes no problem 05:11:21 ... now I have another item, and then the expectation is that the subgrid will grow? 05:11:33 rachelandrew: yes. people have these layouts that are used for multiple things 05:13:00 (having trouble minuting this without context of the whiteboard diagram) 05:13:03 [fantasai draws a picture] 05:13:48 [6-column master grid on the page; header has several rows of stuff with different interesting spanning stuff; main section has a 2-column wide sidebar and a 4-column wide main section] 05:13:54 tantek: i heard a proposal from fantasai to try to write it down so why are we still arguing? 05:14:06 rachelandrew: this was the issue that mats was pointing to and that he wants discussed, and I would agree 05:14:11 ... I think subgrid is important that we get it 05:14:26 ... if we have it locked to two dimensions it is not what people are expecting subgrid to be 05:14:33 ... when I talk to regular developers 05:14:44 Zakim has left #css 05:14:47 [it's unknown how many rows of auto-placed content is in the main section, but the sidebar has to span it all, so it needs to span 1 in the parent grid and the main section takes the main parent's column divisions, but subdivides into as many rows as needed for auto-placed items] 05:14:50 Rossen: what if I go subgrid ina subgrid 05:15:09 ... if I have a subgrid that takes only the columns, and inside of it I have only one subgrid that takes only rows 05:15:15 subgridception 05:16:51 fantasai and rossen draw and discuss at the whiteboard 05:17:57 fantasai: we have parent grid which is black lines, we have a subgrid (blue lines) which cares about columns but not rows, it spans 3 columns, it makes its own rows 05:18:03 ... like four rows for example 05:18:10 ... it has some items 05:18:18 ... and then it has a subgrid itself 05:18:41 ... which cares about the rows from its parent, but not columns 05:18:57 ... so it takes the rows from its parent, so it gets two rows, and then it defines its own columns, and it has maybe like a lot of columns 05:19:04 ... so now we have to do the grid sizing 05:19:12 ... the placement is a nested structure 05:19:43 ... so it looks at this one this one this one [points at diagram] 05:20:00 ... but doesn't care about this (two nested subgrid) 05:20:22 ... when it asks the subgrid to figure out how big are you when you are spanning your columns 05:20:31 ... it takes its columns from the parent so it won't resize those 05:20:39 ... but I have four rows so... 05:20:42 jdaggett has joined #css 05:21:03 ... so then I have four rows, one item in this one, two in this one, one item plus a spanning item in here 05:21:06 ... it does row sizing there 05:21:12 ... so when it asks it ... 05:21:44 Florian: when you're doing the green (2 nested deep)... the width dimension is based on its own auto-sizing? 05:21:55 fantasai: in the current spec it has both 05:22:11 fantasai: in the subgridded dimension we honor the width, in the non-subgridded dimension we ignore it 05:22:25 ... you just treat it as a bunch a content 05:22:41 ... in the subgridded dimension we stretch it out to take all of the available grid area 05:23:02 Rossen: let's consider that this here would be another subgrid item 05:23:12 fantasai: so it too aligns 05:23:16 Rossen: and it has two items 05:23:43 (rossen draws another subgrid at same level as 2nd level deep green line subgrid) 05:24:48 Florian: while we are discussing level 2, maybe I just missed a section 05:24:58 ... how often have you found people using spacer gifs 05:25:04 rachelandrew: they're using generated content 05:25:12 ... for backgrounds and borders 05:25:23 ... everyone wants to put backgrounds and borders on empty areas 05:25:37 zcorpan has joined #css 05:25:51 ... also like name every other line so they can place things 05:25:59 ... auto place against 05:26:04 ... set some structure in the naming 05:26:14 fantasai: you basically have different grids 05:27:56 Florian: should we just acknowledge that this is a problem and we don't have a solution yet? 05:28:05 Rossen: we could have the current subgrid published as a WD 05:28:13 ... and then have fantasai add text for how this could work 05:28:25 Rossen: ideally if we have the current version published so we don't lose it 05:28:48 ... because we said we would remove it from level 1 and put it in level 2 05:29:18 Rossen: anyone objecting to publishing the current subgrid? 05:29:44 Github issue: 958 05:29:53 https://github.com/w3c/csswg-drafts/issues/958 05:30:09 Github topic: https://github.com/w3c/csswg-drafts/issues/958 05:30:09 OK, I'll post this discussion to https://github.com/w3c/csswg-drafts/issues/958 05:30:23 images of the discussion https://lists.w3.org/Archives/Public/www-archive/2017Apr/0004.html 05:30:30 tantek: my request is to put an inline issue in the FPWD pointing to the issue of independent axes 05:30:37 Yay images!! :D 05:30:56 Florian: I don't think grid fragmentation has been figured out 05:31:12 fantasai: I think that and flexbox is a huge feature that has not gotten any love 05:31:28 Florian: given limited resources I'm not sure Vivliostyle can work on it unless people are going to look at it 05:31:46 fantasai: I think that issue of fragmentation and grid, needs someone to care about printing, file an issue against the spec 05:31:47 https://github.com/w3c/csswg-drafts/issues/796 is the issue referring to auto placement and named lines 05:31:52 ... I think that... 05:31:55 ... we did in flexbox 05:32:12 ... there is question about how do you distribute space across a fragementation 05:32:13 Chris__L has joined #css 05:32:17 ... it is tricky 05:32:26 ... we shouldn't try unless we are in the process of implementing it 05:32:42 ... it's not that we don't want it, we don't want it in theory, we want it in practice 05:32:48 ... for flexbox the theory aspects are spec'd 05:33:08 ... in terms of distributing space there is a variety of algorithms of more or less complexity 05:33:17 Florian: and I think that description fits with Vivliostyle 05:33:24 ... the difference is that both of these specs are big efforts 05:33:36 ... if we do that will anyone listen? 05:33:40 Rossen: definitely we'll listen 05:33:47 ... take a look at the current strawman we have there 05:34:07 ... it works in a lot of cases fairly well, but not all 05:34:13 ... if you want to take this and start improving on it 05:34:33 TabAtkins: while chrome cannot currently fragment worth crap, as we move things internally to our own Houdini APIs, then we will care 05:34:49 Rossen: I want to go back to the resolution for the FPWD for Grid level 2 05:35:09 Rossen: any objections to publishing FPWD of Grid level 2? 05:35:17 tantek: I gave my requirement of asking for inline issue 05:35:39 Rossen: then let's call that resolved to publish FPWD with the inline issue 05:35:58 RESOLVED: publish FPWD Grid Level 2 with the inline issue pointing to the discussion of independent subgrid axes 05:36:03 ... 05:36:13 fantasai: people want to style this area of nothing 05:36:22 Florian: empty div? 05:36:39 ... we don't have a way to generate oxes 05:36:42 s/oxes/boxes 05:36:51 rachelandrew: it's visual styling, it's a CSS thing 05:37:02 (something events) 05:37:15 TabAtkins: at some point we'll address this more generally 05:37:21 Florian: you mean just use empty divs for now? 05:37:36 TabAtkins: no I'm for pseudolement or an infinite collection of pseudoelements 05:37:44 Florian: also how you solve the consume that space 05:37:58 TabAtkins: the original version from Bert's draft had a way to say this is an empty cell 05:38:25 Florian: in the limited examples I've tried to write, I've found the "consume this cell so nothing goes there" would solve it, but another way would be auto-place, but start here, and not before 05:38:37 fantasai: so position the first one, and auto-place the rest 05:38:53 ... the main thing is we need stylable things in the grid 05:39:07 ... that's a very strong use requirement coming from the authoring community 05:39:18 rachelandrew: it's like question one coming when people look at grid 05:39:32 iank_: so the specific request is styling row 1 col 2 red 05:39:45 rachelandrew: yeah at the moment people are either sticking in an empty div or generated content to style 05:39:52 iank_: this is like page background effects 05:39:59 Rossen: we are wrapping up 05:40:06 ... do we have an issue for this? 05:40:10 fantasai: I think we do 05:40:26 iank_: this is where I say you could use the paint api to polyfill this 05:40:30 https://github.com/w3c/csswg-drafts/issues/499 05:41:27 tantek_ has joined #css 05:41:27 Topic: none 05:42:35 Topic: CSS Fonts 4 05:42:53 Topic: CSS Fonts 3 05:42:57 bobbytung has joined #css 05:43:14 Florian has joined #css 05:43:15 ScribeNick: dino 05:43:21 https://www.w3.org/People/chris/fwf/ 05:43:52 Chris__L: Myles made an interesting font. 05:44:10 Chris__L: for each char, it displays a cross or tick depending if a feature is on or off 05:44:40 Chris__L: it allows you switch high/low level features on and see the output 05:44:53 Chris__L: the link above shows the results of testing 05:45:10 Chris__L: staged at the moment because they are easier to see live 05:45:21 github topic: none 05:45:32 estellevw has joined #css 05:45:37 Chris__L: the amount of greeniness shows how many implementations we have. red is zero greeniness 05:46:08 Chris__L: the one that sticks out is font-variant-east-asian, only Gecko passing 05:46:20 Chris__L: chrome passes the low level test, but the syntax isn't hooked up 05:46:44 eae: we will try to fix this quarter 05:47:06 Chris__L: scroll to the bottom, see the object model. Nobody implements what the spec says, but they do implement stuff from DOM Level 2 05:47:35 SimonSapin: iirc, the conclusion was that we'd copy the interface from DOM 2 into the Fonts spec. 05:47:44 SimonSapin: and there was only a few attributes missing 05:47:50 SimonSapin: I'll make a pull request 05:48:14 The OM thing is https://github.com/w3c/csswg-drafts/issues/825 05:48:25 jdaggett: the OM rule is non-functional. to make it work you have to jam things into the style. 05:48:41 jdaggett: you can manipulate unicode range on a style property - this is weird 05:49:15 jdaggett: it is badly defined. we are not speccing out what the implementors are implementing. 05:49:22 Chris__L: what do you suggest? 05:49:29 jdaggett: that implementors follow the spec 05:49:39 jdaggett: we should not spec out whacky behaviour on style rules 05:50:06 myles_: content that already exists, will access the descriptors inside the rule. So we need a .style property 05:50:36 jdaggett: are people actually using this functionality, that's been there since CSS 2. Last time I looked, if you went in and changed the font family, font matching didn't respond correctly. 05:50:41 myles_: works in Safari. 05:50:45 jdaggett: not in Chrome 05:50:51 murakami has joined #css 05:50:53 jdaggett: this is broken in practice. 05:51:06 Chris__L: where do we want to go? 05:51:35 jdaggett: if you're looking to go to REC, then put something in that says it is not defined and push the OM to CSS 4 05:51:56 Chris__L: what you have specced is better, but the implementors don't agree. 05:52:20 astearns: we have to move the OM section from Fonts 3 into Fonts 4. any objection? 05:52:58 SimonSapin: i am fine with moving the attributes. But the @font-face rule interface exists 05:53:43 astearns: we can copy over what is in CSS 2 to Fonts 3, or we can have a section saying that CSS 2 exists but we are not putting it in the spec 05:53:59 Chris__L: people seemed to push back that DOM Level 2 is ancient 05:54:08 jdaggett: but all the implementations are in the same boat 05:54:35 RESOLVED: Remove CSS OM section from Fonts Level 3 to Fonts Level 4 05:54:40 SimonSapin: just the attributes? 05:55:00 SimonSapin: option - define CSSFontFaceRule, but without any attributes. 05:55:06 myles_: why is that valuable? 05:55:26 SimonSapin: because you want something to show up in the CSSRules. 05:55:58 Florian: is that implemented? pushing it out doesn't mean we don't want it. 05:56:27 SimonSapin: CSSFontFaceRule with a style attribute is implemented. The font spec has one attribute for each descriptor. 05:56:37 SimonSapin: this comes from DOM Level 2 05:57:42 dbaron: if we do this, we should add a note saying that this is actually defined in Fonts 4, but what is currently implemented is defined in DOM Level 2 05:58:03 astearns: objections to amending the resolution to leave CSSFontFaceRule and add a Note 05:58:05 ? 05:58:25 RESOLVED: As above, but leave CSSFontFaceRule with a note explaining the current state 05:58:53 Chris__L: i would like to talk about the @font-feature-rules for alternates. 05:59:04 Chris__L: myles's fonts don't do stylistic alternates. 05:59:21 myles_: i have now included all of the font features that don't require a numerical argument to turn on 06:00:10 jdaggett: there are some reftests in gecko, testing font variant alternates/position/caps. They have normative fallback behaviour. 06:00:18 jdaggett: they test what you want 06:00:29 Chris__L: does it require a specific testing framework 06:00:47 jdaggett: they are probably Gecko reftests. You'll need to convert them. 06:01:00 Chris__L: any volunteers to convert them to Web Platform Tests 06:01:01 ? 06:01:13 dbaron: 06:01:39 ACTION: Chris__L to port Gecko font variant tests into WPT 06:01:39 Error finding 'Chris__L'. You can review and register nicknames at . 06:01:41 myles, jdaggett, how can I update Fonts.html after editing Fonts.src.html? 06:01:47 ACTION: ChrisL to port Gecko font variant tests into WPT 06:01:48 Created ACTION-843 - Port gecko font variant tests into wpt [on Chris Lilley - due 2017-04-26]. 06:02:11 Florian: a while back we discovered that Ahem didn't work great for testing on high-res screens? 06:02:17 Florian: can we fix this? 06:02:21 myles_: not easily 06:03:00 myles_: use the CSS property to turn off font fringing. Or size your box correctly. 06:03:23 Florian: i think i tried that. You can't get the standard 100x100 green box with Ahem. 06:03:43 myles_: renderers treat text very differently. you can't get pixel perfect. 06:04:13 TabAtkins: so what do we do? that's the idea of using Ahem 06:04:35 dbaron: it's worth digging in to a bit. 06:04:50 Florian: 06:05:13 https://lists.w3.org/Archives/Public/public-css-testsuite/2017Feb/0001.html 06:05:43 astearns: this test will be investigated 06:06:01 astearns: next up in min/max font size 06:06:47 fantasai: the min and max font-size props were added in Level 4. we need to decide how they impact font-relative units. 06:07:29 dbaron: they affect the computed value of font size, so they affect em units. therefore, em units on these properties work just like em units on font-size 06:08:03 ... and thus use the parent's computed font size 06:08:45 myles_: i agree with everything after "therefore", and asked if there was precedent to have the computed value of a property depend on the specified value of another property 06:09:12 fantasai: the 'display' property has this issue. depends on its parent's 'display' and its 'float' and 'position' values 06:09:14 github-bot- has joined #css 06:09:15 myles_: i agree then 06:09:25 astearns: does it need to be added to the draft? 06:09:27 fantasai: yes 06:10:01 RESOLVED: dbaron's explanation above will go into the spec for min/max font size. 06:10:17 ACTION: Myles to put this into the min/max section of the spec 06:10:17 Created ACTION-844 - Put this into the min/max section of the spec [on Myles Maxfield - due 2017-04-26]. 06:11:19 myles_: CSS fonts 4 includes font variations, font display scriptor, min/max font size properties, and color font support for palettes, and text style v emoji style 06:11:40 rrsagent, here 06:11:40 See http://www.w3.org/2017/04/19-css-irc#T06-11-40 06:11:42 myles_: this is a lot of work, and pretty close to what the final collection of work will be 06:11:51 myles_: we should go to First Public Working Draft? 06:11:56 astearns: objections? 06:11:58 06:11:59 +1 06:12:07 +10 actually 06:12:18 RESOLVED: First Public Working Draft of Fonts level 4 will be published. Chris to handle the request. 06:12:35 astearns: Font Load Events 06:13:05 jdaggett: I put that on the agenda. The spec was tweaked on Monday. There was a Last Call WD in 2014, nothing since. We have three implmementations. We should go ahead? 06:13:09 fantasai: any open issues? 06:13:12 jdaggett: unknown 06:13:15 dbaron: any tests? 06:13:28 TabAtkins: I have some issues. Minor. I just need to do them. 06:13:42 jdaggett: Gecko have tests. 06:13:48 myles_: WebKit has tests too 06:14:09 astearns: are the WebKit tests being submitted to WPT? 06:14:11 myles_: no. 06:14:30 astearns: it seems font loading can be on our list of things to push to CR 06:14:43 astearns: I will follow up on tests and closing issues and so on. 06:15:01 myles_: Font Language Override 06:15:24 Chris__L: Jonathan ?? wanted it on 06:15:30 s/??/Kew/ 06:15:54 dbaron: font-language-override was specced as only a property, but other things were also a descriptor. Gecko has implemented it as both. 06:16:35 dbaron: the argument is that it should be a descriptor 06:16:36 Chris__L: this makes sense to me 06:16:44 Chris__L: 06:16:54 Chris__L: 06:17:22 Chris__L: font stylistic sets are font-specific, so we have them on @font-face 06:17:39 Chris__L: font-language-override can also be font-specific, so should also be on @font-face 06:17:39 myles_: in WebKit, we distinguish between fast and complex text paths. We need to determine with path to take before working out which elements in the fallback to use. 06:18:17 myles_: this means they are slightly problematic. there are already some descriptors that cause this issue. I'm a bit hesitant at adding more. 06:18:35 Chris__L: but you're not arguing that the others should be taken out? 06:18:35 myles_: no 06:18:42 fantasai: but you'll have to fix the others? 06:18:47 myles_: i doubt we ever will 06:20:00 dbaron: John Hudson's example was of writing Macedonian, and this font has Macedonian, so I'll use that, but htis other font doesn't, but the Serbian is close enough, so I'll use that 06:20:00 [people talking in Macedonian] 06:20:18 Florian: would that make sense for CJK fonts, where you want to pick particular bits? 06:20:34 https://drafts.csswg.org/css-fonts/#font-language-override-prop 06:20:37 jdaggett: this is when you want to override the system language system for features, such as shaping 06:21:14 Chris__L: this example shows what we are talking about 06:21:29 override the OpenType language implied by the language attribute of the document 06:21:59 astearns: it seems that a property is going to be used much more often than a descriptor 06:22:27 astearns: Fonts 3 currently only has a property. Gecko does descriptor as well. 06:22:41 astearns: Florian proposes putting it into level 4 06:22:52 Chris__L: we could put both property and descriptor into level 4 06:23:03 dbaron: does anyone else implement font language override? 06:23:12 06:23:35 astearns: I'm inclined to leave the property where it is. add descriptor to level 4. Objections? 06:23:37 06:23:57 RESOLVED: Add a font language override descriptor to Fonts Level 4 06:24:12 Chris__L: do you have tests, jdaggett ? 06:24:15 jdaggett: i think so 06:24:48 ACTION: Myles to add font-lang-override descriptor to Fonts Level 4 06:24:48 Created ACTION-845 - Add font-lang-override descriptor to fonts level 4 [on Myles Maxfield - due 2017-04-26]. 06:25:26 ACTION: jdaggett to look for Gecko tests for various font things 06:25:26 Created ACTION-846 - Look for gecko tests for various font things [on John Daggett - due 2017-04-26]. 06:25:33 github-bot-dev has joined #css 06:27:54 15 minute break 06:28:38 Topic: break 06:29:27 github-bot has joined #css 06:30:52 github-bot has joined #css 06:35:01 zcorpan has joined #css 06:44:22 Kitahara has joined #css 06:45:53 bobbytung has joined #css 06:46:51 topic: partial implementations of space-evenly in grid but not flexbox 06:46:52 Hi 06:46:59 ScribeNick: myles 06:47:07 github topic: https://github.com/w3c/csswg-drafts/issues/1167 06:47:22 Guest87 has joined #css 06:47:28 Florian: we need people from blink and WebKit here 06:47:43 Florian: the "alignment" properties apply to all layout modes 06:47:59 Florian: The spec describes how to do this, but browsers don't follow 06:48:04 iank_: are there bugs? 06:48:32 Florian: these browsers support the keywords on flex box but not grid 06:48:53 Florian: you can't use @supports because the browsers do "support" the value 06:49:02 Florian: they shouldn't have shipped it. 06:49:38 myles: we will not un ship it 06:49:48 TabAtkins: it's easy to fix. We will probably fix it 06:49:58 shane: are there issues? 06:50:00 Florian: yes 06:50:27 Florian: you could also just provide a less shitty fallback if you want 06:51:00 myles: We, WebKit, are regretful that we shipped it and want to fix this. 06:51:26 shane: we have an old patch which gets us at least partway there. We can pick it up. 06:51:31 shane: people are responsive. 06:51:44 topic: display 06:51:45 Topic: Finishing with form controls for CSS-display 06:52:19 https://drafts.csswg.org/css-display/#unbox-html 06:52:22 TabAtkins: we all agreed that replaced elements and proper form controls are display none when you set display:contents on them. 06:52:33 TabAtkins: there are some more HTML elements where it's not clear how we should treat them 06:52:39 TabAtkins: ^^^ list 06:53:11 TabAtkins: chrome people have opinions. 06:53:33 TabAtkins: Next up:
and 06:53:44 TabAtkins: they are magical today. They should be display:none. 06:54:09 TabAtkins: our policy is not to make up things without use cases. We are trying to come up with the most reasonable outcome 06:54:29 06:54:44 fantasai: they should do their thing and ignore display:contents 06:54:52 fantasai: no strong opinion 06:55:00 TabAtkins: but display:contents always makes the thing go away 06:55:06 fantasai: but text doesn't go away 06:55:24 tantek: but this isn't like text content 06:55:36 fantasai: but from a CSS author's point of view, it is 06:55:49 fantasai: Jen Simmons raised the issue that
turns into a grid item and this is bad 06:55:57 +1 on TabAtkins proposal 06:56:10 fantasai: people don't think of
as an element 06:56:52 TabAtkins: its easy to run into trouble if you put raw text into a flexbox. So we tell authors to put wrappers around their text 06:56:55 tantek: agreed. 06:57:23 Florian: from an implementation point of view, do
s have magic which is easy to make go away, or is it difficult to make it display:none 06:57:30 (That is, Tab was saying you run into the same problem with bold text if you haven't used a wrapper. 06:57:33 fantasai: it's easy to implement 06:57:44 astearns: any objections to just doing display:none? 06:57:46 06:57:59 RESOLVED: Making
and not display with display:contents 06:58:02 2! 06:58:07 TabAtkins: the