00:30:26 tommyjtl has joined #css 00:47:49 ojan has joined #css 01:09:41 florian has joined #css 01:16:47 tantek has joined #css 01:17:58 Greetings from outside 48 01:18:48 Inside now 01:20:38 florian has joined #css 01:36:01 florian has joined #css 01:36:14 tantek has joined #css 02:06:14 florian has joined #css 02:50:04 florian has joined #css 03:09:06 tommyjtl has joined #css 03:09:22 Florian_ has joined #css 03:15:04 tantek has joined #css 03:53:11 plinss: could http://dev.w3.org/csswg/ be 301 redirects to https://drafts.csswg.org/ instead of a proxy? 03:53:21 also, could http://drafts.csswg.org/ have HSTS? 03:54:17 SimonSapin: it’s possible to set up, but it’s better to keep the drafts in the w3.org URL space for persistence 03:54:43 the next option is to get css.w3.org … (which may be possible soon) 03:55:36 I can add HSTS but I need to be sure the dev.w3.org proxy is using https first 03:55:37 apparently it’s hard to have HTTPS on dev.w3.org 03:57:05 yeah, the TAG has been discussing the issues with moving all of w3.org to https, too many existing links. But maybe we can get dev.w3.org moved 03:59:13 Quoting: I'd rather we just quit using dev.w3.org altogether 04:18:21 tommyjtl has joined #css 04:25:07 Wait why is it a problem? 04:25:26 Is it not possible to have http://dev.w3.org/ redirect to https://dev.w3.org? 04:28:09 yes, it can redirect, the problem is the millions of existing links to http://*.w3.org that will never get updated and will double the number of http roundtrips 04:28:25 for just dev.w3.org it shouldn’t be as big of a deal as all of w3.org 04:28:53 (if found out the other day the dev.w3.org/csswg is half the traffic of dev.w3.org) 04:29:04 s/if/I/ 04:32:57 with existing documents people would get stuck in redirect loops 04:33:02 (it's been tried too) 04:33:54 I also remember something about the hardware that runs dev.w3.org being old and dying, but I don’t see why it couldn’t be replaced 04:33:57 we could have an outgoing apache filter that replaced https with https in static files but not in js so easily 04:34:07 SimonSapin, given grants from Members, yes 04:34:25 iirc the current hardware was supplied by HP in fact, although i might be a generation behind 04:35:12 (or non-Members i suppose!) 04:36:35 if it’s really a money question, I’d consider giving 10$ a month out of pocket for a Linode box 04:36:56 no, not only $ 04:37:14 although that's kind of you :) 04:37:47 csswg.org runs out of a linode box 04:38:19 (my point was surprise that it would be a money question, given the price of servers these days) 04:39:24 if people link to both equally, does it prefer https or http? 04:39:56 http://googlewebmastercentral.blogspot.com.au/2014/08/https-as-ranking-signal.html 04:40:26 liam: FWIW, HP recently offered to donate a rack full of servers, and was politely refused… they went into the recycling bin 04:40:30 SimonSapin, no, it's not even primarily money 04:40:37 plinss, :( i'd have had them! :) 04:40:58 (I don't know about that, so don't know why) 04:41:21 fantasai, google has a guide on how to migrate from http to https 04:41:41 they say you have to use redirects or you risk getting penalized for duplicate content 04:41:52 but yes, prefer https 04:42:02 (and what they say isn't necessarily the full sotry of course) 04:43:15 the laptop i'm keeping going as long as possible though 04:45:04 timbl did an experiment with an http header recently, the consequence of which is that anyone who read his email ended up getting blocked automatically from w3.org even if they didn't explicitly visit the test page 04:45:23 (unclear if it was because browsers have a shared database, or ebcause of readahead) 04:51:07 heh, I was there. He added an HSTS header to a page, and that page redirected https to http 04:51:42 so every browser that visited the page would only visit the https url for the next year (until the hsts expired) 04:51:50 yes 04:55:07 liam: I think Google should just collapse the links on their own, it's silly not to 04:55:38 liam: Theoretically one could serve different content to each, but it doesn't really make sense unless the http one is a redirect to the https :) 05:04:56 fantasai: http://dev.w3.org/csswg/css-values/#custom-idents what does "positionally-ambiguous" mean compared to just "ambiguous"? 05:10:43 tantek has joined #css 05:17:20 SimonSapin: I think it should say "positionally-variable values" instead of "positionally-ambiguous keywords" 05:17:31 SimonSapin: Does that make sense? Should I make that change? 05:18:00 fantasai: what does that mean? :) 05:18:10 Means if you parse 05:18:16 keyword || 05:18:21 or 05:18:25 keyword && 05:18:35 order is not defined in these cases 05:18:53 ok 05:19:26 Feel free to suggest a better sentence :) 05:20:11 is "positionally-variable" when the order *is* significant? 05:20:25 unlike keyword || or keyword && 05:21:42 or the opposite? 05:22:53 opposite 05:24:31 where the values can vary in their position 05:29:01 Ok. I think what’s in the ED now contradicts what I remembered we discussed. 05:30:47 I think we discussed a lot of things 05:31:06 what do you think it should say? 05:38:53 florian has joined #css 07:24:19 fantasai has joined #css 07:28:47 fantasai, agree re. http/https, and also not sure whether that was the main google crawlaer (i think so) or the adsense one 08:07:22 antonp has joined #css 08:11:07 fantasai has joined #css 08:20:04 antonp has joined #css 08:36:24 fantasai: In the same series: http://www.amazon.com/gp/aw/d/B002RI9VFI/ 08:50:16 dauwhe has joined #css 10:01:54 florian has joined #css 10:08:23 florian has joined #css 10:09:51 Florian_ has joined #css 10:17:34 florian has joined #css 10:27:35 Florian_ has joined #css 10:33:03 Florian_ has joined #css 11:13:24 Florian_ has joined #css 11:21:58 Florian_ has joined #css 11:27:12 Florian_ has joined #css 11:35:24 florian has joined #css 11:52:07 Florian_ has joined #css 12:18:22 Florian_ has joined #css 12:29:45 tantek has joined #css 12:43:59 zcorpan has joined #css 12:44:35 hello sydney 13:28:07 dael has joined #css 14:42:36 Ms2ger has joined #css 15:06:56 antonp1 has joined #css 21:33:06 RRSAgent has joined #css 21:33:06 logging to http://www.w3.org/2015/02/08-css-irc 21:33:14 johanneswilm has joined #css 21:33:39 rrsagent, this meeting spans midnight 21:33:52 RRSAgent, make logs public 21:44:38 cyril has joined #css 21:44:52 dino has joined #css 21:45:36 xidorn has joined #css 21:49:55 heycam has joined #css 21:52:17 krit: you’re cheating ; I saw you have a bkfast at the bar downstairs :-) 21:59:38 dbaron has joined #css 22:02:05 kwkbtr has joined #css 22:03:43 zcorpan has joined #css 22:16:21 glazou, if there is space on the agenda today or tomorrow can we talk about the Font Loading API spec (status, discuss the current spec open issues)? 22:16:42 heycam: could you please add it to the agenda on the wiki? 22:17:24 Florian has joined #css 22:18:04 dauwhe has joined #css 22:18:12 glazou, oh, I can log into the wiki. ok :) 22:33:33 cyril has joined #css 22:34:16 tantek has joined #css 22:38:09 jet has joined #css 22:38:14 gregwhitworth has joined #css 22:38:17 Steve Zilles, Adobe 22:38:23 Alan Stearns, Adobe 22:38:40 Greg Whitworth, Microsoft 22:38:55 Cyril Concolato, Telecom ParisTech, Observer 22:38:57 johanneswilm has joined #css 22:39:01 SteveZ has joined #css 22:39:02 Shinyu Murakami, Vivliostyle 22:39:06 Steve Zilles 22:39:06 Simon Pieters, Opera Software 22:39:08 Dave Cramer, Hachette Livre, interested in books 22:39:26 AndreyR has joined #css 22:39:34 Dean Jackson, Apple 22:39:37 Florian Rivoal, Invited Expert 22:39:39 Daniel Glazman, Disruptive Innovations, co-chair 22:39:42 Andrey Rybka Bloomberg 22:39:50 David Baron, Mozilla 22:39:51 Dirk Schulze, Adobe 22:39:52 Johannes Wilm 22:39:55 Tantek Çelik, Mozilla 22:39:55 Toru Kawakubo, Vivliostyle 22:39:57 Jet Villegas, Mozilla 22:40:06 fantasai, Invited Expert 22:40:06 Tab Atkins, Google 22:40:06 Rossen Atanassov, Microsoft 22:40:08 Peter Linss, HP, co-chair 22:40:09 Toru Kawakubo, Vivliostyle 22:40:19 Cameron McCormack, Mozilla 22:40:19 Xidorn Quan, Mozilla 22:40:26 Brian Birtles, Mozilla 22:40:31 Rick Byers, Google 22:40:33 roc has joined #css 22:40:47 Robert O'Callahan, Mozilla 22:40:59 murakami has joined #css 22:41:15 scribenick: tantek 22:41:16 https://wiki.csswg.org/planning/sydney-2015#proposed-agenda-topics 22:41:36 Ian Kilpatrick, Google 22:41:49 glazou: first thing is figuring out the agenda for MT 22:41:57 W is for the FX task force 22:42:27 glazou: W is for the FX task force 22:42:35 glazou: I suggest we sort by priority 22:43:06 Dirk: what is closest to CR? 22:43:09 glazou: CSS3-UI? 22:43:16 dbaron: transitions 22:43:51 tantek: suggest prioritize things that require in-person diagrams 22:43:58 florian: maybe CSS inline 22:44:12 vollick_ has joined #css 22:44:38 dauwhe: can we do that Tuesday? 22:44:58 glazou: there were people that wanted to discuss rounded display 22:45:10 glazou: watchfaces 22:45:51 tantek: CSS3-UI box-sizing intrinsic size would be good to discuss with SVG folks on Wednesday 22:46:06 glazou: CSS3 Text and Writing modes this afternoon (Monday) 22:46:18 florian: block ellipsis and fragmentation links? 22:46:45 tantek: ok with CSS3-UI tomorrow (Tuesday) 22:46:51 fantasai: dbaron had some 2.1 issues 22:47:04 fantasai, which issues? The margin-collapsing one I haven't even sent email about yet? 22:47:12 glazou: heycam you had font-loading issues 22:47:28 heycam: wanted to ask the questions, updates, 20 min this morning on font-loading 22:47:46 glazou: 2.1, snapshot, 2.2 first public WD 22:47:56 fantasai: 2.1 technical issues and snapshot are separate topics 22:48:23 florian: media queries? not sure my priority 22:48:29 s/snapshot/2.1+2.2+snapshot/ 22:48:29 TabAtkins: yeah 22:48:47 s/not sure my/not super high/ 22:48:51 glazou: TabAtkins you wanted to discuss ... 22:48:57 TabAtkins: I need 30-45 min on ... 22:49:13 glazou: Tuesday morning for @extend (?) 22:49:20 s/.../@extend 22:50:05 florian: multiline block ellipsis 22:50:13 florian: preferably not this morning 22:50:49 glazou: form styling controls - tomorrow afternoon 22:51:12 glazou: something for RoC 22:51:20 glazou: :for() for this morning 22:51:24 FYI, other FX topics have been gathered by the SVG WG here: https://www.w3.org/Graphics/SVG/WG/wiki/F2F/Sydney_2015/Agenda_proposals 22:51:32 glazou: prev-sibling and parent combinators also this morning 22:51:44 fantasai: ::marker pseudo-element 15 min 22:51:57 glazou: dbaron margin-collapsing part of 2.1 22:52:08 glazou: tab order display switch 22:52:18 astearns: I did that, does not really need discussion 22:52:45 glazou: flex-break topics? 22:53:00 astearns: tab order put it on overflow 22:53:07 plinss: 2.1 issues ? 22:53:19 fantasai: 2.1 issues let's do that this morning 22:53:21 tantek: agreed 22:53:40 florian: text-wrap balance ? 22:54:05 fantasai: css3 text level 4? 30 min? 22:54:13 fantasai: when doesn't matter 22:54:38 glazou: let's do that today 22:54:47 glazou: what is the agenda so far? 22:56:22 (lots of quiet typing) 22:57:05 fantasai: visible control characters falls under text 22:57:12 fantasai: margin-collapsing is part of 2.1 issues 22:57:40 astearns: flex-break controls could be part of text 4 discussion 22:58:16 fantasai: text-wrap balance should also be part of text level 4 22:58:29 Zakim, who is here? 22:58:29 sorry, tantek, I don't know what conference this is 22:58:31 On IRC I see vollick_, murakami, roc, AndreyR, SteveZ, johanneswilm, gregwhitworth, jet, tantek, cyril, dauwhe, Florian, zcorpan, kwkbtr, dbaron, heycam, xidorn, dino, RRSAgent, 22:58:31 ... Zakim, glazou, dwim1, hgl, antonp1, fantasai, ojan, krijnhoetmer, Rossen, shane, rbyers, dstockwell, krit, mvujovic______, ppk___, CSSWG_LogBot, liam, Rossen_, mihnea_____, 22:58:35 ... amtiskaw, iank, abucur___, birtles, robertknight_clo, ato, renoirb, koji, cabanier, astearns, sgalineau, slightlyoff, hober, shepazu, logbot, JonathanNeal_, timeless, jumland, 22:58:35 ... nikos 22:58:42 fantasai: css 2.2 should go with the snapshot 22:58:55 florian: can we put form controls in the overflow 22:59:34 tantek: form controls Tue PM? 22:59:55 plinss: css-sizing? 23:00:34 tantek: put it overflow 23:00:42 Rossen: put sizing Monday afternoon 23:00:55 plinss: Ruby? 23:01:39 glazou: upcoming meetings end of Tue afternoon 23:01:50 glazou: new publication system before that 23:02:32 plinss: visible control characters? 23:03:02 gregwhitworth: visible control characters part of text 23:03:20 plinss: we have an agenda? 23:03:25 glazou: how much time for 2.1 issues 23:03:28 Rossen: 11 years 23:03:37 … give or take 23:04:00 (display futzing) 23:04:45 glazou: first topic, 2.1 issues 23:04:55 fantasai: first issue, who will make the edits? 23:05:03 TabAtkins: it's in github now so anyone can do it 23:05:11 fantasai: I nominate SimonSapin 23:05:28 glazou: that's it? 23:05:37 dbaron: I had an issue I meant to send email about 23:05:42 … just sent 30 seconds ago 23:05:55 dbaron: I don't know if anyone would have understood it anyway 23:06:00 … since it is margin collapsing 23:06:08 glazou: do we need to call Håkon? 23:06:11 https://lists.w3.org/Archives/Public/www-style/2015Feb/0189.html 23:06:13 dbaron: let's try to talk about this 23:06:22 s/Håkon/Anton/ 23:06:26 … one of the discussions about margin collapsing 23:06:39 … we decided the prose in the spec was not very clear about transitivity 23:06:54 … e.g. if A collapse with B, and B collapse C, then A collapse with C 23:07:01 … if that's not true we need to define what it means 23:07:09 ???: what makes you think it is not true? 23:07:22 dbaron: this guy writing reftest for margin collapsing daniels 23:07:23 hyojin has joined #css 23:07:26 … does not believe this is true 23:07:34 … and a bunch of his tests match browser behavior 23:07:39 … I was trying to fix a bug 23:07:55 … that said min-height and max-height do not break margin-collapsing between the last child of a block and the ... 23:08:28 … min-height and max-height, even when they change the height, do not break margin-collapsing between the bottom margin of the last child of the block, and the bottom margin of the block 23:08:36 … I wrote a patch that fixed that 23:08:44 … it fixed those tests, but broke one other test 23:08:51 … that was interop in all engines 23:09:01 … however I could not figure out how the spec justifies that result 23:09:16 … What I'd like to know is, why does this test behave the way it does? 23:09:20 … either in engines or in the spec 23:09:22 https://lists.w3.org/Archives/Public/www-style/2015Feb/0189.html 23:09:39 https://lists.w3.org/Archives/Public/www-style/2015Feb/att-0189/block-no-content-8.html 23:09:39 … test: https://lists.w3.org/Archives/Public/www-style/2015Feb/att-0189/block-no-content-8.html 23:09:50 … reference: https://lists.w3.org/Archives/Public/www-style/2015Feb/att-0189/block-no-content-8-ref.html 23:10:04 dbaron: key question is gap between 2 and 3rd block 23:10:16 … 60 px between blocks 1,2 23:10:23 … 40 px between blocks 2, 3 23:10:33 … my patch makes it 60 px between blocks 2, 3 23:10:43 … but spec appears to say it should be -20px between blocks 2,3 23:11:07 … every margin in the test should collaps 23:11:15 s/collaps/collapse 23:11:34 dbaron: the interesting question is what happens between the green blocks 23:11:55 … blue has a min-height and a child 23:12:12 … spec says if it did not have a child, it's top / bottom margins would not collapse 23:12:28 … if you have a non-zero min-height and no children then margins do not collapse 23:12:49 … but in this case we have a block with min-height with a child 23:12:55 … all have top/bottom margins 23:13:07 … spec says they should all collapse 23:13:21 TabAtkins: is the confusing line why min-height has an effect with no children? 23:13:35 dbaron: spec's wording is weird, but I think I understand why 23:13:53 fantasai: (reads from 2.1 spec re: margin-collapsing) 23:15:36 dbaron: the thing with the min-height only applies when there's no children 23:15:53 florian: I'm actually confused, what can it mean for the top/bottom margin of the parent to collapse? 23:16:11 dbaron: there's a rule elsewhere that says where the block is when its top & bottom margins collapse 23:16:23 florian: is this useful for a block of non-zero height? 23:16:28 florian: that seems just weird 23:16:50 dbaron: yes. I would go further, not clear any use of top/bottom margins of the same block ever collapsing. but we're stuck with that 23:17:16 florian: to do so when the block has non-zero height is even worse 23:18:40 dbaron: (reads from 2.1 spec re: margin-collapsing) 23:18:45 … (bullet 1, bullet 2) 23:22:00 fantasai: the issue is we did not want to do partial collapsing (re: min-height), and decided to just do the stupid (obvious) thing instead 23:22:18 dbaron: I should do more playing around with this test case to see what happens in other browsers 23:22:43 fantasai: what is the interop on? 23:22:50 dbaron: this test case. 60 px above, 40px below 23:23:00 dbaron: margins 3 & 4 are not collapsing 23:23:17 fantasai: spec should say non-zero min-height means top/bottom margins do not collapse 23:23:31 florian: partial collapsing? 23:23:40 dbaron: I would fine if we modified the rule that ... 23:23:53 dbaron: It would be consistent to modify the 3rd bullet point in the nested list 23:24:00 … to say what it says already 23:24:41 … but add and "and the parent has zero computed min-height, or the bottom margin of the last inflow child does (not) collapse with the top margin of the element" 23:24:41 s/top/bottom 23:25:03 dbaron: 3rd bullet point 23:25:09 … bottom margin of last inflow child 23:25:11 … bottom margin of parent 23:25:14 … no longer collapse 23:25:18 … if the parent has non-zero min-height 23:25:28 … and the bottom margin of the last inflow child collapses with the top margin of the parent 23:26:13 fantasai: (explores another possibility) 23:26:53 fantasai: there's two definitions 23:26:58 … there's a definition for collapsing 23:27:02 … and a definition for adjoining 23:27:21 dbaron: no that sentence below makes adjoining transitive 23:27:59 fantasai: we know what we want to say now 23:28:05 … just need to work on phrasing it 23:28:17 dbaron: I think agreeing on what we want to say should involve more testing of what browsers do 23:28:27 fantasai: whatever it is it is an improvement over what's there 23:28:35 … (in the spec) 23:28:42 glazou: what is the resolution? 23:28:44 fantasai: what dbaron said 23:28:52 dbaron: we should tentatively agree to do that, but do more testing 23:29:19 glazou: what do people think? there were only 3 people discussing 23:29:28 glazou: any objection? 23:29:52 RESOLVED: tentatively do what we agreed, pending more testing 23:30:29 dbaron: I think the edit you fantasai proposed to make is already in the spec, the 3rd bullet. 23:30:36 dbaron: the way this is written is unclear 23:30:43 glazou: we have to move on 23:30:50 glazou: continue working on the issues 23:30:53 … or next topic 23:31:00 … in terms of 2.1 issues, what else? 23:31:16 glazou: dbaron @charset tests? 23:31:17 https://lists.w3.org/Archives/Public/public-css-testsuite/2015Jan/0016.html 23:31:44 dbaron: this was a message from hsivonen 23:31:55 … syntax level 3 changes rules for @charset 23:32:00 … there are tests in 2.1 repository 23:32:06 … that now test incorrect behavior 23:32:11 … we should fix the tests to match level 3 23:32:14 … and errata 2.1 as well 23:32:31 … it seems bad to have tests in the repo that are telling people to behave in a way not compat with level 3 latest spec 23:32:38 glazou: I agree let's fix both 23:32:41 fantasai: yes fix both 23:33:02 ACTION dbaron: propose errata for @charset in 2.1 that brings it into alignment with CSS3 Syntax 23:33:03 Created ACTION-665 - Propose errata for @charset in 2.1 that brings it into alignment with css3 syntax [on David Baron - due 2015-02-15]. 23:33:16 ACTION fantasai: propose errata for margin collapsing issue 23:33:17 Created ACTION-666 - Propose errata for margin collapsing issue [on Elika Etemad - due 2015-02-15]. 23:33:26 glazou: will hsivonen fix the tests? 23:33:29 dbaron: probably? 23:33:36 jet: he has an open question at the bottom 23:33:48 fantasai: basically what we should be doing is errata'ing 2.1 23:33:52 … and fixing the tests 23:33:55 … backporting from 3 to 2 23:34:00 … fixing the ones in 2 23:34:04 … or getting rid of them 23:34:41 glazou: we have versions 23:34:41 fantasai: no we have levels 23:34:41 glazou: anything else on the 2.1 radar? 23:34:42 fantasai: dbaron? 23:34:48 dbaron: just a possible tornado and a few thunderstorms 23:35:02 SimonSapin: we discussed 23:35:07 … links to that spec 23:35:31 florian: so we should switch to snapshot topic 23:35:51 SimonSapin: In CSS 2.x sections, add links to newer specs that replace them 23:35:56 zcorpan: anyone volunteer to edit the tests? 23:35:58 florian: you just did 23:36:03 zcorpan: I did? Ok I can do that 23:36:17 ACTION zcorpan edit CSS 2.1 @charset tests to make them compliant with CSS3 syntax 23:36:17 Created ACTION-667 - Edit css 2.1 @charset tests to make them compliant with css3 syntax [on Simon Pieters - due 2015-02-15]. 23:36:34 Topic: Font Loading API 23:36:37 heycam: test and tasks? 23:36:41 http://dev.w3.org/csswg/css-font-loading/ 23:36:44 … (missed part of question) 23:36:52 TabAtkins: good question 23:37:26 heycam: there are many places in the spec where it says to queeue a task, and does not say why it is necessary, aor what the reuls are for why this operation should be done 23:37:31 s/reuls/rules 23:37:35 s/aor/or 23:37:49 TabAtkins: every time I do something it is observable, so it doesn't happen in the middle of some script 23:38:05 TabAtkins: you can't edit the font-faces attribute at some time because JS might be looking at that 23:38:16 heycam: for operations that are definitely going to wait for the network that makes sense 23:38:22 … but there are uses of that beyond wait for the network 23:38:27 TabAtkins: in the font-face loading algorithm 23:38:36 … we have two uses of delay task until parsing the font-data is done 23:38:48 … or parsing of strings too 23:38:58 heycam: parsing strings is pretty weak(?) 23:39:33 TabAtkins: I purposely moved those into the async section of the algorithm, and from the async section I cannot sync update something that is script visible. 23:39:43 TabAtkins: I have to queue a task 23:39:44 s/weak/quick/ 23:39:45 s/weak(?)/quick/ 23:40:02 heycam: can we discuss open issues in the spec? 23:40:12 heycam: issue 1: is about promise objects and internal set objects 23:40:18 … pristine copies of things 23:40:18 issue 1: http://dev.w3.org/csswg/css-font-loading/#issue-531209c4 23:40:31 heycam: that is not something the webIDL spec says ... 23:40:41 heycam: should happen automatically(?) 23:40:56 heycam: the other three issues I don't have an opinion on so we don't have to discuss them 23:41:16 heycam: another thing - question the usefulness of font-face-set being constructable, why you would want to do it? 23:41:25 TabAtkins: I know I had reasons for it, I think related to workers 23:41:31 TabAtkins: someone internally gave me a use case recently 23:41:43 … stash a bunch of fonts into a font-face-set, tell when they're ready, 23:41:48 … all the fonts loaded at the same time 23:42:00 heycam: could you not do that by creating separate font face objects 23:42:03 … do a promise.all? 23:42:07 TabAtkins: maybe? 23:42:22 … if there's no reason not to make something constructable, there's no reason to make it constructable 23:42:29 heycam: it would complicate my implementation 23:42:37 TabAtkins: so basically I should look for more use-cases for it 23:42:44 zcorpan: queue and task discussion 23:43:04 … if you select one, if it fails to parse, spec says to reject and set status to error 23:43:15 … then step 2, if it fails to parse, it says to queue a task 23:43:21 TabAtkins: because step 2 is async 23:43:31 zcorpan: should step 2 queue a task to reject? 23:43:42 TabAtkins: Rejection isn't observable to script until safe times anyway 23:43:59 zcorpan: what is the ordering between observing the rejection and the queuing … ? 23:44:07 … otherwise you can't read the status... 23:44:13 TabAtkins: this is true I should re-order those 23:44:38 zcorpan: there might be similar ordering issues elsewhere 23:44:38 TabAtkins: no the rest are fine 23:45:11 heycam: are any other implementers interested in this API? 23:45:16 TabAtkins: beyond google and mozilla? 23:45:28 heycam: this is based on an old draft right? 23:45:33 TabAtkins: no I don't think so 23:45:45 … someone recently changed … (?) 23:46:02 … if you know of anything not matching the spec or not matching your implementation, let us know 23:46:05 heycam: that's all I had 23:46:06 TabAtkins: ok 23:46:24 glazou: break. 15 min. no more. 23:46:31 glazou: we'll start again with selectors. 00:05:12 ScribeNick: dbaron 00:05:23 glazou: first topic is :for selector by Florian 00:05:26 https://lists.w3.org/Archives/Public/www-style/2014Dec/0064.html 00:05:29 :for() 00:05:41 Florian: spun out of earlier discussion on :focus-within 00:05:51 johanneswilm has joined #css 00:06:02 Florian: when writing form controls in HTML, can hav labels associated with inputs, either by putting input inside label, or using for attributeand pointing to id of form element 00:06:14 Florian: there's a bunch of state the form input can be in that you use for styling, e.g., invalid 00:06:31 Florian: demand from authors to also style label that goes with the form, based on these states (focus, active, disabled, invalid, etc.) 00:06:52 Florian: proposal is to have a functional pseudo-class that lets you point "label for this contnorl :disabled" 00:06:57 Florian: then can style label 00:07:17 Florian: last time wasn't clear authors wanted it, went and found requests on stackoverflow for it 00:07:23 fantasai: why can't we just propagate the state to the label? 00:07:32 jdaggett has joined #css 00:07:32 Florian: because that is defined in HTML and Hixie's not interested 00:07:39 fantasai: that's ridiculous 00:08:01 Simon: I don't that's the best reason; another reason is that content today uses the pseudo-classes and expects it to apply only to the inputs and not the lables 00:08:16 Florian: also there's a small but worrying-to-some performance impact 00:08:24 Florian: which makes only the people interested in using this bear this cost 00:08:33 Florian: you can potentially associate a thousand labels with a single form element 00:08:53 fantasai, tantek^: that's a much better reason 00:09:00 Florian: corner case ... 00:09:09 Tantek: otherwise difficult to describe with existing selectors 00:09:21 Florian: people sometimes use hacks to put label after, use + selector, and then float to put label where they want it 00:09:31 Tantek: corrupts the natural order of the marku, which we should seek to avoid 00:09:37 Tantek, glazou: I support this 00:09:50 dbaron: What is the syntax? 00:09:55 dbaron: :for()? 00:10:11 fantasai: don't want an ID 00:10:12 florian: Could do that, or just put an ID 00:10:26 fantasai: You want to style these things generically. 00:10:34 andreyr_ has joined #css 00:10:42 Tantek: doesn't have to be a label? 00:10:48 Florian: for attribute only exists on labels 00:10:55 Tantek: doesn't have to... 00:11:00 PeterL: could define more generically 00:11:10 kwkbtr has joined #css 00:11:22 Florian: The way :for() associates is up to the host language. 00:11:34 fantasai: for HTML, it's the for attribute or containment 00:11:49 Florian: yes, HTML does by nesting or attribute; other languages can do as they want 00:11:55 peterl: we should leave it defined by the host language 00:12:13 peterl: if it's not clear enough for HTML we should say what HTML does, but leave it defined by host language 00:12:41 gregwhitworth: IE already does this, and we've gotten no bugs 00:12:51 s/peterl/plinss 00:13:01 Florian: In IE, :active and :focus propagate from HTML to control. IE does that *and* the other way around. 00:13:13 s/In IE/In HTML spec/ 00:13:25 Florian: we previously resolved the IE way was good, I was actioned to go to Hixie, he disagreed 00:13:58 Florian: :hover and :active (not :focus?) 00:14:24 Florian: I don't think IE does it for :invalid, :disabled, and all the others 00:14:52 glazou: I didn't get an answer to question: :for() pseudo that initially works only in HTML because knowledge of the for atttribute comes from above and will not appear in the UA stylesheet or anywhere. 00:15:15 glazou: Two ways to do that: more generic, or with for attribute mentioned. 00:15:26 glazou: My opinion is for attribute mentioned is better because applies to more languages. 00:15:42 glazou: I want to avoid the mess of the class selector where class was originally defined only for HTML and not other languages. 00:15:54 Florian: Should be at least for attribute in HTML 00:15:57 fantasai: and containment 00:16:15 Florian: Could also extend in HTML where a form control is for its form. 00:16:20 fantasai: or fieldset 00:16:36 fantasai: Initial preference would be to propagate state out to fieldset, label, form 00:16:48 fantasai: If we can't do that b/c of web compat then I'd support other syntax 00:16:53 johanneswilm has joined #css 00:16:57 fantasai: I think :for() syntax is vague and confusing, but in favor of solving problem 00:16:59 glazou: agreed 00:17:07 Florian: I don't think syntax is so ugly, but not married to it. 00:17:21 glazou: :for() seems to me confusing, esp. if generic enough that it could be an attribute other than for 00:17:40 Florian: If you don' tthink of attribute for, but just the English word, "the label for invalid things". 00:17:49 Simon: why are we discussing extending this to fieldset and form as well? 00:18:00 fantasai: You might want to style form / fieldset if any control is invalid 00:18:11 Simon: the research was for labels, not fieldsets and forms 00:18:24 Florian: But styling form that contains something invalid is not science fiction. 00:19:01 Tantek: need for something to change somewhere else -- label is most obvious example. Focus in text input-- label most obvious, but might also have help text that showsup. Having that trigger without JS is helpful; can't do that right now. 00:19:13 Tantek: My concern is that feature is too limited in scope to just handling HTML Label for. 00:19:32 Tantek: Other use cases in forms: help text, hover causing information to show up elsewhere. I don't want to preclude those with narrow definition. 00:19:56 Florian: If we define it to work #1 for for attribute #2 for nesting control in label, fieldset, and then leave room for future extensions maybe through @-rule. 00:20:04 Tantek: Already have selector in :for() 00:20:12 Florian: One part is state, other part is associating element. 00:20:21 Florian: Current proposal relies on association being done already. 00:20:36 Tantek: Don't need association; could just apply to all labels. 00:20:58 fantasai, Florian: You need an association. 00:21:04 Florian: Which label is for the form control. 00:21:23 fantasai: Don't want to make the associated between the label and the input in the CSS file, with separate rules for each form control. 00:21:28 s/ated/ation/ 00:22:02 Florian: There are 2 levels, a mechanism for associating. We currently have a label<->control mechanism. Other is using existing associated to match states and propagate states along existing association. I'm only talking about altter. 00:22:24 Florian: That said, happy to use combinator instead of pseudo, etc. Just functionality I'm after. 00:22:34 Florian: In previous life existing as /for/. 00:22:44 Florian: confused by what other word could go there 00:22:54 fantasai: That wasn't for any attribute; it was for an idref attribute. 00:23:06 Florian, the link from your email for TabAtkins's example is 404: https://www.dropbox.com/s/cyu9je5a6cvolyf/Screenshot%202014-12-03%2023.51.47.png?dl=0 00:23:32 Tantek: let's look at your real-world example 00:24:07 http://www.xanthir.com/recipes/showrecipe.php?id=55 00:24:15 Florian: In Tab's site in the example, he has convoluted markup because he doesn't have this. 00:24:29 Tab: If you click on ingredients they get crossed out, done through CSS; had to do weird things. 00:24:40 Tantek: label around input isn't weird 00:25:00 Tab: I forget what was weird. 00:25:06 Florian: There was something wrong; maybe fixed since? 00:25:39 (multiple conversations) 00:25:49 Florian: I think we can put an action on this to construct a document that would benefit. 00:25:57 Tab: there are tons of examples on stackoverflow 00:26:27 Tab: I don't think there's a need for more discovery. 00:26:39 Tantek: I'm just looking for a sample simple document that would benefit. 00:26:52 glazou: I'd rather see Florian spend time on the technical proposal and us on reviewing and getting feedback. 00:26:53 +1 for technical proposal 00:27:02 glazou: I almost see it as a blocking tactic. 00:27:25 Tantek: It's not a blocking tactic. If we don't have a markup to look up then we don't know if it can be solved with existing selcetors or others that are being proposed. 00:27:44 Florian: Last time I proposed this, it stopped with request to go look up examples. I did. 00:28:16 glazou: Tantek, let's try to find the best design without looking at the markup. 00:28:22 Tantek: ok 00:28:45 fantasai: resolution is we agree we should do something, not convinced about this particular proposal. Maybe come up with something easier to understand? 00:29:00 glazou: Florian was looking for approval to continue working 00:29:14 glazou: I think discussion shows interest from WG. Doesn't say we'd eventually accept poposal. 00:29:31 Tantek: I think can make stronger statement: best proposal we've seen so far. If a better alternative shows up we can debate that later. 00:29:44 glazou: Any objection to Florian spending time spec'ing this? 00:29:48 +1 on more formal proposal 00:29:54 fantasai: This would go in selectors level 4. 00:29:56 fantasai: This would go in selectors level 5. 00:30:06 fantasai: Level 4 needs to be trimmed down and pushed out. 00:30:18 RESOLUTION: Florian to work on :for() or whatever it is. 00:30:38 zcorpan: for :active and :hover, we have 2 behaviors. We have IE going 2 ways and others going 1 way (with HTML spec). 00:30:52 Florian: We previously resolved it should go 2 ways but failed to convince Hixie. 00:31:05 zcorpan: Then the correct next spec is violating the HTML spec in other browsers and then getting the spec changed. 00:31:16 Tantek: Other step is to propose patch to HTML. 00:31:45 Tantek: Could submit that to the HTML Working Group. I could help liaison that. 00:31:57 Tantek: If there's consensus there... 00:32:07 Florian: Does it help in the WHATWG to get HTMLWG to accept it? 00:32:10 Tantek: sometimes 00:32:26 Tantek: If browsers respond to that, Hixie will likely spec it. 00:32:47 Topic: Prev-sibling and parent combinators - allow :has() with some combinators in fast profile? 00:33:01 glazou: Next, previous-sibling and parent combinators - [copy above] 00:33:10 Tab: say you have elements #foo and #bar 00:33:30 Tab: Can already select #bar if it has #foo as previous sibling 00:33:39 Tab: with :has combinator 00:33:44 Tab: #foo ~ #bar 00:33:58 Tab: #foo:has(~#bar) 00:34:19 Tab: if we allow :has can select #foo if bar as a following sibling, though only in fast profile 00:34:50 Tab: Benjamin came up with a fun example, which is that you can write :nth-last-child(2 of #foo, #foo ~ bar), which is equivalent 00:36:20 Tab: (explains how these are equvialent) 00:36:20 Tab: not quite a general previous-sibling combinator; we're back-dooring it in in the fast profile 00:36:45 ScribeNick: fantasai 00:37:15 dbaron: I'm skeptical about moving too quickly here 00:37:20 dbaron: You have one impl that has done this 00:37:40 dbaron: The other thing I'm worried about is I would like the perf characteristics of selectors to be visible to authors when they're using them 00:37:52 dbaron: Some of them look scarier than others, and you want the slow things to look scarier than the fast things. 00:38:20 TabAtkins: :has() with combinator is not available in CSS, only for querySelector 00:38:34 TabAtkins: But you can do the :nth-last-child( of ) today in CSS 00:38:44 dbaron: This is only :has() for siblings, not for descendants 00:38:50 dbaron: Which is the more expensive case 00:39:02 TabAtkins: bzbarsky said looking for a parent shouldn't be too expensive 00:39:11 TabAtkins: Just going to the parent addresses the vast majority of cases 00:39:29 Florian: What is your proposal for this? Allow general syntax, or having special syntax? 00:39:37 TabAtkins: Allowing special-cased things might also be okay 00:39:44 TabAtkins: e.g. :hasChild() 00:39:52 dbaron: If I wanted to implement :has() for selector matching 00:40:04 dbaron: I'd probably want to rewrite it internally to look like the subject indicator 00:40:08 dbaron: Although I'm not sure 00:40:19 dbaron: I don't know if that has too many implications 00:40:36 dbaron: subject indicator is more straightforward 00:40:52 dbaron: doesn't allow branching 00:41:00 TabAtkins: Does in combination in :matches() 00:41:10 dbaron: Lots of new stuff without much impl experience... 00:41:17 TabAtkins: People really want prev sibling and parent 00:41:32 TabAtkins: Arbitrary ancestor is kindof not great, but the other two are not too bad perf-wise 00:41:37 TabAtkins: I think we should llow them 00:41:50 TabAtkins: At least direct previous direct sibling 00:42:29 dbaron: Having some reasonable syntax that allows just parent and sibling doesn't seem too bad 00:42:39 TabAtkins: ... specialized syntax like :hasSibling :hasChild 00:42:51 fantasai: I don't like that, I think we should just say that you have to have a combinator at the beginning of :has() 00:43:18 zcorpan: a < foo 00:43:27 fantasai: Um, no I don't think that's great 00:43:33 TabAtkins: a - foo 00:43:42 TabAtkins: it's got parsing issues, have to require white space. 00:44:58 [discussion of syntax] 00:45:01 astearns: problem with :has is you have to explain which versions of :has() work in a stylesheet and which don't 00:45:06 ScribeNick: dbaron 00:45:14 Florian: ? 00:45:23 fantasai: people will end up chaining to multiple levels of :has-child 00:46:08 Whiteboard says: 00:46:15 #foo:has(~#bar) 00:46:24 :nth-last-child(2 of #foo, #foo~bar) 00:46:39 Florian: we just discovered that this part of :has() is fast enough to be in the fast profile. If we've already allowed :has(), changing which subset sounds... 00:46:42 1) a:has(> foo) a:has(+foo) 00:46:52 2) a:has-child(foo) a:has-next-sibling(foo) 00:46:58 Tab: I doubt there's such subdivisiions. ??? ??? 00:47:06 a:has(>foo>bar) vs a:has-child(foo:has-child(bar)) 00:47:09 Tab: I don't know if we want to first poll to see if we want to allow this, which syntax we prefer 00:47:18 Florian: Do we have hope we'll one day we'll make :has fast enough. 00:47:30 fantasai: Totally possible, just have to do some fancy caching 00:47:32 dbaron: disagree 00:47:47 Florian: if people write uses that don't work and depend that they don't work then we can't activate it anymore 00:48:02 fantasai: as long as you put a combinator in the front then you're in one of the safe cases 00:48:12 Tab: no, you have to require all combinators on restricted list 00:48:22 SimonSapin: do we allow more combinators inside ??? with (2) 00:48:43 Tab: maybe lalow child combinators in :has-child() and sibling combinators in :has-sibling() 00:48:55 Tab: or maybe just disallow nesting of :has-pseudoclasses 00:49:16 Tab: dunno if looking arbitrariryl far distance into ancestorswith terrible selectors is something we want to allow 00:49:33 Florian: for future-compat I'm not in favor of option (1) 00:49:46 fantasai: selectors are agressive about being invalid; throws out entire rule... 00:49:50 fantasai: you'd notice 00:49:59 s/inside ???/inside the parentheses/ 00:50:00 Florian: wouldn't count on that; definitely wouldn't want to make that rule start matching later 00:50:38 Tab: objections to concept still? 00:51:02 dbaron: I want to think about it more 00:51:19 dbaron: There's a lot of stuff with a lot of interesting per fimplications in selectors currently, not much use/testing/impl yet 00:51:32 dbaron: I'm not okay with it yet, I might after thinking about it some more 00:51:52 fantaai: I also think you shoudl get some authors to look into this 00:52:09 fantasai: The syntax proposed looks horrible 00:52:43 Tab: dbaron and bz review for performance characteristics? 00:52:57 Tab: we discussed before, but wasn't seriously proposing it before; now I'm seriously proposing it 00:53:46 ACTION dbaron review performance characteristics of parent and previous-sibling combinator, potentially combinable 00:53:46 Created ACTION-668 - Review performance characteristics of parent and previous-sibling combinator, potentially combinable [on David Baron - due 2015-02-16]. 00:53:47 Agenda+ please :) 00:54:16 glazou: Next item on agenda is ::marker 00:54:36 fantasai: been in lists spec for a while. Don't have concrete lists spec. A lot of issues on positioning; not well nailed down. 00:54:44 fantasai: 2 main use cases for ::marker are changing color and font 00:55:00 fantasai: I think those are reasonable without entire spec, could define in pseudo-elements spec without colors and fonts 00:55:56 fantasai: proposal is add ::marker to pseudo-elements spec, takes properties from color module and fonts module (color, font-*, and opacity) 00:55:59 roc: why not opacity? 00:56:03 s/not // 00:56:08 fantasai: Can just do rgba() 00:56:39 fantasai: color property and font properties 00:56:52 Tantek: people want marker closer, etc. 00:56:58 fantasai: We just want to postpone that. 00:57:07 fantasai: Involves kspeccing the layout details 00:58:12 RESOLVED: Add ::marker with font properties and color to pseudo-elements spec (and still plan to do more later in the lists spec). 00:59:34 dbaron: want to defer transitions, fx day is fine 00:59:40 glazou: text level 4, text-wrap: balance 00:59:55 http://dev.w3.org/csswg/css-text-4/ 01:00:00 fantasai: astearns and I drafted a placeholder for text level 4. We pasted in stuff that was pulled out of level 3. 01:00:11 fantasai: These are all pretty fuzzy. 01:00:32 fantasai: The stuff that's in there is basically splitting whitespace into 2 separate properties: text-space-collapse and text-wrap. 01:00:40 fantasai: and adding a new text-space-trim property 01:01:07 fantasai: features that were deferred are ability to discard whitespace and ability to trim whitespace just inside element, or just before/after element (needed for footnote formatting). 01:01:39 fantasai: a couple issues on last line length that were requested, extra hyphenation controls (hyphenate-limit-{zone,chars,lines,last}) 01:01:43 johanneswilm has joined #css 01:01:53 fantasai: string justification for tables deferred from level 3 01:02:04 fantasai: text-spacing property that deals with East Asian stuff not fully worked out yet 01:02:10 fantasai: and text-wrap property has 2 new values 01:02:16 http://dev.w3.org/csswg/css-text-4/#text-wrap 01:02:27 fantasai: one ofthem proposed is text-wrap: avoid value, which says please don't break me, but if I don't fit on the line, then break 01:02:38 fantasai: allows more controlled breaking with phrase-sensitivity 01:02:47 Florian: example using it on an Address 01:03:01 (rapid conversation) 01:03:20 fantasai: more control than just inside of nowrap; here you can use nesting to provide prioritization) 01:03:29 fantasai: was in level 3, were some issues, maybe w.r.t. inheritance 01:03:47 fantasai: so needs to be pulled into separate property 01:04:02 fantasai: then there's the text-wrap: balance property, which only works onblocks with direct line box descendants 01:04:05 fantasai: and inherits 01:04:09 astearns: whole spec is a diff spec 01:04:40 fantasai: There's stuff here that definitely needs work. Feedback: what to do with it? Suggestions on directions? 01:05:00 Florian: for balance specifically, had comments,but spec now took feedback 01:05:04 Florian: havn't reviewed rest 01:05:12 Florian: this should slowly be worked on 01:05:29 astearns: of all the things in the spec at the moment, text-wrap avoid and balance are the ones developers are calling for most strongly 01:05:51 fantasai: A related issue is dealing with break-inside/break-after. 01:06:11 astearns: one issue with text-wrap: avoid is whether it should be tied in with break-avoid properties which have a few more settings that you can use 01:06:45 astearns: my take is that block breaking and inline breaking should be separately controllable things, because inline breaking almost always has to do with text-wrap, it's not a great thing to graft the same block-avoid/break properties onto inline wrapping 01:06:54 astearns: if anyone has contrary idea, we should discuss 01:07:24 fantasai draws: 01:07:44 text-wrap: avoid vs. break-inside: avoid vs. new property 01:08:16 xidornq has joined #css 01:08:16 inheritance BAD traditionally for block axis 01:08:39 fantasai: I think we can't use text-wrap: avoid because text-wrap inherits 01:08:49 fantasai: so I think it has to be break-inside: avoid or a new property 01:09:05 fantasai: astearns, you're suggesting don't want break-inside:avoid 01:09:14 fantasai: so we need a new property; don't know the name. wrap-inside? 01:09:25 astearns: I'm not sure text-wrap: avoid inheriting is a terrible thing. 01:10:28 fantasai: text-wrap: avoid inheriting means that with ... Yo! ... , means that breaks not inside the em will be preferred over breaks inside the em. 01:10:56 astearns: the example you added relies on inheriting, so in some cases it's good 01:11:14 johanneswilm: so avoid doesn't actually mean avoid, it means ... 01:11:19 fantasai: it means avoid, not forbidden 01:11:32 fantasai: we have that, it's called nowrap 01:11:57 dbaron: my understanding is you want something where nested avoids increase the priority 01:12:04 dbaron: and you can't do that with inheritance 01:12:15 fantasai: you do want nesting to increase the priority 01:12:25 TabAtkins: I can see math structures wanting to do that 01:12:34 dauwhe: would you need to set explicit priorities on various things? 01:12:40 TabAtkins: you just wrap extra wrappers 01:12:43 johanneswilm: couldn't you have numbers on it? 01:12:53 fantasai: then you have the z-index problem with really big numbers 01:13:14 fantasai: and most cases with this sort of wrapping, there's a hierarchical structure, where using avoid takes care of it for you 01:13:26 fantasai: we might need priorities in addition to nesting, but nesting takes care of most cases 01:13:50 johanneswilm: so if I have a span and would prefer no breaks inside of it, but inside the em, I'd prefer the break inside the em, how would I express that? 01:14:21 Tab: could put avoid on spans that are siblings of the em 01:15:30 fantasai: inheritance makes it convenient, says every additional element increases avoidance 01:15:41 fantasai: in simple cases like a headline, don't have any extra markup 01:16:21 fantasai: if you have a footer on a slideshow: date, location, talk title: each individually should stay together, but links inside that shouldn't increase avoidance 01:16:36 astearns: definitely cases where it's convenent to inherit, but might be inconvenient 01:16:58 s/might/not where might/ 01:17:12 fantasai: because most markup corresponds to things that mean things 01:17:21 SteveZ: (something about a URL) 01:17:43 SteveZ: but in that case can also label the URLs as text-wrap: ??? 01:17:58 s/???/normal/ 01:18:42 fantasai: so should either be text-wrap: avoid or a separate property 01:18:56 SteveZ: turning it the other way around, why do I need the other property 01:19:17 fantasai: easier to turn on inheritance than it is to turn it off 01:19:59 dbaron: Weird to inherit 01:20:14 dbaron: MOdel we have is that adding inlines or blocks with no styling is essentially a no-op 01:20:21 dbaron: This breaks that model 01:20:55 astearns: haven't specified that it increases 01:21:02 dbaron: yeah, if there's only one level of avoidance it's not a problem 01:21:33 johanneswilm: say I have a book title with subtitle. I'd prefer whole thing not to be broken, but if it needs to be broken, I'd prefer break between title and subtitle. How would I do that. 01:21:41 fantasai: mark up title and subtitle in separate spans 01:21:57 fantasai: and a span around both 01:22:28 astearns: so should specify priority increases 01:22:44 astearns: and then question of whether that requires text-wrap: avoid at the top, or in 3 places 01:22:53 fantasai: I think dbaron's point important, and requires a separate property. 01:23:02 astearns: text-wrap is a new property -- why can't it just not inherit? 01:23:14 fantasai: wrap value and nowrap value must inherit 01:23:28 fantasai: or we could just stick with white-space, and have text-wrap only controlling avoidance behavior 01:23:54 Florian: {asks question} 01:24:01 fantasai: text-wrap is a longhand of shorthand white-space 01:24:10 fantasai: and 'none' value should have been 'nowrap' 01:24:47 http://dev.w3.org/csswg/css-text-4/#white-space-property 01:24:57 zcorpan: fails for me too 01:25:02 astearns: there's handwaving about the shorthand in the intro section; I'd be happy not making shorthand 01:25:05 zcorpan: seems down for me too 01:25:19 gregwhitworth has joined #css 01:25:38 zcorpan, tantek: ERROR 503: Service Temporarily Unavailable 01:25:49 drafts.csswg.org seems to be down, peterl? 01:26:05 fantasai: You don't want to define one property that always overrides another 01:26:25 SteveZ: dbaron's principle requires that nowrap inherit and requires that avoid not inherit 01:26:30 fantasai: I think we need a sepraate property for avoid 01:26:37 seems up now, though 01:27:45 SteveZ: part of problem is that we can't use avoid-break in -- two breaks that could avoid, blocks or lines, and don't know which is intended. 01:28:03 SteveZ: With the fragmenting spec, we've been trying to get generic terminology that applies, and here that doesn't quite work. 01:28:18 SteveZ: I wonder if there are other places where there are multiple possible fragmentations at the same time. 01:28:22 fantasai: yes, flexbox has lines 01:28:31 fantasai: we could use same properties for flex lines as for text 01:28:42 SteveZ: introduce a new property that had more than one use? 01:28:47 fantasai: wrap-inside wrap-before wrap-after? 01:29:02 dauwhe: that sounds almost useful to me 01:29:23 fantasai: works for me 01:29:26 astearns: try fleshing it out? 01:29:37 fantasai: we'll take an action to update spec 01:30:14 ACTION fantasai and astearns to try fleshing out spec for wrap-inside wrap-before wrap-after in css-text-4 01:30:15 Created ACTION-669 - And astearns to try fleshing out spec for wrap-inside wrap-before wrap-after in css-text-4 [on Elika Etemad - due 2015-02-16]. 01:30:28 fantasai: Topic: white-space 01:30:56 fantasai: white-space: normal | nowrap | pre | pre-line 01:31:09 fantasai: |-- text-wrap: nowrap | normal 01:31:32 fantasai: |-- text-space-collapse: collapse | discard | preserve | preserve-breaks 01:32:16 fantasai: text-space-trim: none | trim-inner || consume-after || consume-before 01:32:30 fantasai: white-space controls two different things, collapsing and whether text is allowed to wrap 01:32:45 fantasai: we split this into 2 diferent properties 01:32:50 fantasai adds balance to text-wrap 01:33:00 fantasai: discard is new value, throws out all whitespace 01:33:17 fantasai: preserve is pre, preserve-breaks is pre-line 01:33:30 fantasai: the 2 new subproperties inherit since white-space inherits 01:33:47 fantasai: text-space-trim needs to not inherit, so pulled into separate property 01:33:50 fantasai: was in level 3 01:34:15 fantasai: trim-inner gets rid of space that's just inside the beginning and end of the element 01:34:47 roc has joined #css 01:35:19 fantasai: consume-after ... pulling a footnote out, don't want to format source code so markup is right up against last letter, but want the footnote marker to have no space before it. 01:35:38 fantasai: or if you format it with parentheses, you want the space before the opening parenthesis 01:36:03 s/consume-after/consume-before/ 01:36:36 fantasai: That's the set of whitespace stuff pulled in from old level 3 ideas. What do you all think? 01:36:44 Rossen: (question) 01:36:55 fantasai: line-break and word-break control where linebreaking opportunities are in the text 01:37:06 s/(question)/where is word-break in this?/ 01:37:06 fantasai: this controls whether or not you're wrapping 01:37:27 heycam: consume and discard seem to be similar things, so maybe should use the same names? 01:37:32 fantasai: discard-after and discard-before? 01:37:45 heycam: in SVG, we're making SVG text be defined in terms of CSS text layout 01:38:14 heycam: one of the weirdo things about SVG text is that if you use the old mechanism to say preforatted text, with xml:space=preserve, it preserves all the spaces within lines but discards newlines 01:38:37 heycam: so we have a special value in Gecko that's like pre, but discards newlines 01:39:23 fantasai: text-space-collapse: discard-breaks -- implies you preserve the other things 01:39:44 SteveZ: if that, then poetry one should be discard-extra-whitespace 01:39:56 fantasai: I think it's clear enough... 01:40:28 SteveZ: ??? 01:40:37 heycam: you could have separate values for breaks and the inline things 01:40:40 fantasai: feels unnecessary 01:40:56 SteveZ: suggestions: either preserve-non-breaks parallel to preserve ... 01:41:10 fantasai: Do you discard the breaks or collapse them? 01:41:16 heycam: they get discarded 01:42:08 johanneswilm: (something about whitespace at start and end of line) 01:42:25 heycam: let me just confirm that it doesn't convert the newline into a single space 01:42:37 fantasai: any other comments? 01:42:40 fantasai: ok, go with this then 01:42:51 fantasai: thoughts on turning this into an editor's draft when we have this in? 01:42:55 various: yes 01:42:56 definitely editor's draft 01:43:11 Edits to do 01:43:19 1. consume-before/after -> discard-before/after 01:43:30 2. add discard-breaks (or collapse-breaks, as appropriate) for SVG 01:43:45 3. spec wrap-before/after/inside 01:43:49 (and remove 'avoid' 01:43:50 ) 01:44:06 sgalineau_ has joined #css 01:44:41 heycam: actually it looks like implementations turn newlines into spaces, and not collapse consecutive ones, except in IE 01:44:52 heycam: maybe IE doesn't implement xml:space=preserve 01:44:59 fantasai: so we need a new name, say spacify-breaks for now 01:45:22 http://glazman.org/tmp/IMG_0153.JPG 01:45:24 how about 'breaks-to-spaces' 01:45:28 RESOLUTION: Make css-text-4 an editor's draft (currently a diff spec) 01:45:30 fyif 01:45:46 RESOLUTION: fantasai and astearns to edit 01:46:25 mihnea_____ has joined #css 01:47:08 tomorrow we're in 1 Darling rd. 01:48:06 break for lunch til 14:18 (90min) 01:49:13 amtiskaw has joined #css 01:49:40 jet has joined #css 01:50:57 ato has joined #css 02:16:33 dauwhe has joined #css 02:38:46 Florian has joined #css 02:50:53 zcorpan has joined #css 02:54:42 zcorpan has joined #css 02:57:31 gregwhitworth has joined #css 02:58:31 johanneswilm has joined #css 03:00:56 gregwhitworth has joined #css 03:12:42 estellevw has joined #css 03:14:19 astearns: I don't think breaking flex items across flex-lines makes sense 03:14:31 astearns: I think flex just needs wrap-before+wrap-after, not wrap-inside 03:15:16 fantasai: right - I was thinking of a range of flex items not getting a wrap, but that doesn't quite work 03:15:16 AndreyR has joined #css 03:15:50 jet has left #css 03:16:06 jet has joined #css 03:17:38 koji? 03:18:13 14:18 resume 03:18:31 Topic: sizing 03:18:38 murakami has joined #css 03:19:37 RESOLVED: Add gregwhitworth as editor to Sizing 03:20:35 ACTION: fantasai figure out what it was wrt percentage sizing 03:20:35 Created ACTION-670 - Figure out what it was wrt percentage sizing [on Elika Etemad - due 2015-02-16]. 03:21:06 kwkbtr has joined #css 03:22:25 fantasai: We were discussing the two different concepts of "max-content" sizing: the size that the thing wants to be (e.g. for multicol, col-width * col-count) vs. the width at which it will be the shortest and not waste space horizontally 03:22:37 (which for multicols is col-count*max-content of the content) 03:22:53 fantasai: Conclusion was that 'max-content' keyword would refer to the first concept, since that's what authors really need for stuff 03:23:10 fantasai: in the cases where we need the second concept, we'll call it the super-max-content for now, probably won't be exposed to authors 03:23:15 koji: want to call in? 03:24:15 dbaron: This is the thing where the only difference between them is multicol 03:24:17 fantasai, What's the intrinsic size of div in

? 03:24:42 fantasai: I think so. ALthough gregwhitworth's case is one that might be relevant, too 03:24:51 dbaron: I don't think there's a case fo rhaving this extra spec concept 03:25:23 dbaron: there are lots of concepts that exist that we don't write code for 03:25:47 dbaron: putting it in a spec creates a risk that somebody ends up implementing the concept that isn't used 03:26:11 TabAtkins: So we define max-content, put a note in the spec saying that we might need this extra concept 03:27:21 TabAtkins makes an example 03:27:27 multicol element w/ columsn: 2 200px 03:27:42 TabAtkins: It will lay itself out at 400px 03:28:28 TabAtkins: suppose you have an unbreakable word 03:28:31 fantasai: Could be breakable 03:28:43 fantasai: Actually, that's an issue, if it's unbreakable, you'll have min-content > max-content 03:28:48 dbaron: That is severely broken 03:29:06 dbaron: It's a spec bug if max-content < min-content 03:29:07 TabAtkins: You'll get 2 cols 300px each 03:29:28 fantasai: we're mixing up a bunch of different concepts 03:29:31 scribenick: tantek 03:29:43 fantasai: (goes to whiteboard) 03:29:53 … if container is 600px 03:29:59 … multicol element will layout 300px wide columns 03:30:18 … but at 400px, 200px each col, the first line would wrap 03:30:26 … in the 300px case it doesn't wrap because it fits 03:30:33 … and the height of my thing is going to be 1em 03:30:39 … this got shorter, I'm wasting 58px of space 03:30:52 … (…) so 500 px is a point in the layout that stuff changes 03:30:57 … you have unwrapped all of the lines 03:31:03 … beyond 500px you start getting extra space 03:31:10 … so this is kind of like a breakpoint in the layout 03:31:17 … if you make the thing any narrower than 400px 03:31:22 … then you're going to drop down to 1 column 03:31:34 … then you have another concept 03:31:43 … What is the minimum size that you don't get overflow? 03:31:47 … take the length of the longest word 03:31:55 … mutiply it by the number of columns 03:31:58 … the longest word basically 03:32:03 … whatever that is is the min content size 03:32:15 SteveZ: I think I get min content and unwrapped lines 03:32:22 … but it's this funny thing in between that I don't get 03:32:44 fantasai: this size, which is I want to be that size, that one could be in the middle or smaller than the min content size, or larger than the intrinsic max size 03:32:51 Rossen: let's go one column 03:32:57 … you have 1 col with 200px 03:33:03 … you have min content 100 03:33:12 Rossen: (draws on white board) 03:33:16 … your content inside is 100 03:33:20 … you max is 150 03:33:26 … let's say 2 words 03:33:31 … in this case you're happy 03:33:37 … you're going to have 200px content width 03:33:44 … I think there are three cases 03:33:50 … 1) both min & max > 200 03:33:53 … 2) or only max > 200 03:34:08 … 3) happens when you start multiplying the columns 03:34:37 … what doesn't currently work, what are you proposing to change 03:34:37 … for case #1: both min & max are strictly > col size 03:34:37 … case #2: only max > col size 03:34:49 … case #3: … um 03:34:54 … is you have more than one column 03:35:01 … for completeness 03:35:07 … same as above but with the opposite sign. 03:35:12 fantasai: so the question we have is 03:35:22 … when you have a multicol element that is shrink to fit 03:35:27 … what size does it end up being 03:35:33 Rossen: let's answer 1 col question first 03:35:36 … before multicol 03:35:46 dbaron: isn't 1 col equivalent to non multicol 03:35:51 Rossen: exactly 03:35:58 fantasai: a non-multicol doesn't have a column width 03:36:13 dbaron: I am not at all convinced that we should considr the col width at all for any intrinsic size computation 03:36:24 Rossen: you're saying 1 col is equivalent of having a block 03:36:26 dbaron: yes 03:36:52 Rossen: when I have a block with 200px, what it reports to a float trying to wrap around it, it will report 200px min & max 03:37:03 Rossen: for single col width 200px, it shouldn't honor the 200px 03:37:12 dbaron: col width is a minimum, or more like minimum 03:37:16 Rossen: same as a table cell 03:37:20 fantasai: no it is different 03:37:25 fantasai: if you have a block 03:37:29 … if col width is 200px 03:37:34 … if my block is 50px 03:37:39 … my col will be 50 px 03:37:43 … the col width is a suggestion 03:37:53 dbaron: column width is merely a hint for determining the column count 03:37:56 fantasai: yes 03:38:04 dbaron: although i don't quite remember… 03:38:13 … the formula for when both col count and col width are specified 03:38:19 … it takes the smaller of the two numbers 03:38:21 fantasai: yeah 03:38:36 … if your container is 150px wide, the col will be 150px wide 03:38:46 … if your container is 250px… col will be 250px 03:39:00 … if your container is 400px, your col will be 2 cols of 200px each 03:39:30 … we had (…) but we ran into the shrink to fit sizing in the multicol spec says if you have a float, and you have enough space, then the multicol will be columns * colwidth 03:39:33 … and that's implemented 03:39:45 … if as an author I specify hey, I want you to shrink to fit around this thing 03:39:49 … that's what they expect 03:40:02 … if they have a long line of content, they don't expect the cols to get wide 03:40:08 … we have a problem here 03:40:20 … it's really important that the shrink to fit max is, is … 03:40:36 … it's important that the shrink to fit max include the maximum of the min content size, and then col count * col width 03:40:44 … that way you're maintaining that invariant 03:40:50 … you're also getting the thing the author asked for 03:40:56 … we have this other concept of unwrapped 03:40:59 … authors will not want that 03:41:06 … you will have layout land at that answer for certain cases 03:41:12 … that's a break point in the layout where it won't get shorter 03:41:19 … it might become a useful concept if for example 03:41:24 … if you have tables and you're doing orthogonal flows 03:41:32 … you might want things to be as few lines as possible 03:41:41 … without orthogonal flows it's not that interesting as a concept 03:41:46 … we also have a similar issue 03:41:51 … the shrink to fit sizing should be x 03:42:01 … and if the box is wider it will be wider 03:42:09 … like Greg brought up 03:42:18 … the shrink to fit expectation is narrower than (...) 03:42:25 … that's a concept that we don't have a clear idea where it would be used 03:42:29 … but I have a feeling it will show up 03:42:39 Rossen: go back to .(…) what are we calling it? 03:42:42 fantasai: max conent 03:42:45 s/conent/content 03:42:50 fantasai: we have 3 concepts 03:42:52 … small concept 03:42:55 … two big concepts 03:43:09 … the author gets exposed to these through shrink to fit sizing and the max content keyword 03:43:15 … when the author is doing grid layout for example 03:43:23 … then they're going to expect to be this size and not wrap the text 03:43:33 Rossen: in this case, 600px, 2 cols 03:43:37 … 300px cols each 03:43:44 fantasai: where is 600px coming from 03:43:47 Rossen: min content 03:44:04 fantasai: if you have a really long unbreakable line or an image, then it will be wide enough to fit that image without overflow 03:44:09 Rossen: in this case it will overflow 03:44:11 fantasai: it won't 03:44:37 Rossen: you will have two columns 03:44:37 fantasai: when you layout a multicol element at 600px with 2 cols, each will be 300 px wide 03:44:54 Rossen: your col count has to be driven by the max of (...) 03:45:08 TabAtkins: this is not the size of the largest word 03:45:27 dbaron: maybe we should take some of this offline 03:45:34 … not sure what we're trying to solve right now 03:45:46 TabAtkins: (...) 03:45:55 dbaron: the thing you just said, you implicitly assumed two concepts 03:45:59 … I don't think you have to assume that 03:46:08 fantasai: for the purposes of this discussion there are 2 concepts 03:46:15 dbaron: there are potentially many more concepts 03:46:30 TabAtkins: we need to be ok with multicol having a different answer for that 03:46:42 SteveZ: you're just defining what max content means in a multicol situation 03:46:49 fantasai: the other case is you have a bunch of floats 03:46:55 … and you shrinkwrap a bunch of floats 03:47:05 … you could have this (…) but you actually get this (...) 03:47:18 … the floats (3) could fit next to each other 03:47:36 … but since you asked it to shrinkwrap, current implementations shrink them to one on a line each 03:47:45 gregwhitworth: it is weird and we'll try to spec it 03:47:51 fantasai: more fun times 03:47:54 TabAtkins: resolutions 03:48:08 … can we get a resolution that we should define max content of multicol this way 03:48:15 dbaron: I think I object to a big part of that 03:48:18 fantasai: which part 03:48:20 dbaron: most of it 03:48:30 dbaron: and I want to propose an alternative 03:48:37 SteveZ: the piece that confuses me with a 600px image 03:48:43 … I would expect multicol to go away in that case 03:48:52 Rossen: you specified the number col count 2 03:49:03 TabAtkins: multicol assume if you specify count that you meant it 03:49:08 fantasai: so we need to make this correction 03:49:14 TabAtkins: so we fix this in sizing now 03:49:20 … dbaron can suggest whatever he wants 03:49:26 … and we can resolve differences later 03:49:40 gregwhitworth: we need to discuss per the mail thread what does "min content" really mean 03:49:44 … we can take it offline 03:49:55 TabAtkins: (…) ? 03:50:01 fantasai: the intrinsic size 03:50:12 Rossen: so if it's the only thing you're going to get the specified size 03:50:23 fantasai: no there is a min content size and a min content contribution 03:50:26 … there are two separate concepts 03:50:37 dbaron: one of the reasons for that is that we want the width property to accept values 03:50:43 … that says use the min or max content 03:50:46 q+ about percentage margins in intrinsic sizing 03:50:52 … the min content size does not include the (...) 03:50:59 … you have to factor that into the contribution (...) 03:51:09 gregwhitworth: both of your guys implementations you could make an argument for 03:51:15 q+ 03:51:19 gregwhitworth: you guys (Moz) if you have a really long line ... 03:51:28 gregwhitworth: but blinks will shrink to the size of the longest word 03:51:43 dbaron: I think this is very differen than what Rossen and I were talking about 03:51:57 fantasai: it is full defined and mozilla's implementation matches what it is defined as 03:52:04 SimonSapin: I missed this earlier 03:52:12 … can we got back to percentages? 03:52:22 zakim, ack SimonSapin 03:52:22 I see no one on the speaker queue 03:52:30 scribenick: fantasai 03:52:38 SimonSapin: Intrinsic size computation for blocks 03:52:45 SimonSapin: You account for margin/padding/border of children 03:52:55 SimonSapin: But it's unclear what happens if these contain percentages or auto values 03:53:11 SimonSapin: If you compare with width of children, we have specific text that says it's indefinite, do something else 03:53:23 TabAtkins: But for margin/border/padding we don't say 03:53:27 Rossen: No interop here 03:53:47 dbaron: Auto isn't interesting. just treat as zero 03:53:52 TabAtkins: yeah 03:53:57 SimonSapin: Put that in the spec 03:54:14 dbaron: In gecko we do the reverse computation 03:55:14 fantasai: I think this discussion was super-useful, I understand what's going on here much better thanks to the discussion 03:55:31 fantasai: Let's get together and update the spec before we lose all the context again 03:55:54 RESOLVED: auto margins assumed to be zero for intirnsic size computation 03:56:13 SimonSapin, fwiw, http://dbaron.org/css/intrinsic/#outer-intrinsic did define it :-P 03:56:19 dbaron: Did we come to a conclusion on percentages? 03:56:25 http://glazman.org/tmp/IMG_0154.JPG 03:56:29 Rossen: We discussed computing to zero 03:56:50 dbaron: I think trying to do something useful with percentages is good 03:56:51 dbaron, great! Let’s copy that in Sizing 03:56:55 dbaron: We were unable to do for width 03:57:18 fantasai: I agree we should do something useful and not stupid here 03:57:27 fantasai: Shouldn't create overflow artificially 03:57:36 Rossen talks about stacking percentages 03:57:39 dbaron: Tables already do this 03:57:50 dbaron: Tables do inverting of percentages 03:58:03 Here is the min-content issue we need to discuss: http://dabblet.com/gist/599a04c05a22f48a292d 03:58:07 Discussion is here: https://lists.w3.org/Archives/Public/www-style/2015Jan/0022.html 03:58:08 dbaron: At some point your perferred width becomes infinite, but you never use it directly, you always min it with something 03:59:25 fantasai: With width percentages, you treat as auto for both intrinsic size computation and for final layout 03:59:53 fantasai: with percentage padding, you treat as zero for intrinsic size computation, but then honor it for layout, which results in overflow and bad layout 03:59:56 fantasai: I think this is worth fixing 04:00:06 Rossen says something about making things better for flex, but wasn't sure what he said 04:00:36 ACTION: fantasai, Tab, SimonSapin, Rossen , gregwhitworth , dbaron to figure this all out and spec it. 04:00:36 Error finding 'fantasai,'. You can review and register nicknames at . 04:00:39 Rossen: tonight. 04:00:42 plinss: or else. 04:01:10 Topic: Text 04:01:12 koji? 04:01:59 zakim, room for 3? 04:02:00 ok, plinss; conference Team_(css)04:01Z scheduled with code 26631 (CONF1) for 60 minutes until 0501Z 04:03:01 can I call in? 04:03:16 yes ^ 04:03:21 zakim, code? 04:03:21 the conference code is 26631 (tel:+1.617.761.6200 sip:zakim@voip.w3.org), plinss 04:04:09 Team_(css)04:01Z has now started 04:04:16 +??P0 04:04:27 zakim, ??P0 is MeetingRoom 04:04:27 +MeetingRoom; got it 04:06:02 ScribeNick: ShmabShmatkins 04:06:16 SchmibeNick: ShmabShmatkins 04:06:22 -MeetingRoom 04:06:23 Team_(css)04:01Z has ended 04:06:23 Attendees were MeetingRoom 04:06:46 https://lists.w3.org/Archives/Member/w3c-css-wg/2015JanMar/0080.html 04:07:02 Topic: Text 04:07:08 fantasai: First issue is about line-breaking around emoji/etc 04:07:15 fantasai: There was some bakc-and-forth in the thread 04:07:25 fantasai: The best option is to treat images as ideographic chars for linebreaking. 04:07:37 fantasai: It solves linebreaking problems when images are used as emoji. 04:07:46 fantasai: And gives better behavior than the current spec in general. 04:07:56 fantasai: So this doesn't cause breaks right before an end paren, etc. 04:08:03 fantasai: Main concern is, is this web compatible? 04:08:11 fantasai: Right now everyone breaks around images. 04:08:20 fantasai: But Presto treats images as ideographic chars. 04:08:28 Team_(css)04:01Z has now started 04:08:35 +??P0 04:08:41 fantasai: The critical piece is that the iamges will break between each other if they're siblings, which is handled by this suggested rule. 04:08:45 zakim, ??P0 is MeetingRoom 04:08:45 +MeetingRoom; got it 04:08:46 -MeetingRoom 04:08:47 Team_(css)04:01Z has ended 04:08:47 Attendees were MeetingRoom 04:08:58 fantasai: Only behavior change is a few restrictions we add for ideographic chars. 04:09:06 fantasai: Which you probably meant to work in the first place. 04:09:25 fantasai: We're taking Presto as an example of webcompat. 04:09:33 Team_(css)04:01Z has now started 04:09:40 +MeetingRoom 04:09:42 fantasai: We're hoping this is worth giving a shot at fixing to be sane. 04:09:48 line breaking around images is a bit different in quirks mode: https://quirks.spec.whatwg.org/#the-table-cell-width-calculation-quirk 04:09:55 fantasai: We need to hear back from impls to see if they're willing to implement. 04:10:04 szilles: What unicode categories are these? 04:10:12 fantasai: Proposal is to treat as the ID class (ideographic). 04:10:18 +??P1 04:10:22 fantasai: Current behavior is not actually expressible in teh unicode spec. 04:10:30 zakim, +??p1 is me 04:10:30 sorry, koji, I do not recognize a party named '+??p1' 04:10:37 zakim, ??p1 is me 04:10:37 +koji; got it 04:10:37 fantasai: Unicode puts "glue" (nbsp, etc) as a higer priority as nearly anything else. 04:10:50 fantasai: But images apparently decided they ahve a higher priority than forced non-breaking. 04:10:58 fantasai: So this change'll bring us *more* in line with the unicode spec. 04:11:08 fantasai: Any comments, or should we make the fix? 04:11:21 zcorpan: I don't understand the consequences? 04:11:37 fantasai: Example: " foo", you can't break after the img any more. 04:11:54 fantasai: Or "()", you can't break in the parens anymore, they'll stay with the image. 04:11:57 -koji 04:12:11 zcorpan: I'll search if Presto has any open compat bugs for it. 04:12:29 zcorpan: I also posted a link to Quirks Mode. Line-breaking there is a bit different, at least for table cells. 04:12:45 zcorpan: If we change how linebreaking works around images, it might need to be adjusted in Quirks. 04:13:06 zcorpan: When you calculate the minimum width of the table cell, you act like there's no breaking opportunity around images. 04:13:11 are you proposing to fix just for images and leave other replaced elements? 04:13:14 zcorpan: But when you actually lay out there might be linebreaks there. 04:13:28 fantasai: For all replaced elements. 04:13:34 fantasai: And for U+FFFC 04:14:04 I'm negative, at least for , that'll break too much 04:14:17 I'm not sure how much we'd break for though 04:14:34 fantasai: What would it break for ? 04:15:06 zcorpan: Looks like Presto has at least one bug about " foo" breaking a website due to non-breaking. 04:15:15 Preseto being bugged from users indicates that there are legacy such content 04:15:30 koji: I'm checking it now to see if I can dial in alright. 04:16:09 koji: yes, but it depends how much content this breaks. Hopefully not much. 04:16:26 http://software.hixie.ch/utilities/js/live-dom-viewer/?%3Cstyle%3E%0Ahtml%20%7B%20font-size%3A%203em%3B%20%7D%0A%3C%2Fstyle%3E%0A(%3Cinput%3E)%3Cbr%3E%0A%3Cinput%3E.%3Cbr%3E%0A%3Cinput%3Eabc%3Cbr%3E%0A%3Cinput%3E%26nbsp%3Bfoo 04:16:41 "There are cases where the total width of the images exceeds that of the containing
block and instead of creating a line break, Opera displays the image outside of the block." - url was http://www.clasohlson.se/product/category.aspx?category=kroppsv%c3%a5rd:tandv%c3%a5rd&id=88753177&_path=251882;85177601;88752827;88753177 but probably the site has changed 04:16:41 In HTML4, I believe, authors used to use   as a non-collapsible spaces 04:16:52 and used    04:17:04 not sure how much such content survive today though 04:17:43 + +1.415.231.aaaa 04:18:03 zakim, +1.415.231.aaaa is me 04:18:03 +koji; got it 04:19:24 koji: The bug was reported to Presto by a user; that indicates at leaest some users believe there should be forced break opportunities between   and . 04:19:46 Florian: It's definitely a breaking change; the question is if it's breaking too much. 04:20:12 Florian: Not surprising that Presto gets a bug if everyone else does something different. 04:20:43 Florian: Unsure that one single bug is enough evidence to rule it out. Presto survived for a while without fixing this. 04:21:25 koji, dial-in working OK for you now? 04:22:09 ok, np - feel free to ping me on hangouts or IRC if it goes out again. 04:22:14 fantasai: So it sounds like Greg will look into actual websites and see what may or might not break. 04:22:19 fantasai: Anything else to do? 04:23:22 koji: I have seen editors that, when I type two spaces at the end of a sentence, converts it into multiple   04:23:38 koji: treats nbsp as non-collapsible space 04:23:52 murakami: I think the emoji and gaiji should be treated same as ideographic chars, and do linebreaking correctly. 04:23:59 16,311 pages in httparchive match REGEXP_MATCH(body, r'(\ ]+>\ )') 04:24:19 murakami: I don't understand why people wouldn't expect nbsp to not break. 04:24:49 murakami: That makes no sense and is a bug that we should fix 04:25:11 zcorpan: I checked httparchive for nbsp before/after an image, and there were 16k matches. 04:25:27 zcorpan: ABout 130k pages in the set, so about 12% of all the pages match the query. 04:25:47 zcorpan: Haven't analyzed whether they're broken in Presto or not, but there's a lot of pages. 04:26:14 plinss: So we'll come back to this with data? 04:26:39 johanneswilm: This applies to and and similar too? 04:26:41 fantasai: Yes. 04:27:11 fantasai: Another thing to consider is if nbsp is a big issue, but nothing else is -- nbsp isn't a big deal for emoji, they're mostly concerned about punctuation being correct. 04:27:29 fantasai: We could just say that it behaves as an ideographic char *except* it still has a break opportunity between it and an nbsp. 04:27:36 fantasai: It woudl be stupid, but it would fix all the other cases. 04:28:01 TabAtkins: Suggest we resolve to do ideographic change, and based on data may or may not do nbsp tweak to it 04:28:20 fantasai: zcorpan, can you run a query with parens, or a period after the image? 04:28:23 zcorpan: Sure. 04:28:52 myakura has joined #css 04:29:22 r'(\(]+>[\)\.])' 999 matches 04:29:45 RESOLVED: Treat replaced elements as ideographic chars for line-breaking. Based on data, possible add an exception for nbsp. 04:29:53 999 out of 1000? 04:30:13 out of ~130k 04:30:51 plinss: We need a really-non-breaking-space 04:31:00 fantasai: &zwsp;  04:31:23 zakim who is noisy 04:31:26 dbaron: nbsp changed meaning between original (just a char that didn't add a breaking opportunity) and unicode later meaning (inhibits breaking around it). 04:31:40 http://i.imgur.com/N8ouTs8.png 04:31:52 https://lists.w3.org/Archives/Public/www-style/2014Nov/0282.html 04:31:59 gregwhitworth: We had a bug a while ago (^^^ pic above) showing hex boxes. 04:32:17 gregwhitworth: I brought it up on the list, asking Text to specify that control chars get shown. 04:32:26 gregwhitworth: FF actually did this, but everyone assumed they were broken. 04:32:38 gregwhitworth: So we all need to coordinate our release, to avoid getting inundated with bugs. 04:32:51 gregwhitworth: And coordinate with, say, a 6-month period to give devs warning. 04:33:01 gregwhitworth: So let's agree to make the change in, say, September? 04:33:33 dbaron: Did we back it out? 04:33:43 gregwhitworth: Yeah, the bug is in the discussion. 04:33:55 gregwhitworth: roc is the one that suggested the coordination day. 04:34:07 [greg goes to fetch roc] 04:34:08 stryx` has joined #css 04:34:48 gregwhitworth: roc, we're trying to coordinate the visible-control-chars release. 04:34:59 roc: We alreayd have it implemented, we just need to flip a UA property. 04:35:15 Mozilla bug: https://bugzilla.mozilla.org/show_bug.cgi?id=1099557 04:36:04 RESOLVED: Everyone go coordinate on Sep being when control characters become visible. 04:37:46 zakim, who is noisy? 04:37:53 fantasai: Okay, so MSFT, Blink, and WebKit need ot implement behind a flag, preferably by June, and report back if sooner so we can coordinate 04:38:02 Rossen, listening for 10 seconds I heard sound from the following: MeetingRoom (4%) 04:38:30 zakim, mute MeetingRoom 04:38:30 MeetingRoom should now be muted 04:38:42 zakim, unmute MeetingRoom 04:38:42 MeetingRoom should no longer be muted 04:39:01 [alan summons Dean] 04:39:17 [alan begins by drawing a pentagram on the floor] 04:39:21 [Dean curses us all] 04:41:31 Dean: I can't control when an iPhone releases, so... 04:41:41 gregwhitworth: As long as we have enough. 04:41:49 Dean: If we committed to doing it... 04:42:29 fantasai: Just impl behind a flag, and flip it at the same time as everyone else. Everyone else might get it out sooner, but we all know it's coming out in Safari too. 04:43:02 Dean: Okay. 04:43:27 gregwhitworth: Chrome and FF are the main ones that can just ship it whenever. MS and Apple will have to just commit to it. 04:44:06 [alan erases pentagram] 04:44:11 [Dean returns to whence he came] 04:44:29 ACTION Dean break the web behind a flag in webkit 04:44:29 Created ACTION-671 - Break the web behind a flag in webkit [on Dean Jackson - due 2015-02-16]. 04:45:10 johanneswilm: I hope I'm not using those chars that'll become visible after. 04:45:19 gregwhitworth: We'll put out PR to help people figure this out. 04:45:35 Topic: Writing Modes 04:45:48 fantasai: Writing modes! 04:45:56 fantasai: We dont' hav eimpls of the sideways-left value. 04:46:00 fantasai: 1) leave it as is 04:46:18 fantasai: 2) mark it as at-risk, and note that if someone implements just sideways-right, don't implement sideways 04:46:25 fantasai: 3) punt it to level 4 04:47:01 fantasai: I think we should do #2 because it's important for non-CJK upright scripts. 04:47:15 fantasai: LIke a caption on the left side of a table, or table column headers that are vertical in English, you need this value. 04:47:20 fantasai: So I don't think we should remove it. 04:47:32 fantasai: But if it's the only thing blocking writing modes from exitting CR, it might be worth dropping it. 04:48:04 Tab: I say keep it in until CR-exit is immanent. 04:48:10 koji: I say move it to Level 4. 04:48:55 koji: Concerns about how it is designed today were raised, and I'd like further discussion. 04:48:59 koji: So punting is appropriate. 04:49:04 s/immanent/imminent/ 04:49:06 fantasai: Nobody ahs raised an issue with the design afaik. 04:49:14 fantasai: People have said "I don't like this, it's confusing and complicated". 04:49:32 koji: Rossen suggested rotating the line 180deg inline 04:49:42 fantasai: We could make it apply to blocks only if that's the issue. 04:51:04 plinss: I don't see the harm in marking it at-risk versus punting it for now. 04:51:39 plinss: Has anyone implemented sideways-right but not sideways-left? 04:51:45 fantasai: Yeah, because sideways-right is needed for CJK. 04:52:07 astearns: At-risk seems the right thing to do for now. 04:52:09 AH, Blink, and WebKit does 04:52:13 Rossen: We can alway spush it to 4 later. 04:52:17 plinss: Any objections? 04:52:52 RESOLVED: Keep sideways-left, mark as at-risk, possibly punt if it threatens CR-exit. 04:53:16 fantasai: Next is propagation of writing-mode and direction from 04:53:48 koji: Did we decide on 'sideways'? 04:53:58 fantasai: Same deal - if you can't do sideways-left, you can't do sideways. 04:54:01 koji: Okay. 04:54:25 fantasai: Right now in HTML we prop from root to the ICB, and the proposal is to ignore the value on the root and propagate from the body to both the root and the ICB. Ignore the root's value entirely. 04:54:45 Rossen: So if you have , it's ltr? 04:55:08 Rossen: Is that a good idea? 04:55:26 fantasai: We need to do something like this. For background, we can do the "check to see if root has it specified, if not, check body". 04:55:44 fantasai: But this is inherited - there is always a valid value. So you have to choose one or the other unconditionally. 04:56:11 Florian: I believe direction is a web-compat issue; it's been that way forever. We'd prefer it inherit normally, but we probably can't change it. 04:56:16 Florian: And writing-mode should act similarly. 04:56:26 Rossen: We have logic that doesn't match that since IE6. 04:56:43 Rossen: We take root if specified, and use body otherwise. 04:57:04 Rossen: Same for overflow. 04:57:26 Rossen: This suggestion may have compat issues in cases where both html and body specify a direction. 04:57:50 Rossen: Before we decide how to spec this, we need to udnerstand how we're all doing. 04:58:01 Rossen: I hope this is something we can keep consistent for overflow too. 04:58:59 testcase: data:text/html;charset=utf-8,%0D%0A..]<%2Ftitle>%0D%0A%0D%0A%0D%0A head%2C title { display%3A block%3B }%0D%0A body { border%3A solid%3B width%3A 150%25%3B text-align%3A center%3B }%0D%0A<%2Fstyle>%0D%0A%0D%0A..] 04:59:17 zcorpan: In Blink it used to use the root element if it was specified on both, but it was changed to always use , claiming compat with Gecko and IE. 04:59:35 fantasai: Gecko seems confusing... 04:59:42 dbaron: Gecko is inconsistent based on what is happening. 05:01:11 dbaron: You can test how direction behaves on root by... 05:01:24 dbaron: 1) Which side you can scroll to when there's overflow from the viewport. 05:01:38 dbaron: 2) If the root element is relpos and has both left and right set, which one wins. 05:01:51 dbaron: 3) If the root element has overconstrained margins, which gets ignored. 05:02:11 dbaron: 4) if the root or body is abspos, which position gets used for hypothetical box calcs. 05:02:47 dbaron: Probably most likely to cause breakage is scroll direction. 05:03:38 dbaron: data:text/html;charset=utf-8,%0D%0A..*<%2Ftitle>%0D%0A%0D%0A%0D%0A head%2C title { display%3A block%3B }%0D%0A html { border%3A solid silver%3B width%3A 80%25%3B margin%3A 0%3B }%0D%0A body { border%3A solid%3B width%3A 150%25%3B text-align%3A center%3B }%0D%0A<%2Fstyle>%0D%0A%0D%0A..* 05:03:49 [some discussion about direction] 05:03:50 Presto scrolls as LTR (follows root) 05:04:03 Gecko aligns as LTR, but scrolls as RTL 05:04:09 which is not helpful at all 05:04:28 http://software.hixie.ch/utilities/js/live-dom-viewer/?%3C!DOCTYPE%20html%3E%0A%3Ctitle%3E..*%3C%2Ftitle%3E%0A%3Cstyle%3E%0A%0A%20%20head%2C%20title%20{%20display%3A%20block%3B%20}%0A%20%20html%20{%20border%3A%20solid%20silver%3B%20width%3A%2080%25%3B%20margin%3A%200%3B%20}%0A%20%20body%20{%20border%3A%20solid%3B%20width%3A%20150%25%3B%20text-align%3A%20center%3B%20}%0A%3C%2Fstyle%3E%0A%3Cbody%20dir%3Drtl%3E%0A..* 05:04:46 seems like UI QoI 05:05:05 Blink aligns and scrolls as RTL 05:06:53 IE shows the whole canvas and can scroll to it, and aligns per RTL, but the initial scroll position is per LTR 05:06:54  05:07:35 Florian: So more testing to see what exactly is happening, and which is interoperable? 05:07:46 fantasai: Whichever one is less likely to cause breakage is what we should do. 05:08:12 dbaron: Fixing the spec might make things inconsistent too. 05:08:40 dbaron: You'll need to make up some new term, not computed value, and you'll need to make sure everything refers to this new term, not "computed value". 05:10:58 scribenick: ShmabShmatkins 05:11:20 https://lists.w3.org/Archives/Public/www-style/2015Jan/0272.html 05:11:24 710 pages with and not . (0.24%) 05:11:36 https://bugzilla.mozilla.org/show_bug.cgi?id=1071098#c16 is where I got the list of ways to test direction on the root 05:12:12 fantasai: could propagate from the HTML attribute on the body, but not propagate CSS 'direction' 05:12:13 html:has-child(body[dir=rtl]) { direction: rtl; } 05:12:14 DONE 05:13:26 ACTION Greg to figure out what options are sensible for the html/body dir thing. 05:13:26 Created ACTION-672 - Figure out what options are sensible for the html/body dir thing. [on Greg Whitworth - due 2015-02-16]. 05:14:14
05:21:23 -koji 05:26:23 disconnecting the lone participant, MeetingRoom, in Team_(css)04:01Z 05:26:25 Team_(css)04:01Z has ended 05:26:25 Attendees were MeetingRoom, koji 05:43:23
05:43:57 next topic is? 05:44:20 jdaggett: Finishing up some comments about direction/writing-mode. 05:44:25 Then the SVG1.1 keywords. 05:44:28 ok 05:46:45 dbaron: Xidorn tried to implement something, and we found a problem. 05:47:03 dbaron: In CSS sometimes the process of computing one proeprty depends on another one. 05:47:11 dbaron: And we need to keep these in a partial order, so no loops. 05:47:21 dbaron: We discovered that Ruby and Writing Modes added a loop. 05:47:35 dbaron: It's between 'display' and 'writing-mode'. 05:47:52 dbaron: There's also an influence from 'ruby-position'. 05:48:40 dbaron: display:ruby-text-container && ruby-position:inter-character => writing-mode computes to vertical-rl 05:48:53 dbaron: Because intercharacter ruby needs to be drawn that way. 05:49:14 dbaron: I've seen elevator signs in Taipei look like this. 05:49:52 dbaron: When writing-mode changes between parent and child, and display is inline, it's changed to inline-block. 05:50:16 dbaron: Because you can't really display a writing mode change unless the parent establishes a block 05:50:29 dbaron: I think most of us agree that writing-mode has to mess with display. 05:50:45 kwkbtr has joined #css 05:50:47 gregwhitworth has joined #css 05:50:55 dbaron: So it's not strictly a loop, but this still doesn't work in our architecture. 05:51:15 dbaron: roc suggested that the vertical-lr change be triggered by something else that display:ruby-text-container elements have. 05:53:25 ShmabShmatkins: So our problem here is that we have a strict separation of properties into "levels" that compute in order. 05:53:45 dbaron: Ours isn't strict, but we do have a strict ordering of inherited vs non-inherited properties, which ends up being the same thing. 05:54:18 fantasai: We could make the inline->inline-block a used value. 05:54:29 dbaron: Making the computed value out of sync with the real value will be a security issue. 05:56:48 [dang, missing some minuting] 05:57:14 ShmabShmatkins: I think roc's suggestion can work. Add a magic property to and anonymous ruby text containers. Authors have to add it manually if they're making their own. 05:57:46 fantasai: Can this just be an implementation issue? 05:58:31 [dbaron's thinks furiously] 05:58:50 dbaron: What does it look like in inter-character ruby when there is an with multiple s? 05:59:13 fantasai: Each rt is after each rb. The rtc and rbc both encircle the entire thing. 05:59:26 dbaron: That makes it sound like it's the rt that's vertical-rl, not the rtc. 06:00:04 dbaron: If so, can we fix by changing the condition to "my parent's display is rtc and my ruby-position is inter-character"? 06:00:13 fantasai: Or parent's ruby-position is inter-character. 06:00:23 dbaron: If it's the ruby-text that becomes vertical-lr, I think that's okay. 06:00:28 fantasai: Sounds good. 06:01:07 RESOLVED: writing-mode: vertical-lr on the based on parent's 'display' & 'ruby-position' 06:01:25 heycam: The 'all' shorthand is desgined to exclude direction and unicode-bidi. 06:01:33 heycam: Why? 06:01:46 fantasai: direciton and unicode-bidi should never have existed. They're not stylistic, they're content properties. 06:01:53 fantasai: So when resetting stylistic stuff, they shouldn't be reset. 06:01:59 fantasai: But writing-mode *is* a stylistic choice. 06:02:09 heycam: And text-orientation too? 06:02:12 fantasai: Yes. 06:02:33 Topic: SVG Keywords - kill them? 06:02:48 heycam: There are some svg-specific keywords in writing modes. 06:03:11 heycam: text-orientation:use-glyph-orientation, which means "do what the SVG-specific glyph-orientation-vertical/horizontal properties say". 06:03:26 heycam: I was going to suggest to SVGWG to just drop those, since nobody implements them. 06:03:34 heycam: Presumably you'd drop the value if we drop the proeprties. 06:03:35 fantasai: Yes. 06:03:47 heycam: Next is some writing-mode values, coming from XSL. 06:03:58 heycam: We're going to drop all of those, and just refer to current CSS spec. 06:04:05 heycam: So I suggest they get dropped from CSS. 06:04:10 fantasai: Can you actually drop them? 06:04:30 fantasai: It's reasonably likely there's no web content that uses them, but may be off-web content that uses them. 06:05:56 ShmabShmatkins: Can we just death-pact with the SVGWG and choose to drop them if they do? 06:06:03 heycam: AT least we'll drop them from SVG2. 06:06:08 fantasai: But you'll still need the definition. 06:06:21 fantasai: We might deprecate and define them simultaneously. 06:06:51 heycam: In WM atm, there's wording that says "if you support these values, do XXX". 06:06:56 heycam: We'll let you know what we decide. 06:07:37 heycam: I found an old email of mine saying that some browsers do ipmlement glyph-orientation-*, but they didn't do it interoperably. 06:08:18 fantasai: If the values only show up in attributes, you can use UA CSS to convert it to the proper values. 06:08:32 fantasai: But if the existing content uses the CSS syntax, you need to keep it. 06:10:02 RESOLVED: Drop the values if the SVGWG drops the values/properties, otherwise keep them. 06:10:28 Topic: Multi-line/block ellipsis 06:10:34 This is exported from Photoshop: 06:10:34 Florian: Not the first time we've discussed this. 06:10:38 .cls-15 { 06:10:38 writing-mode: tb; 06:10:38 glyph-orientation-vertical: 0; 06:10:38 } 06:10:40 Florian: To refresh everyone, we have ellipsis. 06:10:53 krit, ok, that is interesting 06:10:55 Florian: It only works in in the inline dimension. If a given line is overflowing, it gets ellipsized. 06:10:56 https://lists.w3.org/Archives/Public/www-style/2015Jan/0357.html 06:11:09 Florian: Most people want something at the end of the last line of a block that's too long in the block direction. 06:11:17 krit, can you write vertical text in photoshop? :) 06:11:32 Florian: We actually ahve a resolution to add it to the spec, without specifying what's getting added. 06:11:41 Florian: So I was looking into this... 06:12:03 Florian: I have some ideas, but while working on this, I figured this was a problem that should be unified with something similar, and so I'll be talking more about fragmentation than ellipsis. 06:12:24 Florian: When you say "I want ellipsis at the end of the last line", what does that mean? Last totally-fitting line? Does ink(shadow) count? 06:12:32 Florian: Or do we just use fragmentation, which defines all of this? 06:12:48 Florian: There's a property in the REgions spec called region-fragment. 06:13:06 http://dev.w3.org/csswg/css-regions/#the-region-fragment-property 06:13:25 Florian: It has 'auto' or 'break'. If the last region of the region chain overflows, and it says "auto", it overflows like normal. If 'break', it acts like there's another region, but just drops the rest. 06:13:40 fantasai: This sounds like another value for overflow-y. 06:13:54 cyril has joined #css 06:14:02 Florian: The REgions spec shows why that's not true; it's independent of overflow. 06:14:36 This is overflow-y: paged-hidden 06:14:38 astearns: overflow-x/y can have effects independently of region-fragment 06:15:11 ShmabShmatkins: Regardless, I think you're not invoking the property itself, just its concept? 06:15:39 Florian: I think we can generalize this concept. 06:15:51 Florian: [described the definition of the property again] 06:16:17 fantasai: So you have overflow:scroll and hidden. 06:16:36 fantasai: Same, but hidden just stops it rather than exposing the rest. 06:16:48 fantasai: Similarly, this is like paged and "paged-hidden" - "page me, but don't expose the rest". 06:16:53 q? 06:16:58 dbaron: I agree with florian. 06:17:07 dbaron: When I was writing the Overflow spec, I found this awkward. 06:17:21 dbaron: It was trying to put two different concepts in the Overflow property, one about visual overflow and one about pagination. 06:18:14 dbaron: It was awkward that there were 'overflow' values (page and fragments) that were about how to paginate, so when you had those values, you had to arbitrarily pick what to do with the visual overflow that visible/hidden handled normally. 06:18:26 fantasai: So that makes sense to me; maybe different properties for visual vs pagination overflow. 06:18:29 fantasai: I'm okay with that. 06:18:38 fantasai: As long as pagination and hiding pagination are in the same control. 06:18:46 Florian: That's chapter 5 of my very long mail. 06:18:53 [[Presumably a new book out this summer.]] 06:19:05 Florian: So my new proposal is a 'fragmention' property. 06:19:27 Florian: With values auto/none/break/paged/clone 06:19:46 Florian: auto is "do the right thing in the middle of a region chain", etc 06:19:49 break is region-break: break behavior 06:19:52 Florian: Should we explain regular pagination in terms of this? 06:19:53 paged is overflow: paged 06:19:59 clone is overflow: fragment 06:20:08 s/fragmention/fragmentation 06:20:13 Florian: By having this property on the page box, having "auto" compute to "paged", which lets you turn off pagination on a page and let things overflow. 06:20:21 Florian: Dunno if that's useful. 06:20:48 Florian: Reason this ties into ellipsis is that we have an issue about block ellipsis, and another issue about "how can we write 'continue on page 3'", we can unify these. 06:21:23 Florian: So we'd solve the "put ... at the end of a block" the same way as "put ... at the end of a region that continues elsewhere", and eventually "put (page 3) at the end of a region" when we have those tools. 06:21:46 tantek: When I've seen "include the first 3 lines" behavior, it's usually on social networks with a "more" link. 06:21:56 tantek: I don't know how to combine auto-ellipsizing that and adding a link. 06:22:04 Rossen: We discussed this in Seoul. 06:22:10 s/link/link that you can attach some other behavior to/ 06:22:16 Rossen: Talked about what to do with ellipsed behavior. 06:22:56 Rossen: We added the "fade" ellipsis behavior, and there was talk about styling it, so it should be a pseudo-element. 06:23:20 Rossen: So the ellipsed block is actually interactive. You can attach event handlers to the pseudo-element. 06:24:24 Florian: Another possibility is adding a "fragment: into()" that we could use later. 06:24:28 tantek: I think I'm okay with unifying 06:24:50 tantek: So we need a string, not just "ellipsis". 06:25:03 fantasai^: Bert had a pull model that I think makes more sense than into() 06:26:01 ShmabShmatkins: You can attach an event listener to the parent of the ::ellipsis pseudo, and do the "more" handling there. 06:26:13 tantek: So one approach is an expansion when you click "more". 06:26:22 tantek: Another is "more" being a link to another page. 06:26:53 tantek: Third is "continued on page 3", where it loads totally different content, maybe saying "continued from page 1". 06:26:54 And some websites use both, and you can't tell which you're going to get until after you click it. 06:27:07 tantek^: another scrolls down to another part of the page 06:27:20 tantek: I'd like to at least capture those. 06:27:44 ShmabShmatkins: First two can be done with JS now; doing it CSS requires reviving the Hyperlink module. Third can be done as Region expansions in the future. 06:28:07 Florian: My basic point is that if we try to solve block ellipsis separately from fragmentation, we'll have to solve these problems twice. 06:28:49 johanneswilm: As I understand it, if you can have an ::after pseudoel that you put the ellipsis in, you can use JS to figure out what page something shows up on, and set 'content' appropriately. 06:29:43 tantek: It's def solvable in JS today. Just want to let there be less JS, or no JS. 06:30:47 Rossen: If your container is actually constrained so there's only two lines visually, you say max-lines:3, the behavior is still bad. 06:30:59 Florian: No, max-lines:3 just puts a break opportunity after the 3rd line. 06:31:20 Florian: Currently max-lines only applies to overflow:fragments; it should apply to any fragmentainer. 06:31:33 ShmabShmatkins: Yes, assuming we have these new fragment values. 06:32:37 Florian: So, proposal is we remove region-fragment property, replace it with the 'fragmentation' property. 06:32:43 dbaron: I'm okay for now, haven't looked into the details. 06:32:48 tantek: I agree with the general scop eof the proposal. 06:33:24 RESOLVED: Replace region-fragment with 'fragmentation', written by Florian, determine where it belongs. 06:33:37 fantasai: Why is max-lines only usable on fragmentainers? Should be on all containers. 06:33:41 fantasai: block containers. 06:36:25 [discussion over this] 06:37:19 [???] 06:37:20 (unminuted discussion about fragmentainers) 06:37:26 [?????????] 06:37:35 (height, fragment or not, making breaks) 06:37:42 [?????????????????????????] 06:37:42 s/[?????????]/[????????????????]/ 06:39:11 Florian: So right now, if you say max-lines:3 on a

in the middle of a page, it'll break the page after the third line. 06:39:25 Florian: Which is silly, so we need the

to be a fragmentainer. 06:39:49 Florian: To be automatic, maybe max-lines:non-none causes fragmentation:auto to compute to 'break'. 06:39:53 fantasai: 'break' is a non-obvious name. 06:40:01 ShmabShmatkins: Maybe 'discard'. 06:40:10 Rossen: So max-lines is non-inherited. 06:40:33 Rossen: So what if you have

...
06:40:51 Florian: Well, regardless of that answer, max-lines should apply to any block. 06:41:03 fantasai^: So, what I understnad is that the proposal is to take the values of 'overflow' that deal with fragmentation andmake them into a separate property, and add a value that does fragmentation but hides the overflow instead of continuing it on another page/clone 06:41:16 astearns: David defined this well in the Overflow spec where he tries to take your case into account. 06:41:26 astearns: We can resolve the issue over there. 06:41:26 http://dev.w3.org/csswg/css-overflow/#max-lines 06:41:53 astearns: But the discussion is about fragmentation. 06:42:05 q? 06:42:15 Florian: So do we want to do regular pagination with this fragmentation property? 06:42:22 fantasai: I was thinking paging was overflow:paged on the root element. 06:42:47 fantasai: overflow:paged creates pages the same way that scrollbox creates a scrollable canvas in the viewport. Instead of scrolls, you get pages. 06:43:02 fantasai: Each of those pages are styable with an @page rule, regardless of whether the whole doc is paged, or a small section. 06:43:48 Florian: So in some contexts, auto becomes paged, and maybe 'break' becomes 'overflow:hidden' or whatever on the root element. 06:45:05 RESOLVED: Split fragmentation values of 'overflow' into a separate property. Further develop this in the overflow module. 06:45:20 Has it been defined what kinds of elements each of those pages has? 06:45:44 (header, body element, footnote area, page number area, page float area?) 06:46:07 Florian: That property that gets separated out, is the region-fragment property. So pull it out. 06:46:17 Or can it be definable by the user? 06:46:58 RESOLVED: region-break gets folded into the new property, too. 06:47:17 astearns: If this goes into Overflow, add Florian as an editor? 06:47:19 dbaron: Yes. 06:47:28 RESOLVED: Florian added as editor to Overflow. 06:48:04 fantasai: Do we have a def of overflow-x/y? 06:48:08 dbaron: Kinda, in Overflow. 06:48:32 fantasai: Gonna say that when we have that, we cut that as Overflow 3 and have everything new in Overflow 4. 06:48:59 Florian: I think region is the only fragmentainer that have ::before/after, but now you can. 06:49:19 astearns: We needed ::before/after in our processing model to see how they work in named flows. 06:50:15 astearns: If we assume that ::before/after are always blocks in a fragmentainer (what we currently do), then we'd want to extend that. 06:50:36 fantasai: What if the remaining space is negative? 06:50:40 Rossen: Defined in the region spec. 06:50:48 fantasai: Can they turn into runins? 06:50:52 Florian: I'd like to. 06:51:30 Florian: When you're doing ::after on fragmentainer, there are cases you want to only do ::after if you're fragmenting. 06:52:09 Florian: So maybe have an ::ellipsis-like thing to help handle that. 06:52:47 fantasai: Then we have the remaining issue about how to make it interactive. 06:53:38 florian: That's a general pseudo-element issue 06:53:50 fantasai: yes, but it's a core part of these use cases; not so much for other pseudos 06:53:53 heycam: How do you align the ::ellipsis? For the block one, does it appear as a block right below? 06:54:31 Florian: The way I remember it is "you know how wide this thing is, so you can lay out your ::after". 06:55:11 johanneswilm: I tried to do footnotes with regions, and ::before/after were problematic. 06:55:32 johanneswilm: I couldn't have a footnote marker get left behind, etc. 06:56:42 [?????????????????] 06:58:05 dbaron: I initially wanted [it] that way... 06:58:19 dbaron: We realized there was a rpoblem that you design some style with overflow:fragments, style each fragment, 06:58:29 dbaron: Then fragment 2 gets a page break in it. 06:58:47 dbaron: You don't want your styles to be one off because you fragment3 styles get applied to the second half of what was originally fragment 2. 06:58:53 s/[?????????????????]/johanneswilm and dauwhe got distracted by footnotes and went off-topic/ 06:58:55 dbaron: Probably a way around that, but we're getting complicated. 06:59:41
07:00:01 Florian: do we want a one-off fragmentation value for columns, or use 'clone' 07:00:07 fantasai: use a magic value 07:00:21 dbaron: not so sure, I wouldn't want to have to explain what that magic does elsewhere 07:01:39 TabAtkins, fantasai: Tiki Bar: ~18:30 Papa Gede's bar, 348 Kent Street. 07:21:17 tantek has joined #css 08:06:17 svillar has joined #css 08:17:55 rego has joined #css 08:26:37 antonp has joined #css 09:10:55 Ms2ger has joined #css 10:07:24 lajava has joined #css 11:19:33 zcorpan has joined #css 11:55:57 dbaron has joined #css 12:10:18 Florian has joined #css 12:18:01 dauwhe has joined #css 12:24:02 jdaggett has joined #css 12:44:14 Florian_ has joined #css 12:52:39 Florian has joined #css 13:00:46 antonp has joined #css 13:17:55 tantek has joined #css 13:36:45 lajava has joined #css 13:49:06 svillar has joined #css 14:26:15 johanneswilm has joined #css 14:56:21 johanneswilm has joined #css 15:19:16 thinkxl has joined #css 15:34:25 lajava has joined #css 16:05:03 johanneswilm has joined #css 16:18:08 Florian has joined #css 16:52:19 bkardell_ has joined #css 16:53:47 anyone with practical implementation knowledge handy atm? 16:53:56 have a simple question 17:12:10 estellevw has joined #css 17:12:59 Ms2ger has joined #css 17:24:32 johanneswilm has joined #css 17:30:10 adenilson has joined #css 17:34:55 shepazu, around? 17:35:04 hey, Ms2ger 17:35:38 shepazu, I'm hearing that the ED link on http://www.w3.org/TR/webmidi/ is broken; is that something you could get fixed in-place? 17:36:32 Ms2ger, I can ask... it's not normally something we do :( 17:36:52 I'd appreciate that 17:37:08 If not, can you keep an eye on it for the next pub? 17:37:23 Also, don't we run linkcheckers anymore? 17:37:37 Oh 17:37:45 Wrong link, not broken link 17:37:54 right 17:39:51 should be http://webaudio.github.io/web-midi-api/ 17:41:48 lajava has joined #css 17:48:27 Ms2ger, current policy is to publish a new draft, still can't update in place :( (though apparently that might be changing soon) 17:49:11 Ah, W3C slowly being dragged into the last century? :) 17:50:23 Ms2ger, don't get me started :P 17:50:52 Ms2ger, but I'm starting the process to publish a new draft, anyway... it needs one, after 1.3 years 17:51:00 You're right, I'd rather not :) 17:51:15 wfm 17:52:09 bkardell_, everyone's in Australia, so you should ask time-shiftedly 17:52:09 Thanks 17:52:35 shepazu, (mumble mumble heartbeat) 17:53:53 Ms2ger, yeah, I should crack the whip a bit more... I don't know what the changes to the spec would be... it's mostly waiting on implementations, I think 18:07:45 johanneswilm has joined #css 18:09:14 Ms2ger has joined #css 18:12:17 lajava has joined #css 18:59:27 Ms2ger has joined #css 19:01:59 dauwhe has joined #css 19:07:29 johanneswilm has joined #css 19:42:12 johanneswilm has joined #css 20:09:03 dauwhe has joined #css 20:21:23 johanneswilm has joined #css 20:23:47 glazou has joined #css 20:26:32 plh has joined #css 20:39:18 dauwhe has joined #css 21:05:53 dauwhe_ has joined #css 21:16:38 glazou has joined #css 21:44:11 zcorpan has joined #css 21:49:49 glazou has joined #css 21:58:40 hyojin has joined #css 22:05:31 dbaron has joined #css 22:06:36 smfr has joined #css 22:07:03 dauwhe has joined #css 22:08:25 roc has joined #css 22:09:02 plinss: is csswg.org going to come back? 22:09:14 oh there it is 22:09:32 it just seems to be running slow this morning, not sure why... 22:12:13 kwkbtr has joined #css 22:17:58 speed: molasses | glacial | intercontinental-drift | galactic-formation 22:18:08 | initial | inherit | auto :) 22:19:51 gregwhitworth has joined #css 22:22:11 xidorn has joined #css 22:22:29 Florian has joined #css 22:29:26 AndreyR has joined #css 22:34:49 Scribenick: TabAtkins 22:35:02 Topic: Rounded displays (sponsored by LG®) 22:35:07 https://www.w3.org/wiki/TPAC2014/SessionIdeas#CSS_Extensions_to_support_a_round_display 22:35:13 dino has joined #css 22:35:13 http://www.w3.org/2014/10/29-rounddisplay-minutes.html 22:35:19 http://www.w3.org/wiki/images/8/84/141029_W3C_TPAC_Breakout_Session_Round_Display.pdf 22:35:34 Hyojin: My name is Hyojin Song, working at LG's Software Platforms Lab. 22:35:52 murakami has joined #css 22:36:41 hyojin: This is the first time for LG to present something to the CSSWG. 22:36:49 hyojin: We have WebOS, embedded in TVs and watches. 22:36:58 ScribeNick: fantasai 22:36:58 hyojin: LG personally released a watch with WebOS last Jan. 22:37:04 hyojin: The platform is the web. 22:37:07 hyojin: Like HTML, CSS. 22:37:21 hyojin: HTML and CSS should support some requirements to present web content to web-based device 22:37:28 hyojin: LG smart watch display is round 22:37:39 hyojin: When developing apps, we have some difficulty aligning content sin the device this way 22:37:47 hyojin: So we would like to propose some ideas for orund display 22:37:53 hyojin: This is a slide presented last TPAC 22:38:02 hyojin: I'm going to briefly show you the concepts of our ideas using this slide 22:38:09 hyojin: New devices with ar round screen are emerging 22:38:26 hyojin: Here are 4 devices: ASUS ZenWatch, Moto360 LG G Watch R LG G3 when cover is close 22:38:30 closed 22:38:40 hyojin: Web was designed for a rectangular screen, especially CSS 22:38:45 tantek has joined #css 22:38:51 jet has joined #css 22:38:52 hyojin: Here are some LG watch appplications [phtographs] 22:39:01 compass app, weather app, phoe dialer, etc. 22:39:06 hyojin: CSS should make these applications 22:39:16 hyojin: We have 4 ideas 22:39:21 hyojin: First is extension of media query 22:39:28 hyojin: Detect a round display 22:39:39 hyojin: Defined a 'device-radius' property, inspired by border-radius 22:39:59 hyojin: We made a specification like this. Very immature, but we have summarized here 22:40:03 [projects spec draft] 22:40:13 hyojin: Takes same syntax as border-radius 22:40:14 jaredwy has joined #css 22:40:28 is there a URL for that spec? 22:40:30 hyojin: 0% is rectangular display 22:40:42 hyojin: Round display 22:40:48 hyojin: Can dtect the shape of the display 22:40:57 sanja has joined #css 22:41:11 Florian: I think the MQ is quite reasonable 22:41:18 Florian: How complicated or simple do we want to be? 22:41:26 Florian: There's a clear real use case for rounded display 22:41:37 Florian: what do we do about e.g. triangle display or whatever? 22:42:09 fantasai: we have proposals for addressing this for borders, triangles for example, changing the shape for the corners 22:42:15 fantasai: this approach is fine and we can extend as we need 22:42:27 glazou: Devices fo rmobile are changing very rapidly 22:42:48 glazou: Change shapes in 2d, but also in 3d, e.g. rounded surface. Display is different on the curve 22:42:54 glazou: First bendable screen just appeared 22:43:06 glazou: Will reach a completely new set of characteristics of screens that we will need to cover in the future 22:43:30 Florian: Works for rect, rounded rect, ellipses, but what else? 22:43:53 roc: Do we have the goal of only detecting what shape it is and use MQ to create different layouts for each shape 22:43:59 roc: Or create layouts that will adapt to any shape 22:44:08 roc: MQ will help with the first, not the second 22:44:23 roc: Need to decide on goal, one or other or both. 22:44:41 hyojin: device-radius is limited in expressivity 22:44:47 hyojin: Next topic is content alignment 22:44:55 hyojin: CSS shape-inside 22:45:05 hyojin: In rectangle display like this [floats and text in rectangle] 22:45:17 hyojin: If you put it on a round display, the corners cannot be shown on the display 22:45:28 hyojin: We want the content to flow inside the shape, like this [photo] 22:45:41 hyojin: We extended shape-inside like this: add value 'display' 22:46:21 hyojin shows content flowed into a circle 22:46:45 hyojin shows content that starts partway down the screen, wraps into the semicircle of the bottom of the screen 22:47:11 hyojin: We didn't implement in browsers, we automatically generate the shape like this [shows code] 22:47:25 hyojin: Next topic is border 22:47:46 hyojin: Borders extend outward from the edge of the screen, want it to fit in the screen. 22:48:06 hyojin: So we defined new 'border-boundary' property, values 'none' or 'display' 22:48:48 Florian: Did you consider keyword to make shape-inside and border-boundary to match? 22:48:58 astearns: I think it's a different problem they're trying to solve 22:49:11 astearns: They're trying to ge tthe childrens border to match the contours of a parent's shape-inside 22:49:26 Florian: Exactly. Parent has hape-inside: display 22:49:36 Florian: The children match the shape-inside of the parent 22:49:56 tantek: This feels like a position: fixed approach 22:50:03 tantek: relative to display 22:50:11 tantek: vs. position: absolute, where relative to some other block 22:50:45 dbaron I think it would also be possible to inset the borders as you go down the tree 22:50:55 dbaron: propagating the shape down based on margin/pdding/border 22:51:10 rossen: You gotta be able to find the shape going down. Display is only oneof the shapes as you're going down 22:51:22 hyojin: Many issues, something to consider, so we wrote the issue sin the spec 22:51:38 hyojin: I will share these materials into the CSS mailing list 22:51:45 hyojin: We can discuss topics of round display issues 22:51:51 hyojin: Last one is about layout features 22:51:59 Rossen: back on the borders 22:52:05 Rossen: This is easy to explain for solid borders 22:52:15 Rossen: What do you expect the behavior to be for, e.g. border -styles other than solid 22:52:39 Rossen: say I have a dashed border-right and a dotted border-top border 22:52:56 dbaron has joined #css 22:52:56 fantasai: Probably same way as you solve it for border-radius 22:53:37 Rossen: If it's round-ish, that works, what if it's a star? 22:53:46 Florian: Will require wordsmithing, but not an unsolvable issue 22:53:59 fantasai: Take 45deg from center, find that point on the shape, or some other formula 22:54:10 johanneswilm has joined #css 22:54:12 hyojin: Using canvas, I can draw differnet border shapes 22:54:35 hyojin: Last one is layout 22:54:50 hyojin: We propose polar coordinates, to position around circle like this 22:55:15 hyojin: polar-angle and polar-distance properties with position: polar 22:55:22 SteveZ has joined #css 22:55:32 e.g. 'polar-angle: 225deg; polar-distance: 100%' 22:55:54 dirk: Positioning only, or other layout? 22:55:57 hyojin: Just positioning 22:56:28 TabAtkins: Other than the fact that 'position: polar' would go on the children, not on the container (be just like alternate version of abspos), looks good to me 22:57:29 dean: Which point is positioned at that point? 22:57:41 fantasai: polar-origin property to determine it 22:57:57 It should take an 'auto' value maybe that does automatic anchoring like backgrounds do 22:58:00 heycam: maybe better as a transform item, an alternate way of specifying a translate 22:58:09 jumland has joined #css 22:58:20 glazou: Rounded display on a sphere, turning, ... 22:58:41 glazou: Why polar coordinates instead of transforms? 22:58:47 hyojin: We developed this using transforms 22:58:55 hyojin: I think the developer cna make applications like this easilky 22:59:07 TabAtkins: One nice thing about this is that you can animate this very nicely 22:59:13 TabAtkins: E.g. spiraling outward much easier. 22:59:37 tantek: This example makes it looks like the distance: 80% was very carefully chose to make it look like there is padding is on the parent that the children bump up against 22:59:43 tantek: Feels like a very fragile way of doing it 22:59:56 tantek: If you change the font size, or the radius of theelements, it will no longer fit nicely 23:00:14 tantek: I wonder if percentage-based distance abspos is what you want, or some model of polar box model 23:00:46 TabAtkins: You can always do calc(100% - half-of radius). 23:00:47 q+ 23:00:59 Florian: Yes if you know your radius 23:01:08 Zakim, ack fantasai 23:01:08 I see no one on the speaker queue 23:01:19 Ya keep sayin’ ma name, Zakim. What is up? 23:01:19 Hello 23:02:04 fantasai: if you have the ability to set origin the way backgrounds do, then you cna take the size into account as positioning 23:02:23 tantek: abspos does a nice job of taking into account borders/padding 23:02:41 tantek: I would challenge this to be as simple as abspos 23:03:37 q+ 23:03:51 q+ 23:03:54 roc: q+ 23:03:57 oops 23:03:59 q+ 23:04:00 fantasai: You might want to have border/padding consideration, yes, but if you can do positioning like backgrounds then you can do offsets and positioning that take into account the size of the item 23:04:14 johanneswilm has joined #css 23:04:29 tantek^: abspols lets you do positioning from the edge without doing calc etc. 23:04:57 fantasai: Abspos doesn't do e.g. centering without knowing the size of the box. background positioning can do offsets, but also more than that 23:05:02 dbaron: Absolute positioning is pretty fragile in most cases. 23:05:06 the example shown looks like it is pushing the child elements to the edge of the padding of the parent - automatically - without having to magically pick 80% 23:05:10 ack me 23:05:21 I would like to NOT have to pick 80% based on the radius of the child, parent etc. 23:05:31 zcorpan: My point was already said by fantasai: background-positioning can do offsets 23:05:33 q+ 23:05:39 Zakim, ack dbaron 23:05:39 I see roc, SteveZ on the speaker queue 23:05:50 dbaron: I would not want to follow abspos as a model 23:05:54 and rather do it like abspos where you it takes into account both the padding of the containing block, and the border of the child 23:06:02 dbaron: We've done a lot of things with layout systems that do more flexible and produce better results 23:06:10 Zakim, ack roc 23:06:10 I see SteveZ on the speaker queue 23:06:16 my point was it should be NO WORSE than abspos 23:06:17 cyril has joined #css 23:06:20 if we can do better, great 23:06:22 roc: Since this ise easily fpolyfillable in its current form 23:06:37 roc: Mabye we produce better custom layout and style integration 23:06:46 roc: do this insteadof adding it to the CSS core 23:06:53 roc: If this has to go into CSS core, then what wouldn't? 23:07:02 ack me 23:07:09 glazou: Even for polyfills, 2 different editors of polyfill for this would like to rely on the spec 23:07:26 roc: Could have a spec for feature sthat are implemented in polyfill rather than in browsers 23:07:36 Zakim, ack SteveZ 23:07:36 I see no one on the speaker queue 23:07:43 roc: Need to be clear about which it is, makes a big difference to constraints around the design 23:07:50 szilles:... 23:08:02 SteveZ: If I consider a center an edge and an angle, it has all of the properties that you want 23:08:07 SteveZ: Could talk about edge shape 23:08:13 ChrisL has joined #css 23:08:33 SteveZ: Adjusting along an angle-line, either toward the center or toward the ege, and has exactly the same set of properties abspos has to day, and you could even use it for squares 23:08:43 SteveZ: So you could use it for better positioning 23:08:51 tantek: Goal is to avoid collisions by default 23:09:07 SteveZ: If you wnat it to touch the outer edge, you say 0 on the outer edge, same as you do with picking left/right/top/bottom 23:09:15 SteveZ: same rules as abspols 23:09:26 SteveZ: Center, you may want a different rule, e.g. center me on the center 23:09:38 SteveZ: Tab's point was that it generalizes the same way 23:09:55 hyojin: In future, need extensions for smart watch 23:10:03 hyojin: I think these are reasonable 23:10:24 hyojin: Will send this to CSS ML, and will collect problems from developers making round dsiplay. I will share wtih CSS WG. 23:10:27 hyojin: Thank you 23:10:32 glazou: Thank you for the presentation 23:10:39 glazou: The way you are expcting to contribute to the document 23:10:48 glazou: Are you requesting an Editors Draft at this point? 23:10:52 hyojin: Yes, we'd like to publish this 23:11:07 Florian: I'm happy about including these ideas, but many of these look like they belong in existing documents 23:11:16 Florian: E.g. put rounded display MQ into the MQ spec 23:11:34 glazou: We could do that, or until things stabilize a bit more, keep them in a separate document 23:11:40 glazou: A partial solution is not enough for LG 23:11:57 glazou: So I think for the time being, keep it all into single editors draft, and as soon as they stabilize dispatch them. 23:12:11 glazou: Proposal is new ED with editor as LG 23:12:14 fantasai: Shortname? 23:12:20 agreed with keeping it all together in a first editor's draft 23:12:34 roc: Might be good to have a spec for all of coordinate layout 23:12:47 roc: If it's not in a browser, then doesn't need to go through W3C 23:13:13 glazou: We have a way to say a spec is not required 23:13:29 roc: Could have the polyfillers sstandardize in a decentralized way 23:13:53 roc: CSSWG's expertise is useful, but that is also useful 23:14:00 q+ 23:14:20 glazou: LG is leading the effort, but it is clear that other vendors with rounded display watchs will have exactly the same issue 23:14:51 glazou: Application authors wanting to address these devices will want a standardized way to develop apps 23:14:58 Zakim, ack ChrisL 23:14:58 I see no one on the speaker queue 23:15:01 q+ 23:15:12 ChrisL: W3C is about interop and getting people to work together. It's not about browsers only. 23:15:42 ChrisL: It's better that people liaise with us, and it's better that we can comment and say in f5 minutes "no, no don't do that! do it this way" 23:15:53 ChrisL: than they continue down 23:16:04 ChrisL: They've taken initiative to come here, we should reciprocate. 23:16:09 ... 23:16:13 Zakim, ack SteveZ 23:16:13 I see no one on the speaker queue 23:16:21 SteveZ: First, there is a cost to doing this, which is it takes us time to review each of these specs 23:16:22 glazou: and the expertise on CSS is here 23:16:24 SteveZ: not zero cost 23:16:29 open source round display watch (failed kickstarter) https://www.kickstarter.com/projects/958981650/the-pi-watch-a-programmable-open-source-smartwatch 23:16:39 SteveZ: There is also a benefit, which is people here have knowledge about how to put thing sinto CSS in a CSS-like way 23:17:12 SteveZ: We've had several discussions through the day,where people make comments on how ... e.g. dbaron's comment about unstled divs and spans being no-ops 23:17:14 I'm logging. Sorry, nothing found for 'where' 23:17:18 I'm logging. I don't understand 'link', dino. Try /msg RRSAgent help 23:17:22 I'm logging. Sorry, nothing found for 'link' 23:17:23 SteveZ: It's good to discuss these so that we don't make it difficult to extend CSS in the future 23:17:24 q+ 23:17:25 q+ 23:17:37 SteveZ: I'm of the opinion that we should do the spec, and don't care how it's implemented 23:17:40 Zakim, ack Florian 23:17:40 I see tantek on the speaker queue 23:17:52 q+ to partially agree with SteveZ, and partially to encourage experimentation to learn from use-cases 23:18:04 Florian: Just as MQ spec editor, I just wnat to say I'm happy with either approach. 23:18:16 Zakim, ack tantek 23:18:16 tantek, you wanted to partially agree with SteveZ, and partially to encourage experimentation to learn from use-cases 23:18:18 I see no one on the speaker queue 23:18:23 Florian: If you would like in MQ draft, would be happy to help 23:18:25 q? 23:18:39 tantek: Would partially agree with Steve's observation that our review is beneficial 23:18:50 tantek: Part of me also wants to see more rapid experimentation, even if solutions are imperfect 23:18:54 q+ 23:18:54 tantek: To use that to learn from the use cases 23:19:07 tantek: To experiment e.g. how do we get things to not overlap 23:19:17 tantek: Learning how prolbems occur in this kind oflayout is itself valuable 23:19:24 tantek: I want to avoid discouraging experimentation 23:19:38 tantek: Specifically avoid scenario of numerous webkit properties being thrown out there 23:19:42 q+ 23:19:56 tantek: without any discussion with WG 23:20:13 dirk: Do we have a way for extending MQ? 23:20:20 TabAtkins: yes 23:20:34 ChrisL: You can link thigs up by having a note in MQ pointing ot the other draft 23:20:35 ack krit 23:20:35 q- 23:20:43 glazou: This only raises one question about what we call an implementation 23:20:50 glazou: We shall now consider a polyfill as an implementation 23:21:29 ... 23:21:47 ChrisL: So you think the wording needs clarification that it qualifies 23:21:53 q+ 23:22:04 dbaron: I think that maybe requires more clarity bout which specs are expected to be implemented in browsers vs. polyfills 23:22:22 dbaron: polyfill should be a valid implementation for the latter type of spec 23:22:29 fantasai: I don't see why there needs to be a distinction 23:22:52 dino: How many browsers does it have to work in? 23:23:01 q+ 23:23:14 ack roc 23:23:15 roc: Implementation in a browser uncovers more interaction problems, that a polyfill might not notice or might not even run into 23:23:46 Florian: As an answer to this, when we count a browser to continue passing previously-passing tests 23:23:49 Zakim, ack glazou 23:23:49 I see zcorpan on the speaker queue 23:24:21 roc: The issue is with interaction of features, e.g. combine multico with X and it explodes 23:24:31 roc: Feature A and Feature B both work, but A+B explodes 23:24:34 jdaggett has joined #css 23:24:37 ack zcorpan 23:24:40 zcorpan: There are also different constraints between browser and polyfill 23:24:46 Zakim, ack zcorpan 23:24:46 I see no one on the speaker queue 23:24:49 hi jdaggett 23:24:52 zcorpan: A polyfill doesn't have t o care about optimization sin the browser, like the preloader 23:24:59 zcorpan: If it does all of its work after all the document is loaded 23:25:09 glazou: morning! 23:25:18 zcorpan: A native implementation might want to do the work during parsing, when element is inserted into DOM 23:25:22 vollick__ has joined #css 23:25:35 glazou: Would it be acceptable to say that for now a document that is aimed only at polyfills accept polyfills as a valid implementation 23:26:47 q+ 23:26:49 q+ dino 23:26:54 q- 23:27:09 fantasai: I'm concerned that if we design specs only for polyfills, we will end up with specs that *can't* be implemented in browsers, should we decide it ought to be folded into the core 23:27:19 ...???? 23:27:21 Florian: ??? 23:27:51 ChrisL: Sounds like we had weak consensus on allowing polyfills as implementations, then discussed having polyfill-sepcific spec,... 23:27:54 dbaron: If a REC says it's designed for polyfills, then sure, we might need to change it in order to produce a REC that can be implemented in browsers. 23:27:59 ChrisL: You really odn't wnat to have to move around your code 23:28:13 ChrisL: we run into the prefixing issue again 23:28:19 wow how did we descend in to details of polyfilling vs. process? 23:28:34 TabAtkins: Polyfilled properties are --foo anyway, so you have the prefixing built into the polyfilling 23:28:40 ... 23:28:48 heycam: standardized version in a browser isn't triggered by that property 23:28:56 dirk: We do not have custom layout 23:29:08 dirk: We have to dcide on this propsal right now. Very interesting discussion, but doesn't help LG right now 23:29:25 q- 23:29:26 TabAtkins: Custom layout will be the hardest part of Houdinin, so a long time from now 23:29:42 TabAtkins: If ucstom layout existed today, mabye different approach, but doesn't exit right now 23:29:50 TabAtkins: Let's do this simple stuff 23:30:00 glazou: Sounds like return to LG, push other stuff to ML 23:30:24 Florian: What does LG want wrt splitting? 23:30:28 dirk: I thin kit should saty the same 23:30:32 glazou: I'd like to review that document 23:30:39 The part of the document I'm most concerned about is the polar coordinate layout bits. 23:30:49 glazou: New editors draft for this? 23:30:52 fantasai: I'm in favor 23:30:53 +1 new editor's draft 23:30:54 tantek: me too 23:31:05 dbaron: I'm in favor, but I'm concerned about polar coordinates 23:31:11 fantasai: Yes, I think it needs work 23:31:22 tantek: Decide on a place for issue to be capture, and ed to link to that 23:31:24 glazou: In the document 23:31:45 tantek: File issues and not block publication 23:31:56 Florian: send mail to www-style 23:32:06 ChrisL, glazou: Don't see how this is different from previous docs 23:32:09 tantek: ... 23:32:20 ChrisL: So you're encouraging use of that existing rule [ to indicate tracker ] 23:32:21 Florian: this has nothing to do with sending email 23:32:32 [bikeshedding shortname] 23:32:44 css-round 23:32:47 css-rounded-display 23:32:54 Rossen: css-o 23:33:00 dbaron: it's a focused-enough specification that it should have a longer shortname 23:33:25 this has to do with requiring a link from the editor's draft to a *specific* place for tracking issues, e.g. W3C Bugzilla, Tracker, or a Wiki page 23:33:31 +1 to css-roundisplay 23:33:44 css-polar? 23:33:44 +1 23:33:45 RESOLVED: Add css-round-display as ED 23:38:07 johanneswilm has joined #css 23:41:39 estellevw has joined #css 23:42:14 timeless has joined #css 23:48:35 ojan has joined #css 23:48:55 break? 23:49:25 just ended, about to resume 23:49:50 JonathanNeal_ has joined #css 23:51:18 Topic: CSS UI 23:51:23 tantek: In pretty good shape with CSS Ui 23:51:25 https://wiki.csswg.org/spec/css3-ui#steps-to-pr 23:51:28 tantek: Set of steps to get to PR 23:51:40 murakami has joined #css 23:51:45 tantek: We're down to about 7 semi-substatial or substantial issues, resolutions on most of them 23:51:59 tantek: Steps to PR we've go tset of drafts to publish, one queued up 23:52:04 tantek: fixes to issue sat this meeting 23:52:17 tantek: Interest in testcases? spec is probably stable 23:52:26 tantek: features is stable, cutitng things, not adding things 23:52:44 ChrisL: Coudln't run the first test 23:52:58 ChrisL: for directional navigation 23:54:00 fantasai: I would like to see a WD of what you think should be going to LCCR, i.e. after you've fixed the oustanding issues, and then request a review of that. You haven't demonstrated wide review 23:54:14 jdaggett: we’ll set that up for next topic, css inline, ok, 23:54:35 ah, ok 23:55:02 Current issues: https://wiki.csswg.org/spec/css3-ui#current-issues 23:55:39 tantek: Issue 47 23:55:46 tantek: Objection from Tab to resolution, +1 from smfr 23:55:47 https://wiki.csswg.org/spec/css3-ui#issue-47 23:56:09 tantek summarizes the issue 23:56:19 original spec talked about a "resize factor" that was maintained 23:56:45 implementations instead modify 'width/height' inline styles directly 23:57:09 tantek: downside of speccing that is that it limits how you handle e.g. resizing of the window by the user 23:57:21 tantek: You rob the author and user of having interfaces that dynamically resize in a sensible manner 23:57:34 tantek: Resolution at last telecon was to change "factor" to "function" 23:57:42 tantek: and allows for more intelligent resizing 23:57:57 tantek: The point here is t not restirct the web platform in ways that preven tit from being competitive with native platforms 23:58:13 tantek: That's the goal of sticking with the function wording, rather than rtificially restricting to style attrs 23:58:32 Florian: Current behavior with browsers does fall short where we could do better 23:58:51 Florian: I disagree that the funciton is a good way to solve this, because it's so generic, better ones and worse ones, could be conformant 23:59:18 Florian: Also, I think it's reasonable to spec in adetailed way what is currently implemented, but also to extend it 23:59:37 Florian: e.g. say "resize me, but do so in percent, rather ahn in pixels" or "resize me in ems rather than in pixels" 23:59:58 Florian: The function that you allow is undefined, which is good because it allows good behavior, but is also bad because it also allows bad behaviors 00:00:07 +1 Florian 00:00:15 Florian: Would rather spec what browsers are actually doing, and allow extending 00:00:20 Dean also said +1 00:00:35 I think the underlying problem with 'resize' is that the feature was specified at the wrong layer of the platform (too low). 00:00:36 +1 00:00:41 fantasai: What would would be worse than the current behavior? 00:01:43 Florian: ... not ineroperable 00:02:16 fantasai: So your issue is that non-interoperable is bad. I'm asking, what is a specific behavior that is worse than the curent behavior? Because I think the current bheavior is the worst tha I can think of that isn't pathological (e.g. semi-random output on resize) 00:02:33 dbaron: I think the underlying problem with this feautre is that it was designed at the wrong layer of the platform 00:02:47 dbaron: Was trying to hookinto low-level CSS width funcitons what should have been a hgher function 00:03:03 dbaron: It's a lot of work for something that shows up in hgh-evel controls 00:03:20 dbaron: Implementations proxy it down to a lower level, using what authors could use to do it 00:03:41 dbaron: reue their existing code rather than changing width/height computation for everything else in their codebase 00:03:46 dbaron: We have a legacy feature 00:03:51 dbaron: We should just spec it better 00:04:09 q+ 00:04:11 dbaron: And figure out a better way to have the feature that doesn't go poking in low-level CSS calculations 00:04:20 tantek: The intent was to keep it high-level from the start 00:04:41 tantek: that's how it started, trying to specify purely as a high-level feature, not imposing at all on how impl implemented it 00:04:49 tantek: The factor was a possible case, generalize dto function 00:05:03 tantek: There seems to be that even that is specifying too much 00:05:12 TabAktkins: Not specifying enough 00:05:20 tantek: Goal was to make this a high-level feature for authors 00:05:29 tantek: Not sure what different approach could be takn 00:05:36 TabAtkins has joined #css 00:05:53 Florian: What we have now is extensible 00:05:59 tantek: By specifying new values 00:06:44 fantasai: The default behavior would still be the stupid behavior, that doesn't resize well. Even if you add more keywords, the number of people who use it would be negligible 00:06:55 tantek: Should do the right thing by default 00:07:23 Florian: I have wording for the current interop behavior 00:07:33 Florian: Blink and webkit differ from FF in a couple cases 00:07:49 Florian: I propose to spec this and see if anyone disagrees 00:07:55 Florian: built up from tests 00:08:11 zcorpan: When and if we do come up with a successor of this feature, that can provide better behavior 00:08:29 zcorpan: I thin kit is good to not let the different browsers choose different behaviors for the same request from teh authors 00:08:40 zcorpan: bad if .e.g one browser uses pixels and other uses percents 00:09:44 fantasai: The author doesn't notice any problems or differences in behavior because they're designing in a single size 00:10:12 fantasai: The differences in behavior only show up when you resize the window 00:10:31 tantek: Resizing the window is pretty common *rotates his phone* This is resizing the window 00:10:37 achicu_____ has joined #css 00:10:48 Tab, florian: You just resize it again. 00:11:00 tantek: If the sceen gets narrow I can't get to the resie handle 00:11:05 tab: scroll an resize again 00:11:22 [basically user has sucky experience because we have interop, and we don't give a shit] 00:11:44 tantek: You want to make the poor behavior a must? 00:11:55 JonathanNeal_ has joined #css 00:11:59 hola 00:12:16 lmclister______ has joined #css 00:13:04 fantasai: So I don't unerstand the suggestions to create a new feature that does better 00:13:15 fantasai: Either you are happy with the existing behavior, or you want a better behavior. 00:13:29 fantasai: if you want a better behavior, you could do it by adding a new feature, or you can do it by improving the existing one 00:13:42 fantasai: The only reason to create a new feature rather than imprving the existing one is if you have a legacy problem 00:13:49 fantasai: I don't think we have a legacy problem 00:13:56 s/problem/problem here 00:13:58 heycam: thanks! 00:14:18 [...] 00:14:37 tabatkins: floating first letter is an example where we had bad behavior, couldn't improve it so made new feature 00:15:29 tantek: Did design methodology change? 00:15:54 ChrisL: Must is what you should say in all cases where you know what is the right hting to do 00:16:05 ChrisL: Should allows you to not o that if you have a good reason, but good reason is not defined 00:16:35 SteveZ: Should was being used often in cases where there was not interop, and we didn't expect interop in the timeframe of getting the spec out, but there was at least one version that people could match over time to get interop 00:16:53 SteveZ: So we used should in context of saying, you're not going to be an invalid implementation just ecause of the fact you don't match it now, but this i where we want people to be going 00:17:11 tantek: So if there was in implementation of resize of good behavior, we could put a should 00:17:20 SteveZ: Yes, and we could spe cthat particular one as a should 00:17:57 fantasai: And we use d'may' in cases where we didn't have an implementation, but we knew which direction we wanted to go to 00:18:12 tantek: My memory agrees with what steve was saying 00:18:36 tantek: I'm oky with speccing style attr in pixels, and nobody shows any intent to make it better. 00:19:10 https://wiki.csswg.org/spec/css3-ui#issue-48 00:19:10 RESOLVED: spec sucky behavior because we have interop and nobody wants to make it better 00:19:22 Florian: cursor: auto is vaguely defined 00:19:54 RESOLVED: spec resize property to inject 'width/height' style attr values in pixels 00:19:57 I guess my opinion about it being badly designed might not be as strong as it was 10 minutes ago, after looking at our code. 00:20:15 tantek: We had a group discussio non auto cursor, to try to restrict auto value as much as possible 00:20:24 tantek: define specifics instead 00:20:37 tantek: issue wrt resze areas and scollbars 00:20:44 tantek: proposal handles this, but may need additional wording 00:21:08 though I still don't know how resizing the old way would interact with something like flexbox 00:21:12 Florian: dbaron's original proposal of switching between switching between text vs. default 00:21:19 (old way being as a resize factor) 00:21:25 Florian: either out of scope for CSS, or expressable in a UA style sheet 00:22:03 Florian: We decided that resize cursor for the resize handler is an override over whatever cursor value tha author chose, not specific to auto 00:22:22 Florian: You can do magic over links for auto, but don't have to 00:22:36 Florian: The only thing that needs to be magic inside auto is text vs. empty space 00:22:54 ChrisL: Should we have some way to know whether you're empty space or text 00:23:07 tantek: Don't have a way to detect scrollbars or ersize handlers either 00:23:14 Florian: We don't have a ::cursor pseudo 00:23:42 ChrisL: So proposal is to have auto switch between 'default' and 'text' base don whether you're over text 00:24:07 tantek: and text already hadles horizontal vs vertical text cursors 00:24:34 ChrisL: what about links? 00:24:41 Florian: You hae a ua style rule for that 00:24:53 zcorpan: If you specify auto on a link, then you get a text cursor 00:25:03 zcorpan: html style sheet requires UA to specify pointer on links 00:25:18 tantek: Possible regression if people have written * { cursor: auto; } 00:25:32 Florian: Matches what firefox does, webkit does more magic 00:25:46 RESOLVED: auto cursor switches between default/text whether you're over text. No other magic 00:26:02 Issue 55: https://wiki.csswg.org/spec/css3-ui#issue-55 00:26:03 Topic: outline 00:26:18 Florian: Simple cases, everyone understands outline, but aside from that there's no interop 00:26:25 Florian: Not possible to spec it all in Level 3 timeframe 00:26:44 Florian: Would like group to sanction having a very loose spec for outline in L3 00:26:51 tantek^: In some cases we can't spec 00:26:56 agree 00:27:00 Florian: And clarify in L4 00:27:10 jumland has joined #css 00:27:13 Florian: E.g. what do you do if element is tranformed? Do you transform the outline or not? 00:27:39 Florian: If children overflow, do you extend outline to include them? Is the outline a rectange or weird shape in that case? 00:27:51 tantek: Contrary to resize, this is a feature wher we've seen a lot of innovation in browsers 00:28:03 tantek: It is an area that is so diverse that we don't want to pick any favorites righ tnow, because we don't know how to specify those 00:28:12 tantek: We've sene some nice stuff, and want to see what hte market comes up with 00:29:06 tantek: issue 55 and 51 close as no change 00:29:11 fantasai: agree with closing 55 00:29:19 Florian: 51 is transforming outline 00:29:32 fantasai: If you have interop on something you don't want, then need to speak up about it 00:29:35 no obj 00:29:49 ... 00:29:50 nikos has joined #css 00:30:13 Florian: Need to answer question of whether outline is supposed to be a focus indicator or a border that doesn't take up layout 00:30:58 fantasai: whether it rounds on radius, z-inex 00:31:14 s/inex/index 00:31:18 fantasai: I'm concerned that if you don't deal with this now, you'll end up not having a choice 00:31:45 fantasai: you need to address hte transform issue 00:32:24 ... must do it now or its too late 00:32:52 ... do we want to transform the outline or not 00:33:23 fantasai: would like to know what other people think, because my opinion is completely worthless here 00:33:44 dbaron: If you're in a 3d schene, there isn't necessarily a decent definition of what era is covered by your children 00:33:57 Florian: If you wnat outline to be a focus indicator, you put outline around the projected result 00:34:02 Florian: We haven't specified this 00:34:25 52: https://wiki.csswg.org/spec/css3-ui#issue-52 00:34:28 dbaron; Think we can't specify now 00:34:30 tantek: Objections? 00:34:46 RESOLVED: Don't specify anything for how outline sactually work other than what's there already 00:35:20 tantek: No interop on pseudo-elements 00:35:28 tantek: Suggest to say that they don't apply to pseudo-elements 00:35:31 nduca has joined #css 00:36:05 Florian: I don't think you can say that it does not apply and then make it apply later 00:36:19 dbaron: What we do is say the applies to line, and then have a note saying that in the future we might extend things 00:36:38 tantek: proposal is resize doesn't apply to pseudos, and add a note that it may apply in the future 00:37:15 fantasai: Wouldn't say where it's going to be solved, just say it may be solved in the future 00:37:33 RESOLVED: resize doesn't apply to pseudos. Note that this may change in the fuutre 00:38:13 https://wiki.csswg.org/spec/css3-ui#issue-68 00:38:38 Florian: Initial version of text overflow required overfow ~= visible and line would overflow its containing block 00:38:51 Florian: This is unfortunate if you have a float in the way. You'd overlap the float 00:39:01 Florian: spec is changed to elide before the float 00:39:05 Florian: Which is what Webkit does 00:39:30 tantek: Suggestion to reuqest that text-overfow apply even when overflow is visible 00:39:47 rossen: prolematic 00:40:00 I think generalizing to regardless of overflow value is too big of a change 00:40:10 rosen: What would a block with text-overflow: ellipsis would report for its main content size, if all lines are llipsized? 00:40:16 fantasai: text-overflow does not affect sizing 00:40:44 ... 00:41:04 Florian: What was specced was firefox's behavior. now specced webkit's behavior. 00:41:14 Florian: Firefox also asked for not requiring the overflow rule 00:41:35 tantek: We dont' have an implementation yet, though 00:41:42 agree with Tantek 00:41:54 fantasai: main concern I have with the overflow issue is web compat 00:43:17 RESOLVED: leave spec as-is, don't apply text-overflow when overflow: visible 00:43:26 https://wiki.csswg.org/spec/css3-ui#issue-76 00:43:49 tantek: Request made over twitter to allow implementations to elllipse for text overflow not at a character break boundary but at a line break opportunity 00:43:59 tantek: Seems like a reasonable request, not sure if anyone would ever do it, so I put it in as a may 00:44:03 tantek: One request ot revert it 00:44:34 tantek: Text overflow, when you get to point where it overflows, isntead of clipping you back off the number of characters to have ellipsis and not partial characters 00:44:45 tantek: Proposal is to ellipse at a word boundary, line-wrapping opportunity 00:45:01 Florian: I have a few probems with this problems 00:45:11 Florian: What looks better depends a lot on the context 00:45:20 dino: we would do that, ellipse at a line-wrap opportunity 00:45:32 Florian: If you're in a mixed directionality context, starting elingsh, Hebrew going the other way around. Now what exactly are you doing? You don't want ellipsis in the middle of the line 00:45:40 TabAtkins: Ellipsis is visual 00:45:55 Florian: Another issue is do you know enough about wrapping opportunities to do it at the visual layer when you're doing the ellipsis 00:46:07 Florian: Another isue is scrolling. If you scroll, upposed to reveal more content as you go 00:46:19 Florian: really weird to dro pin word sas you scroll 00:46:47 tantek: Behvior for scrolling is already looser than wording for not scrolling 00:47:17 fantasai: I disagree with this change, if you want this change it should be a separate property and/or keyword 00:47:30 … to allow ellipsing at a word / line-wrap opportunity 00:47:32 q- 00:47:54 Zakim, ack fantasai 00:47:54 I see no one on the speaker queue 00:48:43 RESOLVED: Drop wording allowing word-drops, add as a new feature in L4 e.g. as a new keyword or something 00:49:21 Zakim, room for 3? 00:49:21 Zakim, room for 3? 00:49:22 ok, glazou; conference Team_(css)00:49Z scheduled with code 26631 (CONF1) for 60 minutes until 0149Z 00:49:22 dbaron, an adhoc conference was scheduled here less than 2 minutes ago 00:49:37 jdaggett, ^ 00:49:56 dbaron: got it 00:50:28 Team_(css)00:49Z has now started 00:50:36 + +61.2.956.6.aaaa 00:50:36 +[IPcaller] 00:51:03 ok, muted 00:51:15 zakim, +ipcaller is me 00:51:15 sorry, jdaggett, I do not recognize a party named '+ipcaller' 00:51:25 Zakim, aaaa is MeetingRoom 00:51:25 +MeetingRoom; got it 00:51:27 zakim, +[IPcaller] is me 00:51:27 sorry, jdaggett, I do not recognize a party named '+[IPcaller]' 00:51:39 Zakim, [IPcaller] is jdaggett 00:51:39 +jdaggett; got it 00:51:39 Zakim, [IPCaller] is jdaggett 00:51:40 sorry, heycam, I do not recognize a party named '[IPCaller]' 00:51:53 Zakim, you have a short memory 00:51:53 I don't understand 'you have a short memory', heycam 00:52:00 hehe 00:52:11 Topic: CSS Inline 00:52:24 dauwhe: Wanted to go over some issues with inital letters 00:52:40 dauwhe: Then wanted to review css-linebox stuff 00:52:48 dauwhe: Florian raised various issues, here's the first one 00:53:17 dauwhe: Where initial letter is part of the same word, we want at least Latin text to kern back a little bit so that there istn' a break within teh word 00:53:45 dauwhe: but don't want to do that for CJK 00:54:25 [sending slides over] 00:54:44 SteveZ: There are examples where you want to kern the second line as well 00:54:51 SteveZ: You want to follow the shape of the outline 00:54:59 dauwhe: We do want that, but the full effect of that would be the next level 00:55:08 SteveZ: By specifying what your'e doing, you screw up the extension 00:55:28 +Liam 00:57:13 is this discussion about the illustration in 2.9? http://dev.w3.org/csswg/css-inline/#initial-letter-position 00:57:16 fantasai: yes, we want to do kerning around the shape of the letter eventually, but that's a stylistic choice: we decided to do the rectangular version first 00:57:44 liam: shoot 00:57:52 fantasai: We're not going to allow various behaviors, have to define one or the other, shouldn't be up to the UA 00:57:53 Zakim, unmute liam 00:57:53 Liam should no longer be muted 00:58:01 SteveZ: ... 00:58:27 Liam: There are examples that don't kern the first line of text, but they're not good examples, should try to do it if we can 00:58:48 ... 00:59:10 jdaggett: It think this is a feature that needs more work 00:59:18 [not good - there were technological limitations in the past] 00:59:19 jdaggett: e.g. distance from glyph outline to text needs to be controllable 00:59:49 jdaggett, slides here: https://lists.w3.org/Archives/Public/www-archive/2015Feb/0004.html 01:00:05 fantasai: I think for controlling the distance you can use the padding/margin on that side of the glyph 01:01:00 a decade ago I had proposed ::first-letter('A') to select only first letters that were a capital 'A' in order to customize styling on it 01:01:01 I actually haven't found examples of follow-the-curve. 01:01:35 -Liam 01:01:40 I found examples of follow-the-curve plenty over a decade ago 01:01:51 fantasai: From what Liam and dave cramer was saying is that the common case is kerning that first line, so that should be the default. 01:01:52 +Liam 01:02:05 q+ 01:02:12 fantasai: If you want a rectangle, you can add a transparent border 01:02:28 s/use the padding/use the 01:03:01 SteveZ: issue is should the kerning apply only on the top example, the rectangular one, or should it apply 01:03:02 http://graphicdesign.stackexchange.com/questions/10561/text-wrap-in-illustrator-cs6 01:03:09 SteveZ: What should be tehd efault 01:03:49 fantasai: the way it works right now is that you only do this kerning if you have marigns but not borders or padding 01:05:00 q? 01:05:02 fantasai: we took the marign collapsing principle that the edges of the box are permeable if padding/border is zero 01:05:08 fantasai: So you can get both behaviors 01:05:16 fantasai: And I thin kthe model is fairly consistent 01:05:30 [argument over which is more common, clearly not clear] 01:05:45 Yeah, I've seen a lot where the first line follows the initial letter outline, but I couldn't find examples where lines other than the first do. 01:05:52 fantasai: You can add margins if you want more spacing, you can add spacing if you want rectangularness 01:06:55 dauwhe: We could defer if necessary for implementations 01:07:00 fantasai: I would prefer to try for this 01:07:34 fantasai: There is a sensical mode. Wrt implementability, you need the glyph outline (which you have to have anyway, sicne that define sthe content box of the initial letter) 01:07:41 fantasai: and you need an offset control, which is provided by margin 01:07:58 tantek talks about full wrapping 01:08:09 dauwhe: Case #3 is much more common and simple, prefer to defer it 01:08:25 Florian: Unless someone wants to argue that the bottom is undesirable or relatively bad thing that we don't want to be the default, then 01:08:33 Florian: I think the model is very sane. 01:08:57 SteveZ: My concerns weren't that case #3 isn't deirable, but worried about separating case #3 and full kerning 01:09:18 SteveZ: Want to see how it interacts with full kerning 01:09:31 tantek: I'd like to see what full kerning would look like, an dinclude it in teh draft now, before cutting it 01:09:43 dauwhe: I'm okay, if that's where we want to go 01:10:00 q+ 01:10:05 Liam, tantek, Szilles, fantasai agree on this approach 01:10:34 liam: As an implementer, think it's good to have all possibilities there, will help to organize your code appropriately 01:10:53 q- 01:10:56 ack jdaggett 01:10:59 jdaggett: I want to make clear that I think the difference between the first option and the one that's in any way following the outline is an exponential order of time difference 01:11:15 jdaggett: because you're looking at the glyph outline 01:11:37 jdaggett: Wouldn't imagine that a mobile browser wants to do that 01:11:51 dauwhe: Wouldn't it make sense to include this and then react to implementation experience later 01:12:00 jdaggett: I think this should be opt-in behavior 01:12:16 tantek: I think some impls have motivation to do high-fidelity rendering 01:12:30 tantek: You mention mobile, I thin that's a top use case 01:12:40 jdaggett: I don't think it's universally true that his is the optimal thing 01:12:44 jdaggett: It depends on the use case 01:13:01 jdaggett: The behavior of margins vs. padding is confusing to authors 01:13:14 dbaron: I agree that doing this based on padding/border being set is confusing 01:13:19 dbaron: Odd implicit thing that people won't get 01:13:56 dauwhe: full kerning would need another switch 01:14:11 dauwhe: I think at this poin tit's worth doing the full thing, cost mostly on editors writing spec, and then check in with implementors later 01:14:28 +1 for borders and padding being confusing in this case 01:14:31 stryx` has joined #css 01:15:00 RESOLVED: Add full kerning to css-inline, perhaps dropped later based on implementation experience, but try to figure out how it all fits together 01:15:03 +1 add and solicit more feedback 01:15:06 +1 01:15:35 dauwhe: Florian brought up issue of what if initial letter is a different script than the surrounding text. 01:15:58 dauwhe: Conclusion is you use the top alignment point of each script and the bottom alignment poitn of each script 01:16:11 q+ to ask about leading quote 01:16:17 dauwhe: E.g. A inside indic script shows cap-height to hanging-example, alphabetic to alphabetic 01:16:25 dauwhe: Florian has an example of this 01:16:31 Florian: Chinese-english dictionary 01:17:07 RESOLVED: Choose alignment points as described above 01:17:15 dauwhe: Next issue is run-in 01:17:29 Florian: Combination of run-in and :first-letter 01:17:46 Florian: Having ::first-letter select the first letter of the original text seems very weird 01:18:28 Florian: Makes more sense to select the first letter including the run-in 01:18:35 Florian: Should either select that or select nothing 01:19:01 tantek: I lean towards selecting nothing, the author can select the first letter of the run-in 01:19:17 dbaron: Does ::first-letter apply to run-ins? I don't think it does. 01:19:23 example of mixed scripts http://florian.rivoal.net/csswg/cn-en_raised-cap_shed.jpg 01:19:26 but it could 01:19:41 ::first-letter *could* apply to something with display:run-in 01:20:54 fantasai: I think dbaron' is right. Run-ins are defined as inlines, effectively. And you can have multiple run-ins run into the same paragraph, in which case one of them for sure won't be at the beginning of the paragraph 01:21:10 fantasai: So I'm not sure we can have ::first-letter apply to run-ins. 01:21:34 fantasai: In which case, you'll want to have ::first-letter select the first letter of the first run-in in a paragraph, since there's no other way to do it 01:21:48 fantasai: Although I'm not a box-construction expert, so I don't know if that's sane. 01:22:46 What decision are we trying to make right now? 01:23:08 fantasai explaisn run-in box model: old model was run-in is a block if it doesn't run into anything; new model it's always an inline, sometimes inside an anonymous block 01:23:55 Florian, fantasai: So if we want to do this, either run-ins need to accept ::first-letter, or ::first-letter needs to apply to to a run-in inside a paragraph 01:24:31 SteveZ: Off-topic: the example on the screen is aligne dto the x-height, not the cap-height 01:24:49 dauwhe: The box aligns to the alignment points, it has padding and a background 01:25:17 Discussion moved ot ML 01:25:29 dauwhe: We had a discussion wrt floats and initial letter 01:26:14 SteveZ: Having a float that occurs in the 2nd line be 1 line down from teh top of the paragraph is the worst behavior 01:27:47 fantasai: You run into a problem when you have a floating image somewher in lines 1-3 -- in those cases you should clear the initial letter. 01:28:15 Florian: [to steve] that proposal would introduce a loop in the layout that doesn't exist 01:28:20 I think line 1 should be fine, floats in lines 2+ should clear 01:28:21 SteveZ: No it doesn't , it alrady exists 01:28:50 The static on the audio system is really getting on my nerves. 01:30:16 [discussion about whether floats moving up creates a problem] 01:31:15 Rossen: Do you expect your proposed algorithm to work for only left floats? 01:31:20 SteveZ: yes 01:31:34 Rossen: Then you're proposal only affects one side of floats 01:32:01 dbaron: We only have a problem on ths side of the initial letter 01:32:03 -Liam 01:32:06 dbaron: And I don't belive steve. There's a problem. 01:32:48 fantasai: Does anyone other than Steve think ther eis not a problem? 01:32:50 [silence] 01:33:04 fantasai: Okay, then I suggest someon eexplain it to seve during a break, otherwise we'll spend the rest of the presentatio neplaing how floats work 01:33:14 next slide 01:33:35 dauwhe: Want the ability to position the box as a whole including borders padding backgrounds 01:34:07 dauwhe: florian suggested that we use box-sizing to deterine whether you align the letter or the box 01:34:28 astearns: I thin it's a bit confusing to use box-sizing. might be better to have that as a keyword in the initial-letter property 01:35:14 Florian: The initial letter-align property says which set of baselines to use 01:35:19 Florian: Must speak eithe rof the ltter or the box 01:35:30 Florian: If you're aligning a box, the baseline values mean nothing 01:35:48 Florian: Other values were aobut vertical centering of box once you have the box or something 01:36:02 Florian: We could have a different property for this switch 01:36:24 Florian: The nice thing about box-sizing is that... 01:36:44 astearns: it made a lot of sense to have hsape-outside key off of box sizing 01:36:56 astearns: but we were eventually convinced that having that conflation of concerns for box-sizing was something to avoid 01:37:05 astearns: and that's why we put the keyword into the shape keyword itself 01:37:15 fantasai: Why not use initial-letter-align? 01:37:18 topic? 01:37:23 (is there a URL) 01:37:29 Florian: What does padding do if you don't have this? 01:38:08 Florian: Why not use box-sizeing, since we've changed what we're using box sizing 01:38:17 fantasai: People put box-sizing on everything today, to make it border-box 01:39:24 Florian: Then by default in those pages you will align the border box 01:39:30 ... 01:39:49 dauwhe: The initial indic req doc says that the bottom alignment point of indic scripts is the text-bottom edge (base don em box) 01:39:56 dauwhe: but it is definitely not correct 01:40:08 dauwhe shows example 01:40:17 dauwhe: You get very unrealistic results, don't seem to match examples i've seen 01:40:24 dauwhe: because this alignment point is not a visible thing in the font 01:40:32 dauwhe: The bototm alignment point in these scripts is in fact the alphabetic baseline 01:40:49 dauwhe: Matches much more closely to real examples, and to things we can see in the fonts 01:41:00 dauwhe: Still have lots of questions about CJK 01:41:11 dauwhe: The top exampel here is Hebrew 01:41:21 dauwhe: One problem with Hebrew is that the font metrics don't seem to have a natural alignment point 01:41:29 dauwhe: There's a strong vetical rhythm along the top of the characters 01:41:46 dauwhe: there is a probable top alignment point there 01:41:54 dauwhe: but ti's not an existing metfic. It's not the x-height, or cpa-height 01:42:03 dauwhe: Not what issue that raises for this 01:42:09 dauwhe: In the case of Arabic I have no clue 01:42:36 fantasai: I think the character you want to align to is the alef 01:42:48 fantasai: the top of the first letter at the begining of your example 01:42:59 lam has the same height (normally) 01:43:11 dauwhe: projects a table of alignment points 01:43:29 dauwhe: myth of hanging baseline 01:43:44 dauwhe: John Hudson mad ethe point that most fonts typically don't implement the base table that specifies the position of a hanging baseline 01:43:52 dauwhe: And most software doesn't actually use the hanging baseline 01:44:00 dauwhe: They're not even sure if hangin base line is what happens in these scripts 01:44:11 dauwhe: Here's some example sof characters i vastly different size 01:44:23 dauwhe: What happens in every implementation I'm aware of is alignment at alphabetic baseline 01:44:33 dauwhe: Looking at CKJ, lots of options in indesign 01:44:36 +Liam 01:44:46 dauwhe: Lots of questions about that 01:44:59 dauwhe: And that's the intro to the next bit, the rest of CSS inline 01:45:05 dauwhe: Wanted to ge ta sense of what that needs to include 01:45:12 dauwhe: What needs to change from CSs2.1? 01:45:20 dauwhe: Do we really need to define 20 kinds of baselines? 01:45:32 dauwhe: To match bottom ideographic char frame with mathemtaic baseline??? 01:45:47 jdaggett: I think we have some issue with inter-group issue 01:45:52 jdaggett: SVG has a bunch of stuff taken from XSL 01:46:06 jdaggett: dominant-baseline and various properties 01:46:13 jdaggett: huge number of values 01:46:18 jdaggett: Some people say this is a compat issue 01:46:23 dominant baseline stuff was copied from xslt yes and needs to be cleaned up 01:46:25 jdaggett: But need to coordinate with SVG to see who's going to do what 01:46:29 jdaggett: Dunno what's actually implemented 01:46:38 jdaggett: properties are parsed, but what's implemented? 01:46:45 dauwhe: Yes, curious about what's happening in the wild 01:47:00 SteveZ: I was going to ask, in the indic example you have there, 01:47:11 example: http://mxr.mozilla.org/mozilla-central/source/layout/svg/SVGTextFrame.cpp#328 01:47:13 SteveZ: It's what browsers do today, but certainly not what happens in print 01:47:18 s/xslt/XSL-FO/ 01:47:19 SteveZ: They do use that in print 01:47:24 gecko dominant-baseline implementation 01:47:39 dauwhe: I haven't actually seen an example of mixed-text sizes in the real world, other than drop-caps 01:48:08 jdaggett: I think we have to temper things with actual data that we get from fonts 01:48:24 jdaggett: We have to be careful of using theoretical models of what different baselines exist theoretically vs real world font metrics 01:48:34 dauwhe: Yeah, I don't belive anything until I can read it out fo the font metric 01:48:41 SteveZ: That leave syou with real problem with Hebrew then 01:48:54 SteveZ: Sounds like you're going to end up synthesizing font metrics that you need 01:49:05 SteveZ: Existing font metric principle won't work 01:49:09 dauwhe: It's a starting point, not an ending point 01:49:49 dauwhe: Shoudl we move forward? 01:50:05 fantasai: Yes, even hav some exisitng resolutions on what to add 01:50:17 jdaggett: Lots of stuff from SVG, XSL, don't want to add 01:50:24 fantasai: Yeah, don't wnat to copy from XSL 01:50:51 SteveZ: Text align had made some assumptions, so XSL was to make vertical-align be a shortcut 01:50:56 s/text align/vertical align/ 01:51:19 SteveZ: Wnated to place thing,s not just glyphs, but also images 01:51:56 SteveZ: The list of baelines is unimportant. There was some set that was useful that you might get at. 01:52:16 RESOLVED: lunch 01:52:27
01:52:32 -jdaggett 01:52:50 -Liam 01:53:16 Florian has joined #css 01:53:28 -MeetingRoom 01:53:29 Team_(css)00:49Z has ended 01:53:29 Attendees were +61.2.956.6.aaaa, MeetingRoom, jdaggett, Liam 02:09:31 adenilson has joined #css 02:34:09 xidorn has joined #css 02:36:28 dauwhe has joined #css 02:36:32 dauwhe has joined #css 02:37:30 estellevw has joined #css 02:44:13 johanneswilm has joined #css 02:46:18 TabAtkins: awesome 02:46:29 murakami has joined #css 02:54:16 Florian has joined #css 02:54:35 gregwhitworth has joined #css 02:56:30 Florian has joined #css 02:58:19 tantek has joined #css 03:02:00 shepazu has joined #css 03:08:42 Topic: Page Floats 03:09:21 I hope you all expose more CSS power to JavaScript for polyfilling. 03:09:35 ?: Currently spec is unmaintained 03:09:43 murakami has joined #css 03:09:56 tantek has joined #css 03:09:59 ?: Page floats is rule that says images/figures should go to the top, could also say they go to the top in certian circumstances in some cases, to bottom in others 03:10:13 ?: Right now spec that exists for it has Håkon as editor, and hasn't been working on it 03:10:25 ?: Contains page floats, but also exclusions, regions, etc. thatothers are working on 03:10:34 ?: Proposing for me to join the eidtorial team for this spec 03:10:40 s/?/johanneswilm 03:10:46 tantek: Did you talk to hwocome about it? 03:11:08 johanneswilm: Will try to engage with him, and everyone in print sector e.g. AH, PrinceXML, vivliostyle 03:11:20 johanneswilm: Our goal is to create a JS polyfill to get this functionality in browsers 03:11:30 johanneswilm: Getting browsers to implement was not successful 03:11:49 dino: Printing might be a narrow use case, but books are not 03:11:52 i think håkon now maintains https://books.spec.whatwg.org/ 03:11:53 johanneswilm: Dunno why it wasn't implemented 03:11:59 fantasai: Because it's vastly underspecified 03:12:05 Rossen_away: You mentioned a bunch of things 03:12:19 Rossen_away: What exactly did you want to take over, just page floats? Exclusions? Something else? 03:12:30 johanneswilm: This is CSS Page Floats. We think that's what it should be about. 03:12:37 johanneswilm: Exlusions, regions, don't want to work on it 03:12:45 johanneswilm: Understand it's being worked on elsewhere 03:13:02 Rossen_away: Path forward wehad agreed on was that exclusions is amodule that provides specification on what happens with exclusion areas 03:13:11 zcorpan: it looks like https://books.spec.whatwg.org/ has not been updated in over 2 (almost 3) months. 03:13:15 johanneswilm: How these are positioned is not up to that spec, only about propagation of the geometry 03:13:18 q+ 03:13:31 s/johanneswilm/Rossen/ 03:13:42 Rossen: Doesn't deal with layout 03:13:45 and https://books.spec.whatwg.org/ does not appear to mention page-floats 03:13:50 AndreyR has joined #css 03:13:53 Rossen: Are you also planning to work on exclusions, or just layout? 03:14:10 tantek: https://figures.spec.whatwg.org/ 03:14:18 only thing that books whatwg spec appears to affect re: floats is float: footnote 03:14:19 https://figures.spec.whatwg.org/#page-floats 03:14:22 johanneswilm: Need to investigate underlying fundamentals 03:14:30 johanneswilm: Idea is not to talk about it here 03:14:43 johanneswilm: Want to make it very simple to start with, so just rectangular floats that go up or down 03:14:45 thanks astearns zcorpan 03:14:56 johanneswilm: And then in discussion with other projects that work with this, try to see what direction they want to go with it 03:15:02 https://figures.spec.whatwg.org/ appears to not have been updated since 2014-09-30 03:15:14 that is - not updated 4-5 months 03:15:16 Florian: To be clear, exclusions and regions in this spec are not what we can exclusions and regions. They are howcome's counter-proposals to. 03:15:35 johanneswilm: The counter-proposals, we don't really need them in there. 03:15:38 dino: Can we remove them? 03:15:44 s/what we can/what we call 03:15:46 dino: It's obviously confusing 03:15:55 agreed, remove them 03:16:04 RESOLVED: Remove exclusions and regions sections from page floats spec 03:16:26 RESOLVED: johanneswilm added as editor 03:17:01 dino: Webkit has been interested in implementing this for awhile, for pages/columns in browser, for our ibooks product 03:17:07 dino: You don't have to ask just printing companies 03:17:09 johanneswilm: Sounds great 03:17:19 johanneswilm: Want to work together with everyone who wants to work on this 03:17:28 johanneswilm: have a specification that everybody can be proud of 03:17:40 tantek: Do you have an approach in mind for keeping in sync with Figures spec? 03:17:42 https://figures.spec.whatwg.org/#page-floats 03:17:48 johanneswilm: We will be talking to howcome and find out what is possible there 03:17:55 johanneswilm: He also has his own idea of exclusions and regions 03:18:01 johanneswilm: and first-letter caps 03:18:13 johanneswilm: Idea is not to import another idea, but we want to try to incorporate as much as possible with howcome 03:18:30 ChrisL: Anyone implementing Figures? 03:18:35 gregwhitworth has joined #css 03:18:47 dauwhe: I'm not aware of anyone. Will have more info after I visit YesLogic this week 03:19:00 dauwhe: howcome isn't involved in the WG anymore, this is the group that has to decide what gos in the spec 03:19:18 ChrisL: Great that there's not just a totally-separate-from-browsers group doing this on the side 03:19:41 Rossen_away: For other browsers that have expeirmental implementations of exclusions, I don't want to all of a sudden drop them and sart working on page floats and stop working on exclusions 03:19:46 johanneswilm: I don't think they are exclusive 03:19:55 johanneswilm: If anyone has written thesis in laTex 03:20:04 johanneswilm: You can write a directive that all figure sand captions go to the top 03:20:12 johanneswilm: This is the same. You define onece, wher eeverything goes 03:20:24 johanneswilm: If you want more grpahic art of making books, you want to decide where each figure goes, where each whatever 03:20:33 johanneswilm: text goes around in funny ways 03:20:40 johanneswilm: no computer can do that automatically 03:20:57 cameron: Is it in the spec to go to a new page or a named page? 03:21:20 johanneswilm: Right now just want to get a simple specification that is similart to what is shipping in these implementations 03:21:29 johanneswilm: that said, there are many common things not implemented anywhere 03:21:36 johanneswilm: floating things on other pages, e.g. 03:21:47 johanneswilm: or float imaes all to a set of 8 pages that are in color others black and white 03:21:56 johanneswilm: we can grow as far as we need to, but not more than there is implemented 03:22:02 dauwhe: that's a significant use case for us 03:22:52 Topic: @extend 03:23:52 JonathanNeal_ has joined #css 03:23:57 TabAtkins: One of the most consistently popular parts of SASS is @extend rule 03:24:01 TabAtkins: massive update 03:24:20 https://lists.w3.org/Archives/Public/public-houdini/2015Jan/0005.html 03:24:23 TabAtkins: dbaron about 2 years ago suggested something that had almost exactly the same shape as @xtend, but with less convenient syntax 03:24:30 TabAtkins: Suggested just using @extend, that's what people are used to 03:24:38 TabAtkins: here's a proposal to add @extend to CSS finally 03:24:53 http://tabatkins.github.io/specs/css-extend-rule/ 03:25:12 TabAtkins: Somewhat trivial example, but large corpus of examples 03:25:25 TabAtkins: Say you have a bunch of styles for a .error class 03:25:34 TabAtkins: Later you realize you ned to make a really serious error class 03:25:51 TabAtkins: same styles, but make it red and bold as well 03:26:08 TabAtkins: ways to do this now, have to make all markup using seriouserro class also have error class 03:26:12 TabAtkins: Need to track in HTML 03:26:25 TabAtkins: also in DOM manipulation 03:26:43 TabAtkins: add and remove together, fairly error prone 03:26:56 TabAtkins: alternate way is that in CSS every rule that has .error, also have a .seriouserror selector 03:27:09 TabAtkins: Also not great, because have to duplicate every single selector 03:27:15 TabAtkins: Also maintain that as you remove selectors 03:27:20 TabAtkins: Lots o f potention for typos 03:27:32 TabAtkins: Not good solutions to hadling this kind of subclassing of widgets in CSS 03:27:38 TabAtkins: @extend rule captures this concept 03:27:57 .seriouserror { 03:28:01 @extend .error; 03:28:02 } 03:28:35 TabAtkins: Means that every element to which this style rule applies 03:28:45 TabAtkins: also matches the .error class. 03:28:51 TabAtkins: Draft as it is allows everything 03:28:56 TabAtkins: e.g. use :not() 03:29:31 TabAtkins: Would be fine to restrict to feature selectors: tag names, classes, attrs, IDs, stuff that's in the DOM 03:29:50 TabAtkins: There are potential use cases e.g. :hover, but that makes it much more complicated 03:29:55 TabAtkins: That's basically it 03:30:25 TabAtkins: If you're not familiar with how insanely useful this has been, I suggest you just ask on twitter. "How useful is @extend?" You'll get "OMG, so usef, why aren't you doing it yet?" 03:30:39 TabAtkins: Impleentationwise I have no idea 03:31:33 fantasai: Compound or complex selectors? 03:32:12 TabAtkins: compound selectors only 03:32:20 TabAtkins: Don't think it's worth the complexity 03:32:34 fantasai: Agree, just want to be clear 03:32:51 TabAtkins: @extend rule might make it match more rules, which might themselves have @extend; 03:33:04 TabAtkins: Shouldn't be a big deal, but a large number of chained extensions 03:33:11 dino: loop? 03:33:20 TabAtkins: Can't subtract features. 03:33:31 TabAtkins: No loopse 03:33:51 TabAtkins: No specificity issues. 03:34:08 TabAtkins: Just behaves like it also has the .error class. 03:35:14 dbaron: Are yo umatching specificity of seriouserror or error? 03:35:19 fantasai makes tab write on the board: 03:35:30 #serious-error { @extend .error; } 03:35:34 .error { color: blue; } 03:35:44 dbaron: Is color: blue class-specific or ID-specific? 03:35:51 TabAtkins: class-specific 03:35:52 Tab says that with #seriouserror { @extend .error } .error { color: blue} the specificity used for color:blue comes from .error 03:36:09 glazou: OM to represent @extend? 03:36:26 TabAtkins: We discussed this in the past, we'll add .cssRules on the stylerule interface 03:36:44 cameron: Does this work across style sheets? 03:36:46 TabAtkins: Yes 03:37:11 cameron: Simpler mode is just single class names or single IDs only 03:37:17 TabAtkins: Answer is I'm not sure 03:37:24 TabAtkins: SASS allows fuller model than what I'm doing now 03:37:33 TabAtkins: Might be possible to trim it down 03:37:41 TabAtkins: Could put as an issue in the draft 03:37:57 glazou: You allow only compound selectors in here? The other place? 03:38:02 TabAtkins: selector on the rule can be anything 03:38:15 roc: querySelector? 03:38:23 TabAtkins: Unsure. Dunno what's useful 03:38:32 dino: I really like this proposal. Wondering whether just having placeholders is enough 03:38:53 TabAtkins: Placeholder selector is a concept introduced by SASS 03:39:06 TabAtkins: They use the % sign. It's just like a class, just impossible to match with any feature in the DOM 03:39:38 TabAtkins: The reason why this is ued is so taht when you're designing style sets you don't have to worry about accidentally clashing with stuff actually in the DOM 03:39:50 TabAtkins: Quite a bit of the stuff with @extend can be used is placeholders 03:39:59 TabAtkins: You might have to start with .error, and then rewrite it to %error 03:40:15 TabAtkins: would want to do more research if most use cases can be done with just placeholders/classes 03:40:37 fantasai: It does seem like placeholders would be a simpler model to have. 03:41:02 dino: I think the placeholders will encourage peopel to code the way you said, to use semantic class names and use placeholders however is best for styling. 03:41:11 dino: How does SASS do it? 03:41:31 TabAtkins: They do it by selector-rewriting. This has a different selector specificity behavior; SASS authors think it's fine. 03:41:55 dino: I wonder if we could just have it as a copy, copying the properties directly in. I guess it applie shte hash serious... 03:42:03 dino: What would be the problems with it? 03:42:21 TabAtkins: @extend has a dual form with @mixin 03:42:38 TabAtkins: we could consider extending in the future 03:42:48 TabAtkins: SASS shows @extend is preferred by authors, so should do it first 03:42:58 dino: Awareness of specificity.. . it's a difference from the way normal CSS reads 03:43:03 pjrm has joined #css 03:43:06 dino: shorthand, longhand 03:43:12 plinss: I'm not sure that you will be aware of the specificity 03:43:19 plinss: There could be other rules somewhere in the mix, there's a .error 03:43:28 dino: especially if .error extends from something 03:43:35 plinss: ... 03:43:38 plinss: no predictability 03:44:04 TabAtkins: With a little bit of discipline, using mainly just placeholders, then will get into less trouble than that 03:44:10 dino: yes, I like placeholders better 03:44:39 TabAtkins: Unless we allow @extend to affect querySelector, the placeholder won't match anything aside of the querySelector call 03:44:50 cameron: I think it might be useful to querySelector all my buttons 03:45:11 TabAtkins: I can see it'd be useful, might be issue 03:45:29 plinss: Really odd querySelector doesn't work, but also really weird that CSS affects the DOm 03:45:44 TabAtkins writes 03:45:58 .foo { @extend: button; } 03:46:06 TabAtkins: This will pull in the UA styles for buttons 03:46:29 cameron: Sounds neat, but internally we set some rule sin the UA style sheet that really can't be applied to othe relements 03:46:43 cameron: due to scurity, or we make certian assumptions about what elements they apply to 03:47:11 dbaron: form controls probably shoudl have been designed as values of 'display', but they're not. 03:47:23 dbaron: So they require element-specific knowledge, and the Web depends on that. 03:47:36 please add "roc's head explodes" to the minutes 03:47:43 dbaron: If you put 'display: inlie' or 'display: block' on a button, it's still a button 03:48:05 Florian: Have appearance property for that. The 'none' value has fair amoutn of interop, but other values work differently in different browsers 03:48:18 t 03:48:46 Florian: The buttonness of your button is not expressed in CSS. 03:48:57 dbaron: Our buttons, for example, have 2 sets of borders instead of two. 03:49:06 dbaron: If you @extend, you'll get one set but not the others. 03:49:20 greg: control would be even worse"] 03:56:49 foo:not(.error) { @extend .error; } 03:56:58 glazou: That's a loop, yes? 03:57:01 TabAtkins: yes. 03:57:20 TabAtkins: hm, maybe have to do a loop-detection phase 03:57:25 roc: Two things aren't quite the same 03:57:35 roc: With custom selectors you ahve t list all the extensions in one place 03:57:49 roc: With the @extend you can increase the list anywher ein the style sheets, which makes it much more useful 03:58:12 dbaron: You could have something that is outside of a style rule, but still has advantage of spreading around the style sheets 03:58:19 dbaron: which is what I was proposing a few years ago 03:58:31 dbaron: Part of what makes me think it doesn't fit the model is putting it inside the style rule 03:58:45 fantasai: Can you summarize your proposal, dbaron? 03:59:15 q? 03:59:20 people tell fantasai to go read it. While taking minutes and trying to keep up with the discussion. 03:59:23 q- 03:59:34 ack Florian 03:59:37 q- shorthand 03:59:39 q- long 03:59:42 plinss: What thing, if @extend is inside the rule 03:59:43 ack dino 03:59:48 ack dino: 03:59:59 plinss: I may have, to go back to earlier example, I may have 6 different rules that apply serious erro rwith various selectors 04:00:09 plinss: If I want to include .error, have to put it in all of them 04:00:18 gregwhitworth has joined #css 04:00:19 plinss: When any of the other smatch, then only put it here 04:00:28 q+ to say I don't just want to limit it to placeholders 04:00:30 smatch! 04:00:33 shmatch 04:00:46 schmelectors? 04:00:47 q+ to say that a big part of what I don't like about it is the name 04:00:54 q+ to ask'); DROP TABLE queue 04:01:01 q- 04:01:04 plinss: If I have 1 rule with .seriouserro:hover, and that contains @extend .error 04:01:23 plinss: It may have other selectors before .ersiouserror 04:01:36 plinss: If I put it in a rule that only matches sometimes. 04:01:45 plinss: May be an advantage, but may be somewhat confusing 04:02:03 plinss: If you don't understand cascade/specificity correctly, you might get yourself into a confused situation 04:02:13 plinss: What I'm wondering is if it would be better to have it separate, not in a style rule 04:02:20 plinss: This selector is equivalent to this other selctor 04:02:29 plinss: Then it applies to all rueles and all style sheets 04:02:48 TabAtkins: Difference between this and @extend .seriouserror .error; is literally a matter of 2 chars 04:02:53 plinss: It's a big difference in behavior 04:03:07 TabAtkins: it's just syntactic. 04:04:23 q+ to ask about interaction with combinators 04:04:37 q+ to describe previous proposal 04:04:44 plinss: If you have .foo > .seriouserror 04:04:50 plinss: Below that I have .bar > .seriouserror 04:04:55 plinss: And in that one I didn't put @extend 04:05:10 plinss: But if I have a separate rule that is @extend .seriouserror .error ti works on both 04:05:24 TabAtkins: yeah, same thing. You might have to have a separate rule that just holds @extend, but it's fine. 04:05:36 plinss: Oh, nevermind 04:06:15 plinss: Going back to dbaron's point, I think there's a lot of ppl who don't understnad how to compose style correctly 04:06:24 plinss: I think this just lets people who are doing it wrong od it wrong in more interesting ways 04:06:37 TabAtkins: yes, but it also makes people who know what theyr'e doing to have much more maintainable style sheets 04:06:53 plinss: I support better maintenace completely, but this feels really wrong to me. 04:06:55 aside: how *do* you compose styles correctly? anyone have a suggested "how to" guide? URL? 04:07:24 plinss: I would like to see different ways of composing style rules, rathe rthan this. 04:07:25 s/aside/tantek on irc aside 04:07:31 glazou: The problem is referencing a given rule from another rule. 04:07:44 plinss: in my hea,d without really understnaidn this, I would rathe rit simply references the other rule 04:08:00 plinss: Would rather say "what I really wanted was this set of properties, plus all the propertyies from the other rule over there" 04:08:06 plinss: Not by mangling what matches what. 04:08:12 TabAtkins: People don't wnat that 04:08:18 plinss: Because they don't understna dhow to compose CSS 04:08:43 TabAtkins: You can have a bunch of style rules that apply style rules to .error in different contexts,. 04:08:50 TabAtkins: referencing a block doens't work well there 04:08:55 q+ to agree with Tab about people wanting to extend one class with another being important 04:09:19 Tabatkins: I'm willing to let them be wrong if it helps them out 04:09:20 TabAtkins: It is extermeely popular in SASS commnity, shows it's helpul to people 04:09:24 plinss: But it's a model that's wrong 04:09:32 TabAtkins: I'm willing ot let the be wrong if it's helfpul 04:09:46 plinss: Going back to querySelector, that's really concering because selector behavior which is different from style sheets 04:10:03 plinss: Doesn't fit in architectural model of the Web 04:10:12 dino: I would like to not change querySelector, otherwise I don't have any problem 04:10:27 dino: I think the point about CSS being able to change JS apis is good, I agree 04:10:32 dino: I still like eveyrthing else 04:10:36 ack dbaron 04:10:36 dbaron, you wanted to say I don't just want to limit it to placeholders and to say that a big part of what I don't like about it is the name and to ask about interaction with 04:10:40 ... combinators and to describe previous proposal and to agree with Tab about people wanting to extend one class with another being important 04:10:45 [ tantek - I dont believe in right or wrong in this sort of thing anyway ] 04:10:57 zakim, suggest a syntax for extending css 04:10:57 I don't understand 'suggest a syntax for extending css', ChrisL 04:11:09 fantasai: It's in the logs 04:11:16 dbaron: I agree that extending one class with another is something we should do and is important to authors 04:11:33 dbaron: Authors end up writing 4 different selector sbecause buil hierarchy of stuff. So solving that point is important 04:11:41 dbaron: Wanted to ask question of what this actually does 04:11:55 dbaron: Suppose you have .article { @extend .section; } 04:12:27 dbaron: And then .seriouserror { @extend .error; } 04:12:43 dbaron: and then you have .section .error { color: whatever; } 04:13:00 dbaron: This will match when you have
TabAtkins: yes. 04:13:05 dbaron: good. 04:13:50 dbaron: It follows from the fact that I think this is improtant that we shouldn't limit it to just placeholder 04:13:57 dbaron: But I think a big part of my problem with it is the name. 04:14:01 dbaron: It's the wrong mental model, 04:14:08 glazou: More assimilate than extend 04:14:15 TabAtkins: I would be somewhat unhappy if we changed the name 04:14:37 TabAtkins: But has advantage that ... 04:14:39 s/assimilate/simulate 04:14:44 dbaron: I don't believe that for a second. 04:14:53 dbaron: All people whose pages are going to break aren't going to be happy. 04:14:59 TabAtkins: That's SASS's responsibility. 04:15:06 TabAtkins: Different name would avoid that problem 04:15:19 s/.../ ... something about turning off @extend in SASS / 04:16:21 plinss worries about nested selector matching 04:16:25 estellevw has joined #css 04:16:32 TabAtkins: You collec tthe @extend rules, iterate until stable 04:16:34 s/plinss/glazou and plinss 04:16:51 TabAtkins: Then in addition to DOM class list, you also look in the @extend class list. 04:17:06 dbaron: That assumes the @extend rule is inside a selector that is jsut a class 04:17:14 TabAtkins: You match this, then you add this to extend this 04:17:31 plinss: Tab hasn't actually written a selector matching algorithm... 04:17:47 glazou: I'm afraid this is a feature for batch processors, not for dynamic browser. I'm worried about perf 04:17:54 TabAtkins: Batch processors can't implement this ocrrectly 04:17:54 about 6 lines up glazou raised the issue of performance 04:18:10 s/batch /pre 04:18:36 plinss: If you separate @extends out, then you can precompute it all 04:18:58 fantasai: They're syntactically equivalent 04:19:31 fantasai: it may not be the syntax you want, but they are equivalent 04:19:52 fantasai: if I can write a perl script that rewrites it then it's equivalent 04:20:33 glazou: Selector matching: You try to match all of the selectors in the CSSOM against the element that you have in your hand. 04:21:42 di foo .bar { ... } 04:21:50 div > p > foo .section { #extend .bar } 04:22:00 glazou: You run selector matching, then realize it extends, have to go run it again. 04:22:16 glazou: If you have a different syntax, you can keep the @extend rules in their own list and prcess them first and then do selecto rmatching. 04:22:18 q? 04:22:22 otherwise first rule will never match 04:23:04 fantasai: You could do that anyway. When you parse the rules, instead of storing @extend in the style rules list with the declarations, build up your separate @extend list. 04:23:11 fantasai: They are syntactically equivalent. 04:23:25 s/glazou/plinss/ 04:23:26 I still have no idea how we'd implement this in a browser... 04:24:03 glazou: I perfectly understand usefulness, but unsure how to implement this in a browser. 04:24:23 plinss: Just explode out the selectors 04:24:32 TabAtkins: No, that won't get you the righ behavior 04:24:54 dbaron: I think it's really useful for authors, but no idea how to implement it 04:25:03 I think selector variables are much more straightforward. 04:25:16 plinss: I run into this problem myself 04:25:30 plinss: I'm not convicned this is the right way to solve the problem, but not sure it's the right way 04:26:26 fantasai: ... 04:26:30 I for one like @extends 04:26:39 dbaron: I had two proposals, one similar to selector variables one similar to extend 04:26:40 s/@extends/@extend 04:26:54 dbaron: And I think I like Tab's selector variables syntax better. 04:27:01 roc: if your estric tit to the placeholders version 04:27:14 roc: Then you can treat it as a different syntax as alisaed selectors 04:27:29 roc: And it's very clear how to implement that 04:27:33 SimonSapin:... ? 04:28:01 s/estric tit/restrict it/ 04:28:04 TabAtkins: %foo > .error { @extend %bar; } 04:28:28 maybe s/selector variables/custom selectors/ 04:28:47 TabAtkins: Complex selector sare quite common in SASS like that. They have to use some heuristics for it, because can't do it quite correctly 04:29:32 s/.../It depends on whether you allow using selector aliases before you define them/ 04:29:38 TabAtkins: can I have ED? 04:29:45 fantasai: I don't hear agreement on the draft. 04:30:05 fantasai: I don't even hear any ideas of what Tab needs to do to fix it so that we all agree it's going in the right direction. 04:30:13 fantasai: So I'm not happy with an ED 04:30:26 fantasai: But I also want us to tell Tab what he needs to do to get there 04:30:48 glazou: My concern is that if we accept ED and then have a media storm if we reject or change significantly 04:30:51 plinss: Had the same thing with variables 04:30:55 glazou: Yes, and I would like to avoid that. 04:31:31 zakim, remind TabAtkins in 15 years to re-propose @extends 04:31:31 I don't understand you, ChrisL 04:31:58 dbaron: I'm nervous about making something an ED when more people in the room think it's not going to work than think it's going to work. 04:32:24 hmm ... %foo > .error { @extend %foo; } 04:32:45 ... 04:32:45 div { @extend %foo; } 04:32:55 css-as 04:32:59 plinss: Call it maybe Style Rule Composition 04:33:28 [random comments] 04:33:42 shortname sugestions 04:33:50 css-subclassing 04:33:57 css-bikeshedding 04:34:02 css-composition 04:34:09 so @extend is different from custom selectors because it allows defining recursive selectors 04:34:12 css-class-class 04:35:20 proposal: Make an editor's draft with big red warning to work on the problem, called CSS Style Rule Composition, shortname tbd 04:35:25 RESOLVED: Make an editor's draft with big red warning to work on the problem, called CSS Style Rule Composition, shortname tbd 04:35:29 is it break time yet? 04:35:55 tabatkins: next I'd like to present, I just want to use JavaScript instead ;) 04:36:27
04:59:17 johanneswilm has joined #css 05:00:10 ScribeNick: TabAtkins 05:00:26 Topic: 05:00:42 SimonSapin: We have an issue when can occur at the same position as keywords, could be amibiguous. 05:00:47 SimonSapin: Need to define how to resolve. 05:01:17 SimonSapin: Right now the spec says that the first occurence of something ambiguous is given to the keyword, and afterwards is . 05:01:26 SimonSapin: But that means you ahve to remember what you've parsed so far. 05:01:34 SimonSapin: That's annoying to implement, and maybe surprising to authors. 05:01:43 SimonSapin: If you reorder things where order normally doesn't matter, it changes the meaning. 05:02:02 SimonSapin: Another option is to restrict based on what it can be ambiguous with. 05:02:33 vollick__ has joined #css 05:02:35 SimonSapin: For example, list-style-type takes either | string | none 05:02:40 SimonSapin: And is 05:02:53 SimonSapin: So if you specify "none", it can't be a , as it'll be ambiguous. 05:02:55 SimonSapin: But that's easy. 05:03:14 SimonSapin: In list-style, at the same position as you would have a , you might have "outside" keyword, a valid list-style-position value. 05:03:31 SimonSapin: So here we should restrict to not be able to be "outside". 05:03:46 dbaron: So you'd restrict "outside" from list-style-type as well? 05:03:57 SimonSapin: That's possible, but it's harder to maintain. 05:05:13 TabAtkins: We explicitly rejected the "exclude keywords from all contexts it can be used", because that set is large and ever growing, and confusing to think about. 05:05:40 TabAtkins: We also purposely moved away from the simpler "exclude keywords from the current context", because it still makes it hard to extend the set of keywords in the future; they might be used by authors. 05:05:53 TabAtkins: We purposely moved to the current behavior, which matches animation, to avoid those problems. 05:07:03 SimonSapin: Describe current animation behavior? 05:07:25 TabAtkins: What the spec currently says - only claims unknown keywords, or known keywords that correspond to properties that are already set by earlier keywords. 05:07:51 TabAtkins: So you can name an animation "forwards" as long as you also always specify the animation-direction part of the animation shorthand, and put the animation-name at the end. 05:08:07 SimonSapin: That measn in a context where order normally doesn't matter, sometimes it does and you can't. 05:08:56 TabAtkins: Rijght. 05:09:06 TabAtkins: All new grammars should always be positionally unambiguous. 05:09:23 The values spec should probably say that (i.e., give advice for spec authors). 05:10:00 TabAtkins: The only reason we have this problem is old properties that get upgraded to , so something that wasn't ambiguous becomes ambiguous. 05:10:10 TabAtkins: Are you okay with this, given that context? 05:10:22 SimonSapin: Okay, I can live with this. I'd like to explore other options, but maybe in a later meeting. 05:10:53 TabAtkins: Next is global keywords - allow or exclude? I don't care. 05:11:06 fantasai: Weak pref for excluding. I don't think there's any reason to allow them, and they cause some problems. 05:11:16 fantasai: And we already exclude them in font-family and counter-styles. 05:11:36 fantasai: It's better to catch errors earlier, so it's a benefit to authors and just exclude it. 05:11:43 estellevw has joined #css 05:12:13 TabAtkins: I'm fine with that - it amkes it harder to add global keywords, but we don't do those often anyway. 05:12:20 SimonSapin: I think it's arbitrary to exclude them, but meh. 05:12:53 RESOLVED: Exclude the global keywords from . 05:13:27 s/exclude them,/exclude them when not ambiguous,/ 05:16:20 SimonSapin: One remark about . 05:17:12 SimonSapin: The spec says that other specs must clearly say what keywords are excluded. Why normative? 05:17:14 TabAtkins: Why not? 05:17:53 RESOLVED: Pending edits, publish V&U as new CR. 05:18:13 ChrisL: Remember we'll need an up-to-date DoC to republish. 05:18:29 rrsagent, here 05:18:29 See http://www.w3.org/2015/02/08-css-irc#T05-18-29 05:18:45 ScribeNick: fantasai 05:19:02 Topic: Flexbox 05:19:22 TabAtkins: Bug. Don't understand why Chrome and FF interoperably don't do the right thing. IE does the right thing. Pls explain it all. 05:20:46 fantasai: If you have an abspols flex container, it wraps to the window width, but doesn't shrinkwrap into it. 05:21:39 fantasai: We think this is wrong, just wanted to check we're not missing something. 05:22:22 https://lists.w3.org/Archives/Public/www-style/2014Sep/0396.html 05:22:47 fantasai: Issue about no-wrap is still open 05:22:52 fantasai: and have some pagination stuff 05:22:58 fantasai: then should publish 05:23:16 Topic: Form Control Styling 05:23:18 http://dev.w3.org/csswg/css-forms/ 05:23:25 TabAtkins: fantasai brought up form control styling 05:23:34 TabAtkins: Started a nice thread 05:23:44 TabAtkins: Started disagreeing on what is reasonable to allow form control styling 05:24:01 TabAtkins: Have a basic exploratory draft 05:24:35 TabAtkins: Writes up various proposals. We need more screenshots 05:24:45 dino: Web controls are horrible on iPhone 05:25:12 ACTION: florian to make page of all form controls 05:25:12 Created ACTION-673 - Make page of all form controls [on Florian Rivoal - due 2015-02-17]. 05:25:30 fantasai: so proposal is collect screenshots 05:25:45 TabAtkins: Two proposals so far, read and comment and throw out more ideas. 05:26:01 TabAtkins: And really, want more screenshots. Espe. from outside Android/iOS bubble 05:26:18 Topic: Snapshot 05:26:27 ScribeNick: TabAtkins 05:26:37 fantasai: Aaron posted a proposal for a snapshot 2015 05:26:42 www.w3.org/mid/BLUPR03MB199E2D02A3708B7400C5108AD270@BLUPR03MB199.namprd03.prod.outlook.com 05:26:42 fantasai: His proposal is: 05:26:47 https://lists.w3.org/Archives/Public/www-style/2015Feb/0200.html 05:26:48 fantasai: ^^^ 05:26:58 fantasai: We need to update the snapshot. 05:27:08 fantasai: Intro needs reworking, change the vendor-prefix section. 05:27:14 fantasai: But also need to decide what goes into the snapshot. 05:27:25 fantasai: Proposal so far is everything in Rec, 05:27:46 Florian: dbaron and I have also helped him iterate on this 05:28:02 fantasai: Also animation, backgrounds, cascade, conditional, flexbox, fonts, images, multicol, transform, transitions, and v&u. 05:28:09 fantasai: Some discussion about counter-styles. 05:28:13 fantasai: And syntax. 05:28:31 dbaron: Does anyone else implement text-decor-3? 05:28:52 fantasai: I think apple does text-emphasis? 05:28:59 fantasai: I'm guessing it'll wait to 2016, based on what I know. 05:29:36 fantasai: Any other editors think their specs are ready? 05:30:18 TabAtkins: There was a suggestion for the will-change spec. It's stable and widely implemented. 05:30:25 tantek: I think UI meets the criteria too. 05:30:58 TabAtkins: Did you drop all the weird stuff that nobody ipmlemented? 05:31:11 tantek: ::value/choices not yet, but will be dropped asap. Then it's all implemented stuff. 05:32:02 fantasai: I say we leave it out until the new draft that drops those is up. 05:32:25 tantek: How long to do it? 05:32:36 Florian: Several bits need to be rewritten, so won't be published for a little bit. 05:32:40 [some discussion about UI] 05:33:20 fantasai: I'd like will-change to move to CR, if it's ready to be included in the snapshot. 05:34:01 dbaron: Is Syntax a yes? 05:34:04 dbaron: I'd like to see it in. 05:34:10 fantasai: If you say it should go in, I'll support that. 05:35:05 TabAtkins: Everyone okay with Syntax in? 05:35:12 [general assent/disinterest] 05:35:23 SimonSapin: Anything we don't want that it's in CR? 05:35:26 I don't understand the criteria being used 05:35:29 fantasai: Speech, because no ipmls. 05:35:34 fantasai: Text-decor not yet. 05:35:36 appears to be inconsistently applied 05:35:40 fantasai: Writing-modes not yet. 05:36:14 fantasai: Shapes and Masking are not in yet. 05:36:34 TabAtkins: Shapes is in two impls. Sounds like it should go in. 05:37:02 astearns: I think Shapes is reasonably stable, but I'd still like another impl. 05:37:05 TabAtkins: So in or not? 05:37:07 astearns: I dunno. 05:37:31 astearns: Let's leave it out. I don't expect to see changes, but we'll see. 05:37:39 dbaron: I think whoever made the list didn't go through FXTF. 05:37:59 dbaron: Compositing, Masking, Filters, what's ipml status? 05:38:04 TabAtkins: I think they're all in Blink/WEbkit. 05:38:15 roc: FF doesn't do Masking. We do Compositing and Filters. 05:38:42 krit: With exception of Blending, all other specs have partial impls, but aren't implemented entirely. 05:39:07 krit: So Blending should go in. 05:39:31 fantasai: So, Aaron's list, plus will-change and UI once they're updated, plus compositing. 05:39:38 s/Aaron/Arron/ 05:39:55 fantasai: Plus Syntax. 05:40:15 Florian: Do we inline the intro chapters from CSS2? It has a nice introduction to CSS. 05:40:18 so we are including CSS3-UI? 05:40:31 tantek: once the edits are made, yes 05:40:37 Florian: If the snapshot is the intro to stable CSS, seems reasonable to put that there. 05:40:49 tantek: same as with will-change 05:40:55 ChrisL: It turns "a list of stuff" into "a list of stuff plus some introductory material". Do people read it? 05:40:56 astearns: edits we agreed to in this meeting? 05:41:07 because edits are going to be made for quite some time 05:41:10 ChrisL: Will the intro be the same? 05:41:20 s/asterns:/astearns," 05:41:24 Florian: Initially could be the same, but might change too. 05:41:26 oops 05:41:37 fantasai: I think we should do minimal stuff first. Update list of specs and interactions, update vendor prefixing, then publish. 05:41:44 astearns, edits we agreed to in this meeting? because edits are going to be made for quite some time. 05:41:57 fantasai: I think we should include the intro from CSS2 about "this is how property tables work, etc". 05:42:04 tantek: I thought you had a set of edits to make before publishing 05:42:06 fantasai: And a glossary of terms auto-genned from Shepherd for those specs. 05:42:14 fantasai: All this latter stuff as a second pub. 05:42:28 astearns: nope, we already have a draft in the pipe to be published per resolution 2015-01-21 05:42:41 TabAtkins: Sounds good. WE can do the minimal stuff by end of Feb, adtl pubs pending interest. 05:42:49 astearns, no, we already have a draft in the pipe to be published per resolution 2015-01-21 05:43:00 and I would assert event that draft is good enough to be included 05:43:00 fantasai^: And a property index auto-genned by Shepherd 05:43:46 RESOLVED: Produce the snapshot with fantasai's list, update vendor prefix policy. Group will review when finished. 05:44:37 Topic: CSS 2 updates 05:44:56 plinss, maybe dev.w3.org/csswg/css/ should be an alias for the snapshot rather than 2.x, to match http://www.w3.org/TR/CSS/ 05:44:56 fantasai: I think someone was proposing we should publish drafts where we remove sections of CSS2. 05:45:05 fantasai: Unsure we can do that without a lot of overhead, and I'm not sure it's a great idea. 05:45:18 fantasai: But we *should* put a note under every replaced subheading pointing to the replacing draft. 05:45:26 fantasai: At some point int he future we can publish a skeleton spec. 05:45:45 Florian: Do we put a note pointing to specs when they're Rec? Or as soon as they exist? 05:45:52 TabAtkins: As soon as browsers accept them as definitive. 05:46:04 fantasai: CR, definitely. Earlier on a case-by-case basis. 05:46:12 ChrisL: You're proposing a skeletonization. 05:46:46 [discussion of zombie bodies of CSS2.1] 05:46:54 [chrisl describe Night of the Living CSS2] 05:47:20 ChrisL: Apparently we have a bunch of errata to publish. I thought that's what CSS2.2 was about? 05:47:31 ChrisL: Is the whole point of this to just point to the new stuff, why roll in errata in the first place? 05:47:48 fantasai: I think there's some sections of 2.1 we don't have a replacement fo ryet. 05:48:03 fantasai: Some have been replaced; their contents are still correct and can be used as a ref, but we should point to the newer ref. 05:48:10 fantasai: So if we make changes, might as well keep them in sync. 05:48:18 fantasai: But some sections have been completely gutted and redesigned, like syntax. 05:48:30 fantasai: The warning should be more stringent and emphasize that the new ref is very important to look at. 05:48:37 fantasai: We won't be maintaining any errata for syntax. 05:48:55 ChrisL: ARe ther pending errata for 2.1 that need to be published? 05:49:03 ChrisL: Where is that best going to go for people to notice it? 05:49:17 ChrisL: The sections getting replaced should be the new stuff. 05:49:27 Florian: If entire sections are wrong, just say "go look at the new stuff". 05:50:17 fantasai: Part of th eproblem is that our errata maintenance process is unmanageable. It's too hard to publish our errata docs. 05:50:28 fantasai: WE can at least publish notes saying "look over here", so we should do that. 05:50:36 fantasai: And also solve the errata problem, but that's separable. 05:51:01 ChrisL: I just wanted to make sure the errata moved from the errata doc to someplace people will actually look at them. 05:51:10 SimonSapin: The editors draft contains the errata inline. 05:51:38 ChrisL: And there's a note on 2.1 pointing to the ED. 05:52:21 TabAtkins: So does anyone object to adding the notes to the ED, per fantasai? 05:52:34 Florian: Is the criteria for drafts the same as the snapshot? 05:52:56 fantasai: No. CSS2.1 might have a terrible section that's still being repalced by something better, but churning. It's still good to look at the new draft, versus the CSS2 def. 05:53:03 fantasai: So if it's stable OR better, we should point to it. 05:53:30 ChrisL: How to indicate it? People can deep-link. 05:53:34 fantasai: A note on every subsection. 05:53:45 TabAtkins: Yeah, that's probably sufficiently dense that you'll tend to see it. 05:54:44 Florian: Bikeshed should have something for specs to indicate they replace something. 05:54:49 TabAtkins: In time! 05:56:10 SimonSapin: My list of replacement is my personal judgement of what people should look at for implementation. 05:56:15 RESOLVED: Add a note to every subsection pointing to drafts that replace those parts of CSS. 05:56:28 the list in question: https://github.com/servo/servo/wiki/Relevant-spec-links#css-2 05:56:43 s/subsection/subsection of CSS2/ 05:57:39 Topic: Obsoleting css3-linebox 05:57:45 http://www.w3.org/TR/css3-linebox/ 05:58:03 TabAtkins: Tav from SVG keeps landing on this spec and it confuses him. Can we fix it. 05:58:10 fantasai: We're going to redirect this to css-inline-3. 05:58:30 fantasai: I think it was supposed to be published when we did the last draft of dropcaps, but looks like next draft. 05:58:46 TabAtkins: So when's the timeline? 05:59:08 TabAtkins: If it's gonna be this month, fine, otherwise do a note for now. 05:59:13 dauwhe: Let's just do the note now. 05:59:33 RESOLVED: Ask Chris to put an obsoletion notice on the current css3-linebox on TR. 06:00:02 dbaron: I wish I'd at some point published the linebox edits as a WD. 06:00:06 dbaron: No idea where it went now. 06:00:16 dbaron: It's not in the draft repo as css-linebox. 06:01:39 Topic: New publication system 06:02:20 ChrisL: Existing publication system is a piece of shit. 06:02:37 ChrisL: It takes html => tidy => xhtml => php => composter, produces error messages as a primary function 06:02:52 ChrisL: Then when it's free of error messages, ask someone else to do the same exact thing and disagree iwth you. 06:02:58 ChrisL: This is not a good model. 06:03:02 ChrisL: Replacing it with echidna. 06:03:30 ChrisL: The source tool is in github so you can look at it, change it, etc 06:03:48 ChrisL: Been in alpha, apart to go into public beta (tomorrow, hopefully, or today in australia, who knows) 06:03:55 ChrisL: Been testing it today with css3-ui. 06:04:02 ChrisL: It's cursed though. Breaks everything. 06:04:26 ChrisL: Benefits: 06:04:32 ChrisL: Publish any day. All 7 days. 06:04:39 this is what happens when systems pay attention to invisible metadata :P 06:04:40 ChrisL: Can publish multiple times per day; last per day will be retained. 06:04:49 ChrisL: Downsides: first beta won't do CR, only WD. 06:04:58 ChrisL: It won't do cross-WG publications yet. 06:05:02 ChrisL: Those'll be worked on. 06:05:04 pjrm has joined #css 06:05:07 ChrisL: But no FXTF stuff yet. 06:05:19 ChrisL: No human in the way to complain about your stylesheet. 06:05:40 astearns: "last per day will be retained"? 06:05:51 ChrisL: If you publish and notice a problem, you can jsut fix it and nobody will know. 06:06:09 ChrisL: But with more than 24 hours, you're screwed. 06:06:19 heycam: Does anyone get the right to push the button? 06:06:22 fantasai: Everyone but Tab. 06:06:32 ChrisL: Anyone can. There's a token system? I don't understand it well. 06:06:33 Chris: Boston Time 06:06:56 ChrisL: afaik there's nothing preventing chairs from giving it to the editors. 06:06:57 heycam: is there documentation? 06:06:58 heycam: Any docs? 06:07:02 ChrisL: HAHAHAHA 06:07:02 ChrisL: Yes, somewhat. 06:07:17 ChrisL: I'll find it. 06:07:36 https://github.com/w3c/echidna 06:07:40 ChrisL: there is a link to a link to a ^^^ 06:07:48 https://github.com/w3c/echidna/wiki 06:08:07 krit: If something goes wrong, will someone fix it? 06:08:11 Yves has joined #css 06:08:21 ChrisL: Yeah, it's an official systeam product, they'll fix it. 06:08:27 Yves has left #css 06:08:31 SimonSapin: Does that mean we can have max-width:50em on our stylesheets? 06:08:41 ChrisL: Don't know. As long as the checker doesn't complain, you can probably get away with it. 06:09:55 ChrisL: Currently something we have to take out when we publish is the tests script. 06:10:12 ChrisL: W3C is now allowing those scripts, and not under the directory it's pbulished in. 06:10:39 ChrisL: I scared the systeam by first asking for a W3C mathjax install. When they said no, I pointed out we have 60+ individual mathjax versions all bitrotting, and they capitulated. 06:10:58 ChrisL: Bert is maintaining mathjax, Peter will maintain the results script, and I'll talk to Lea about prism.js. 06:11:13 ChrisL: So over time there'll be several approved scripts people can just use. 06:12:16 krit: Can we get a `bikeshed publish` command? 06:12:24 ChrisL: Sure, probably. 06:12:42 tantek: When will we see the first draft? 06:12:46 ChrisL: Maybe tomorrow. 06:13:55 tantek: How long until we can publish CRs, joint work, etc. 06:13:59 ChrisL: A few months. 06:14:20 astearns: Since FPWDs trigger review too, does that mean they can't do it yet either? 06:14:24 ChrisL: Dunno. Probably. 06:14:26 rrsagent, here 06:14:26 See http://www.w3.org/2015/02/08-css-irc#T06-14-26 06:14:45 Topic: Upcoming meeting dates and locations 06:14:58 glazou: Next meeting is confirmed in New York, 18-20 May. 06:15:19 https://wiki.csswg.org/planning/new-york-2015 06:15:23 glazou: We still have to discuss end of august. 06:15:27 some documentation https://github.com/w3c/echidna/wiki/How-to-use-Echidna#current-limitations 06:16:19 TabAtkins: People tell me Zurich is a hellhole in August. 06:16:28 dbaron: And it's gotten very expensive lately. 06:16:34 echidna on github https://github.com/w3c/echidna 06:16:38 TabAtkins: Right. >So what about Paris? 06:16:47 dbaron: Note that everyone leaves Paris in August. 06:16:49 TabAtkins: So cheap hotels? 06:16:57 dbaron: Also some restaurants will be closed. 06:17:29 no, because people from other countries flood in, just as the French fgo to Italy and the Italians all go to Greece :) 06:18:12 TabAtkins: So it sounds like Paris si the best idea. 06:18:14 [general assent] 06:18:26 in case anyone wondered, our cuddly new publication system is named after this http://answersafrica.com/wp-content/uploads/2013/10/echidna2.jpg 06:18:30 plinss: Let's nail down dates. Currently Aug 24-28 blocked out. 06:19:44 dino: What about houdini? 06:21:06 Rossen: 1-2 days. We'll work it out on the ML. 06:24:55 TabAtkins: So, suggestion from Tantek is that Firefox hosts Paris August instead, and Google just does Sydney again next Feb. 06:25:18 TabAtkins, well, it was more of a floated idea to consider 06:27:03 TabAtkins, dual motion 06:27:06 RESOLVED: Moz does August meeting in Paris. 06:27:33 SimonSapin, re the room in paris, both double-check with Shannon *and* book the room in the calendar 06:28:13 dbaron, will do 06:28:36 TabAtkins: Dates! 06:28:48 Florian: Suggest 24-26 06:28:58 szilles: Possible conflict on 24, maybe do 25-27 06:29:38 heycam: Next scheduled SVG meeting is June in Sweden. 06:29:51 heycam: Don't think we're meeting between then and TPAC. 06:30:25 RESOLVED: Provisionally accept Aug 25-27 (Tue-Thu) as the meeting dates. 06:30:52 tantek: Tentatively block out next Feb meeting as first week of Feb? 06:31:16 RESOLVED: Pencil in week of Feb 1st for 2016 meeting. 06:31:25 SimonSapin: Feb 1st is FOSDEM. 06:31:27 with Google hosting in Sydney 06:31:40 glazou: I can't do after Feb 20 06:31:51 getting away from Valentine's Day is a plus 06:32:20 ChrisL: That'll conflict with my 20th wedding anniversary. 06:32:49 dbaron: This year, the week before this week was a more expensive for flights, because of Australia flight patterns, though that went away closer in. 06:33:49 « girlfriend of a standards’ freak, lone evenings » 06:34:39 glazou has left #css 06:34:42 ADJOURNED 06:35:08
06:38:04 glazou has joined #css 06:38:52 br { @extends .break; action: resume; } 06:38:54 ScribeNick: shane 06:39:18 dbaron: discussion on the mailing list - agreed on line height rules. But it's not in the spec yet. 06:39:24 fantasai: it seemed like that made sense. 06:39:38 fantasai: will try to write it up and grasp it fully. 06:40:00 dbaron: with some of the prose for figuring out what this means in terms of vertical placement/sizing I couldn't figure it out 06:40:36 xidorn: open bug about how height in ruby base container can be determined 06:40:58 dbaron: prose in spec about how this can be determined. OK for ruby text container but ruby base container should act like an inline as much as possible. 06:41:27 fantasai: I think ruby base container in terms of how it effects line layout should be like an inline, but in terms of how it effects the spacing of ruby annotations on either size need to take into account border padding and margin 06:41:35 dbaron: ok with that 06:41:45 dbaron: part that's weird is sizing of the content box is not like an inline 06:42:00 fantasai: right. Sizing of content box should include margin boxes of all of the bases 06:42:15 dbaron: is that because you don't like how inlines work? 06:42:28 fantasai: don't like that margins don't effect layout for those. 06:42:43 fantasai: if you put borders on ruby bases, having that not effect position of ruby text seems wrong 06:42:54 fantasai: how does the author get it right then? line height? 06:43:01 dbaron: fine with it to move the ruby text 06:43:40 fantasai: simplest way to keep things from colliding is to have the ruby base container contain all of the ruby base boxes and text container (?) contain ruby text and stack them with no gaps 06:43:53 dbaron: if you don't want line height to effect ruby position that makes sense 06:44:05 SteveZ: but ruby has to effect line height 06:44:08 dbaron: I'm OK with that. 06:44:17 xidorn: does vertical align property effect ruby text? 06:44:19 fantasai: yes 06:44:21 xidorn: but how? 06:44:43 fantasai: don't remember scoping. Ruby text at same annotation level with align with each other. 06:44:57 dbaron: so basically ruby text container acts like a line for purposes of alignment 06:45:12 SteveZ: so what connects lines? 06:45:27 SteveZ: will I get strange behaviour if I put non-ruby stuff between two things? 06:45:53 SteveZ: e.g. underlines don't jump around. Concerned that ruby might act different. I don't know what should happen though. 06:46:12 fantasai: 06:46:41 SteveZ: what if one of the letters was bigger? 06:46:46 fantasai: 06:47:14 fantasai: basically you do the sizing of the characters, then the base box wraps around that, then the text sits on top so it's always aligned 06:48:01 SteveZ: why isn't the ruby text box a line box the whole line long? 06:49:28 xidorn: another concern is the line height of the anonymous ruby text container. In the current model it should inherit from its parent. But I don't think it is desirable. 06:50:01 fantasai: I think you're right. We shouldn't be using properties of the ruby text container for layout. We should be using the ruby text, then wrapping the container around the result. 06:50:52 dbaron: be careful about difference between line box and inline box. Inline box has a line height but line box wraps around a bunch of inline boxes and takes height from them. 06:51:15 dbaron: I think what you're saying makes sense. More complicated but OK. Put in spec please? 06:51:19 fantasai: what's not in the spec? 06:51:25 dbaron: vertical alignmnt 06:51:29 fantasai: I'll just check 06:52:02 fantasai: I need to fix that then 06:52:17 dbaron: that's biggest set of issues I was worried about. 06:52:37 dbaron: would like to see spec edits resulting from discussion with xidorn and kochii though. 06:52:40 fantasai: couple of hard issues 06:54:05 fantasai: handling whitespace between ruby text. Problem is that if you've got ruby text that you've marked up but there's whitespace in-between. Want the whitespace to stay there but I size the ruby text elements to 50% of base text. But then whitespace ends up being really tall and really wide and the wrong size. 06:54:19 Florian: that's not something we can fix 06:54:30 fantasai: yes, HTML people don't like autogenerating tags 06:54:40 fantasai: that's the issue I haven't really figured out how to solve. 06:55:01 dbaron: is it possible to say that the whitespace goes away but that there are other spacing rules for ruby text? 06:55:16 dbaron: e.g. what script they're in, whether script has a certain property. 06:55:26 dbaron: e.g. newlines go away in Chinese 06:55:41 SteveZ: does that mean you want to put another character than whitespace in? 06:56:06 fantasai: I think you could reasonably argue that those rules could get rid of the whitespace but there are other cases where you don't want it too 06:56:22 fantasai: issue is that we want font set on the outer box but instead it's set on the inner boxes 06:56:57 Florian: can we reverse-propagate style to the parent? 06:57:00 dbaron: never done it before 06:57:17 astearns: any other reason we'd want to style the text container? 06:57:21 fantasai: possibly? 06:57:40 fantasai: we do forbid you from making ruby text and ruby base containers visible. 06:57:58 fantasai: this is because some impls will want an internalized structure that's different from the CSS hierarchy 06:58:05 fantasai: styling those boxes isn't an important use case. 06:58:16 fantasai: should be fine to have different internal model 06:58:41 fantasai: so boxes aren't directly detectable, can only inherit properties through them 06:58:59 astearns: can you say line height of container is max line height of children? 06:59:13 SteveZ: that doesn't work. Really want to set it to font size of children 06:59:34 SteveZ: only concerned about whitespace between? 06:59:41 fantasai: yeah everything else is wrapped 07:00:05 Rossen: is this really a common use case? 07:00:13 fantasai: it isn't an error condition but it isn't common 07:00:50 SteveZ: classic one is where you have double ruby (english + ??). English one would need the spaces. 07:01:07 SteveZ: would be common in English ruby 07:01:14 fantasai: not sure what the rules are in pinyin 07:01:52 Florian: some syllables need to be separated by an apostrophe if there isn't a space. Otherwise it's stylistic 07:02:22 Florian: if the only purpose of propagating up is to propagate back down again that seems like the least bad idea 07:02:35 fantasai: agreed. I'll use that for now. If anyone thinks of something better can change it. 07:03:16 fantasai: next issue. Webkit has a special keyword for ruby-font-size. Inter-character generates smaller font than above or below. 07:03:32 fantasai: resolved as locale-specific rule in stylesheet for ruby 07:03:48 Florian: is by language not by script. Close enough? 07:04:10 fantasai: can do it by lang. Can set font size explicitly if a problem. This is just for default size. 07:04:14 Florian: OK 07:05:26 RESOLVED: use locale-specific :lang rules instead of something like webkit-ruby-size. 07:06:47 fantasai: next issue. Ruby-position property had 2 keywords for position in horizontal text and for vertical text. 07:07:11 fantasai: suggestion was to simplify to a single keyword for both (over, under, inter-character) 07:07:18 dino: we have after, before, inter-character 07:07:52 http://upload.wikimedia.org/wikipedia/commons/c/c7/Hunmin_jeong-eum.jpg 07:07:53 fantasai: over means right, under left, and inter-character same as over for vertical text 07:08:08 Florian: this example shows inter-character for vertical text 07:08:15 fantasai: can extend back to two keywords if necessary 07:08:32 fantasai: but this is the common case 07:08:41 fantasai: can we resolve to do this? 07:08:57 scribenick TabAtkins 07:09:00 NOOOOOOOOOOOO 07:09:33 szilles: My undesrtanding of the problem of translating above/below to vertical is that traditionally japanese does right (above) but some chinese cases go left. 07:09:46 fantasai: That's why we had two values, but Xidorn says we dont' need them. 07:09:52 xidorn: I don't see any left cases. 07:10:05 xidorn: You don't have any pictures of left. 07:10:21 xidorn: I don't know what use-cases you've found. 07:10:29 fantasai: This is stuff I inherited from the previous editro. 07:11:00 fantasai: The difference between over/under is. 07:11:34 fantasai: If you have block-flow of vertical text laying out right to left, before is right, after is left. If the blocks stack left to right, vice versa. 07:11:46 fantasai: But over/under depend on what way text is rotated, not block-flow direction. 07:12:07 fantasai: So proposal is to knock it it down to over|under|inter-character, and we can add more in the future if needed. 07:12:14 dbaron: What was the two-value syntax? 07:12:30 [over|under|inter-character] || [left|right] 07:12:34 fantasai: Would let you specify left|right as well, so one's for horizontal and one's for vertical writing. 07:12:45 Florian: The current proposal combines them. 07:13:41 RESOLVED: ruby-position simplified to over|under|inter-character 07:14:08 fantasai: Next is default value of ruby-align 07:14:18 fantasai: Two values are center and space-around. 07:14:21 fantasai: space-around is a justification value. 07:14:33 fantasai: It'd space around at the justificatoin opportunities. 07:14:48 fantasai: So latin text would stay together, but Chinese would be able to split between each char. 07:15:03 fantasai: So we set the initial value to space-around. 07:15:25 fantasai: Problem is that bopomofo can be justified, but bopomofo ruby should be centered by default (due to language users preference). 07:15:39 fantasai: 1) change initial value to center 07:15:52 fantasai: Reset it for Japanese to be space-around in the UA stylesheet. 07:16:15 fantasai: 2) Keep it as space-around, reset it for chinese to center. 07:16:50 fantasai: 3) Have a value that does custom justifications - auto - which justifies between Han and Kana, and not between bopomofo. 07:17:01 fantasai: I prefer 2 07:17:14 s/I prefer 2/Spec is currently 2/ 07:17:25 fantasai: But multi-word ruby you may not want to justify spaces, so maybe 1/3. 07:17:32 fantasai: It seems only Han/Kana should be justifying. 07:17:42 TabAtkins: 1 seems simple then. 07:17:51 szilles: 3 is the classic way we do it, but it requires magic. 07:18:02 fantasai: I don't think 3 is too magic, but 1 is definitely simpler. 07:18:22 fantasai: Main concern with 1 is "do we have a concern with legacy untagged content?" 07:19:15 szilles: 3 is script-based 07:19:30 szilles: Why is 1 better? 07:19:47 fantasai: Simpler. 1 is just a 1-line fix to your UA stylesheet; 3 is effectively a new jsutification algo. 07:20:10 TabAtkins: Can we just do 1 unless we see evidence of brekage in the wild? 07:20:21 fantasai: Dunno what Koji wants. Let's do 1 unless Koji dissents. 07:21:04 RESOLVED: Either option 1 or 3 for ruby-position, at editor's discretion. 07:21:21 ADJOURN FOR REALZIES THIS TIME 07:21:53 dauwhe has joined #css 08:14:16 Ms2ger has joined #css 08:29:32 tantek has joined #css 08:31:32 lajava has joined #css 08:34:43 zcorpan has joined #css 08:58:56 lajava has joined #css 09:19:47 antonp has joined #css 09:39:19 zcorpan has joined #css 10:06:11 svillar has joined #css 10:10:24 zcorpan_ has joined #css 10:12:34 fantasai: oh, noooo, please... 10:17:12 fantasai: actually, it's an interesting question; how to justify Bopomofo in normal text, outside the ruby. In my rough understanding, it's a space-delimited writing system, no? 10:47:09 pjrm has joined #css 11:12:11 glazou has joined #css 11:19:46 dauwhe has joined #css 11:19:53 lajava has joined #css 11:34:53 dbaron has joined #css 12:00:22 Florian has joined #css 12:09:32 tantek has joined #css 12:10:26 Florian has joined #css 12:38:05 svillar has joined #css 12:48:40 tantek has joined #css 13:03:38 plh has joined #css 13:18:14 Florian has joined #css 14:02:43 tantek has joined #css 14:08:25 stryx` has joined #css 14:14:42 fantasai: we do have rtc:lang(zh), rt:lang(zh) { ruby-align: center; } in http://dev.w3.org/csswg/css-ruby/#default-ua-ruby isn't this enough? 14:21:52 fantasai: oh, that's what you added 3 days ago, ok... 14:25:21 lajava has joined #css 14:54:52 svillar has joined #css 15:28:48 thinkxl has joined #css 16:53:51 Florian has joined #css 17:05:28 tantek has joined #css 17:14:31 estellevw has joined #css 17:39:30 adenilson has joined #css 17:41:56 lajava has joined #css 18:49:52 bcampbell has joined #css 20:23:37 johanneswilm has joined #css 21:20:40 bcampbell has joined #css 21:24:07 Florian has joined #css 21:32:19 koji, fantasai: shouldn’t UA rules go into https://html.spec.whatwg.org/multipage/rendering.html ? 21:45:20 tantek has joined #css 21:50:26 Florian has joined #css 21:52:13 Florian has joined #css 22:00:47 Florian has joined #css 22:03:04 glazou has joined #css 22:03:37 Florian has joined #css 22:11:22 dbaron has joined #css 22:14:01 kwkbtr has joined #css 22:14:18 we'll be using #fx today for minuting 22:14:57 liam has changed the topic to: See also #fx for minutes - logs: http://krijnhoetmer.nl/irc-logs/css - Sydney ftf meeting https://wiki.csswg.org/planning/sydney-2015 (JS only logs: https://log.csswg.org/irc.w3.org/css/today ) 22:15:33 nikos has joined #css 22:15:40 dino has joined #css 22:16:32 tantek has joined #css 22:16:54 Florian has joined #css 22:17:46 murakami has joined #css 22:20:01 AndreyR has joined #css 22:21:49 smfr has joined #css 22:24:05 johanneswilm has joined #css 22:24:58 murakami has joined #css 22:25:34 roc has joined #css 22:26:00 stakagi has joined #css 22:26:55 stakagi has joined #css 22:27:28 dbaron has joined #css 22:30:07 xidorn has joined #css 22:31:15 Topic: SVG Sizing and box-sizing 22:31:20 ScribeNick: fantasai 22:31:25 We're looking at some testcases from Tantek 22:31:45 Current testcase is SVG image with width=100 viewBox="0 0 100 100" 22:31:45 fantasai, heycam is scribing in #fx 22:31:48 oh 22:31:52 that' swhy I can't see anything :) 22:31:54 jet has joined #css 22:44:52 koji: ping me when you're online, let's talk about ruby :) 22:52:58 hyojin has joined #css 23:04:12 remember, the meeting is in #fx today 23:17:10 Florian has joined #css 23:53:33 anything actually being minuted? 23:57:04 sgalineau: #fx please 23:57:44 smfr: am there. not seeing anything. maybe irccloud is being funky. 23:59:15 sgalineau, still on break maybe? 23:59:29 oh you said that already, sorry 23:59:34 liam: yes, as it turns out 23:59:38 johanneswilm has joined #css 23:59:53 liam: or at the beach 00:00:53 :D 00:00:55 snow here. 00:03:55 kwkbtr has joined #css 00:06:38 stakagi has joined #css 00:19:32 hyojin__ has joined #css 00:23:34 adenilson has joined #css 01:03:49 tantek has joined #css 01:10:54 jdaggett has joined #css 01:17:23 glazou has joined #css 01:37:31 adenilson has joined #css 01:38:17 adenilson has joined #css 01:39:41 koji: Hi :) 01:39:57 Question 1: 01:40:01 'vertical-align' property 01:40:08 should definitely apply to ruby container 01:40:14 but should it also apply to ? 01:40:23 shepazu_ has joined #css 01:40:29 I'm thining it should apply to , so you can align with respect to each other 01:40:29 smfr has left #css 01:40:45 it makes things easier if it doesn't apply, I think 01:41:28 fantasai: hm, that's where my understanding is a bit unreliable... 01:42:30 when vertical-align is aligned to , I assume its baseline is the baseline of , correct? 01:45:49 when you say it applies to but not to , line boxes of is not affected by the vertical-align of ? 01:47:05 if so, that does not sound great, but I'm not sure if my understanding is accurate 02:15:10 kwkbtr has joined #css 02:35:54 stryx` has joined #css 02:38:07 hyojin has joined #css 02:50:17 stakagi has joined #css 02:59:23 johanneswilm has joined #css 03:00:09 kwkbtr has joined #css 03:02:04 Florian has joined #css 03:02:20 fantasai, btw, regarding text-decorations and selection in Gecko -- Gecko has code specific to determining what color to use for the text-decoration when it's in selected text 03:03:51 tantek has joined #css 03:08:05 TabAtkins: Bikeshed used to add a string in the console what you need to add to the spec to let Bikeshed select the right spec for a defintion. It still says which spec, type and name but you can not copy past anymore. Can this change back? 03:09:54 krit: You have to put it into a 
 block now.
03:09:54  krit: I stopped outputting the text for Link Defaults metadata, because it can't handle for='' values.
03:10:35  TabAtkins: oh, but I still can copy paste from the console but into this 
?
03:10:49  krit: (The message actually says that, but it's easy to skip past because it looks similar to the old message.)
03:10:51  krit: Yeah.
03:13:53  TabAtkins: thanks
03:15:07  koji: No,  would be aligned within , but you can't align different  differently
03:23:55  tantek_ has joined #css
03:25:15  adenilson_ has joined #css
03:40:01  fantasai, koji, I think that means we handle vertical-align on  as if it is always |baseline|, right?
03:40:15  yeah
03:40:30  if that helps
03:40:33  I'm not sure it helps
03:40:47  if you increase the font-size on , you still have different alignment problems :/
03:41:21  no, I don't think there would be
03:41:49  but if some s inside  have different font-size, then there might be, I guess
03:43:58  as long as one vertical-align value can be set to all bases in one , I think that's sufficient
03:44:26  does that answer?
03:44:39  yeah
03:44:46  too
03:44:54  :)
03:45:00  xidornq has joined #css
03:45:27  koji: http://www.w3.org/Style/CSS/read
03:46:32  xidorn: ah right the problem was top/bottom alignment of the bases.
03:46:32  xidorn: I can think of possibilities where author wants center or text-top to base text, so I wish we allow that possibility, but can't think of any scenario where authors want different alignment within single 
03:47:35  xidorn: what if we defined vertical-align: top/bottom to be within the ruby base container only?
03:48:59  fantasai, let me learn what vertical-align is supposed to do for a bit
03:49:31  okay
03:50:11  then what would be the top/bottom of the line if there is margin on s?
03:50:36  vertical align works like this:
03:50:44  align everything that's not top/bottom
03:50:49  measure from the top to the bottom
03:51:00  max(that measurement, size of boxes that are top/bottom)
03:51:07  that gets you height of line
03:51:15  then shift top/bottom boxes to the top/bottom of the line
03:51:17  (roughly)
03:51:22  What I'm suggesting is
03:51:33  that instead of vertical-align: top/bottom on  pushing to top/bottom of the line
03:51:45  we do a local alignment within the 
03:51:50  normally, inlines do not have block-axis margin, so they can be vertical aligned
03:52:06  they have it, you just don't measure it
03:52:12  but if 's margin expands the height of , what should happen
03:52:52  the  gets taller
03:53:10  :)
04:06:52  TabAtkins: Why do I get this warning now and how can I get rid of it by still keeping ''none''? WARNING: Multiple possible 'maybe' refs for 'none'.
04:07:27  fantasai: If you run into more obvious "I always want to get this term from this spec" cases, feel free to do edits on the spec-data/readonly/link-defaults.infotree file. You can do it on GitHub and submit a PR automatically, very easy.
04:07:43  krit: Because there are a bunch of "none" values it can choose from, same as "auto". Specify the property you want.
04:08:05  TabAtkins: So I need to add  No, just ''foo/none''
04:08:33  oh, ok thanks
04:08:37  You can generally use the foo/bar syntax in the autolinking syntaxes.
04:15:27  TabAtkins: I get "Multiple possible 'dfn' refs for 'containing block'." even though I added spec:css21; type:dfn; text:containing block already
04:15:46  TabAtkins: there is no other choice actually
04:16:37  TabAtkins: and last but not least: Bikeshed now prefers you specify alternate linking texts with the 'lt' attribute, not 'title'
04:16:48  TabAtkins: which titles does Bikeshed mean?
04:17:43  TabAtkins: found the title one (but don't understand it)
04:23:00  fantasai, does that also mean descendants of  will also only be aligned within ?
04:23:57  xidorn: no idea, I don't have an opinion on this
04:25:51  krit: Yeah, sorry, if a spec defines an identical term multiple times, you can't shut Bikeshed up.  I'm working with plinss to fix this for specs that are auto-parsed (rather than using Bikeshed, which throws fatal errors if you duplicate definitions).  You can add the term to Ignored Terms to silence the error, at least.
04:26:25  TabAtkins: ah forgot about ignore
04:41:03  estellevw has joined #css
05:02:20  dbaron: Is "(More details here.)" at https://wiki.csswg.org/planning/hosting supposed to be a link?
05:02:44  SimonSapin, I think it means "FIXME: Write more details here"
05:02:51  ok :)
05:10:25  willy has joined #css
05:11:06  willy has left #css
05:20:42  johanneswilm has joined #css
05:20:50  kwkbtr has joined #css
05:22:55  rego has joined #css
05:23:09  astearns: I’m just curious: does it help to open pull requests on the draft repo rather than pushing directly?
05:23:09  Yes, that's what it means.
05:23:16  I also thought it was supposed to be a link at first, though.
05:23:18  kwkbtr has joined #css
05:23:52  SimonSapin: I'm making changes in branches on my own fork of the repo
05:24:23  I suppose I could be branching from the main repo, but I've always used a separate fork with git
05:25:00  I just push to master on the main repo.
05:25:22  yolo
05:25:25  Florian has joined #css
05:25:27  Florian has joined #css
05:36:18  I just flail about in the source-control system I'm given - it would be nice to have a wiki page with recommended step-by-step instructions for editing drafts in git
05:39:03  jdaggett has joined #css
05:41:29  The usual workflow with a single shared repository and a single branch should Just Work. When it doesn’t, nag plinss :)
05:42:25  a pull request can be useful to get review from a (co-)editor before merging
05:47:07  SimonSapin: pointer to "the usual workflow"?
05:55:07  astearns: there are tons of guides out there, with various levels of details. what are you familiar with?
05:55:08  It should look like you did in hg. You just work in the main branch and push when you feel like.
05:55:34  plinss: The Houdini bikeshed errors email is being sent with a subject talking about CSSWG.
05:56:11  I don’t really want to write yet another monad^W git tutorial
05:57:03  i found http://lea.verou.me/2011/10/easily-keep-gh-pages-in-sync-with-master/ useful fwiw
05:57:48  estellevw has joined #css
06:06:37  SimonSapin: But git is just a monad, so you can kill two birds!
06:07:30  liam: Nah, that's overcomplicated.  If you want to display your master branch, just follow http://www.xanthir.com/b4Zz0
06:07:59  I think the instructions in my post weren't possible in 2011.
06:09:29  i think that's a simpler way of working but not having a master doesn't suit everyone
06:09:32  (er, so to speak)
06:11:45  tantek has joined #css
06:13:13  SimonSapin: the guides I've been following say to fork, branch, commit, push, pull request, merge
06:14:33  I see. That is useful if you don’t have push access to the repository (and someone else merges) or if you want review from someone before merging.
06:15:04  might not be a bad idea to require reviews :)
06:15:30  several WG members freaked out when I suggested this before
06:15:55  I got shit to do, man, i can't wait for reviews
06:16:07  so the workflow should be clone, commit, push?
06:16:09  and you get the problem of absent reviewers
06:16:19  not accepting the pull requests in time
06:16:20  tantek_ has joined #css
06:16:50  astearns: right, commit+push should be enough (assuming you already have a clone)
06:17:06  ok
06:17:45  I suspect requiring reviews for Tab's commits only might get wider approval :)
06:17:47  apparently https://mac.github.com/ is a thing, too
06:19:10  I've used the windows github software before. Pretty decent.
06:19:32  I use the Mac app for some things, but mostly prefer the command line
06:26:28  glazou has joined #css
06:32:09  Florian has joined #css
06:53:25  Florian has joined #css
07:00:36  Florian has joined #css
07:04:14  adenilson has joined #css
07:04:43  estellevw has left #css
07:52:24  johanneswilm has joined #css
07:54:46  antonp has joined #css
08:20:12  antonp has joined #css
08:36:06  svillar has joined #css
08:47:30  estellevw has joined #css
09:28:57  lajava has joined #css
10:05:39  Florian has joined #css
10:43:55  lajava has joined #css
10:45:55  Ms2ger has joined #css
11:02:45  zcorpan has joined #css
11:17:31  zcorpan has joined #css
11:31:45  johanneswilm has joined #css
11:34:34  antonp has joined #css
11:38:53  zcorpan has joined #css
12:15:42  Florian has joined #css
13:14:48  plh has joined #css
13:26:32  plh has joined #css
13:55:29  svillar has joined #css
14:25:40  zcorpan has joined #css
14:50:04  Ms2ger has joined #css
15:24:05  antonp has joined #css
15:29:57  Florian has joined #css
15:34:51  anssik has joined #css
15:58:51  johanneswilm has joined #css
16:33:52  estellevw has joined #css
16:34:44  zcorpan has joined #css
16:47:20  estellevw_ has joined #css