00:00:03 koji: I propose we move this to CR, is there any objection? 00:00:12 alan: what about the various categories of faillures? 00:00:13 s/CR/PR/ 00:00:41 florian: we don't have two implementations for sideways, so we would need to drop them 00:00:50 jensimmons: I don't like that 00:01:01 alan: delay them to next level is what we meant 00:01:21 jensimmons: could we sponsor another implementation to get rid of this problem? 00:01:27 where's the link to the test results? 00:01:39 koji: we are looking into it but it won't happen very soon 00:02:10 florian: so you don't think that changing the level will make it slower to be implemented? that is right? 00:02:24 writing-mode: sideways-* 00:02:30 ??: we have plans, we won't change them based on the level 00:02:37 florian: then I am fine 00:02:44 s/??/myles/ 00:03:15 tantek: a behind-flag implementation counts btw 00:03:28 myles: that sounds weird though 00:03:56 florian: (nice try to get implementation timeframe from myles) 00:04:18 is there a link to the issue for implementing sideways-* in Blink? 00:04:30 well, of course…. I should say, could someone drop the link 00:04:37 s/we have plans/i can't comment on plans/ 00:04:44 i definitely did not say that we have plans 00:04:59 i said implementation doesn't look like it will be very difficult 00:05:07 fantasai: since we have received a lot of help from the japanese government, we should consider moving forward without one feature than just delay the whole thing for one feature 00:05:09 (based on not having done it) 00:06:20 fantasai: how long does it take to go from one stage to the other? 00:06:32 here’s the ticket for implementation in webkit https://bugs.webkit.org/show_bug.cgi?id=166941 00:06:35 Bert: six weeks 00:06:50 dbaron: plus some one month or two of padding (laugh) 00:08:18 Bert: (details the "six" weeks which means three weeks minimum but a few more weeks of padding) 00:08:44 fantasai: ten weeks before the tokyo f2f then? 00:09:01 dbaron: that seems pretty soon, february 6 00:09:03 note that you can also do some random sampling of recent (2016) RECs and time since their PR on w3.org/TR 00:09:20 dbaron: so we can delay for as muc as two weaks without risking not having a rec in japan 00:09:37 jcraig has joined #css 00:09:41 dbaron: seems short to attempt any implementation 00:10:02 alan: proposal is therefore to drop sideways and go to pr as soon as possible then 00:10:21 CSP2 did it in about 6 weeks 00:10:23 florian: is there anything else waiting for level 4? 00:11:07 florian: otherwise you can make a level 4 right away and push a very light level 4, we could get sideways pretty soon 00:11:40 actually CSP2 did it in 5 weeks and 2 days 00:12:10 gsnedders: I thought we could get away with the waiting time if there is good indication the features arent likely to cause trouble 00:12:20 gsnedders: since they are in current cr, that match the criteria 00:12:35 tantek: i had the same point; plus you can also overlap the exclusions periods 00:13:18 SteveZ: the process doesn't have special consideration for levels 00:13:35 s/SteveZ/tantek 00:14:09 SteveZ: other solution would be to spit the spec 00:14:34 Florian: we won't get an implementaiton in the time we would save anyway, lets just do the normal way 00:15:23 alan: can we resolve on taking the current spec to PR minus the sideways features? 00:15:34 dbaron: can we get the link to the implementation report? 00:15:44 http://test.csswg.org/harness/review/css-writing-modes-3_dev 00:16:27 https://test.csswg.org/harness/results/css-writing-modes-3_dev/grouped/filter/1/ specifcally shows what doesn't meet CR-exit criteria 00:17:07 fantasai: since some tests are failling, we would need to write a document on why some of the tests do not really matter 00:18:23 Florian: we really need some document because some things are red and we will need to justify why for the transition 00:18:29 http://kojiishi.github.io/generate-w3c-implementation-report/css-writing-modes-3/status-2016-09.html 00:19:51 Florian: and don't forget to also include all the tests that we do pass, there should be a lot of green and a bit of red to put all the chances on our side 00:20:14 when was the last time CSSWG took something to PR? 00:20:51 Florian: 232 tests don't pass because new tests seem to have been added 00:20:55 Florian: that seems a lot 00:21:06 also need to have feature coverage in tests 00:21:18 koji: In september there were 118 00:22:46 Florian: the other problem is that features themselves have failure, even if we can always find two implementations for any test 00:23:13 Rossen: well the criteria is clear, it is by feature 00:23:24 Florian: yes, and features can require more than one test 00:23:43 ??: so what do we do? 00:23:47 yes 00:25:36 tantek: Also we can draw a line on the test suite, and keep letting people contribute tests, we cannot keep the report up to date all the time  00:25:48 not me! 00:26:05 * sorry tantek 00:27:33 Florian: is there a text-combine implementation? 00:27:48 Rossen: yes, in Edge it now does 00:27:59 tantek: Second implentation? 00:28:09 Florian: so do we drop? 00:28:48 jcraig has joined #css 00:29:23 Florian: also some features we will remove may need errata in the future 00:29:32 Florian: the look-ahead feature 00:30:06 ??: we could make it undefined in the level 3 then 00:31:02 (Florian and fantasai reviewing the features) 00:32:36 fantasai: multicol + orthogonal flow which is too long for the document => do something smart (but nobody implemented it) 00:33:02 Florian: but this is not a feature, just a behavior clarification; we can use SHOULD and get away with it without actually removing the recommendation 00:34:26 gsnedders: are webkit and blink able to be considered two implementations? 00:34:45 q? 00:34:55 eae: that happened during the fork, so a fair amount is shared, but a fair amount is likely not too 00:36:14 Florian: so, anyway, can we use SHOULD, I dont like undifining the feature, we have a goal 00:36:23 fantasai: Or we could use MAY 00:36:38 alan: So, looks like we need an updated draft, then we can ask for PR 00:36:46 fantasai: I will work on the edits 00:37:06 alan: and koji will work on the implementation report 00:37:35 Florian: with a test snapshot from september minus things we will have removed? 00:37:54 plinss: it is possible (but requires some work) 00:38:39 alan: and then we split the spec, with what name for the second version 00:38:56 fantasai: Writings Modes Level 4; levels is a css thing not in the process 00:39:35 SteveZ: I don't see any rule who seem to either encourage nor discourage that 00:40:47 SteveZ: the other problem is that changing the MUST to SHOULD risk to be considered a substantial change and trigger another CR 00:41:04 jcraig has joined #css 00:41:52 Florian: well, the change will not risk having an impact on existing implementations, everyone that was compliant still is 00:42:15 tantek: I disagree with SteveZ too 00:42:33 Rossen: let;s keep the split process out of the f2f 00:44:31 ACTION fantasai: drop at-risk features that were not implemented (with possibly a "soft-drop") and publish updated L3, and republish what we have now as L4 00:44:32 Created ACTION-815 - Drop at-risk features that were not implemented (with possibly a "soft-drop") and publish updated l3, and republish what we have now as l4 [on Elika Etemad - due 2017-01-19]. 00:44:41 RESOLVED: Create Level 4 of Writing Modes as current draft, Level 3 to drop all at-risk items, publications TBD 00:45:12 ACTION koji compile impl report for writing-modes 00:45:12 Created ACTION-816 - Compile impl report for writing-modes [on Koji Ishii - due 2017-01-19]. 00:45:21 ACTION plinss create snapshot of writing modes test suite 00:45:21 Created ACTION-817 - Create snapshot of writing modes test suite [on Peter Linss - due 2017-01-19]. 00:45:38 ScribeNick: Florian 00:46:01 fremy: We added some text for width distribution in fixed table layout 00:46:07 fremy: please review 00:46:18 fremy: also fixed some bugs 00:46:36 fremy: the spec missed some referecences to css21 00:47:15 fremy: it's been clarified with regards to percentage heights 00:47:33 fremy: it would be good to have a new WD 00:48:31 Florian: we have a bit of an ongoing discussion on repeated headers and footers, but that doesn't have to block 00:48:33 https://github.com/w3c/csswg-drafts/projects/3 00:48:45 RESOLVED: publish new WD of css-tables 00:49:07 gregwhitworth: please give feedback on the things that are marked as "need UA review" 00:49:46 dbaron: it's called "ready for UA review" 00:49:49 s/need/ready 00:49:52 fremy_ has joined #css 00:50:45 gregwhitworth: this is better to get confirmation from existing implementation first that this is fine before trying to get WG discussions / resolution 00:51:01 Topic: background-repeat-x/-y 00:51:22 shane: we had a resolution to add in 2013 00:51:43 shane: usage was low then 00:51:45 (citation needed ;) 00:51:47 ) 00:51:49 shane: it no longer is 00:51:49 https://bugs.chromium.org/p/chromium/issues/detail?id=376179 00:52:04 old resolution: https://lists.w3.org/Archives/Public/www-style/2014Apr/0188.html 00:52:08 shane: removing them now would be hard 00:52:47 shane: tab convinced me that there would be breakage if we removed 00:53:17 shane: I think we're stuck with them in Blink, so they should be speced and others should implement 00:53:51 astearns: we can add them as legacy things without adding the logical version and the mask-repeat version 00:53:59 astearns: or we can add everything 00:54:28 astearns: or we can throw our hands up in the air and punt 00:54:51 astearns: fantasai, you used to be for it... 00:54:55 fantasai: I don't remember 00:55:00 did anyone mention deprecation as an option? 00:55:30 fremy_: I am not sure why we removed from our implementation 00:56:24 quoting from those April 2014 minutes: 00:56:24 > fantasai: I'm okay if we add logical keywords at the same time so 00:56:24 > we can make sure they work out correctly. 00:56:46 tantek: astearns's first option should use the word deprecation 00:57:13 SteveZ has joined #css 00:58:56 Florian: can we make logical direction keywords work with the -x and -y longhands 00:59:35 astearns: I don't think it would be hard 01:00:21 dbaron: shorthands don't store things 01:00:35 dbaron: but we could store "repeat-block" in both -x and -y 01:00:59 dbaron: you can store the repeat-block on both background-repeat-x and -y, and it means either repeat or no-repeat based on the directionality 01:01:06 rrsagent, pointer? 01:01:06 See http://www.w3.org/2017/01/12-css-irc#T01-01-06 01:01:21 fremy_: can we punt? 01:01:33 shane: it doesn't help 01:01:37 tantek: agreed 01:03:33 astearns: Straw poll: option1: just add -x and -y deprecated, or option 2: add everything: logical longhands, and mask 01:03:52 dbaron: option 3: add -x and -y deprecated and add to mask as well 01:04:17 dbaron: in our case the implementation is shared, so I would really like to keep them the same 01:04:38 shane: I'd be ok with having -x and -y on mask 01:05:49 astearns: poll is between option 2 and 3, option 1 is exlcuded 01:06:21 ScribeNick: fantasai 01:06:54 Option 2: Add background-repeat-x/y, mark deprecated, figure out some way to shove logical keywords into this data structure. 01:06:56 s/exlcuded/excluded/ 01:06:58 option 3 is still deprecate right? 01:07:12 s/Option 2/Option 3/ 01:07:41 Option : Add background-repeat-x/y and logical longhands 01:07:45 Both options include masking 01:07:50 s/Option/Option 2/ 01:08:09 01:08:25 01:08:43 <fantasai> tantek, no I don't think so 01:08:59 <tantek> *with* deprecation! 01:09:15 <dbaron> seems like about 9 in favor of option 3, and 0 in favor of option 2 01:09:34 <Rossen> ... and many abstained 01:09:49 <tantek> o/ deprecate all the {repeat|mask}-{x|y} things! 01:10:40 <fantasai> astearns: Proposed resolution is to add background-repeat-x/y longhands and mask-repeat-x/y longhands, mark them deprecated, and deal with the shorthand weirdness, possibly like dbaron proposed 01:10:50 <fantasai> RESOLVED: add background-repeat-x/y longhands and mask-repeat-x/y longhands, mark them deprecated, and deal with the shorthand weirdness, possibly like dbaron proposed 01:12:40 <fantasai> [discussing what to discuss] 01:12:52 <fremy_> https://github.com/w3c/csswg-drafts/issues/508 01:13:00 <fantasai> https://drafts.csswg.org/css-values-4/ 01:13:09 <fantasai> https://drafts.csswg.org/css-text-decor-4/ 01:13:14 <fantasai> Topic: Values & Units 01:13:19 <astearns> https://drafts.csswg.org/css-values-4/#changes 01:13:28 <fantasai> https://drafts.csswg.org/css-text-decor-4/ 01:13:40 <fantasai> https://drafts.csswg.org/css-values-4/#changes 01:13:52 <fantasai> Added the vi, vb, ic, lh' and rlh'' units. 01:14:09 <fantasai> fantasai: Should we publish FPWD, or are there other things we want to handle before FPWD? 01:15:08 <fantasai> fantasai: calc() serialization rules are also "new", marked as under discussion 01:15:15 <fantasai> jensimmons: Aspect ratio unit? 01:15:23 <fantasai> fantasai: Still not clear whether that should be unit or property 01:15:46 <fantasai> Florian: Lots of proposals for units 01:16:00 <fantasai> dauwhe: I propose closing issue 837 with prejudice 01:17:05 <fantasai> Florian: And person proposing them explicitly said, not discussing use cases 01:17:14 <fremy> fremy has joined #css 01:17:52 <fantasai> astearns: So, resolve to close issue? 01:18:19 <fantasai> tantek: I propose requesting that the person proposing these units incubate them in the WICG 01:19:05 <fantasai> astearns: I'm hearing no objection to close this issue per WG resolution 01:19:19 <fantasai> RESOLVED: Reject all changes in https://github.com/w3c/csswg-drafts/issues/837 01:20:27 <fantasai> fantasai: Wanted to see if anyone has other things to add to this draft before FPWD 01:20:45 <fantasai> dauwhe: Have we discussed adding old-school typographic units? 01:21:06 <fantasai> dauwhe: I've done a bunch of conversions from pica notation 01:21:20 <fantasai> dauwhe: <picas>p<points> 01:21:46 <fantasai> astearns: I've been waiting for properties and values to get to the poitn where you can put your own parsing for ths 01:23:02 <fantasai> astearns: Would you want to see picas in this draft, or wait for the future, or...? 01:23:18 <Rossen> q? 01:23:22 <fantasai> dauwhe: As long as we're drawing up a FPWD, might be worth putting in 01:23:39 <fantasai> SteveZ: Role of FPWD is to trigger patent review, so more complete is better than less complete 01:24:04 <fantasai> astearns: Would anyone object? 01:24:17 <fantasai> fantasai: Would like to hear from dbaron/TabAtkins because this involves the parser 01:24:28 <fantasai> TabAtkins: This doesn't parse well with CSS. 01:24:42 <fantasai> TabAtkins: Strongly opposed to that particular notation going into CSS, unless we adjusted Syntax to allow for it. 01:24:53 <fantasai> TabAtkins: And then I'd still be unhappy about it 01:25:08 <dbaron> dbaron: are you allowed to use e notation in both halves? 01:25:30 <fantasai> Florian: What about introducing a functional notatioN? 01:25:49 <fantasai> Florian: it would at least allow you to convert existing designs very easily 01:26:04 <fantasai> TabAtkins: Kinda would prefer to wait for Houdini to see if it's popular enough 01:26:14 <fantasai> Florian: Doubt these units are patented 01:26:22 <fantasai> dauwhe: There's 19th century prior art here. 01:26:44 <fantasai> dauwhe: It's nice, but not critical 01:26:50 <fantasai> fantasai: There was a request for a cap height unit 01:26:50 <fantasai> https://github.com/w3c/csswg-drafts/issues/660 01:27:10 <fantasai> SteveZ: i18n issues? 01:27:42 <fantasai> Florian: Are there fonts that don't contain ASCII range? 01:28:21 <fantasai> dauwhe: Inline does have heuristics for figuring these out, because it needs the cap height 01:28:40 <fantasai> myles^: Problems with cap-height aren't any worse than ex-height 01:29:06 <fantasai> astearns: Objections to capheigh? 01:29:11 <fantasai> SteveZ: Use case? 01:29:26 <fantasai> astearns: Sizing things to match capital letters 01:29:53 <fantasai> SteveZ: Thai? 01:29:59 <fantasai> myles: ex-height in Thai? 01:30:17 <fantasai> myles: We've certainly had requests for this unit. Haven't had as many request for all of the various other typographic units 01:30:26 <fantasai> SteveZ: We don't get much requests for things that aren't English or European 01:30:41 <fantasai> SteveZ: Indic/SEAsian dont' talk to us very much 01:31:00 <fantasai> Bert: There are various TFs writing typography requirements for various languages 01:31:08 <fantasai> Bert: Shoudl at some point read them 01:31:35 <fantasai> SteveZ: I won't object strenuously 01:31:40 <fantasai> Florian: would like to see specific use case 01:32:19 <fantasai> fantasai: Bert had a magazine where the title was in caps, and there was a wide stripe of color exacly the cap height. 01:32:27 <fantasai> astearns: We need to know this measure for initial letter anyway 01:32:39 <fantasai> Florian: There we have the feature but not the unit 01:32:59 <fantasai> astearns: We know the feature is inadequate for some other languages. Adding this in would allow doing something slightly different if that's what you wanted. 01:33:22 <fantasai> SteveZ: So for languages that have caps, you'd use this unit, and for others you'd use some other measure 01:33:50 <fantasai> astearns: Say you have fancy roman font, and fancy background. Initial letter will alight top of fancy background with top of first line. But what you really want to do is to match the perceived cap height of those glyphs 01:33:59 <fantasai> dauwhe: initial-letter will take the cap-height of the glyph 01:34:04 <fantasai> astearns: Depends on how the font is put together. 01:34:16 <fantasai> Florian: But then the cap height unit wouldn't help either, because it comes from same source 01:34:51 <fantasai> Florian: Not strongly oppose, just might come up with better solution to use cases if we don't need the use cases 01:34:56 <dbaron> would the unit be 'cap'? ('ch' is taken!) 01:35:06 <fantasai> TabAtkins: Core use case is image replacement for glyphs that are matched exactly to the capital letters 01:35:13 <fantasai> cap sounds good to me :) 01:35:49 <fantasai> plinss: that's what it use to be 01:36:09 <fantasai> astearns: objections to cap unit? 01:36:22 <fantasai> SteveZ: Given there's a defnition in initial-letter, no objection 01:36:27 <fantasai> RESOLVED: Add cap unit 01:37:05 <fantasai> ACTION TabAtkins Fix bikeshed errors in css-values-4 01:37:06 <trackbot> Created ACTION-818 - Fix bikeshed errors in css-values-4 [on Tab Atkins Jr. - due 2017-01-19]. 01:38:28 <fantasai> plinss: Propose to add ciceros, didot, and ens 01:38:56 <dauwhe> https://github.com/w3c/csswg-drafts/issues/315 01:39:25 <fantasai> Bert: People use mm now 01:39:33 <fantasai> smfr: Don't want to add if no one's going to use them. 01:40:14 <plinss> didot (dt) where 15dt=16pt, cicero (cc) where 1cc=12dt, en=0.5em 01:40:53 <liam> +1 to adding didot and cicero and ens 01:41:14 <fantasai> fantasai: Since these are simply multiples of existing units, might be worth waiting to see if there is author demand 01:41:25 <fantasai> Florian: What about height of kanji characters? 01:41:28 <fantasai> fantasai: Why not use ems? 01:41:31 <liam> +1 though to way of adding user-defined units instead 01:42:13 <liam> [en is useful because it approximates average character width for a lot of fonts] 01:42:17 <fantasai> astearns: dt, cc, etc. can be done through preprocessor 01:42:29 <fantasai> astearns: For those units that aren't simple conversions, might want to see evidence 01:42:32 <myles> liam: isn't that just calc? 01:42:42 <fantasai> astearns: that people are putting in the effort to make those conversions 01:43:12 <fantasai> dauwhe: Might be worth checking PDF renderers as well 01:43:23 <liam> [no, not calc really, although a preprocessor could do that for the static cases (not e.g. cap height)] 01:44:01 <fantasai> plinss: It's a multiple, but not so convenient 01:44:19 <fantasai> SteveZ: Put an issue in the document? 01:44:23 <fantasai> Florian: If you have use cases, come forward. 01:45:16 <fantasai> RESOLVED: Add issue to css-values-4 asking for whether didot, cicero, ens are needed. 01:45:28 <fantasai> myles: When do we know when to cut off feedback on this issue? 01:45:36 <fantasai> astearns: When we want to close issues to go to CR 01:45:45 <fantasai> Florian: Kanji character 01:46:15 <fantasai> Florian: If you size a gaiji image to 1em, ink area will be a bit too big 01:46:30 <fantasai> dbaron: ic unit? 01:46:38 <fantasai> fantasai: It's equivalent to an em generally 01:46:43 <fantasai> s/unit/unit is wrong axis/ 01:46:48 <fantasai> fantasai: Includes the extra space 01:47:38 <fantasai> .... 01:47:39 <dbaron> s/Kanji character/Kanji height/ (?) 01:48:19 <fantasai> fantasai: I understand the use case perfectly, and if we get that request from CJK people, then I'm ok to add it. But so far doesn't seem to be a high request. 01:48:31 <fantasai> dbaron: Are the font metrics for that any good? 01:48:45 <fantasai> dauwhe: Font metrics are a constant disappointment 01:49:12 <fantasai> myles: It's important for a UA to be able to figure out if the metric is bad and provide an alternate. For cap-height, very simple. 01:49:43 <fantasai> fantasai: We actually have the heuristics for this in the initial letter spec, because needed there. 01:49:58 <fantasai> SteveZ: Ppl at Adobe reviewed that section and said it was OK. 01:50:09 <fantasai> astearns: We have a use case, idea of how it'd be done... 01:50:15 <fantasai> Florian: But don't have strong demand 01:50:25 <fantasai> RESOLVED: Add an issue to ask if there's a need for this unit. 01:51:02 <fantasai> astearns: Anything else for this draft/ 01:51:11 <dbaron> s/draft\//draft?/ 01:51:12 <fantasai> fantasai: unit math, e.g. divide length by length and use in a formula 01:51:17 <fantasai> https://github.com/w3c/csswg-drafts/issues/545 01:51:22 <fantasai> fantasai: Also min() and max() 01:51:25 <fantasai> https://github.com/w3c/csswg-drafts/issues/544 01:51:36 <fantasai> astearns: Do we want to put unit math in the draft? 01:51:44 <fantasai> dbaron: I think we already have a resolution to do this. 01:52:01 <fantasai> RESOLVED: Add unit math to css-values-4 01:52:13 <fantasai> astearns: Dont' have to get all the deatils in, just get it roughly sketched in. 01:52:20 <fantasai> astearns: I think we should get min/max in as well 01:52:34 <fantasai> dbaron: Question about min/max 01:52:45 <fantasai> dbaron: Are we only adding them inside calc, or also as top-level things? 01:53:20 <fantasai> discussion of what that means 01:53:31 <fantasai> TabAtkins: would min() and max() accept expressions then at top level? 01:53:38 <fantasai> dbaron: Early drafts of calc() accepted min() and max() 01:53:45 <fantasai> dbaron: They were things that could be in calc() 01:54:00 <fantasai> dbaron: If the calc() only contained min() or max() and nothing else, could eleminate the calc() wrapper 01:55:16 <fantasai> RESOLVED: add min() and max() to css-values-4, valid within and without calc(), accepts calc expressions as arguments, N arguments 01:55:45 <gsnedders> 325 Westlake Ave N 01:56:00 <gsnedders> "The Penthouse" (PH) 01:56:02 <zcorpan> zcorpan has joined #css 01:56:06 <gsnedders> (PH on the buzzer, that is) 01:56:44 <zcorpan> zcorpan has joined #css 01:59:33 <jcraig> jcraig has joined #css 02:07:28 <AndroUser2> AndroUser2 has joined #css 02:09:03 <jcraig> jcraig has joined #css 02:48:47 <stryx`> stryx` has joined #css 03:04:37 <Guest87> Guest87 has joined #css 03:04:45 <Guest87> Guest87 has left #css 03:37:04 <AndroUser2> AndroUser2 has joined #css 04:47:19 <AndroUser2> AndroUser2 has joined #css 05:34:28 <dauwhe> dauwhe has joined #css 05:47:11 <jcraig> jcraig has joined #css 06:05:07 <AndroUser2> AndroUser2 has joined #css 06:25:43 <tantek> tantek has joined #css 06:34:11 <myles> myles has joined #css 06:35:02 <astearns> Trackbot, end meeting 06:35:02 <trackbot> Zakim, list attendees 06:35:10 <trackbot> RRSAgent, please draft minutes 06:35:10 <RRSAgent> I have made the request to generate http://www.w3.org/2017/01/12-css-minutes.html trackbot 06:35:11 <trackbot> RRSAgent, bye 06:35:11 <RRSAgent> I see 2 open action items saved in http://www.w3.org/2017/01/11-css-actions.rdf : 06:35:11 <RRSAgent> ACTION: fantasai to ask about case for left in i18n review [1] 06:35:11 <RRSAgent> recorded in http://www.w3.org/2017/01/11-css-irc#T18-22-35 06:35:11 <RRSAgent> ACTION: fantasai to drop at-risk features that were not implemented (with possibly a "soft-drop") and publish updated L3, and republish what we have now as L4 [2] 06:35:11 <RRSAgent> recorded in http://www.w3.org/2017/01/12-css-irc#T00-44-31 17:13:34 <RRSAgent> RRSAgent has joined #css 17:13:34 <RRSAgent> logging to http://www.w3.org/2017/01/12-css-irc 17:13:36 <trackbot> RRSAgent, make logs public 17:13:36 <Zakim> Zakim has joined #css 17:13:38 <trackbot> Zakim, this will be Style_CSS FP 17:13:38 <Zakim> ok, trackbot 17:13:39 <trackbot> Meeting: Cascading Style Sheets (CSS) Working Group Teleconference 17:13:39 <trackbot> Date: 12 January 2017 17:14:20 <Florian> Florian has joined #css 17:15:49 <jensimmons> jensimmons has joined #css 17:18:28 <smfr> smfr has joined #css 17:18:47 <zcorpan> scribenick: zcorpan 17:18:48 <SteveZ> SteveZ has joined #css 17:18:52 <SteveZ> present+ 17:18:53 <dbaron> [ doing breakouts again, other half is in #fx ] 17:18:54 <nainar> nainar has joined #css 17:19:04 <zcorpan> Topic: text decoration level 4 17:19:05 <arybka> arybka has joined #css 17:19:09 <fantasai> http://drafts.csswg.org/css-text-decor-4/ 17:20:38 <arronei> arronei has joined #css 17:21:07 <myles> present+ myles 17:21:17 <Guest87> Guest87 has joined #css 17:21:33 <zcorpan> fantasai: i drafted up a text decoration module 17:21:40 <rachelandrew> present+ 17:21:48 <zcorpan> fantasai: plan so far is to add ... text-shadow i haven't added 17:22:02 <zcorpan> fantasai: text-declaration-width 17:22:08 <zcorpan> fantasai: ideally you get that info from the font 17:22:14 <zcorpan> fantasai: can specify a length 17:22:22 <zcorpan> fantasai: doesn't cascade independently 17:22:45 <zcorpan> fantasai: text-underline-offset which needs overline offset also... 17:23:00 <zcorpan> fantasai: if you specify a length, all of the auto ??? 17:23:08 <zcorpan> fantasai: depends on the value of text-underline-position 17:23:20 <zcorpan> fantasai: (reads from spec) 17:23:59 <zcorpan> fantasai: positive moves up. consistent with how vertical-align works 17:24:06 <zcorpan> Florian: i expected the opposite 17:24:09 <surma> present+ 17:24:12 <zcorpan> fantasai: wanted to align with vertical-align 17:24:31 <tantek> tantek has joined #css 17:24:46 <zcorpan> fantasai: i had it go inward rather than up, so if they flip sides it goes in the right direction as appropriate 17:24:59 <zcorpan> fantasai: if you're starting with under edge it might go up 17:25:14 <zcorpan> fantasai: consistency with vertical-align is important. consistency with font coordinate is also 17:25:21 <zcorpan> eae: this makes sense to me 17:25:34 <zcorpan> fantasai: currently make UAs allow to make automatic adjustments 17:25:59 <zcorpan> fantasai: e.g. here there's no vertical align (example in spec) 17:26:05 <melanierichards> present+ 17:26:08 <zcorpan> fantasai: similar effect with automatic baseline 17:26:36 <zcorpan> fantasai: what happens is the underline is slicing through the text, so can move it 17:26:48 <zcorpan> fremy: green one is what edge is doing 17:26:57 <zcorpan> koji: ??? 17:27:08 <zcorpan> myles: 2 spans with different box sizes? 17:27:16 <zcorpan> fantasai: inside there's a big text element. nested spans 17:27:27 <jensimmons> what’s the link to the page on the screen? 17:27:27 <zcorpan> fantasai: small text span has small underline ... 17:27:40 <zcorpan> koji: webkit and blink does low text position 17:28:05 <zcorpan> fantasai: question is, do we want this property to also effect the automatic adjustments 17:28:17 <zcorpan> astearns: we can ask authors 17:28:22 <zcorpan> astearns: leave as is for now 17:28:32 <zcorpan> astearns: anyone have an opinion on this? 17:28:56 <zcorpan> fremy: specifying the properties is fine but giving control to the author will produce different results anyway 17:29:12 <zcorpan> fremy: author will try in one browser and then give different in another browser 17:29:23 <zcorpan> fremy: auto value should just do nothing 17:29:40 <zcorpan> fremy: specify some other completely different behavior for other values, that can be consistent across browsers 17:29:57 <zcorpan> astearns: agree for the case where it is author-controlled 17:30:08 <zcorpan> fantasai: we should od that also 17:30:21 <zcorpan> fremy: gecko is using only elements where you specify underline 17:30:29 <zcorpan> fremy: edge uses the entire text range 17:30:45 <zcorpan> fremy: violation of the spec but produces better results than gecko 17:31:17 <zcorpan> jensimmons: link? 17:31:25 <fantasai> https://drafts.csswg.org/css-text-decor-3/#text-underline-position-property 17:31:27 <zcorpan> koji: q about offset 17:31:41 <zcorpan> koji: table sets initial position alphabetic baseline 17:31:54 <zcorpan> koji: what offset is not specified when it's under.... 17:32:04 <zcorpan> koji: for auto we draw slightly below baseline 17:32:13 <zcorpan> fantasai: 0 is alphabetic baseline 17:32:35 <zcorpan> fantasai: if we start from the UA chosen position the author won't know where that is 17:32:42 <zcorpan> fantasai: 0 at baseline is better 17:32:53 <zcorpan> Florian: ??? 17:33:05 <zcorpan> fantasai: have control over where the anchor is 17:33:26 <zcorpan> ACTION fantasai: add example to offset from different anchor points 17:33:27 <trackbot> Created ACTION-819 - Add example to offset from different anchor points [on Elika Etemad - due 2017-01-19]. 17:33:31 <astearns> s/???/is this going to make authors want a descender unit?/ 17:33:34 <zcorpan> myles: ??? 17:33:42 <zcorpan> myles: should grow outward 17:33:44 <zcorpan> fantasai: ok 17:34:01 <astearns> s/???/is there a reason why you chose to center the thickness/? 17:34:11 <zcorpan> fantasai: centered from the given position. myles said it should be outside from that position 17:34:21 <zcorpan> SteveZ: can change width without changing position 17:34:25 <zcorpan> fantasai: sounds good 17:34:33 <zcorpan> myles: reason we use the word width? 17:34:44 <zcorpan> fantasai: consistency with border-width 17:35:00 <zcorpan> myles: width is usually a metric vertically 17:35:05 <zcorpan> fantasai: not true for border-width 17:35:12 <zcorpan> fantasai: better to be consistent 17:35:20 <zcorpan> astearns: ??? 17:35:27 <zcorpan> Florian: too long 17:35:48 <tantek> s/???/thickness 17:35:58 <fantasai> s/???/Should list it as a mistake to call things -width, should have been -thickness/ 17:36:06 <zcorpan> koji: proposal that we could have a value to specify user value in the font 17:36:07 <fantasai> s/consistent/consistent with border-width, stroke-width, etc./ 17:36:15 <zcorpan> fantasai: that's auto 17:36:17 <zcorpan> myles: don't think so 17:36:30 <zcorpan> myles: i tried to make auto take into consideration what the font says 17:36:33 <zcorpan> myles: terrible results 17:36:52 <zcorpan> myles: having taken the font's metric into consideration ... should be seaprate thing 17:36:58 <zcorpan> myles: use primary ... 17:37:05 <zcorpan> Florian: because fonts are broken? 17:37:07 <zcorpan> myles: right 17:37:16 <zcorpan> myles: so should be seaprate value 17:37:36 <zcorpan> fantasai: we have a keyword somewhere for this 17:37:43 <zcorpan> fantasai: can't remember what we used it for 17:37:48 <zcorpan> SteveZ: ??? 17:38:45 <zcorpan> fantasai: looking at text-decor-4.... 17:38:55 <zcorpan> fantasai: use-font keyword 17:38:57 <zcorpan> fantasai: sounds good 17:39:06 <zcorpan> fantasai: also add text-underline-offset 17:39:22 <zcorpan> SteveZ: why vertical text is alphabetic baseline is the choice 17:39:29 <zcorpan> fantasai: will want that in some cases 17:39:42 <zcorpan> fantasai: auto keyword, should be able to specify offsets from there... 17:39:58 <zcorpan> SteveZ: agree, ... 17:40:02 <jensimmons> *** I want to concur with myles that text-decoration-width is confusing. 17:40:14 <zcorpan> fantasai: for vertical text, japanese/chinese, will get left or right line rather than alphabetic line 17:40:17 <jensimmons> *** having a hard time getting a chance to speak 17:40:22 <zcorpan> SteveZ: get ransom note underlines 17:40:32 <zcorpan> fantasai: want shift by language 17:40:40 <myles> jensimmons: do a q+ 17:40:44 <zcorpan> fantasai: position of the underline is controlled by the underline element, not descendants 17:41:09 <zcorpan> jensimmons: concur with myles concern about having width for underline will be confusing 17:41:14 <zcorpan> jensimmons: can bikeshed it later 17:41:35 <zcorpan> jensimmons: underline ... width seems like how wide it is 17:41:51 <zcorpan> jensimmons: text-decoration is already hard to remember 17:42:13 <zcorpan> myles: you still have to use the phrase "text-decoration" to turn it on 17:42:21 <zcorpan> jensimmons: yes. not suggesting to change that 17:42:39 <zcorpan> fantasai: we can in the future decide ... 17:42:47 <zcorpan> jensimmons: i'm advocating "thickness" or similar word 17:42:53 <zcorpan> fantasai: 1) too long 17:43:04 <zcorpan> fantasai: 2) because we're using width for stroke-width, is consistent 17:43:17 <zcorpan> jensimmons: i understand. but still confusing i think 17:43:27 <zcorpan> fremy: more people don't speak english 17:43:55 <zcorpan> fremy: size? 17:44:22 <fantasai> s/consistent/consistent, which is especially important for non-English speakers/ 17:44:27 <zcorpan> myles: might be worth it to be inconsistent 17:44:35 <zcorpan> astearns: it might. but will not figure this out today 17:44:47 <zcorpan> fantasai: text-emphasis-skip 17:44:57 <zcorpan> fantasai: allows you to say which characters are skipped 17:45:05 <zcorpan> fantasai: typically you skip spaces and puctuation 17:45:09 <zcorpan> fantasai: can skip other 17:45:19 <zcorpan> fantasai: so you don't have to put spans 17:45:43 <zcorpan> Florian: do we need the same kind of split into longhands as text-decoration-skip= 17:45:52 <zcorpan> fantasai: don't think so, related set of things 17:46:12 <zcorpan> fantasai: that's it for what's in the draft 17:46:19 <zcorpan> Bert: ??? shorthands? 17:46:21 <zcorpan> fantasai: it's not 17:46:32 <zcorpan> fantasai: is document-wide setting 17:46:45 <zcorpan> fantasai: may change later, e.g. for a particular headline 17:46:58 <ChrisL> ChrisL has joined #css 17:47:03 <zcorpan> fremy: if we have text emphasis and don't specify skip, value will be inherit 17:47:13 <zcorpan> fantasai: don't think we do that anywhere else 17:47:23 <zcorpan> fantasai: shorthand resets everything 17:47:53 <zcorpan> astearns: things we decided to add ??? 17:48:00 <zcorpan> Florian: we should get an ED 17:48:16 <zcorpan> Florian: in the header you're linking to tracker, want to change that? 17:48:17 <Bert> s/??? shorthands/Is 'text-emphasis-skip' part of the 'text-emphasis' shorthand/ 17:48:58 <zcorpan> fremy: interested in having clear illustration for what expected result should be for auto 17:49:08 <zcorpan> fremy: should have pictures 17:49:12 <zcorpan> fantasai: level 3 17:49:28 <zcorpan> fantasai: we'll add examples 17:49:39 <zcorpan> astearns: also example for positive vs negative offsets 17:49:44 <zcorpan> fremy: ??? 17:49:49 <zcorpan> Florian: open issue for that 17:50:09 <zcorpan> myles: think it's doable for an impl to clamp values to reasoable extremes 17:50:15 <zcorpan> fantasai: good point. should put that in 17:50:28 <zcorpan> fantasai: ink overflow? 17:50:38 <zcorpan> myles: don't want super big underlines 17:50:52 <zcorpan> fantasai: 1) should allow UA to clamp offset values 17:50:59 <zcorpan> fantasai: 2) specify that it's ink overflow 17:51:06 <zcorpan> astearns: some % of an em? 17:51:14 <zcorpan> myles: whatever is sane 17:51:20 <zcorpan> eae: we clamp font size 17:52:00 <zcorpan> fantasai: features on the web are abusable 17:52:27 <zcorpan> fantasai: shifting an offset, why can't i move it to anywhere on the page... 17:52:45 <zcorpan> astearns: should we close off the L4 discussion? 17:52:56 <zcorpan> astearns: resolution for FPWD? 17:53:06 <zcorpan> fremy: webkit-text-field cna specify an image 17:53:14 <zcorpan> fantasai: issue for paint spec 17:53:22 <zcorpan> fremy: if it's considered part of the text 17:53:28 <zcorpan> fremy: ??? 17:53:57 <zcorpan> myles: i imagine it would be, this is how i do overlines.... 17:54:07 <zcorpan> myles: should clarify to not use this for overlines 17:54:11 <zcorpan> fantasai: yeah ok 17:54:42 <zcorpan> fantasai: by april level 3 should be stable enough 17:55:02 <zcorpan> myles: provies valuable use cases 17:55:15 <zcorpan> Florian: together with cap-height ... 17:55:33 <zcorpan> Florian: the thickness/width thing 17:55:41 <zcorpan> Florian: when it's wavy, thickness of the stroke? 17:55:46 <zcorpan> fantasai: don't think it's specified 17:56:19 <zcorpan> fantasai: if you say straight/wavy, the amplitude is greater than the thickness... 17:56:22 <zcorpan> SteveZ: ??? 17:56:50 <fantasai> s/amplitude/amplitude of the wave/ 17:56:53 <zcorpan> astearns: anyone object to FPWD of level 4 17:56:59 <zcorpan> Florian: pending edits sounds good 17:57:06 <fantasai> s/thickness/thickness of the straight line, which is more like the thickness of the wave stroke/ 17:57:15 <zcorpan> RESOLVED: FPWD of text-decoration level 4 17:58:37 <myles> skk: i don't understand 17:58:47 <zcorpan> fantasai: have to balance .. .do the diff spec to make it more maintainable and less risk to introduce errors 17:59:05 <zcorpan> fantasai: it's reasonable to fold in when the lower level draft has gone through CR 17:59:09 <myles> skk: are there text decorations in this manga? 17:59:39 <zcorpan> fantasai: flexbox went through this double phase 18:00:51 <zcorpan> SteveZ: content of this spec is what's in previous... 18:01:12 <zcorpan> fantasai: we should publish early and often 18:01:20 <zcorpan> fantasai: other option is to hold off publishing 18:01:38 <zcorpan> tantek: should have more info in intro about why it's so empty 18:01:52 <zcorpan> SteveZ: abstract could say that 18:01:57 <zcorpan> tantek: or status 18:02:07 <zcorpan> fantasai: section 1 is basically that... 18:02:17 <zcorpan> Bert: ok 18:02:47 <zcorpan> astearns: level 3? 18:02:47 <tantek> I was thinking in generic language that we could perhaps include in other delta specs too 18:03:00 <zcorpan> fantasai: text-underline-position 18:03:10 <zcorpan> fantasai: auto value which is like alphabetic most of the time 18:03:24 <zcorpan> fantasai: used to have alphabetic, but request to drop that so we did 18:03:37 <zcorpan> fantasai: left/right which do under 18:03:41 <astearns> we should have a standard "include level 3 content here" issue (from bikeshed?) and a standard intro issue describing diff specs 18:03:52 <zcorpan> fantasai: restrictions/allowances of where to draw the underline 18:04:00 <zcorpan> fantasai: (reads from spec) 18:04:51 <astearns> s/level 3/level n-1/ 18:05:21 <zcorpan> Florian: subscript is not to avoid ??? 18:05:38 <zcorpan> SteveZ: first 1st is correct? or both? 18:05:42 <zcorpan> fantasai: both correct 18:05:58 <zcorpan> fantasai: can use from OpenType 18:06:11 <zcorpan> fantasai: baseline alignment causes boxes to be position slightly offset 18:06:19 <zcorpan> fantasai: edges of the boxes won't necessarily all align 18:06:34 <zcorpan> fantasai: UAs is expected to accommodate thos ethings 18:06:42 <zcorpan> fantasai: don't adjust for that shift 18:06:53 <zcorpan> fantasai: jstu done baseline alignment, not baseline shifting 18:07:04 <zcorpan> SteveZ: no difference between font size change 18:07:06 <zcorpan> fantasai: right 18:07:37 <zcorpan> fantasai: if alphabetic baseline in two different fonts are different... UA will account for that 18:07:46 <zcorpan> SteveZ: subscribt can use skipping 18:07:55 <zcorpan> fantasai: yes 18:07:59 <zcorpan> fremy: transform? 18:08:04 <zcorpan> fantasai: we ignore transform 18:08:11 <zcorpan> SteveZ: transform is applied after 18:08:13 <zcorpan> fantasai: yes 18:08:24 <zcorpan> fantasai: relative position is more interesting 18:08:52 <zcorpan> fantasai: different impl do different things, should try to maek teh spec match what UAs do or want to do 18:09:13 <zcorpan> Florian: do you know if the range of varaitions is inside the allowed spec things? 18:09:22 <zcorpan> fantasai: outside, do the thing that is not allowed 18:09:41 <zcorpan> fantasai: red thing is wrong 18:10:00 <zcorpan> myles: i think this is a good direction 18:10:05 <jamesn> jamesn has joined #css 18:10:10 <jcraig> jcraig has joined #css 18:10:12 <zcorpan> myles: we don't follow it but that is bad. positive feedback! 18:10:38 <zcorpan> astearns: a bug for this? 18:11:25 <eae> ScribeNick: eae 18:11:29 <eae> Topic: step-sizing 18:12:07 <eae> astearns: not sure what the right order of discussion is 18:12:12 <koji> https://drafts.csswg.org/css-step-sizing-1/ 18:12:31 <eae> koji: I have updated the spec since last time I asked for a review, primarily I got feedback on three items. 18:13:07 <eae> koji: first one, inline stepping, we think it's nice to do but consensus was that it is lower priority than height. Propose to defer. Was removed from spec. 18:13:34 <eae> koji: second thing; baseline feature from previous drat. Similar feedback, concerns about ???, lower priority than other features. Was also removed. 18:13:44 <eae> koji: the only feature remaining is line-height stepping. 18:13:48 <astearns> s/???/baseline/ 18:14:07 <astearns> s/inline stepping/inline-width stepping/ 18:14:18 <eae> koji: last feedback, a few people wanted to have block height in addition to line height. Only line-height stepping is too fragile. Having block-height as well makes it more stable. 18:14:57 <eae> koji: Spec has been under discussion for over a year, propose to publish draft as is and then work together with fantasi to update and come up with new working draft. 18:15:06 <eae> fantasai: we should have all features for the first working draft. 18:15:20 <eae> fantasai: Can sketch up for first publish based on email. 18:15:35 <fantasai> https://lists.w3.org/Archives/Public/www-style/2016May/0089.html 18:15:40 <eae> fantasai: the part you have written is more concrete, if we want to add more things later we can do that. 18:15:59 <eae> ????: Copy email into github issue 490 18:16:13 <nainar> s/???/dauwhe 18:16:14 <eae> astearns: we should at least have the outline in the draft. 18:17:10 <eae> Florian: I used to have concerns but I have no storng objections for the block parts. What has been sketched out so far has missing pieces but no worrying aspects. 18:17:31 <eae> Florian: one of the reasons for the spec taking so long is due to objectionable parts of the spec rather than missing pieces 18:17:40 <eae> Florian: will not block current suggestion 18:18:34 <eae> fantasai: first public draft doesn't have to have all of the details, goal is to get the feature there so people can see what it looks like. 18:19:17 <eae> astearns: if line-step sizing goas ahead and block step sizing does not we can then move that to the next level. Concerned about adding block step sizing later on. 18:19:32 <eae> Bert: Not prohibited by process, there is a second step. 18:19:47 <astearns> s/Bert/stevez/ 18:19:58 <eae> Florian: Once we have sketched out the block part, if there are still concerns we should take it out. 18:20:08 <eae> SteveZ: you can always mark it at risk. 18:20:54 <eae> There are important use cases only addressed by block step sizing. 18:21:12 <eae> fantasai: with block step sizing I think we can get to 80% of the uses cases, without it much less so. 18:21:33 <eae> astearns: getting the outline and publishing the draft sounds like the way to do it. 18:22:06 <eae> myles: Is the idea that browsers in the future will support this *and* line grid? 18:22:08 <eae> astearns: yes 18:22:41 <eae> Florian: Once you have this and line grid, it is not clear that there are many cases where you want to use this alone but I can see uses for this and line grid being used in conjunction. 18:23:42 <eae> Florian: you set your line height which gives the rhythm for the line grid, if you then have sup/sub or different font sizes.. sometimes it is enough to adjust the line grid, sometimes not. You don't want double spacing. Combining line grid and step size might be a way to adjust the slack that sticks out. 18:24:03 <eae> myles: sounds like that shouldn't require this, should be part of line grid. 18:24:21 <eae> fantasai: there used to be a slack propoerty, maybe 18:25:24 <eae> astearns: one example I have considered, I'm using a line-grid for setting baseline. There are also grpahnics using line grid. currently fuzzy, only does positioning of the elements. Only adjust positioning, seems appropriate, shouldn't also change sizing. step size can be used to control the sizing. 18:25:38 <eae> fantasai: think line-grid proposal would support that and resize the box. 18:26:01 <eae> astearns: should be a separation of concerns, line grid should only change position and then step sizing can control size 18:26:25 <eae> fantasai: reminds me of some of the grid proposals, different model. 18:27:29 <eae> fantasai: when you fall of your rhythm, you have to figure out how to handle that case. line grid and step sizing handle that differently. You might value one over the other. When there is a missed opportunity for line grid there is a gap. For step sizing you do not. One might want one or the other. Not unreasonable to have both. 18:28:06 <eae> fantasai: having a gap in the content across pages looks bad, in multi-col having the gap to get alignment might be appropriate. Depends on use case. 18:29:02 <eae> astearns: put another way, there are examples in the line-grid spec that have examples that do not fit the rhythm as the gaps would be too big. There are extra things in line-grid to avoid that. We might be able to remove line-grid complexity b suing step-sizing. 18:29:12 <eae> fantasai: I think tnat's a different thing 18:30:14 <eae> myles: There are differences and both have uses cases. Interop between the two could be complicated and for many authors that migh be confusing. Especially as authors might only know about one or the other. I think it would make a lot of sense to have both described in the same document to preempt that. 18:31:08 <eae> fantasai: Quite different and the interplay isn't that big between them. Would prefer to have them described separately. Technical details are different, would prefer in separate models but am fine with a lot of references between the two. 18:31:33 <eae> fantasai: In terms of technical work, having them in separate models prefered and make it easier. 18:32:37 <eae> SteveZ: I can see a reason to put them together, there are conflicts if both are turned on. On the other hand, from an impl. point of view, step sizing likely to happen much quciker than line-grid so they'll be separate anyway. Having a not that explains how they work together would be helpful. Might end up in one of the specs eventually. 18:33:03 <eae> Florian: The risk of getting interaction wrong from haivng two specs is minimized by having the same people working on both. There is tension. 18:33:38 <eae> myles: if you fast forward 50 years, there will be two similar but very different specs that are confusing. An author will have difficulty figouring our which one to use. 18:34:08 <eae> Florian: If you put too much into a single spec it'll be terrifying. The step-sizing part os comparably much simpler. If you combine it that might scare authors away. 18:34:39 <eae> astearns: I share your (myles) concern for authors. We should raise issues on the specs to clarify the potential conflicts. Ideally before the 50 years pass. 18:34:52 <eae> myles: Of course this should be defined and speced. 18:35:18 <eae> SteveZ: No reason we cannot combine the two at some point in the future. If we do that I propose we change the name of step-sizing. 18:35:26 <eae> fantasai: We could also rename it later. 18:35:48 <eae> Florian: We might want to have a rhythm spec in the future. 18:36:23 <eae> fantasai: As we're talking about flying cars and the future, I'd like to see not just snapping ??? but snapping to a grid, which people have been asking about. 18:37:04 <astearns> s/???/to lines/ 18:37:17 <eae> fantasai: had that in mind as eventually direction when working on the draft. Support snapping to any line in the grid. Becomes a much more general purpose layout tool. 18:37:30 <fantasai> s/snapping to a grid/snapping to an explicit layout grid/ 18:37:41 <eae> Florian: We'll eventually need to integrate with multi-col. 18:37:56 <eae> myles: Sounds like I'm being overruled, two documents solving similar problems. 18:38:43 <eae> astearns: Wouldn't call it being overruled. I think this is a set of concerns we need to keep in mind. You are welcome to object to publishing a first working draft. 18:38:57 <eae> myles: Won't object. 18:39:21 <eae> SteveZ: Can we at least file an issue and put that into the first public working draft? 18:39:24 <eae> Florian: yes! 18:39:30 <eae> astearns: any other questions/comments? 18:39:37 <eae> SteveZ: I really don't like the name step sizing. 18:39:42 <eae> Florian: suggests how, not why. 18:40:23 <eae> astearns: Steve, are you going to object? 18:40:31 <eae> SteveZ: no, name is confusing but won't object. 18:40:37 <eae> ??: name is bad, also conflicts with snap. 18:40:45 <dauwhe> s/??/dauwhe/ 18:40:45 <eae> fantasai: we did rename that to scroll-snap. 18:41:10 <eae> astearns: lacking proposed alternate, will close subject. 18:42:09 <eae> RESOLVED: First published working draft for step sizing. 18:42:14 <eae> <br size=15m> 18:43:56 <fantasai> RESOLVED: koji, fantasai, and dauwhe as co-editors 18:58:38 <smfr> smfr has joined #css 19:03:29 <jcraig> jcraig has joined #css 19:04:30 <fantasai> text issues that need help 19:04:32 <fantasai> https://www.w3.org/mid/20150211003752.GA14268@pescadero.dbaron.org 19:05:08 <fantasai> </br> 19:05:33 <fantasai> SteveZ: Offline discussion to change name of css-step-sizing to css-rhythm as CSS Rhythmic Sizing 19:05:48 <fantasai> SteveZ: Reason that designers are more likely to recognize that 19:05:53 <fantasai> astearns: Actual reason is to see Koji dancing 19:06:23 <jensimmons> jensimmons has joined #css 19:06:33 <fantasai> astearns: We're only changing the name of the draft. 19:06:44 <fantasai> astearns: Not making a property called rhythm, because nobody knows how to spell it 19:07:14 <fantasai> melanierichards: As a designer, I like the idea of using rhythm to describe this, but line grid also seems like it would fit under here 19:07:23 <fantasai> SteveZ: That was intended, so that in future we could fit line grid under here 19:07:49 <fantasai> SteveZ: Basically, I think there was sympathy to what myles was saying in the long term, just not in the short term 19:08:01 <fantasai> esprehn: What are you going to call the inline-axis version? 19:08:03 <fantasai> dauwhe: harmony 19:08:29 <fantasai> Florian: It's not a certainty that we'll merge the specs in, but we want to leave the door open 19:08:36 <fantasai> RESOLVED: css-rhythm 19:09:20 <fantasai> Florian: Slightly related question: should lh and rlh be affected by line-height-step? 19:09:36 <fantasai> fantasai, astearns: I think it should be 19:09:45 <fantasai> astearns: We could just open an issue on the spec 19:10:11 <fantasai> Florian: ok, i'll do that 19:10:20 <fantasai> Topic: Line Grid 19:10:33 <fantasai> Florian: I think one major reason line grid hasn't made progress is complexity 19:10:43 <fantasai> Florian: Could be interesting to try to find a simpler L1 19:11:10 <fantasai> Florian: Feedback from implementers was that this is too large to consider, given it's not high enough priority 19:11:22 <fantasai> Florian: Would like to find a subset that can grow into what it is now 19:11:30 <fantasai> Florian: What I understand to be the worst part of line grid 19:11:40 <fantasai> Florian: is that it can make size depend on position and position depend on size 19:11:46 <fantasai> Florian: For example,if you have a vertical flexbox 19:11:56 <fantasai> Florian: The flexbox establishes a line grid, and flex items snap to it 19:12:19 <fantasai> Florian: Depending where the flex items are, will snap differently, which may then affect its size, which they affects its position 19:12:23 <dbaron> I remember having a discussion with fantasai about something else that was difficult about line grid, but that actually had a bunch of aspects in common with things needed for other specifications, and seemed like it would be doable... but I don't remember what the issue was. 19:12:52 <fantasai> Florian: line grid makes the position of something influence its intrinsic size, which makes it tricky 19:13:02 <fantasai> Florian: Was thinking to break that loop for L1 19:13:14 <fantasai> Florian: First is add as initial value to line-grid property an 'auto' keyword, 19:13:57 <fantasai> Florian: Which does the same as match-parent on most elements and same as create on BFC 19:14:06 <fantasai> Florian: ... 19:14:21 <fantasai> Florian: Enforce not allowing line grid to pass through BFC to descendants 19:14:45 <fantasai> s/.../then drop the match-parent value/ 19:15:03 <fantasai> Florian: In L2, add back match-parent and sort out cyclic dependencies 19:15:29 <fantasai> Florian: Do people agree that this simplifies things? Is it a good idea? 19:15:41 <fantasai> astearns: I think it does simplifies things, but not sure that what it leaves is interesting enough to implement 19:15:59 <fantasai> astearns: What you lose is ability to align baselines between columns 19:16:19 <fantasai> Florian: If you do columns with actual multicol, you don't, because each column starts at the same place 19:16:31 <fantasai> astearns: Columns in page layout 19:16:49 <fantasai> astearns: Different blocks in a page layout, I mean 19:16:57 <fantasai> fantasai: Simple case of main content and sidebar, can't handle it 19:17:14 <fantasai> astearns: If you get their tops to align perfectly, then, you could maybe make that work? 19:17:20 <fantasai> astearns: But also depends on nesting formatting contexts. 19:17:50 <fantasai> astearns: Currently spec tries to limit the interaction between positioning and sizing by saying that the effect on sizing of shifting the blocks position can only be a cetain amount which is less than one line grid height 19:18:07 <fantasai> astearns: And its done this way, there's an algo for sayin, you size a thing as if its position would fall correctly on the grid. 19:18:23 <fantasai> astearns: Then you find out by how much you're off the grid, and then you add that much size at a particular place 19:18:31 <fantasai> astearns: So that when you are positioned you are sized correclty 19:18:38 <fantasai> astearns: It's not a loop but an adjustment you have to make 19:18:53 <fantasai> Florian: Another variant was instead of match-parent value dropped, make it at-risk 19:18:57 <fantasai> Florian: .... 19:19:04 <fantasai> Florian: Leaves it up to UA 19:19:47 <fantasai> Florian: Even if you implement everything, I think 'auto' is useful 19:20:03 <fantasai> fantasai: 'auto' is unpredictable, from an author POV, because BFC is unpredictable, from author POV 19:20:26 <fantasai> astearns: Making the default value whatever it is create a line grid, makes line grid an opt-in thing 19:20:42 <fantasai> astearns: Participating in a parent or an ancestor's line grid is an opt-in thing 19:20:54 <fantasai> astearns: Makes it much more difficult to find all the places where you have to set match-parent 19:22:29 <fantasai> fantasai: You are not making the system easy to understand if you're making it depend on BFC vs regular block. 19:22:35 <myles> q+ 19:22:46 <fantasai> Florian: Use a * selector 19:22:51 <fantasai> fantasai: That's not a very nice way to do things 19:23:10 <fantasai> astearns: Maybe do auto, but instead of match-parent use named line grid 19:23:19 <fantasai> astearns: ... no I'm wrong 19:24:13 <fantasai> fantasai: I don't think simplifying things down here is a good idea. I think having a compelling, coherent solution to a set of compelling use cases would be a better approach 19:24:17 <astearns> q? 19:24:20 <astearns> ack myles 19:24:25 <fantasai> Florian: Implementers cite complexity 19:24:58 <fantasai> myles: We have described use cases that would be omitted from line grid if this were accepted 19:25:06 <fantasai> myles: And those are some important use case that we see people trying to solve 19:25:22 <fantasai> myles: Therefore if this proposal were accepted,it would be even lower priority than it is now. 19:25:43 <fantasai> fremy: Proposal doesn't say you can't implement everything. 19:26:02 <fantasai> Florian: Implementers weren't interest in the proposal 19:26:10 <fantasai> myles: This proposal would make us less interested. 19:26:29 <fantasai> astearns: fremy was saying that you could ignore the level 1 cut 19:26:38 <fantasai> astearns: My concern is that this L1 proposal would make L2 less easy to use 19:26:58 <fantasai> Florian: I'm not hearing overwhelming consensus over the idea, so willing to drop it. 19:27:18 <fantasai> astearns: I'm perfectly happy to define a simplification, as long as it's something we actually want. 19:28:21 <fantasai> fantasai: .... 19:28:38 <fantasai> fantasai: So sitting around and waiting might be more productive than trying to find a simplification 19:29:04 <fantasai> Florian: Is it useful to try to find a simplification, from implementer's point of view? 19:29:14 <fantasai> Emil: Not from our PoV 19:29:18 <fantasai> myles: Not from our PoV 19:29:41 <fantasai> fremy: For us, depends on the time scale. We're not going to ship any of this within the next year or two. 19:30:06 <fantasai> fremy: Even later, interdependency of size and position is a problem for us. 19:30:35 <fantasai> fremy: Right now, we would only consider if it's a web-compat issue 19:30:44 <fantasai> fremy: making a simplification might change thins 19:30:54 <fantasai> myles: Sounds like we should wait a year or two 19:31:10 <fantasai> fremy: If other vendors are going to implement, get critical mass, then we'll look into it 19:32:10 <myles> s/Emil/eae 19:32:14 <fantasai> astearns: I appreciate the attempt, and if someone has a good idea of a good simplification, then would consider it. But probably not worth spending time on it right now 19:32:40 <fantasai> fremy: Having line grid within BFC is better than not at all 19:33:00 <fantasai> ... 19:33:18 <fantasai> fremy: You would make it a property of the grid declaration, then don't need to declare match-parent on individual other elements 19:33:48 <fantasai> astearns: I could see that possibly working from impl side. Be concerned about the author story, to explain why grid is working here and not other places 19:34:07 <fantasai> astearns: Also utility of the feature is limited if it can't go through formatting contexts, then only get very local rhythm 19:34:23 <fantasai> astearns: Could you add an issue to the spec suggesting this grid-until-fc idea? 19:34:35 <fantasai> astearns: Two people in the room who are implementers expressed interest in it 19:34:46 <fantasai> iank_: Might be able to go through FCs, but a bunch of questions that we'd need to sort through 19:34:57 <fantasai> iank_: Obviously this doesn't cross writing modes 19:35:01 <fantasai> Florian: We already have that limitation 19:35:10 <jcraig> jcraig has joined #css 19:35:11 <fantasai> iank_: I'm semi-confident we could do it within an FC 19:35:16 <fantasai> iank_: Less confident about crossing FCs 19:35:28 <fantasai> astearns: Please add an issue, I'll think through it 19:35:36 <fantasai> astearns: Also, I described algo on limiting effects on sizing 19:35:42 <fantasai> astearns: Please review and see if it's OK 19:35:50 <fantasai> astearns: More feedback fro mmore implementers would help 19:36:06 <fantasai> ACTION: fremy to propose within-BFC line grid declaration 19:36:07 <trackbot> Created ACTION-820 - Propose within-bfc line grid declaration [on François Remy - due 2017-01-19]. 19:36:22 <fantasai> Florian: Separate line grid proposal -- since we just adopted line-height-step thing 19:36:37 <fantasai> Florian: Should the line grid be established by the stepped height 19:36:39 <fantasai> fantasai: Yes 19:36:50 <fantasai> astearns: Open an issue and I'll make the change 19:37:03 <fantasai> RESOLVED: line-height-step affects line grid 19:37:21 <fantasai> Florian: Just makes sure that when you turn both on, they work together rather than interfering 19:37:38 <fantasai> astearns: Any other discussion items on line grid? 19:37:47 <fantasai> astearns: Out of agenda items for the morning 19:38:24 <fantasai> Topic: block step sizing 19:38:28 <fantasai> https://lists.w3.org/Archives/Public/www-style/2016May/0089.html 19:38:51 <jcraig> jcraig has joined #css 19:39:32 <fantasai> SteveZ: How does this interact with margin collapsing? 19:39:55 <fantasai> fantasai: I think what it would mean is that the margin contributed by this element is increased 19:40:24 <fantasai> fantasai: You would have to increase the collapsed margin by this amount 19:40:50 <fantasai> SteveZ: If another collapsed margin is larger... 19:40:54 <fantasai> iank_: You'd just pull the block down 19:41:31 <fantasai> astearns: Should stepped things not collapse margins? 19:42:04 <fantasai> ... 19:42:20 <fantasai> fantasai: The plan here was to turn anything that's step-sized a BFC 19:42:30 <fantasai> fantasai: since that would avoid the float complexities 19:42:34 <smfr> smfr has joined #css 19:42:39 <fantasai> iank_: You'd still have to deal with clearance 19:43:13 <fantasai> fantasai: The goal is to have the margin box of this element to be a multiple of the step size 19:43:49 <fantasai> fantasai: defining how margin collapsing works is definitely going to be an issue we need to tackle 19:44:12 <fantasai> iank_: I think we only want to allow increasing the size of the border box, not increasing the margins 19:44:24 <fantasai> fremy: you get a problem with border images 19:44:33 <fantasai> SteveZ: or change the aspect ratio of an image 19:45:14 <fantasai> SteveZ: Seems like we'd really like it to be in the margin box, if we can define how it behaves 19:46:12 <fantasai> fantasai: You could, in terms of implementation strategy, treat it as a kind of outer invisible border, so it's still inside the box object's rect geometry 19:46:57 <fantasai> Florian: ... 19:47:20 <fantasai> SteveZ: My concern is that if, in margin collapsing, we have a box which has been size-adjusted 19:47:32 <fantasai> SteveZ: If its margin wins, then you're reasonably certain that the alignment is kept. 19:47:42 <fantasai> SteveZ: If the other margin wins, then it's not as obvious to me that the margin says 19:47:51 <fantasai> Florian: You could adjust the collapsed margin 19:48:28 <fantasai> fantasai: I have a simpler idea. How about we ignored the result of the collapsed margin 19:49:13 <fantasai> fantasai: Just step-size the margin box of the element as specified, ignoring other margins 19:50:27 <fantasai> fantasai: Collapsing margins may result in throwing off the rhythm--but that's if you specify *other* margins without step-sizing them. 19:50:35 <fantasai> fremy: what about float clearance? 19:50:56 <fantasai> fantasai: I think we should consider that out of scope. We're step sizing this box, not step sizing the whole layout 19:51:02 <fantasai> Florian: This isn't line grid. 19:51:19 <fantasai> fantasai: Right. If you step size the float, and you step size the things wrapping around the float, then it'll all line up. 19:51:36 <fantasai> fantasai: But step-sizing clearance before an element because you decided to stepwise size that element, that seems like a bad thing to try to do here. 19:54:09 <fantasai> fantasai: Step-sizing would allow you to add space to the margin or to the padding, but it should be looking at the element locally, so it only affects that element's marign or that element's padding. The result then interacts with margin collapsing, as if it were the specified margin 19:54:14 <fantasai> size 19:54:20 <fantasai> fremy: What about just always adding the space to the bottom? 19:54:32 <fantasai> dauwhe: That's rather less useful. In fact you most often want it at the top. 19:54:42 <fantasai> Florian (before that line)^: It's configurable 19:54:47 <fantasai> astearns: Other comments on proposal? 19:54:58 <fantasai> fremy: what would you do on a flex item? 19:55:08 <fantasai> fremy: Do you increase the margin before you flex? or after you flex? 19:55:27 <jcraig> jcraig has joined #css 19:55:49 <fantasai> fantasai: I think that you would want to do the step sizing prior to flexing 19:55:54 <fantasai> fantasai: but i'm not sure 19:55:58 <fantasai> astearns: I think it's just like sizing 19:56:05 <fantasai> astearns: It's a height that goes into the flex calculation 19:56:21 <fantasai> astearns: Your final height might not be a step height. Flex wins 19:56:26 <fantasai> astearns: Grid positioning wins 19:56:32 <fantasai> astearns: This is just an input into layout calcution 19:57:01 <fantasai> fantasai: Another way to look at this, which wouldhave the opposite effect, is to treat it the as min/max clamping from the min/max-width/height propertys 19:57:10 <fantasai> fantasai: And we already know how those interact. 19:57:22 <fantasai> fantasai: Probably we should look at use cases here. 19:57:56 <fantasai> fantasai: In any case, the most critical piece here is getting it to work for block-level elements. 19:58:10 <fantasai> fantasai: We can start by defining it for those, and then add in for other layout modes as we figure them out 19:58:18 <fantasai> fantasai: Kinda like we've been doing for box alignment. 19:58:22 <fantasai> fremy: I like this idea. 19:58:41 <fantasai> SteveZ: Question on alignment, if I have two cell table, one row, two columns 19:58:55 <fantasai> SteveZ: 1st column has a heading in it, 2nd column doesn't. I do baseline alignment. I've broken the rhythm. 19:59:23 <fantasai> SteveZ: i haven't got control of being able to push that first line of text onto the line height, I can put space above/below it, but text will land where it lands 19:59:40 <fantasai> SteveZ: Is there a need for distributing space above and below so that baseline lands on the line grid? 19:59:57 <fantasai> Florian: I think that's what you get when you define interaction of this and line grid. 20:00:08 <fantasai> SteveZ: Agree it doesn't get aligned, don't need to solve that problem yet 20:00:40 <fantasai> SteveZ: Looking at alternative that distributes space above and below in a way that aligns to the baseline grid 20:00:48 <fantasai> Florian: I want to solve that, but it would be along the line grid 20:01:01 <fantasai> SteveZ: Stick an issue in the document says, is it worth solving this problem? 20:02:13 <fantasai> fantasai: The goal of this spec is to get the margin box of the element step-sized. The contents of the element lay out with respect to the resulting size, but don't interact with anything outside. 20:02:21 <fantasai> fantasai: There are many use cases where that is what you want. 20:02:51 <fantasai> SteveZ: I want to add a space distribution option that lets you align the baseline of the content to a multiple of the lines 20:03:01 <fantasai> astearns: That's a different feature. 20:03:06 <fantasai> Florian: I would try to use the line grid to solve that problem. 20:03:55 <fantasai> fantasai: This is just a black box. you don't know the content inside it. 20:04:47 <fantasai> SteveZ: .... 20:04:59 <fantasai> fantasai: You're not caring about the baseline there, you're caring about the position of the edges of the line box. 20:05:21 <fantasai> SteveZ: Case is you want your headings, let's say they are 2lh hgih, I'd like them ideally to align with the same rhythm as the other thing 20:05:26 <fantasai> SteveZ: But that doesn't immediately fall out.. 20:05:34 <fantasai> Florian: I don't think it does, and you solve it with the line grid 20:05:55 <fantasai> Bert: question for clarification... 20:06:03 <fantasai> Bert: block-adjust-insert: margin | padding 20:06:39 <fantasai> Bert: So the goal is to size the margin box or the padding box? 20:07:35 <fantasai> fantasai: I think the goal is the step-size the margin box, and it says whether you do that by inserting space int the margin area (invisible) or padding area (increases border-box height) 20:07:44 <fantasai> Bert: What if you want to step-size the border box? 20:07:53 <fantasai> Florian: Use margins that are a multiple of the step size? 20:08:00 <fantasai> fantasai: Could be something else to consider. 20:08:05 <fantasai> SteveZ: ... 20:08:12 <fantasai> Florian: Step sizing alone to achieve vertical rhythm is fiddly 20:08:32 <fantasai> astearns: other comments on rhythm? or take a break? 20:08:41 <fantasai> astearns: OK, caling a break 20:08:46 <fantasai> astearns: 22min until food arrives 20:08:53 <fantasai> astearns: I'm assuming 12:30 is lunch, as yesterday? 20:09:13 <fantasai> fantasai: Wait, I don't need to be minuting this. Why am I minuting this. 20:09:16 <fantasai> <br type=lunch> 20:24:17 <jcraig> jcraig has joined #css 20:25:05 <jensimmons> jensimmons has joined #css 20:26:34 <zcorpan_> zcorpan_ has joined #css 20:32:39 <svillar> svillar has joined #css 20:37:17 <AndroUser2> AndroUser2 has joined #css 20:38:55 <jcraig> jcraig has joined #css 20:47:59 <AndroUser2> AndroUser2 has joined #css 20:53:29 <Guest87> Guest87 has joined #css 20:54:58 <AndroUser2> AndroUser2 has joined #css 21:02:45 <jcraig> jcraig has joined #css 21:10:22 <Florian> Florian has joined #css 21:11:39 <AndroUser2> AndroUser2 has joined #css 21:14:33 <antonp1> antonp1 has joined #css 21:29:28 <AndroUser2> AndroUser2 has joined #css 21:33:57 <AndroUser2> AndroUser2 has joined #css 21:34:46 <myles> myles has joined #css 21:36:04 <smfr> smfr has joined #css 21:38:21 <jcraig> jcraig has joined #css 21:42:30 <Florian> Florian has joined #css 21:43:47 <Florian> Scribenick: Florian 21:43:55 <Florian> Topic: Font color palettes 21:44:10 <Florian> myles: [presents the topic, slides to be posted later] 21:44:43 <Florian> all: [applaud] 21:46:46 <tantek> tantek has joined #css 21:49:47 <astearns> https://drafts.csswg.org/css-fonts-4/#font-palette-control 21:50:10 <jensimmons> thank you 21:51:17 <Florian> TabAtkins: none of the proposals make sense if you cannot change the colors in the palettes 21:51:23 <Florian> TabAtkins: Myles said you can't 21:52:10 <Florian> TabAtkins: If you can have functional names for the color (main fill, shadow...), and set them to something, then it works 21:52:35 <Florian> TabAtkins: but that assumes that you can set the colors individually, not just select a palette 21:53:29 <Florian> myles: The font contains a list of colors, and palettes are define by referring to some colors in that list 21:54:43 <Florian> fantasai: are all the palettes the same number of colors 21:55:06 <Florian> fantasai: Tab was saying that you want to change the the colors in a particular slot of a palette 21:55:32 <Florian> fantasai: manipulating the colors in the list of colors is not useful, but changing colors in a particular palette is 21:56:08 <Florian> surma: so we have a collection of themes, and and you can pick one right? 21:56:11 <Florian> astearns: yes 21:56:24 <Florian> myles: so I think this is very confusing 21:56:32 <Florian> myles: and would like to propose an alternate syntax 21:56:44 <Florian> myles: [proposal in the presentation] 21:58:08 <Florian> gsnedders: what happens if you don't set the base palette 21:58:13 <Florian> myles: we pick something by default 21:58:26 <Florian> Florian: can you not override individual colors? 21:58:28 <Florian> myles: yes 21:59:04 <liam> [it might be useful to be able to say 0 white 31black and have the intermediate entried filled in linear interpolated values?] 21:59:50 <Florian> fantasai: first comment: as an author, are you going to think per font, and think across fallbacks 21:59:52 <astearns> liam: not clear whether font palettes are set up in a fashion where you'd want to fill entries in that manner 22:00:12 <Florian> fantasai: will I remember to set the theme for fallbacks? 22:00:20 <Florian> TabAtkins: you'll need to do both 22:00:25 <Florian> myles: and you can do both 22:00:42 <Florian> myles: I think both will be popular 22:00:55 <Florian> myles: there aren't many fonts like that yet, so we have limited data about that 22:01:34 <liam> astearns, I think if CSS supported it, they would be. Today the technology is still very new. 22:01:46 <Florian> dbaron: what you loose with this proposal is the ability to name individual colors within the palettes, right? 22:01:56 <Florian> Bert: that's an advantage, you don't have to name things. 22:02:40 <Florian> eae: the original proposal let you name the colors, this lets you name the theme. 22:02:52 <liam> [can't see the proposal here :) but not having to name things != not able to name things] 22:03:21 <Florian> zcorpan_: you can use variables to share colors across themes 22:03:33 <Florian> TabAtkins: no you can't, these are not properties, no cascading 22:03:35 <liam> [css custom properties, or preprocessors though] 22:04:08 <astearns> proposal: @font-palette-values "Jupiter Sans" "Arizona" { base-palette: 3; 1: rgb(); 2: rgb(); } 22:04:10 <Florian> TabAtkins: so you lose the ability to tweak individual colors in the palette on a per element basis 22:04:24 <astearns> usage: font-palette: named-palette(Arizona); 22:05:09 <Florian> TabAtkins: you can set up colors using variables for you page and use them everywhere, but here you have to repeat manually 22:05:22 <Florian> Bert: can we consider the named palette to be a color? 22:05:48 <Florian> Florian: how does that work when using it on things other than fonts? 22:05:55 <Florian> Bert: you just pick one 22:06:13 <Florian> TabAtkins: could we reintroduce the naming of the colors as well? 22:07:01 <Florian> esprehn: can you set it on the color property instead of the font-palette? 22:07:25 <liam> shouldn't this go in @font-face ? can it also be made to work for SVG e.g. for border images? 22:07:50 <Florian> dbaron: in the palette definition, you could define which of the color is the one to use when it is used as a generic color 22:07:57 <Florian> Bert: that's what I said 22:08:24 <dbaron> (my comment was in response to Tab saying (in response to ??) that the named-palette() could be a value of 'color' instead) 22:08:36 <Florian> astearns: that would allow us to use these constructed palettes anywhere you can use a color 22:08:53 <TabAtkins> (I didn't say that, I said it was relatively unimportant whether it was in 'color' or 'font-palette'.) 22:09:09 <esprehn> what does base-palette: 3 do here? 22:09:56 <Florian> Florian: That's orthogonal to being able to override individual colors in the palette on a per element basis 22:10:45 <Florian> dbaron: that is to enable 'currentcolor' in other color properties to match something from the palette, rather than the now ignored color property 22:11:12 <dauwhe> dauwhe has joined #css 22:11:47 <zcorpan> zcorpan has joined #css 22:11:53 <Florian> plinss: that doesn't work, because matching a color in the palette is not what you want, you need something that visually matches the palette 22:12:05 <Florian> Florian: could be defined as an extra color in the palette, even if the font doesn't use it 22:12:15 <Florian> ????: but font's don't have that entry 22:12:16 <fantasai> plinss^: which may not be one of these indexed colors 22:12:29 <fantasai> s/????fantasai/ 22:12:34 <fantasai> s/don't have/aren't likely to have/ 22:12:44 <Florian> TabAtkins: gradients are computed from the colors in the palette right? 22:12:45 <Florian> myles: yes 22:13:26 <Florian> esprehn: what happens to the color property 22:13:31 <Florian> myles: it is ignored 22:13:48 <Zakim> Zakim has left #css 22:14:17 <Florian> myles: today the color property is ignored with fonts that have a palette 22:14:58 <fremy> fremy has joined #css 22:15:02 <Florian> fremy: using the color property as all the colors in the palette would be terrible for emojis. 22:16:28 <astearns> esprehn talks about being able to modify all of the palette colors to make them redder, darker, etc. 22:16:35 <Florian> esprehn: you may want to influence the spectrum of the colors in the palette based on the the color property 22:16:50 <Florian> SteveZ: you don't want that to happen on emojis 22:16:52 <TabAtkins> I find it very unlikely that we can do an automated color-shift that'll have a good effect in general. 22:16:53 <smfr> smfr has joined #css 22:17:01 <Florian> myles: you're smileys are going to look sick 22:17:10 <Florian> SteveZ: you could use it to change skin tone on a face 22:17:12 <zcorpan> s/you're/your/ 22:17:56 <Florian> TabAtkins: backtracking a bit, was it intentional that you removed the ability to give names to individual colors, or just a side effect of simplifying 22:18:01 <Florian> myles: more of the later 22:18:10 <Florian> myles: because that seems less important 22:18:28 <fremy> q+ 22:18:48 <Florian> plinss: naming the palette slots and being able to control that seems very fragile 22:19:59 <Florian> TabAtkins: my main use case is to get some way to use the colors you've defined in variables 22:20:08 <Zakim> Zakim has joined #css 22:20:25 <Florian> fremy: I am worried about not having the ability to do transitions on color palettes 22:20:37 <Florian> myles: that may be a good thing 22:21:00 <Florian> plinss: I don't see why you couldn't do it. May look ridiculous, but it should work. 22:21:18 <Florian> gsnedders: is that reasonable to expect font libraries to do that 22:21:24 <Florian> plinss: if you can set colors, you can do that 22:21:59 <Florian> astearns: there are effects that are useful. Make the highlights and flares be animated 22:22:32 <Florian> Florian: Just make the var() function in in a palette definition fetch the value from the root 22:22:43 <Florian> fremy: that doesn't let you change them on a per element basis 22:22:49 <Florian> TabAtkins: that's ok, I don't care too much about that 22:23:07 <Florian> fantasai: could you resolve the colors in the palette on a per element basis 22:23:30 <Florian> myles: that might be a good idea 22:23:44 <Florian> TabAtkins: it works. More complex, but more in line with how variables work 22:24:19 <Florian> esprehn: ??? 22:24:25 <Florian> TabAtkins: I don't want to expose indicies 22:24:43 <Florian> TabAtkins: because they can mean different things in different colors 22:25:09 <astearns> s/???/what if we had a palette(colorindex colorvalue...) syntax? 22:25:31 <esprehn> esprehn: I asked if we could do palette(Name) and palette(1 color 2 color) and transition by expanding to the long form inline 22:25:45 <Florian> plinss: you can get what esprehn is proposing by ..... then you just use the slot names 22:25:54 <Florian> fantasai: that's what the previous proposal was 22:25:56 <esprehn> TabAtkins said no, because the indexes map to a specific font, so putting them in a property doesn't work with font fallback 22:26:20 <Florian> TabAtkins: with this one you can do that without inventing a new naming scheme, just reuse custom properties 22:26:54 <Florian> SteveZ: so if I had trajan with an arizona color scheme, I would define the mapping to its indicies 22:26:57 <Florian> TabAtkins: yes 22:27:23 <Florian> TabAtkins: the only downside is that the interpolation without exposing an interpolate function 22:27:37 <Florian> fremy: just animate the color properties 22:28:05 <Florian> TabAtkins: so don't make font-palette animatable, animate only via custom properties? 22:28:07 <Florian> fremy: yes 22:28:20 <Florian> SteveZ: why are there palettes at all 22:28:27 <Florian> myles: you need at least one of them 22:29:02 <Florian> myles: to pick a set of colors in a GUI 22:29:10 <Florian> astearns: because font designers want control 22:29:34 <Florian> fantasai: it depends on the kind of font. For emoji you'd want to rely on the font designer for example 22:29:44 <Florian> fantasai: [bikeshedding] 22:29:45 <Florian> myles: sure 22:30:31 <dbaron> Florian: The name that we should name internally within CSS should be an ident rather than a string 22:30:47 <dbaron> Florian: So @font-palette-values "Jupiter Sans" arizona { ... } 22:31:19 <Florian> myles: I wanted to avoid conflicts with light and dark 22:31:30 <Florian> TabAtkins: that's fine 22:31:33 <liam> [a current trend in typography is "hand drawn" layered fonts, where you put each layer in a different colour] 22:32:01 <Florian> TabAtkins: it's a tradeoff between bother authors or our future selves 22:32:08 <Florian> fantasai: counter styles does this already 22:32:54 <Florian> fantasai: if you define a custom name that is the same as a keyword that already exists, the custom one wins 22:33:17 <Florian> plinss: [mumbles] 22:33:48 <Florian> zcorpan: the font name should maybe be inside the brackets 22:34:04 <Florian> zcorpan: less confusing, especially with font names that might not be quoted 22:35:07 <Florian> myles: we can move the font-family name into the descritors 22:35:14 <Florian> TabAtkins: or the other way around 22:35:22 <Florian> TabAtkins: but let's push that discussion into an issue 22:35:23 <esprehn> clearly it should be @font-palette-name "Arizona" for-font "Jupiter Sans" { ... } 22:35:38 <Florian> TabAtkins: I'd like to resolve on the general proposal, and do the rest of the bickering in github 22:35:43 <Florian> Florian: +1 22:35:47 <Florian> astearns: I like that 22:36:13 <Florian> Bert: you can maybe put the whole thing inside the font palette property 22:36:26 <fantasai> fantasai: Then you can't reuse it other places 22:36:43 <Florian> Bert: If you don't want to invent a reusable name, you could just inline it. 22:36:54 <Florian> TabAtkins: an anonymous font palette 22:37:00 <Florian> astearns: we could do that later 22:37:11 <fantasai> I would also suggest s/base-palette/extends/ to be consistent with the terms in @counter-styles 22:37:12 <Florian> Bert: yes. that gives us access at the property level 22:37:40 <fantasai> Currently on the board: 22:38:04 <fantasai> @font-palette-values "Jupiter Sans" Arizona { base-palette: 3; 1: rgb(...); 4: var(--stuff); } 22:38:10 <fantasai> font-palette: Arizonal 22:38:16 <fantasai> s/Arizonal/Arizona;/ 22:38:18 <TabAtkins> Proposal: Accept Myles's slimmed down palette control (associate a palette name with a font, assign colors to individual palette entries), with variables usable in the palette entries, drawn from the element's custom properties on use. 22:40:07 <Florian> RESOLVED: Accept Myles's slimmed down palette control (associate a palette name with a font, assign colors to individual palette entries), with variables usable in the palette entries, drawn from the element's custom properties on use. 22:41:09 <Florian> SteveZ: typically, the first palette is a bi-color with black and a main color, should it use the color from the color property 22:41:30 <Florian> fremy: the palette can use current color 22:42:58 <Florian> SteveZ: people wanting to change the color of an emoji, and having to define a custom palette just for that seems overkill 22:43:12 <Florian> SteveZ: so using the currentcolor in the default palette would be useful 22:43:24 <Florian> SteveZ: please mark as an issue 22:44:54 <Florian> fantasai: ??? 22:45:06 <Florian> TabAtkins: the idea was that indices would only apply to the first font, not to fallbacks 22:45:17 <Florian> fantasai: it's not just that, there are issues with cascading and inheritance 22:45:27 <Florian> TabAtkins: true 22:45:53 <Florian> fantasai: there are many ways to end up with a font that's not the one you thought about, and then your palette makes no sense 22:46:51 <Florian> Bert: maybe we need a none or default or auto or normal, instead of the integer in the font-palette property 22:47:06 <Florian> astearns: it's a bit annoying, but it removes the footgun 22:47:34 <Florian> RESOLVED: replace the <integer> in font-palette with "normal", and make it the initial value. 22:48:02 <Florian> fremy: how about the font-shorthand? 22:48:08 <Florian> myles: please file an issue? 22:48:28 <fantasai> ScribeNick: fantasai 22:49:11 <fantasai> dbaron: So, this is a spec that Tab proposed a few years ago and for some reason we never accepted it as an ED 22:49:30 <fantasai> dbaron: It's in Tab's personal github, we have an impl in Gecko preffed off because it's just in Tab's repo 22:49:34 <fantasai> TabAtkins: So do we 22:49:43 <fantasai> Florian: So we can go straight to CR! 22:49:47 <fantasai> <laughs> 22:49:54 <esprehn> myles: what does the NSText/iOS API for this font stuff look like? 22:50:00 <fantasai> <Tab attempts to pronouce FPWD> 22:50:14 <TabAtkins> fuh-pwid 22:50:17 <dbaron> https://tabatkins.github.io/specs/css-font-display/ 22:50:32 <astearns> topic - FPWD for ^ 22:50:43 <fantasai> dbaron: This is me going through our list of features we have implemented and preffed off, and figure out why they're preffed off and if we can ship them 22:50:50 <fantasai> myles: How about putting it into css-font-loading 22:51:03 <fantasai> Florian: Small scoped modules are easy to work with. This is fairly self-contained, so keep it that way? 22:51:16 <fantasai> myles: If it does goe into Fonts, does that make you co-editor? 22:51:24 <fantasai> myles: My opinions have changed 22:51:36 <fantasai> dbaron loses his implementation hook 22:52:07 <fantasai> astearns: any objections to FPWD? 22:52:16 <fantasai> SteveZ: I'd like to object 22:52:38 <fantasai> SteveZ: If people are going to find things, keeping it split out much harder. 22:52:55 <fantasai> dbaron finds his implementation 22:53:10 <fantasai> astearns: I'd like to keep them separate for the sake of moving quickly 22:53:23 <fantasai> fantasai: We could consider merging the two specs once they're in CR 22:53:30 <fantasai> SteveZ: Please cross-reference extensively 22:53:46 <fantasai> gsnedders: Let's get an FPWD asap so we can start the 180-day counter 22:53:53 <fantasai> RESOLVED: FPWD for font-display 22:54:10 <fantasai> plinss: BTW, font-loading has been in LC since May 2014 22:54:42 <fantasai> s/180/150/ 22:56:53 <fantasai> [process discussions] 22:57:12 <fantasai> dbaron: two issues in GitHub and 6 in the spec 22:57:19 <fantasai> ACTION: Deal with issues on font-loading so it can go to CR 22:57:19 <trackbot> Error finding 'Deal'. You can review and register nicknames at <http://www.w3.org/Style/CSS/Tracker/users>. 22:57:51 <fantasai> ACTION: TabAtkins Deal with issues on font-loading so it can go to CR 22:57:51 <trackbot> Created ACTION-821 - Deal with issues on font-loading so it can go to cr [on Tab Atkins Jr. - due 2017-01-19]. 22:58:02 <dbaron> <span style="font-stretch: ultra-expanded">review</span> 22:58:43 <fantasai> fantasai: Btw, when is Transitions going to CR? We resolved to do that a couple years ago as well 22:59:24 <fantasai> dbaron: People keep raising more issues. 22:59:37 <astearns> topic: Tokyo FTF 22:59:46 <astearns> hiroshi projecting 22:59:49 <fantasai> skk: Prepared this slide to describe 22:59:53 <astearns> April 18-21 23:00:06 <fantasai> skk: 18th is Houdini, other three days for CSSWG 23:00:19 <fantasai> skk: On ML I proposed a JP Industry Meetup 23:00:27 <fantasai> skk: As we did in Sapporo TPAC 23:00:35 <fantasai> skk: In addition, also have a Vertical Writing Web Award 23:00:46 <tgraham``> tgraham`` has joined #css 23:00:52 <fantasai> skk: Result will be decided in March, so we can present to this WG 23:00:59 <fantasai> skk: Would like to have some joint meeting itme slot 23:01:06 <fantasai> skk: Proposed at first the 17th 23:02:07 <fantasai> skk: But yesterday, was suggested that 17th not so good because 18th is Houdini, and industry meeting is preferred closer to CSS meeting which is more related 23:02:22 <dbaron> Note the AC Meeting is Sunday evening through Tuesday in Beijing 23:02:27 <fantasai> skk: So, proposal to change 20th to half day CSS and half day JP industry meeting 23:02:46 <fantasai> skk: Then follow by dinner 23:02:52 <fantasai> skk: That maybe helpful for discussions 23:03:03 <fantasai> skk: Is there preference for Monday or half-day Thursday? 23:03:21 <fantasai> Florian: We need to announce to Japan, so need to make final decision asap 23:03:50 <fantasai> Rossen: What time were you thinking about starting? 23:04:04 <fantasai> skk: I haven't decided well, but from my mind 1pm-6pm in the afternoon 23:04:33 <fantasai> Florian: If we feel this might be reducing CSS meeting too much is to also consider expanding dual-track to parallelize Houdini and CSS 23:05:49 <fantasai> fantasai: Are we more likely to successfully dual-track JP meetup with houdini or with other topics in CSS? 23:06:38 <fantasai> astearns: CSS is a bigger group so Houdini seems more likely 23:06:45 <fantasai> Rossen: Thursday afternoon seems likely 23:06:58 <fantasai> Rossen: We can decide later if we have critical mass to dual-track the afternoon on another topic 23:07:15 <fantasai> Rossen: But having on a separate day, especially if it extends the number of meeting days, is maybe hard to justify 23:07:19 <astearns> what I meant is that we'll get more participants in the industry meetup if we have it on a CSS day 23:07:21 <fantasai> Rossen: So I think this plan makes more sense 23:07:50 <fantasai> skk: OK, I will announce for Thursday industry meetup 23:08:08 <fantasai> skk: I will notify everyone of the time schedule 23:08:38 <fantasai> RESOLVED: Industry meetup Thursday afternoon in Tokyo 23:09:15 <myles> myles has joined #css 23:25:41 <ChrisL> ChrisL has joined #css 23:29:59 <Florian> Florian has joined #css 23:30:07 <gsnedders> http://doodle.com/poll/n7dg3i2hmuvzagws 23:34:23 <arybka> arybka has joined #css 23:34:47 <astearns> provisionally meet week 1 or 2 in Aug, in Europe 23:35:01 <astearns> checking hosting availability for those dates 23:36:20 <Bert> My meeting rooms in Sophia-Antipolis are all available. Hotels I don't know... 23:40:19 <rachelandrew> just noting that week 1 and 2 in Europe is prime school holiday season. Expensive hotels and airports are interesting. 23:40:55 <astearns> https://tabatkins.github.io/bikeshed/#cli-echidna 23:42:32 <astearns> www.w3.org/users/myprofile 23:43:33 <astearns> , your W3C ID (the number at the end of the url when you navigate to https://www.w3.org/users/myprofile) can be added as a w3cid #### clause. 23:44:55 <jcraig> jcraig has joined #css 23:45:16 <astearns> bikeshed echidna -u="somebody" -p="stuff" -d="link to decision to pub" 23:46:33 <astearns> will give you a link to progress/errors 23:46:46 <astearns> q: status magic? 23:46:52 <astearns> has to be WD 23:47:11 <astearns> q: can you configure username/pass? 23:47:12 <astearns> not yet 23:55:37 <jcraig> jcraig has joined #css 23:56:17 <myles> myles has joined #css 23:56:36 <dbaron> the scheme should be https: 23:56:37 <fantasai> ScribeNick: fantasai 23:56:43 <fantasai> Topic: CSS2.1 23:56:57 <fantasai> astearns: Idea is that we have one /TR document that is CSS2 23:57:06 <fantasai> astearns: That has everything that is really implemented in browsers 23:57:11 <fantasai> astearns: And is the reference that everything goes to 23:57:18 <fantasai> astearns: Then we also have a /TR document that is a NOTE 23:57:23 <fantasai> astearns: That is the same thing, but with proposed errata 23:57:27 <fantasai> astearns: Stuff that isn't quite vetted 23:57:32 <fantasai> astearns: Aren't tests, or tests aren't passing 23:57:51 <fantasai> astearns: And we periodically--much more frequently than previously--update CSS2 with whatever in the NOTE is finished 23:58:03 <fantasai> Florian: One of the things that we said we'd be doing with CSS2.Something 23:58:09 <fantasai> Florian: Was to delete the things better defined elsewhere 23:58:25 <fantasai> Florian: If we are replacing CSS2.1, do we replace with things that have deleted sections? 23:58:34 <jcraig> jcraig has joined #css 23:59:00 <fantasai> fantasai: I think we should not delete anything 23:59:55 <fantasai> fantasai: But we can put a note (not an obnoxious notice, but a regular note) at the top of each replaced section/subsection pointing to the corresponding section/subsection in the replacement spec