00:04:17 emalasky has joined #css 00:06:39 glenn has joined #css 00:11:47 myakura has joined #css 00:18:44 kennyluck has joined #css 00:21:28 masatakayakura has joined #css 00:23:51 mgylling has joined #css 00:26:16 dauwhe has joined #css 00:28:16 glenn has joined #css 00:34:18 dauwhe has joined #css 00:35:12 sgalineau has joined #css 00:35:21 cwdoh has joined #css 00:36:20 r12a has joined #css 00:36:23 dauwhe_ has joined #css 00:36:35 glenn_ has joined #css 00:41:19 cwdoh has joined #css 00:43:47 glenn has joined #css 00:49:39 mgylling_ has joined #css 00:49:40 dsinger has joined #css 00:52:16 hayato_ has joined #CSS 00:53:01 dsinger_ has joined #css 00:56:07 dsinger_ has left #css 00:59:27 cwdoh has joined #css 01:03:13 silvia has joined #css 01:03:25 silvia1 has joined #css 01:05:17 liam has joined #css 01:05:26 cwdoh has joined #css 01:05:55 tobie has joined #css 01:05:57 cwdoh has joined #css 01:06:28 lmcliste_ has joined #css 01:06:45 ijongcheol has joined #CSS 01:07:48 kurosawa has joined #css 01:09:12 plh has joined #css 01:12:52 silvia has joined #css 01:14:27 lmcliste_ has joined #css 01:15:16 kimwoonyoung has joined #css 01:17:16 stakagi has joined #css 01:17:46 zhouchao has joined #css 01:18:18 leif has joined #css 01:19:01 rhauck has joined #css 01:22:18 Zakim has joined #css 01:22:19 kennyluck has joined #css 01:22:28 zakim, room for 4? 01:22:29 ok, plinss; conference Team_(css)01:22Z scheduled with code 26634 (CONF4) for 60 minutes until 0222Z 01:22:46 kennyluck has joined #css 01:23:02 zakim, call Wuzhou_East 01:23:02 ok, plinss; the call is being made 01:23:03 Team_(css)01:22Z has now started 01:23:05 +Wuzhou_East 01:23:12 zqzhang has joined #css 01:23:20 dbaron has joined #css 01:23:30 bobby has joined #css 01:23:38 rhauck1 has joined #css 01:25:03 rhauck has joined #css 01:26:06 -Wuzhou_East 01:26:06 Team_(css)01:22Z has ended 01:26:06 Attendees were Wuzhou_East 01:26:14 Rossen_ has joined #css 01:26:14 zakim, remind us in 9 hours to get some sleep 01:26:14 ok, plinss 01:28:10 rhauck2 has joined #css 01:28:10 rrsagent, make logs public 01:28:15 lmcliste_ has joined #css 01:28:50 kawabata2 has joined #css 01:29:55 dino has joined #css 01:29:55 r12a has joined #css 01:30:04 ScribeNick: dbaron 01:30:19 Topic: Box generation and elements as regions 01:31:03 jet has joined #css 01:31:47 [projector and microphone configuration] 01:31:52 koji has joined #css 01:32:48 Alan shows http://www.theguardian.com/world?view=mobile 01:32:56 Alan: wanted to describe a few things we're doing with regions 01:33:05 Alan: We're pushing for using regions and named flows in responsive UI designs 01:33:43 Alan: I'm showing a site from the guardian, not using regions at all. Has navigation bar at top, with menu that comes out. Assuming for a landscape tablet display. As you narrow the display, the navigation elements move to the menu. 01:34:08 Alan: Script is putting items that don't fit in the width and moves elements around in the DOM. 01:34:17 Alan: script is a little buggy and janky 01:34:30 Zeke_ has joined #css 01:34:37 Alan: really easy to do by defining navigation elements as belonging to a named flow, two regions: nav bar, and menu 01:34:47 Alan: that's much more performant, and doesn't need script 01:35:03 Alan: Similar thing ,example at http://adobe-webplatform.github.io/regions-adaptive/ 01:35:28 Alan: Don't want these buttons to show up on mobile, so at a certain width all the buttons get collected into a named flow and put into a slide-out. 01:35:42 Alan: no script, just a media query that turns on the named flow 01:35:54 Alan: just wanted to introduce these ideas to the group 01:35:56 bobby has joined #css 01:36:34 Alan: In this case it's a region chain of regions all with a particular height (viewport height) so the content is interspersed with images (http://adobe-webplatform.github.io/Demo-for-National-Geographic-Orphan-Elephants/ ) 01:37:15 Alan: I've been posting to www-style about how named flows work with overflow:fragments in an attempt to convince people that the issue in regions about box generation should be closed because every box generation mechanism we have defined or proposed for CSS is something regions can participate in. 01:37:33 Alan: The original issue was put into the specification because people wanted to see what the page template proposal that we had only talked about would look like. 01:37:43 ChrisL has joined #css 01:37:46 Alan: I produced the page template proposal where we can target CSS-generated boxes with region chains. 01:38:01 Alan: I assume we're going to do something similar in future work with this group. Regions works well with that. 01:38:29 Alan: Introduced before and after elements, and introduced overflow:fragments which dbaron ran with and produced an interesting spec; but again, regions works well with overflow:fragments. 01:38:47 Alan: you can take 2 overflow:fragments elements in your document, link with named flow, and have content flowing through elements without adding region elements to markup at all 01:39:20 Alan: so the question was, do we need a box generation mechanism forregions, and I've maintained all along that we don't, and we'll use every box generation mechanism we have for CSS. 01:39:32 Alan: so unless anybody has an objection I'd like to close that one particular issue 01:40:12 lmcliste_ has joined #css 01:41:37 ChrisL has joined #css 01:41:38 bobby has joined #css 01:42:13 dbaron: I'm ok with closing 15733 01:42:33 fantasai: 16858 stays open 01:42:36 astearns: yeah 01:42:49 RESOLVED: closing issue in bug 15733 01:43:30 Alan: I don't know that it's going to be fruitful to talk about elements today. I've been posting to list; on dbaron's todo list to look at those messages. 01:44:01 Alan: If anyone wanted to discuss what we've been talking about on the list about using named flows and region chains as lower level mechanism for describing fragmentation and pagination and thinsg, but also happy continuing discussion on list. 01:44:09 Alan: Anybody want to talk about that right now? 01:44:24 Alan: if not, move on to next agenda item 01:44:30 Topic: CSS Writing modes, Tr fallback 01:44:36 ChrisL has joined #css 01:44:39 Peter: Maybe we can close this one today? 01:44:45 glenn has joined #css 01:45:37 ChrisL has joined #css 01:45:48 Koji projects http://www.unicode.org/reports/tr50/ 01:45:55 Koji: issue is Tr fallback in writing-modes 01:45:59 Koji: background on discussion: 01:46:15 israelh has joined #CSS 01:46:32 Dongwon has joined #css 01:46:35 Koji: UTR50 describes 4 values (shows Table 1). One of them is Tr. T means transform, not only about upright or rotated, but usually requires different type of transformation 01:46:37 ChrisL has joined #css 01:46:39 glenn has joined #css 01:46:48 Koji: Tr means if font doesn't provide alternative glyphs it should fall back to rotated 01:47:28 Koji: Tr has 2 purposes (1) for backwards compat -- but all existing fonts have alternative glyphs 01:47:36 ChrisL has joined #css 01:47:58 Koji: example is U+3030 WAVY DASH - not only about rotation but also includes flipping 01:48:15 for backwards compat -- you can see, these characters are not transformed, just rotated, but since all fonts contain transformed glyhs that perform the rotation, want to use those glyphs 01:48:17 Koji: recommendation is preference for flipping in font system, but preference to fall back to rotated fonts 01:48:33 Koji: in CSS writing modes, we had same definition for Tr at one point 01:48:36 ChrisL has joined #css 01:48:44 s/example is/(2) example is/ 01:48:53 Koji: 1.5 years ago John proposed that implementation cost of Tr fallback is high, and # of chars affected is about 10-20 characters 01:49:11 Koji: given the definition -- if font provides all alternative glyphs for these 20 codepoints, issues will go away 01:49:13 mz-modeltaxi has joined #css 01:49:29 Koji: John said even though UTR50 defines fallback, given implementation cost, wants CSS to define fallback to upright 01:49:55 Koji: after that we had 2 different feedback from developers, saying implementation is easy, and they want their UA to display those characters correctly, even with existing fonts 01:50:15 Koji: so we have a situation where 2 developers want fallback to rotated and 1 to upright 01:50:25 Koji: fantasai and I discussed, considered 5-10 characters as subtle difference. 01:50:40 Koji: We agreed to defined to define UA may fall back to upright or sideways, which is what we have in spec right now. 01:51:02 Koji: in September John raised concern that 2 options can cause confusion to authors, and fallback to rotated is wrong or cost high 01:51:09 Koji: so John wants CSS to define "must upright" 01:51:25 Koji: so sylvain agreed with that; glenn disagrees and wants rotated or both options 01:51:35 Koji: James Clark is ???, fantasai and Rossen are opposed too 01:51:43 Koji: Eric said he agrees with john 2 weeks ago 01:51:57 Koji: I talked with Eric last week during UTC, still wants upright, but ok for WG to resolve 01:52:07 Koji: I think that's pretty much situation up to today 01:52:15 Koji: This issue is last issue remaining for LC of css-writing-modes 01:52:19 For Adobe, Eric Muller believes the best option is to mandate no fallback http://lists.w3.org/Archives/Public/public-i18n-cjk/2013OctDec/0036.html 01:52:27 SteveZ: 2 comments: 01:52:46 SteveZ: (1) you said TR50 said "should falllback" but what said is "can fallback", though that's a nit. 01:53:20 dwim has joined #css 01:53:23 SteveZ: (2) second point Eric was concerned about was telling whether font had the appropriate characters. He's concerned about looking at font data because with font subsetting you may get false information about what the font is doing if you're getting a subset. So he was concerned about building that particular piece. 01:53:33 q+ 01:53:38 eliezerb has joined #css 01:53:39 SteveZ: (3) John's point was that whenever we have optional sorts of things, it means implementations diverge and users get unhappy 01:53:46 Koji: comments on those three: 01:53:55 Koji: (1) As you said it's "can". 01:54:03 ChrisL has joined #css 01:54:07 Koji: and as Eric said this UTR50 is a formalism, so it's not forcing everything. 01:54:20 s/a formalism/informative/ 01:54:29 Koji: (2) so I understand that not only it has some other issues like John pointed out, may break dlig 01:54:44 Koji: argument is that can be fixed by designing fonts correctly or designing embedding correctly 01:54:52 Koji: so there are challenges 01:54:59 Koji: but that's not something really not possible 01:55:13 Koji: (3) There may be a ??? on UTR50 01:55:23 Koji: But original goal of UTR50 was to provide consistent orientation 01:55:33 Koji: during development phase we figured it's not possible with existing fonts 01:55:50 Koji: so our goal was to give best consistency, and complete consistency if UTR50 compatible font is used 01:56:00 Koji: and there are 10 characters we are discussing for Tr 01:56:06 Koji: and 20 or more that will be inconsistent anyway 01:56:28 Koji: I'm working with Japanese publishers and AntennaHouse about how authors have to be careful when authoring to be careful orientation consistent across existing fonts 01:56:44 Koji: I agree that allowing both options can diverge and add more burden to authors, but it's not something we can really avoid 01:56:52 ChrisL has joined #css 01:56:55 Koji: given the cost; development cost varies depending on architecture 01:57:07 Koji: Given that we can't reach consensus I think allowing both is best option 01:57:33 SteveZ: concerned about something you said: fixing a rare case and fixing it at the cost of putting burden on anyone who develops font subsetting 01:57:37 ChrisL has joined #css 01:57:51 SteveZ: font subsetting seems likely to be very popular for East Asian fonts. Adding cost to that to fix this problem seems wrong way to go. 01:57:56 fantasai: don't see what this has to do with subsetting 01:58:10 SteveZ: probably not in this case... either character is there or not 01:58:14 q+ 01:58:23 Koji: let me explain: Tr defines render as upright, but if no vertical alt, fallback to rotated 01:58:37 Koji: font subsetting could only subset one glyph without the vert table 01:58:38 ChrisL has joined #css 01:58:53 Koji: in that case using the subsetted font UA cannot determine if codepoint has vertical alternate glyph or not. 01:58:57 SteveZ: yes, sounds correct 01:59:14 glenn has joined #css 01:59:35 Koji: the case for PDF, but for epub or html where user can override writing modes for usability/accessibility, regardless of this issue, font subsetting should include both horizontal and vertical alternate glyphs into the subsetted fonts. If they do that they also solve this problem. 01:59:39 ChrisL has joined #css 01:59:44 Koji: It's true that it requires additional step, but it's not only to solve this problem. 01:59:57 Koji: does that answer your questions? 02:00:22 SteveZ: I certainly understand what you're saying; requirement for not subsetting with only one of directional things is not coming from this but coming from that user style sheets could override, so you need that capability anyway. 02:00:39 ChrisL has joined #css 02:00:41 Koji: this is about 10 characetrs. In John's original proposal those 10 characters will be rendered incorrectly for some existing fonts 02:00:46 zhouchao_ has joined #css 02:00:51 Koji: John and Eric think that's ok because rarely used characters ... 02:00:56 Sylvain: no, they think fonts will get fixed 02:01:12 Koji: I know there are technical differences... if it's about subtle differences why do we care so much? 02:01:28 SteveZ: understand last way, but applies equally way to any resolution 02:01:38 ChrisL has joined #css 02:01:46 dino has joined #css 02:01:47 Koji: Thus I ask either behavior. John wants to demand single behavior, I want to know why. 02:01:57 Jet: the cost to every other codepoint that's not those 10 02:02:20 Jet: extra conditional in code -- vs benefit to rendering those characters incorrectly 02:02:21 q? 02:02:35 Sylvain: I posted a link to Eric Muller's post. Eric thinks no fallback is the better decision. 02:02:37 ChrisL has joined #css 02:02:45 Sylvain: That's consistent with feedback I got from other experts. 02:03:05 Sylvain: I think issue about cost was not about absolute cost, but about cost relative to how often it's needed, since expectation is that fonts will be fixed. 02:03:17 Sylvain: In general in standards providing optional behavior is a source of incompatibility. 02:03:25 Sylvain: I think that makes sense. 02:03:37 ChrisL has joined #css 02:03:40 Koji: It costs more for one option for one architecture but opposite cost for other architectures. 02:03:47 Koji: So if we mandate one we have to pick one. 02:03:54 Sylvain: That's the point of mandating. 02:04:05 Koji: Costs more for some browsers and less for others. 02:04:14 Sylvain: I don't think having no fall back can cost more than fallback. 02:04:20 Koji: I disagree. 02:04:47 Koji: 1.5 years ago discussion cost is sky high another developer said cost is low another developer said cost is opposite 02:05:18 Sylvain: You write complex fallback code that you have to test for something that will happen extremely rarely. Not sky high in terms of total amount; it's relative to the benefit. 02:05:30 Sylvain: Mandating no fallback will lead fonts to update. (?) 02:05:36 Sylvain: So that code will never be used 02:05:36 cabanier has joined #css 02:05:37 cabanier_ has joined #css 02:05:46 Peter: does practice of subsetting potentially break that argument? 02:06:13 Peter: If alternates end up not part of the subset, not guaranteed to have them. 02:06:37 ChrisL has joined #css 02:06:38 If we assume fonts will get fixed, can we also assume subsetting tools will get fixed? 02:06:45 SteveZ: Koji's point was that subsetting for CSS requires both glyphs to be there because you don't know what will be there until things arrive. You can always do it wrong, but then people will get bad results and people will stop using your system. 02:06:52 glenn_ has joined #css 02:06:55 Rossen: What if we, instead of disallowing it, discourage it? 02:07:12 Rossen: We can say that behavior is not expected, but if there's an implementation that really wants to do it, it's at least not forbidden? 02:07:28 Rossen: authors reading spec should not expect it to be supported, but not restricted to forbid behavior 02:07:37 ChrisL has joined #css 02:07:38 fantasai: I think another thing to consider would be font formats other than opentype. 02:08:01 fantasai: In OpenType a number of these characters are transformed by convention, but this might not be true in another font format might have different expectations. 02:08:14 fantasai: So even if we want to mandate this for OpenType I don't think it would make sense to mandate for all font formats. 02:08:28 fantasai: Also doesn'tmake sense ... ??? if handled at font engine level rather than text layout level. 02:08:51 SteveZ: Rossen, if I understood you: "if the data for the rotated form is not present, this specification does not define what should be done"? 02:08:54 fantasai: works for me 02:08:59 Rossen: That's more of the undefined case 02:09:04 cabanier_ has left #css 02:09:28 SteveZ: I think advantage of undefined, still leaves the forcing function of getting the fonts updated, because you don't know what's going to happen. 02:09:42 Rossen: Would anyone not be able to live with undefined? 02:09:55 taocai has joined #css 02:10:06 r12a: Would it be a question of leaving it undefined like that, or undefined plus recommend that you follow UTR50? 02:10:30 fantasai: wording I'd suggest is that it's undefined whether the UA is allowed to synthesize some kind of substitute glyph 02:11:02 eliezerb has joined #css 02:11:03 dbaron: no longer Rossen's "undefined but discouraged" proposal? 02:11:10 ChrisL has joined #css 02:11:14 (I'd prefer undefined but discouraged over simply undefined.) 02:11:31 SteveZ: where are we? 02:11:38 Rossen: I think between disallowed and undefined? 02:11:44 Rossen: As I understand, John wants disallowed 02:11:47 fwiw feedback on fallback implementation cost I have heard: cheap to hack it, more expensive to do it right. too expensive for the number of cases that will exercise it 02:12:10 "UA may but is not expected to synthesize the substitute glyph"? 02:12:22 Rossen: If we say UAs are not expected to support rotated sideways glyph, but not required not to, then that should be a way of saying basically: don't expect it to work, but implementations might do it. 02:12:38 ChrisL: or in other words would be saying "you may fall back but not required to" just like TR50 says 02:12:52 SteveZ: That's why I'd prefer it's simply undefined, since otherwise you're back out of undefined. 02:13:09 [various people mumbling] 02:13:16 Bert: That's the wrong way round, I'd say. 02:13:25 Rosssen: Current spec says UA may, but not required to fall back to 02:13:30 Rossen: current statement is close 02:13:39 Bert: current statement suggest that what TR50 says is that rotating better than not 02:13:49 Bert: want implementations to rotate but we still like them to do it 02:13:56 Bert: I think wording should be clear that we still want them to. 02:14:10 dbaron: I think many people here disagree that we want them to 02:14:26 dbaron: ppl think we're bette roff expecting font to have correct data in it, instead of addign features to work around bugs in a font 02:14:30 +1 to dbaron 02:14:36 Bert: That' assumes it's a bug in the font, maybe it's not. 02:14:49 Peter: In general I'm ok with any of these proposals. 02:15:03 I think for OpenType it would be considered a bug in the font, but for other font formats might not be... 02:15:11 Peter: I'm concerned that I don't want us to say "you must not do this" because if you have a font engine that does this then the UA has to undo what the font engine is doing. 02:15:21 s/bette roff/better of/ 02:15:25 Peter: Just saying it's undefined because it is defined in UTR50 02:15:42 Peter: if we're explicitly undefining it then we're just sanctioning what UTR50 says 02:15:46 +1 to Peter 02:15:57 wrt undoing font engine 02:16:19 Peter: so if we have an explicit preference we'd ??? 02:16:36 Peter: I have concerns if we're willfully violating an other spec, if it says "can do it" and we say "must not do it" 02:16:36 "the UA is not expected to fallback..." 02:16:51 fantasai: Can we straw poll on wording "may, but is not expected to"? 02:17:05 Peter: should we reference April 1 update to RFC2119? 02:17:18 fantasai: ? 02:17:26 Rossen: what if we say UA is not expected to do fallback? 02:17:32 fantasai: we have to say allowed disallowed or optional 02:17:32 glenn has joined #css 02:17:37 fantasai: we have to say, normatively, what is it 02:17:37 ChrisL has joined #css 02:17:45 fantasai: saying something is expected or not expected is not really normative 02:17:52 SteveZ: Seems to me we have 3 possibilities: 02:17:56 cabanier1 has joined #css 02:17:58 SteveZ: (1) John's "must not" 02:18:03 SteveZ: (2) undefined 02:18:16 SteveZ: (3) should use the font, but failing that can do fallback per TR50 02:18:33 SteveZ: I think those are only 3 on the floor. Apperas to me at this point that easiest to eliminate is (1). 02:18:39 silvia has joined #css 02:18:49 jehoochen__ has joined #css 02:18:50 SteveZ: that leaves us with 2 different ways of saying can fall back, either by not saying anything or by saying you can 02:19:03 SteveZ: I'd propose a straw poll that would eliminate the first option 02:19:11 SteveZ: and then we can see if there's a significant difference between other two 02:19:38 SteveZ: Seems easier to eliminate (1) from straw poll 02:19:51 fantasai: 2 wordings on floor: 02:20:07 "If the vert alt glyph is not present in the font, UA may but is not expected to substitute the glyph" 02:20:10 vs 02:20:19 "If the vert alt glyph is not present in the font, behavior is undefined" 02:20:20 ?? 02:20:25 peterl: RFC6919, "REALLY SHOULD NOT" 02:20:51 MUST SHOULD NOT 02:21:00 SteveZ: I think fantasai's second option captures what we should get at 02:21:19 MAY WISH TO 02:21:21 fantasai: The first one is my proposal, because I don't like leaving things blanket undefined 02:21:24 emalasky has joined #css 02:21:30 Y U FALLBACK 02:21:35 r12a: What happened about the straw poll to eliminate (1)? 02:21:50 http://tools.ietf.org/html/rfc6919#section-3 02:22:09 r12a: can we resolve to eliminate option 1? 02:22:19 STRAW POLL: 02:22:25 A) "If the vert alt glyph is not present in the font, UA may but is not expected to substitute the glyph" 02:22:32 B) "If the vert alt glyph is not present in the font, behavior is undefined" 02:22:32 [2013-11-12 10:20:20 +0800] ?? 02:22:44 (oops, ignore that extra line of copy/paste) 02:22:55 r12a-limechat has joined #css 02:23:09 fantasai: I don't like (B) because it allows the UA to do absolutely anything it wants. 02:23:31 STRAW POLL: 02:23:39 A) "If the vert alt glyph is not present in the font, UA may, but is not expected to, substitute the glyph" 02:23:46 B) "If the vert alt glyph is not present in the font, behavior is undefined" 02:23:51 Alan: A 02:23:52 zcorpan has joined #css 02:24:03 rhauck: A 02:24:06 dirk: abstain 02:24:25 Bert: of these two, prefer A 02:24:28 emalasky1 has joined #css 02:24:32 zcorpan: abstain 02:24:57 kazutaka: A 02:25:00 yamamoto: A 02:25:04 Koji: A 02:25:07 Rossen: A 02:25:10 Israel: A 02:25:12 jet: A 02:25:13 chrisL: A 02:25:16 Lea: A 02:25:21 Sylvain: A 02:25:31 3 A's 02:25:33 Dean: abstain 02:25:34 fantasai: A 02:25:36 dbaron: A 02:25:39 cwdoh has joined #css 02:25:39 hober: mu 02:25:39 SteveZ: A 02:25:45 Kennyluck: A 02:25:47 Leif: abstain 02:25:48 Peter: A 02:26:08 Bert: My question is, are we really doing what Unicode want us to do? 02:26:22 TabAtkins: abstain 02:26:24 bert: was it really a neutral choice to be doing it or not, or do we ??? 02:26:28 bobby has joined #css 02:26:53 leif1 has joined #css 02:26:54 fantasai: descriptions in unicode spec are informative saying what categories mean, not dictating a behavior 02:27:03 Bert: if they didn't want implementations to rotate, why did we write it there/ 02:27:04 zcorpan has joined #css 02:27:12 Bert: I think we're saying opposite of UTR50. 02:27:21 Peter: UTR50 says can, we're saying may but not expected to 02:27:43 r12a: is substite the right word, or is rotate? 02:27:49 fantasai: synthesize the substitute glyph 02:27:53 fantasai: wording's a little bit off 02:28:01 leif1 has joined #css 02:28:04 Peter: I think "MAY WISH TO" from RFC6991 02:28:09 Peter: I think "MAY WISH TO" from RFC6919 02:28:42 Peter: I think we should use "MAY WISH TO" and refence RFC6919. 02:29:17 RESOLUTION: Accepting option A, with term "MAY WISH TO" and referencing RFC6919. 02:29:27 http://tools.ietf.org/html/rfc6919 02:29:42 Peter: spec ready to advance? 02:29:47 "This phrase is frequently used to avoid further delay in approval of a document." 02:29:56 fantasai: I expect this to be the first of at least two last calls. 02:29:59 seems appropriate 02:30:05 Peter: Anything to rename? 02:30:42 RESOLVED: Take CSS Writing Modes to Last Call. 02:31:03 Peter: break until 11am. 02:31:17 I think there's an open issue on possibly renaming text-combine-horizontal to something better/easier-to-type/less-confusing 02:32:07 danielkim has joined #css 02:32:39 tobie has joined #css 02:35:00 ChrisLilley has joined #css 02:35:24 simonstewart has joined #css 02:38:27 ijongcheol has joined #CSS 02:42:04 dbaron has joined #css 02:42:28 koji has joined #css 02:43:01 Zeke_ has joined #css 02:45:56 bobby has joined #css 02:46:01 danielkim has joined #css 02:47:30 dbaron_ has joined #css 02:53:08 jet has joined #css 02:55:14 trackbot has joined #css 02:55:23 ChrisLilley has joined #css 03:00:29 Dongwon has joined #css 03:00:40 ChrisLilley has joined #css 03:01:29 kurosawa has joined #css 03:02:33 silvia has joined #css 03:02:42 silvia1 has joined #css 03:08:27 myakura has joined #css 03:10:29 stakagi has joined #css 03:11:56 hayato_ has joined #CSS 03:15:03 kimwoonyoung has joined #css 03:15:18 bobby has joined #css 03:15:21 koji has joined #css 03:16:15 Rossen_ has joined #css 03:16:51 q 03:17:17 israelh has joined #css 03:20:06 kurosawa has joined #css 03:20:51 cwdoh has joined #css 03:21:42 ijongcheol has joined #CSS 03:22:00 Did we not return, or is nobody minuting? 03:22:26 emalasky has joined #css 03:22:32 nothing secret, just not necessary to minute 03:22:47 kk 03:23:40 as far as I know we are making http://girliemac.github.io/presentation-slides/html5-mobile-approach/images/css-is-awesome.png our official logo 03:25:21 ChrisLilley has joined #css 03:25:35 hayato___ has joined #CSS 03:25:43 ChrisLilley has joined #css 03:26:02 From CSSWG design that didn't get implemented -- "mood": flowing, transparent, layered, professional, informed 03:26:51 ScribeNick: SimonSapin 03:27:05 Topic: Text module 03:27:47 fantasai: to prepared to discuss 03:27:49 plinss: defer 03:27:54 Topic: Charter 03:28:13 Bert: last time we had milestones, wiki page for dates 03:28:23 Bert: most people said can’t put dates 03:28:39 Bert: now list specs in scope, and says we don’t have dates 03:28:44 http://www.w3.org/Style/2013/css-charter 03:29:13 Bert: mostly same as previous charter 03:29:23 Bert: same participation reqs, chairs, mailing list 03:29:27 Bert: list of modules longer 03:29:28 simonstewart has joined #css 03:29:35 Bert: diff list of liaisons 03:29:56 Bert: look if it’s complete and not too long 03:30:15 Bert: about not having milestones, only a list of things we work on, without dates 03:30:26 Dongwon has joined #css 03:30:28 Bert: do you agree with that? Can it get past AC review? 03:30:35 ChrisLilley has joined #css 03:31:03 Bert: glazou said we have a few drafts that are requirements for other groups, we should give that higher priority 03:31:27 Bert: didn’t list those, glazou sent email with the list 03:31:35 Bert: we could mark those explicitly 03:32:20 SteveZ has joined #css 03:32:28 astearns: is there a logic to the order? 03:32:40 zqzhang has joined #css 03:32:41 Bert: no, automatic tool takes the order from the /TR page 03:33:11 Bert: date is to be updated when we have review, roughly 2 years 03:33:19 dbaron_: guess the order is by age of WD 03:33:40 dbaron_: there is a bunch that appear twice 03:33:46 Bert: that’s a bug 03:33:56 fantasai: suggest taking the Current Work page 03:34:06 dbaron_: looks like list of shortnames ever used 03:34:13 duplication: UI, borders, CSS1 ,CSS2 03:34:17 Bert: someone wants to get through the list to fix? 03:34:24 ChrisLilley has joined #css 03:34:31 fantasai: can you take it from Current Page? 03:34:49 http://www.w3.org/Style/CSS/current-work 03:34:50 Bert: some are missing 03:35:05 ChrisL: that’s a feature 03:35:06 We're also probably not going to work on becss. 03:35:27 Yeah, don't want to include the Abandoned drafts 03:35:38 plinss: any feedback on the charter? folks generally happy with it? 03:36:20 ChrisL: we’re looking at the suggested extensions from 1998 and slitting our wrists 03:36:28 plinss: update the module list before we submit? 03:36:38 dauwhe_: page templates is only an editor's draft 03:36:41 ChrisL: looks fine, I suspect AC won’t object 03:37:01 ChirsL: we say we don’t have milestones because … 03:37:12 dauwhe_: I believe we resolved to get simple pagination done first, before making page templates a working draft 03:37:16 ChirsL: and say that things needed by HTML5 are … 03:37:31 plinss: email to internal list when ready 03:37:46 ACTION: Bert to update the list of deliverables in the charter 03:37:46 Created ACTION-595 - Update the list of deliverables in the charter [on Bert Bos - due 2013-11-19]. 03:38:15 plinss: anything else on charter? 03:38:21 zhouchao has joined #css 03:38:24 Topic: Styling left vs. right pages 03:38:34 I wouldn't mind seeing us doing asynchronous decision making, but I'm not in the mood to have that discussion right now... 03:39:02 emalasky1 has joined #css 03:39:54 asynch decision discussion better done asynchronously 03:40:15 leaverou: discussed this in private and on mailing list 03:40:27 leaverou: long, but no conclusion 03:40:35 ChrisL has joined #css 03:40:39 leaverou: people write books in CSS, including design of the book 03:40:48 naka_ has joined #css 03:41:01 leaverou: I first designed mine in Illustrator, then many things were not possible in CSS 03:41:13 leaverou: no way to style elements depending on right or left pages 03:41:33 leaverou: we have @page, for the page itself or headers/footers, but not elements on the page 03:41:48 leaverou: to do sidebars in print formatters, you use "float: outside" 03:42:07 leaverou: to push it you use "float-offset" but that’s limited 03:42:21 leaverou: it’s not just the sidebar, [projecting] 03:42:48 leaverou: these things have different border-radius, rotate transform, margin, etc. depending on left/right page 03:43:04 leaverou: float: inside/outside and margin-inside/outside are not enough 03:43:13 silvia has joined #css 03:43:15 leaverou: we can,t keep adding properties, need a more generic solution 03:43:44 plh has joined #css 03:43:46 http://lists.w3.org/Archives/Public/www-style/2013Jul/0607.html 03:43:49 leaverou: proposal on the list … 03:43:52 satakagi has joined #css 03:44:09 leaverou: @page :left, nest style rules 03:44:21 leaverou: syntax not doable, ambiguous with declarations 03:44:45 leaverou: needs infinite look-ahead, same as in Hierarchies 03:44:59 leaverou: proposal to use braces, at-rules, or pseudo-elements 03:45:00 Note, Hierarchies has been fixed. 03:45:04 ChrisL has joined #css 03:45:14 leaverou: div::page(left) 03:45:15 silvia has joined #css 03:45:26 ChrisL has joined #css 03:45:31 leaverou: still limited, you want to style based on type of page (chapter, …) 03:45:37 leaverou: and other page selectors 03:46:22 leaverou: other proposal from AntennaHouse: extending Variables to inherit from @page 03:46:41 leaverou: but then you have different property values on different pages for the same element 03:46:55 TabAtkins, how? 03:47:08 fantasai: whatever syntax we use here should be the same as for Regions 03:47:31 dbaron: styling things between pages has a lot in common with between regions 03:47:41 SimonSapin: http://tabatkins.github.io/specs/css-nesting/Overview.html#the-nested-block 03:47:41 silvia has joined #css 03:47:42 dbaron: we don’t want to allow completely arbitrary style 03:47:57 dbaron: we don’t want something that starts as a table, continues as a float, etc 03:48:03 SimonSapin: Wrap the selectors in an anonymous {} block. 03:48:09 Rather, the whole thing. 03:48:13 dbaron: there is no concept to continue the inside of a table onto the next page as something else 03:48:31 dbaron: so far we don’t have the ability to fragment things into completely different types 03:48:43 silvia1 has joined #css 03:48:51 dbaron: if we have a display-inside / display-inside split, we can’t change display-inside between fragments 03:49:04 dbaron: we’r gonnna need implem experience 03:49:17 leaverou: could be limited to not allow some properties like display 03:49:29 leaverou: or just no style fragments, only based on the first page 03:49:42 dbaron: there may still be some hard cases 03:49:55 dbaron: hard to spec and get interop, even if easy to implement, with edge cases 03:49:56 q+ 03:50:08 dbaron: with this style fits on this page but doesn’t with other style 03:50:09 q- 03:50:24 dbaron: also not convinced that styling based on the first page is that useful 03:50:57 leaverou: I realize there are use cases spawnning pages, but most I’ve seen are within one page 03:51:10 astearns: when you’r printing, you control pagination 03:51:30 astearns: on screen, things intentended to be on one page may be split 03:51:49 silvia has joined #css 03:51:59 leaverou: print formatters vendors have clients that demand features, and they will implement even without spec 03:52:02 ChrisL has joined #css 03:52:18 q? 03:52:20 dino: I agree these are all great use-cases, but who is gonna do the work? 03:52:56 fantasai: once we hack the syntax and model stablizes for Regions, the only thing that would different in syntax is changing the work region to page 03:53:07 s/work/word/ 03:53:10 fantasai: the hard part of the work, Alan is already working on 03:53:19 danielkim has left #css 03:53:32 astearns: agree with dbaron that we’re gonna need impl experience to decide what can be styled, don’t have it yet for Region 03:54:13 leaverou: btw, there is already a pseudo-class for styling … In paged media or GCPM, styling fragments of an element based on what page they appear 03:54:28 leaverou: fragmentation problems still exist 03:55:05 dauwhe_: want to mention that left/right, named pages, also need to identify arbitrary pages in a sequence 03:55:13 dauwhe_: 6th page in a sequence 03:55:36 leaverou: another thing needed is syntax like :nth-page 03:55:49 leaverou: targetting pages between the 10th and the 100th 03:55:58 leaverou: would be useful for page number 03:56:14 leaverou: there is no such thing as inline-block for margin boxes… 03:56:28 dino: you need nested regions of pages that themselves can be styled 03:56:34 dauwhe_: PrinceXML has :nth-page 03:57:01 dauwhe_: discussion on www-style, but complicated to define what is a page, first of chapter vs. first of document 03:57:15 dauwhe_: whole class of issues around identifying pages 03:57:35 SteveZ: XSL did come up with rules to select which of the next template is used for a given page 03:57:53 SteveZ: want a number of sources that are active, choos the template based on what kind of things are available 03:58:11 SteveZ: which template you pick depend o which are associated with the content of that page 03:58:26 SteveZ: this divorces the design of template with their selection, rule-based 03:58:33 Note my previous discussion with Hakon, that "foo:nth-page(5)" does *not* select the 5th "foo" page, but rather the 5th page if it is also a "foo" page. 03:58:39 SteveZ: :nth-page assumes that you know what content goes there 03:58:44 In other words, selectors don't modify each other. 03:58:50 SteveZ: as astearns says you may not know 03:59:08 SteveZ: XSL tired to define but never succedded sync points 03:59:13 TabAtkins, so how do we select the 5th foo page? 03:59:18 ChrisL has joined #css 03:59:43 :nth-match(5 of foo) 03:59:43 SteveZ: the notion of identifyin sync content, stream of figures / stream of text 03:59:52 We've already solved this problem in Selectors. 03:59:54 SteveZ: thing figure goes with this piece of text 04:00:00 TabAtkins, cool 04:00:14 SteveZ: as close as possible , which may not be very close, but at least being able to declare that would be useful 04:00:44 plinss: I agree this should be aligned with Regions 04:01:02 fantasai: doesn’t belong in Fragmentation 04:01:07 plinss: useful for multicol? 04:01:14 fantasai: I think less so 04:01:45 fantasai: track as something we need to address, note that we need this for pages, but not much to do right now 04:01:55 astearns: if AH or Prince wants to run with it… 04:02:01 plh has joined #css 04:02:33 astearns: I,d be happy to put a note "this mechanism should be applied to pages" 04:02:45 astearns: if there is impl interest, pages may be done before pages 04:02:59 astearns: but I don’t know how Antenna House or Prince are prioritizing 04:03:03 s/before pages/before regions/ 04:03:23 plinss: is there consensus that this is a good idea? 04:03:39 leaverou: if the mechinism is defined in Regions, do we still need to define the syntax? 04:03:52 myakura_ has joined #css 04:04:00 astearns: there is a syntax for Region […] all contnet that falls in this region, here are their style 04:04:01 ChrisL has joined #css 04:04:14 astearns: same would apply when selecting a page instead of a region 04:05:03 astearns: just changing that part of the selector that says I’m styling this region 04:05:15 ChrisL: we still need to write this down 04:05:33 astearns: it will be the same for styling content in Shadow DOM 04:05:57 Pages use a somewhat different selection mechanism (at-rule to introduce the selector), but yeah, similar mechanics. 04:06:09 hayato_ has joined #CSS 04:06:11 leaverou: the way this will be done in Regions is through pseudo-elements? 04:06:13 fantasai: yes 04:06:25 leaverou: but @page rules are more concise 04:06:47 leaverou: if you have a series of things that need to differ page page style, need to repeat the page selector 04:07:00 ".foo::region .bar" for .bars inside of the region hosted by .foo 04:07:01 fantasai: same problem with regions, we should solve this for all of the things 04:07:24 astearns: syntax for Regions has the constraint that it needs to fit in future nesting mechanisms that reduce repetion 04:07:25 ChrisL has joined #css 04:07:43 leaverou: will this apply to all page selectors and combinations of those? 04:08:16 dauwhe_: I guess we just start trying things 04:08:26 ChrisL has joined #css 04:08:49 plinss: trailing off, but not hearing any objection. Will follow the work on Regions 04:09:06 Bert: we have Dave editor of GCPM, I suggest we concentrate effort around Dave 04:09:17 Bert: see which things are already covered in Regions 04:09:28 ChrisL has joined #css 04:10:45 Why do we want to push this into GCPM? 04:11:05 [minute taker fell off IRC] 04:11:16 kawabata2 has joined #css 04:11:25 ChrisLilley has joined #css 04:11:38 emalasky has joined #css 04:11:38 ScribeNick: dino 04:12:16 Bert: People should meet informally to discuss the next steps 04:12:25 ijongcheol has joined #CSS 04:12:50 plinss: I don't have an issue with David taking this on. Some people have suggested a page layout task force so it doesn't take up much of the group's time 04:13:11 plinss: i don't want to continue dumping "all the things" into GCPM 04:13:13 +1 to plinss 04:13:20 ChrisLilley has joined #css 04:13:33 dbaron: i'd be inclined that this deserves it's own module 04:13:42 astearns: or a new level of paged media 04:13:46 plinss: possible 04:13:59 Rossen_: what happened to the one daniel was starting in Lyon? 04:14:13 Rossen_: sounds like the same conversation we've already had 04:14:30 SimonSapin: he has a proposal for the future of paged media 04:14:41 (on dev.w3.org) 04:14:42 http://dev.w3.org/csswg/css-page-4/ 04:15:05 plinss: Dave, are you willing to champion the work? 04:15:12 dauwhe_: yes 04:15:48 SimonSapin: We discussed two things: one of which lea asked (styling elements based on page location), and better page selectors (which is in the paged media spec) 04:15:56 plinss: also need to expand on "spreads" 04:16:07 --- LUNCH BREAK --- 04:16:20 hold the lunch break 04:16:30 r12a: are you going to discuss CSS Text? 04:16:42 plinss: we deferred because fantasai needed to prepare 04:16:51 fantasai: i can maybe work on it during lunch 04:17:02 fantasai: agenda+ backgrounds and borders? 04:17:04 plinss: ok 04:17:11 dbaron: agenda+ one thing about charter? 04:17:18 plinss: let's do this now 04:17:34 Topic: Charter stuff again 04:17:45 dbaron: comment about async participation 04:18:21 dbaron: many WGs have requirements about async decision making. e.g. WebApps, a bunch of related API groups, and HTML (but that is a special snowflake) 04:18:45 dbaron: i don't necessarily want to force the async decision making policy here, but I would like to see us try to make async decisions more often 04:19:35 dbaron: async == decisions are not generally taken in a meeting like a vote. rather the chair sends the notification via email, people can object before some time period elapses. 04:19:56 Async decision-making will likely speed up a lot of decisions, too. No need to wait for a slot during telcon, potentially getting bumped multiple weeks. 04:20:03 dbaron: i often find myself unsure whether or not to object within 10s at a meeting. I think it leads to decisions made with more consideration. 04:20:22 s/think it/think async/ 04:20:34 dbaron: what do other people think? 04:20:40 ChrisLilley: on the one hand... 04:21:11 TabAtkins: +1 04:21:11 ChrisLilley: that can be a benefit... e.g. Tab isn't here and he needs 48 hours to object.. 04:21:37 ChrisLilley: but i don't want to be in the situation where we're waiting for people to read the notification, stall, etc 04:21:44 ChrisLilley: how is it working in other groups? 04:22:07 dbaron: one of the important points is that these groups are not making the decision EVER on the telcon, but everything is on the mailing list 04:22:33 dbaron: the forcing function is sometimes useful. i don't participate in these groups, but i've heard it is working well 04:22:52 steveZ: also allows people not on telcons to get involved 04:23:10 SteveZ: the notification needs to be clear what the decision will be 04:23:51 israelh: in webapps, i've noticed that sometimes the decision thread doesn't really give you a clear outcome, and we still need to come together on a call to make the final final final decision. how do you figure out what the tiebreaker is? 04:24:42 kennyluck: it's often dependent on the type of decision: publishing a spec vs technical decisions 04:24:57 plinss: in general all i care about is making good decisions 04:25:13 plinss: i'm ok with whatever technique we use to get to that point 04:25:32 plinss: i'll note that we often do async because we know someone is not yet ready/present. 04:25:47 My point is that I don't know who can send CfCs. Everyone? 04:25:57 plinss: dbaron, are you encouraging us to do it more? 04:26:01 dbaron: yes, do it more 04:26:29 krit: so will it be all decisions, or will we still need f2f meetings? 04:26:43 astearns: I think people will get comfortable will asking more time. 04:27:09 plinss: yes, to be clear, all WG members are free to ask for more time or open something if it is an error 04:27:12 plh has joined #css 04:27:23 plinss: we've never refused such a request 04:28:19 zcorpan: i think async works pretty well. but if there is a situation where we can make a decision now, that should be available, just not the common case. 04:28:44 krit: I'm asking for whether all decisions must be made at telcons, or if the mailing list was enough 04:28:49 dbaron: mailing list would be enough 04:28:53 sgalineau: agreed 04:29:01 plinss: do we want to put this in the charter? 04:29:11 ijongcheol has joined #CSS 04:29:21 dbaron: some other groups have it in the charter. i don't think we need it that formal, but we should move in that direction 04:29:39 SteveZ: should we put that it is allowed into the charter? 04:29:41 dbaron: maybe 04:29:59 SteveZ: maybe it should be listed as a process to stop people objecting to the process 04:30:21 astearns: there is nothing in the charter that says all decisions require a quorum, so we're not explicit 04:30:34 SteveZ: i would like to understand the rules 04:30:49 +1 to SteveZ 04:31:06 krit: dbaron, could you send a proposal to the mailing list? 04:31:09 dbaron: yes 04:31:26 SimonSapin: good q on irc, who can ask for a decision on the mailing list? 04:31:38 fantasai: it should always come from the chairs 04:32:07 plinss: i don't think we should say that we're going to do everything this way. Some things might be better this way, others might not. 04:32:30 plinss: anyone can always ask the chairs to adjust the way we work, even for a particular issue 04:32:48 plinss: fear is that we'll be making decisions by defualt because people are not participating 04:33:08 astearns: it will be interesting to see how many bad decisions we've had to back out because no one participated 04:33:21 plinss: maybe it will be better if the email is clear what the decision will be 04:33:41 plinss: we'll probably have to have discussion about what the proposed decision will be 04:33:49 +1. straw polling rarely works over email. better make a call to force feedback. 04:34:16 dbaron: i think it works for "can we publish" 04:34:38 SimonSapin: i don't think this is about taking options away 04:34:47 plinss: agreed. 04:35:05 ACTION: dbaron to send a proposal for async decisions 04:35:06 Created ACTION-596 - Send a proposal for async decisions [on David Baron - due 2013-11-19]. 04:35:13 sp the conclusion is that we'll discuss this on the mailing list…. 04:35:19 --- REALLY LUNCH BREAK --- 04:35:40 When is lunch til? 04:35:47 1? 04:36:01 Nah, that's in half an hour. 04:36:09 between 1:30 and 2 04:36:09 cwdoh has joined #css 04:36:15 TabAtkins: depending on cafeteria lines 04:36:25 TabAtkins: How about I'll text you if we get back before 2? 04:36:28 kk 04:36:35 glenn has joined #css 04:47:48 silvia has joined #css 04:50:55 simonstewart has joined #css 04:57:31 mgylling has joined #css 05:07:46 jehoochen__ has joined #css 05:18:49 silvia1 has joined #css 05:22:43 dauwhe has joined #css 05:25:17 ijongcheol has joined #CSS 05:27:01 dauwhe has joined #css 05:28:39 bobby has joined #css 05:29:28 tobie has joined #css 05:34:13 dauwhe has joined #css 05:34:24 mgylling has joined #css 05:36:06 kurosawa has joined #css 05:36:11 dauwhe has joined #css 05:36:33 dbaron has joined #css 05:36:38 dauwhe_ has joined #css 05:37:10 nvdbleek has joined #css 05:39:25 mgylling_ has joined #css 05:41:03 zcorpan has joined #css 05:41:15 zqzhang_ has joined #css 05:41:44 jet has joined #css 05:42:13 rhauck has joined #css 05:42:31 dino has joined #css 05:42:42 silvia has joined #css 05:43:39 zcorpan has joined #css 05:43:58 lmcliste_ has joined #css 05:44:07 cyril has joined #css 05:44:23 silvia1 has joined #css 05:44:45 myakura has joined #css 05:47:34 rhauck has joined #css 05:48:09 rhauck1 has joined #css 05:49:46 rhauck2 has joined #css 05:50:28 glenn has joined #css 05:53:29 waiting for everyone to get back from lunch 05:54:03 hayato_ has joined #CSS 05:54:09 ijongcheol has joined #CSS 05:54:56 kimwoonyoung has joined #css 05:56:41 zcorpan_ has joined #css 05:57:23 shepazu has joined #css 05:58:15 kennyluck has joined #css 05:58:37 emalasky has joined #css 05:59:21 satakagi has joined #css 06:01:52 simonstewart has joined #css 06:02:27 israelh has joined #css 06:03:01 mz-modeltaxi has joined #css 06:03:34 nikos has joined #css 06:03:48 nsakai2 has joined #css 06:03:56 emalasky1 has joined #css 06:04:00 birtles_ has joined #css 06:04:04 bobby has joined #css 06:04:21 heycam` has joined #css 06:04:25 Scribe: Cameron 06:04:28 ScribeNick: heycam 06:04:28 https://dvcs.w3.org/hg/FXTF/raw-file/default/filters/index.html#security 06:04:31 Topic: Filter Effects 06:04:36 krit: last time we talked about having a security issues section 06:04:41 ... roc had some concerns about the security model we had 06:04:43 ... hwe asked me to write it 06:04:51 ... this is not just for custom filters 06:04:53 Rossen_ has joined #css 06:04:58 ...but also some other issues, such as element() function 06:05:09 ... SVG filters have an issue where you can get certain data about the pixels that you filter 06:05:12 ... timing attacks 06:05:13 sgalineau has joined #css 06:05:17 ... with normal SVG filter functions 06:05:19 > 06:05:39 ... feDisplacementMap you can cause different timing behaviours depending on pixel values you get 06:05:58 ... we came up with that we taint certain filter primtiives that have reference to user data 06:06:12 ... with feImage, all of the filter sources like SourceGraphic 06:06:44 ... all of these primtiives that take pixel colour that can be affected by the color proprerty are tainted 06:06:57 ... once feDisplacementMap takes such an input, it is tainted 06:07:06 ... some people already reviewed this section, some people at Google and Mozilla 06:07:11 ... roc and heycam kind of looked at it 06:07:19 ... Steven White from Google 06:07:31 ... I think the security section as it is now is OK, but would like wider review, so I'd like to publish a new WD 06:07:45 ... do both WGs support publishing a new WD? 06:07:50 ed: any objections to publishing a new WD? 06:08:02 ... none heard 06:08:15 RESOLUTION: CSS/SVG agree to publish a new WD of FIlter Effects 06:08:31 ed: can we limit this to taining only when use use the color property, or does it have to be for elements in any case? 06:08:37 krit: it's not easy to determine where you get the colour from 06:08:44 ... so I'd rather be more restrictive 06:09:13 ... there are some issues in the spec, SVG specific -- we can discuss them in the SVG WG meeting 06:09:24 Topic: CSS Transforms 06:09:46 krit: for CSS ramsforms, one thing missing is the property definitions 06:09:55 ... we did not specify what the value of these properties means 06:09:59 ... this is now in the Transforms spec 06:10:07 ... a lot of things were clarified, e.g. with transform-origin and perspective 06:10:13 ... there are still some open issue, esp with 3D transforms 06:10:17 http://dev.w3.org/csswg/css-transforms/ 06:10:18 ... smfr is reviewing some of my tests 06:10:26 ... I would like to write more tests, and discuss them in January 06:10:35 ... also new in the spec is a new decomposing model for matrices 06:10:45 ... dbaron found that matrix decompoosing works differently between safari and other browsers 06:11:02 ... dino took an action to review the source code, and I've added the decomposing code to the spec 06:11:12 ... again would like wider review of these things, so would like a new WD of CSS Transforms 06:11:15 jehoochen__ has joined #css 06:11:26 ed: any objections to publishing a WD? 06:11:29 ... none heard 06:11:37 RESOLUTION: We will publish a new WD of CSS Transforms. 06:11:40 Topic: Geometric API spec 06:11:56 s/Geometric/Geometry/ 06:12:08 krit: simon pieters added new types to the CSSOM View spec 06:12:09 kawabata2 has joined #css 06:12:16 ... DOMPoint, DOMRect, DOMQuad and DOMRectList 06:12:31 https://dvcs.w3.org/hg/FXTF/raw-file/tip/geometry/Overview.html 06:12:32 ... all these interfaces are now joined with DOMMatrix into the one spec 06:12:49 ... if you look at the interfaces, you see them there in the draft 06:12:54 ... we're not asking for FPWD at this point 06:13:01 dwim has joined #css 06:13:07 ... what I'd like to discuss or mention is the model of the interface structure 06:13:09 dbaron has joined #css 06:13:15 ... we had long discussions about r/o interfaces, and ones which are r/w 06:13:28 hayato_ has joined #CSS 06:13:37 rayberg_ has joined #css 06:13:41 ... we had concerns on the ML about having interfaces that are sometimes readable sometimes not 06:13:51 ... the general agreement was not to have these kinds of interfaces in hte future 06:14:06 ... there was a need for DOMRect etc. to have read-only APIs for SVG DOM, and some CSSOM View APIs 06:14:14 ... but we want to have them writable so you can do something useful with them 06:14:22 ... there were different solutions on the ML 06:14:25 ... none were really sufficient 06:14:32 emalasky has joined #css 06:14:41 ... the one that was accepted was having a readable interface as a base interface, and a writable one inheriting from that 06:14:51 ... initially we called the parent interface DOM*ReadOnly, which is foncusing 06:14:57 nvdbleek has joined #css 06:15:05 ... doing 'instanceof DOMRectReadOnly' would return true even for a writable DOMRect 06:15:25 cwdoh has joined #css 06:15:27 ... we discussed in Web Apps WG yesterday, and we at least agreed that the inheritance structure is the best of the proposals we have so far 06:15:35 ... some concerns about using "View" name 06:15:51 s/foncusing/confusing/ 06:15:52 ... other than that, most people agreed on the naming scheme 06:15:56 ... so this is what will be in the spec 06:16:02 ... I'd also like to discuss some issues 06:16:05 ... first is with SVGPoint 06:16:14 ... we mentioned before DOMRect, DOMRectList (which is needed in CSSOM View) 06:16:14 r12a has joined #css 06:16:31 simon: CSSOM View references the GEometry spec for DOMRectList 06:16:36 zcorpan_: Yo, several of your IDL interface defs are linking back to CSSOM, which just says that they're defined in Geometry. To force Bikeshed to mark something up as a definition, add dfn-force='' to the 
.
06:16:38  krit: SVG has SVGPoint interface we'd like to replace with DOMPoint
06:16:42  ... we also have an SVGPointList
06:16:51  ... compared to DOMRect, do we also want a DOMPoint list?
06:17:00  Like 
...

06:17:03  ... or just recereate SVGPointList and keep that SVG-specific for now
06:17:13  nvdbleek has joined #css
06:17:17  zcorpan has joined #css
06:17:27  doug: is there any evidence that people are using the SVGPointList interface in the wild?
06:17:28  krit: no
06:17:30  ... well that's not fully true
06:17:36  ... there are libraries using the SVG DOM interfaces
06:17:54  Is DOMRectList actually needed, or is it just used in the existing IDL and we're keeping it?
06:17:56  ... Snap SVG for example
06:18:02  We should try to migrate it to an Array if possible.
06:18:06  ... he's at least using SVG DOM, not sure if he's using SVGPointList
06:18:13  doug: could somebody at Adobe look into that?
06:18:22  ... I personally think we should de-SVG all the things
06:18:38  ... I think we should do what makes more sense for long term, not for backwards compat with SVG
06:18:47  simon: in general, when adding new list-y things, we try to use a JS Array
06:18:55  why the hell aren't any of these things constructable?
06:18:56  ... which can be represented in several ways in WebIDL now
06:19:01  and why aren't they just JS arrays?
06:19:09  s/simon/zcorpan/
06:19:09  slightlyoff: it's our plan to
06:19:17  nvdbleek has joined #css
06:19:18  slightlyoff: see also my SVG DOM improvement proposal
06:19:23  heycam`: ok, that's good, 'cause this is depressing: http://www.w3.org/TR/SVG11/coords.html#InterfaceSVGPointList
06:19:43  slightlyoff: Don't want Points/etc to be just arrays.  The Lists, yes, that's what I (and now zcorpan) just said.
06:20:01  no instances of SVGPointList in snap source
06:20:14  http://dev.w3.org/SVG/proposals/improving-svg-dom/
06:20:21  TabAtkins: yes, was referring to the lists
06:20:28  krit: is SVGPointList already compatible with the new ideas in Web IDL?
06:20:43  leif has joined #css
06:20:50  nvdbleek has joined #css
06:21:09  heycam: I didn't change anything with SVGPointList apart from adding indexed properites and lngth property
06:21:13  ... which implementations already support
06:21:17  it'd be much better if there were an svg.* object instead of all of the SVG* prefixing = \
06:21:22  danielkim has joined #css
06:21:47  krit: so I think we should not create a new DOMPointList interface
06:22:06  doug: we should do whatever is best for the longer m, and not feel constained by the previous specs
06:22:09  ... since SVGPointList is not really used
06:22:19  slightlyoff: SVG.*.  Uppercase for great justice! (And better author-collision avoidance.)
06:22:29  TabAtkins: !?!!!?
06:22:37  TabAtkins: seriously...that's O_o
06:22:40  So what happened regarding the third (immutable) rect type in http://lists.w3.org/Archives/Public/public-script-coord/2013OctDec/0045.html ?
06:22:42  Um.
06:22:45  did that get dropped?
06:22:56  We always uppercase interfaces.
06:23:05  TabAtkins: I mean, eventually you'll want this this stuff to be an ES6 module, right?
06:23:17  Sure, yeah.
06:23:22  TabAtkins: fine for the interfaces, but putting the interfaces in a single object instead of in the global
06:23:33  A namespacing interace is just a shitty module.
06:23:35  TabAtkins: that was the "." in my "svg.*"
06:23:41  ...I know.
06:23:51  We already have window.CSS for the same thing.
06:23:56  heycam: depends on what we do with the grand SVG DOM rethinking
06:23:57  TabAtkins: beats the dihereah ya'll have going on here
06:24:11  bobby has joined #css
06:24:19  l2spell ^_^
06:25:08  krit: I would like to remove the issue about clarifying whether DOMPointList is needed or not
06:25:08  danielki_ has joined #css
06:25:12  ... because I think it's not
06:26:33  heycam: I agree
06:26:48  +1
06:26:55  RESOLUTION: Don't create a new DOMPointList; try to use Arrays if we need something like that.
06:27:12  krit: second I'd like to discuss is SVGPOint has a function matrixTransform
06:27:16  ... should we have that on DOMPoint
06:27:30  ... you can pass a DOMMatrix into it, and it will transform the coordinates of the point and return a new one
06:27:43  simon: isn't that covered by the new Geometry stuff in CSS OM View?
06:28:08  ... oh, it's not the same -- was thinking of convertPointFromNode
06:28:34  krit: the Matrix that is already shipping in Safari/Blink/IE, prefixed, has a function transformPoint
06:28:36  ... it's on DOMMatrix
06:28:44  ... SVG put this function on SVGPoint
06:28:50  ... it would be duplication to have in both places
06:28:51  http://dev.w3.org/csswg/cssom-view
06:29:08  ... the qn is should we have it for SVG, or can we live with removing it?
06:29:15  ed: my guess is content would break if we remove it
06:29:24  dino: I think we should leave it off
06:29:29  ... DOMPoint doesn't have any methods currently
06:29:38  ed: how do you suggest to resolve the SVGPoint issue? not care about it?
06:29:39  dino: yeah
06:29:53  simon: it might make sense to check how much the function is used in the wild
06:29:59  ... if it's used quite a bit, we might need to retain it as a quirk
06:30:04  ... otherwise remove it
06:30:07  krit: how do we get this data?
06:30:12  simon: we could add in a use counter to blink
06:30:21  ... or research content or something
06:30:29  why are all of these things marked readonly?
06:30:36  http://dev.w3.org/fxtf/geometry/#DOMPoint
06:30:37  myakura has joined #css
06:30:39  dino: there are plenty of ways this API could break
06:31:02  krit: with the exception of this function, content would not break
06:31:16  silvia has joined #css
06:31:19  ... I would be fine with keeping this issue open, waiting for better data
06:31:26  ... we could ask Blink people to check
06:31:38  ACTION: Erik to add a use counter for SVGMatrix.transformPoint
06:31:38  Error finding 'Erik'. You can review and register nicknames at .
06:32:15  dino: D3 uses Point.matrixTransform
06:32:17  q+ to ask about intersections
06:32:26  q-
06:32:42  action should be about SVGPoint.matrixTransform
06:32:42  Error finding 'should'. You can review and register nicknames at .
06:33:13  zcorpan_ has joined #css
06:33:58  doug: one thing I wanted frmo a Geometry API for 13 years is the ability to get intersections between shapes
06:34:08  ... have you put any thought into that?
06:34:08  krit: no
06:34:08  doug: do
06:34:17  krit: I would like the community group to come up with some proposals
06:34:21  again, why is all of this stuff readonly?
06:34:55  doug: interesctions are useful for a bunch of things
06:35:03  simon: would like to see use cases
06:35:21  doug: there is a script librrary out there that kidn of does intersections
06:35:24  ... by kevin lindsey
06:35:36  ... I talked with him about that; he said many of the pieces are hacky and hard to do in JS
06:35:45  ... you can't get certain kinds of intersections
06:35:46  slightlyoff: It's not readonly.  There are readonly *variants* of th einterfaces, for various uses in APIs.
06:35:47  dino: I disagree
06:36:06  But they all have mutable versions too.
06:36:17  ... when we proposed the matrix api there was pushback from developers making a point that every time you cross the boundary from JS to native code, you get a performance hit
06:36:21  TabAtkins: where are those?
06:36:25  ... in many cases you want to leave things in JS so people can pick the impl they want
06:36:34  Right there, in the spec next to the other ones?
06:36:34  ... with intersections, you want them for physics lirbaryies or ...
06:36:36  TabAtkins: not seeing mutable version here: http://dev.w3.org/fxtf/geometry/#DOMPoint
06:36:41  ... and they're hand tuned
06:36:55  oooh...I see
06:36:57  ... might be better to leave them to JS to see what comes up
06:37:03  slightlyoff: The DOMPoint interface is mutable.
06:37:04  what's the reason to have the readonly version at all?
06:37:07  ... JS performance is good
06:37:09  plh has joined #css
06:37:18  ... getting fast access to geometry data of SVG could be useful
06:37:36  ... doign intersections in a physics library, you might want to intersect with approximations of a shape, not the accurate actual shapes
06:37:40  Because you need readonlys for APIs at various times.  Plenty of times you're exposing a point on some interface, and it's not meant to be mutable, or mutating it won't do anything.
06:37:45  krit: there's no JS library that does it completely?
06:37:46  zcorpan_ has joined #css
06:37:46  silvia1 has joined #css
06:37:54  ... so it's less likely we can do it in a reasonable amount of time
06:37:57  In other words, same reason to have the "readonly" keyword in any situation?
06:38:36  silvia2 has joined #css
06:38:51  heycam: I think it's just as easy/hard in JS as C++
06:38:51  Hanging mutable-but-useless attributes off an interfaces is a bad idea.  Should either be readonly, or should be a method that returns an object, or should be mutable and live.  Pick one.
06:39:00  (Apparently the last one is usually bad.)
06:39:05  TabAtkins: I'm really unsure why "mutating it wouldn't do anything" is anything other than "it wasn't defiend with an accessor pair, so c'est la vie"
06:39:06  doug: is the cost between JS->native more expensive than doing the operations in JS itself?
06:39:14  dino: I expect you'll be better off leaving it in JS
06:39:16  silvia3 has joined #css
06:39:19  TabAtkins: the idea that you should be locking things down is just odd
06:39:29  ... there's also a cost doing it in JS -- nobody else has done it other than Kevin since it's hard
06:39:33  rik: Raphael does it
06:39:36  dwim has joined #css
06:39:48  doug: there's a download cost too
06:39:50  slightlyoff: What happens when you mutate a point on a DOMRect?  It magically becomes a DOMQuad? It just starts wildly violating rect-based assumptions?
06:39:55  ... is it a common enough case to put it in the browser
06:39:57  ... it's a CBA
06:40:05  DOMRect has a mutation API - mutate x/y/width/height.
06:40:08  ... we should do that, rather than just assume it's better to do in JS
06:40:18  ... Kevin is on the hook to put a proposal to the CG
06:40:35  krit: even if it's formalised in a draft, that'd be helpful
06:40:39  lmcliste_ has joined #css
06:40:40  TabAtkins: it's JavaScript? You document your assumptions.
06:40:41  ... even if not implemented in  a browser
06:40:49  ... last issue I want to discuss is ISSUE 5
06:40:52  ... DOMMatrix takes a string
06:40:56  ... from a CSS transform
06:40:58  silvia3 has left #css
06:41:21  ... we agreed on this; only problem is whether this string needs to be strict CSS, or is a string from SVG trasnform="" attribute OK too
06:41:25  And your assumptions might be "this isn't how you mutate the object, it's just some useful info you can use. Accordingly, we're documenting it as readonly."
06:41:35  ... e.g. "transform(20,20)" -- CSS needs units, SG doesn't
06:41:38  s/SG/SVG/
06:41:44  ... would this string work passing it to DOMMatrix?
06:41:50  dino: yes
06:42:16  dbaron: I'm not crazy about implicit pixel units
06:42:19  I'm okay with accepting the looser SVG syntax, I think.
06:42:22  TabAtkins: I'm really just unsure what the case for this is aside from pre-emptive invariant preservation
06:42:35  TabAtkins: most JS objects are mutable and the world is not, yet, on fire
06:42:39  ... where do these values go?
06:42:44  krit: it's a parameter to DOMMatrix constructor
06:43:03  dbaron: I guess I'm ok with it
06:43:05  ... it's reasonably isolated
06:43:18  slightlyoff: Again, it's identical to making literally anything else readonly.  If you'd expose "readonly attribute double x; readonly attribute double y;", you can instead just expose "readonly attribute DOMPointReadonly;"
06:43:29  krit: need to time think about it more, or resolve?
06:43:52  TabAtkins: that's not a case for *if* it's something you should do, which is what I'm questioning
06:43:52  dino: leave it in, but leave in text saying "speak up if you disagree"
06:44:01  plinss: what's the point of this?
06:44:10  krit: if you have SVG transform="" attribute, it doesn't require px units
06:44:21  plinss: but you're not using this in an SVG context?
06:44:23  krit: you might
06:44:24  cwdoh has joined #css
06:44:58  slightlyoff: Had this dicussion on the list before. Live objects are discouraged API design (prefer mutating methods).  If an object isn't live, it probably shouldn't be mutable either - better author affordance.
06:45:06  glazou has joined #css
06:45:28  TabAtkins: this is alien to most JS practice
06:45:32  Otherwise, you mutate something, nothing happens, but now the attribute is lying.
06:45:36  tobie has joined #css
06:45:48  TabAtkins: so whatever you might prefer from some other perspective, it's just not something I think these WGs should be worrying too much about
06:45:49  Sure, because readonly isn't easy to do in JS. Gotta screw around with getters.
06:45:56  heycam: you could say to authors to get the transform values from CSS APIs, which will have the units in there
06:45:59  krit: let's keep the issue in there for now
06:46:12  dbaron: one other question about the vairous rect types
06:46:19  ... earlier in the thread was a proposal for a type representing an immutable rect
06:46:22  ... did that go away?
06:46:26  Part of having an interface description language is being able to abstract some of the difficulties of the underlying implementation language, when it's useful to do so.
06:46:45  simon: there is a mutable DOMMrect
06:46:53  dbaron: in the url I pasted earlier, there was a proposal for three types
06:46:58  ... DOMREctView as a base type
06:46:58  TabAtkins: that doesn't make this design any less alien
06:46:59  TabAtkins: also, you don't need that, you only need a property descriptor
06:47:04  ... that you can't change, but may or may not be changing
06:47:10  dwim has joined #css
06:47:10  ... two derived types
06:47:13  ... one that you can change
06:47:19  .. and one known not to be changing
06:47:23  slightlyoff: Property descriptors are at least as fiddly as getters. ^_^
06:47:25  simon: that's what we have now, but the immutable is not used by anything
06:47:42  ... the View interface would get used for live reflections, but from script read only
06:47:46  slightlyoff: I don't think cleaving hard to the particular syntax affordances of JS is particularly important.
06:47:50  ... there are no objects known to be immutable
06:48:00  dbaron: but if there were you'd add a type?
06:48:00  simon: yes
06:48:28  heycam: or we could go down the road of having a frozen plain object for that
06:48:34  +1 to what heycam` said
06:48:45  Yeah, more freezing.
06:49:10  alex: until someone presents a compelling use case for the read only versions of these interfaces, seems better to have mutable versions
06:49:22  ... immutable is needed for perserving invaraints the system is sensitive to
06:49:31  ... but if not, preventing the user from modfiying it doesn't seem useful
06:49:37  ... immutability isn't buying anything in those cases
06:49:58  ... there's a generic argument here about it being a better documented pattenr, but I think that's outside the bounds of how you'd write these things in plain JS
06:50:07  simon: that's not a position that has been presented until today
06:50:17  ... it's good that you broughti t up
06:50:20  It buys us protection from "I'm reading these values, but they're not accurate!" (because somebody mistakenly mutated them before).
06:50:22  ... the group might need more time to ponder
06:50:50  dbaron: alex is arguing against the third type?
06:50:55  alex: and the View type
06:50:59  s/broughti t/brought it/
06:51:04  dbaron: Alex is arguing against all but the mutable types.
06:51:22  dbaron: I think one issue that makes rects difficult is that there are multiple ways  -- do people want x/y/width/height, top/left/bottom/right, or other ways of looking at it?
06:51:42  ... one factor is if you're not providing mutability, it's easier to provide those views
06:51:51  ... but if it's mutable, you have to define how changing any of those views mean
06:51:55  alex: dont' think that's true
06:52:01  ... just have to define what the relationship between theo bjects is
06:52:09  ... if an object vends a rect, does it have reln?
06:52:15  ... or is it just a copy that it's handing out?
06:52:23  ... that's what you're implicitly talking about
06:52:34  dbaron: there are rect apis that you want a mutable rect that maintains a reln with the thing that handed it out
06:52:39  ... one example is on a Quad
06:52:46  ... you want the minimal rect that bounds the quad as a property on the obejct
06:52:50  bobby has joined #css
06:52:56  ... you want it to always give you the same object, otherwise it would be confusing
06:53:04  ... so you want the object to maintain a reln with the quad that handed itout
06:53:11  ... don't want a new object each time you grab the property
06:53:18  plinss: if you mutate the rect do you get a new quad?
06:53:22  dbaron: you can't mutate the rect
06:53:35  ... there's no single mutation to the quad
06:53:43  plinss: so either you raise an execption, or it has no effect
06:53:50  dbaron: right, so in this case, the design is that it would be a DOMRectView
06:54:01  plinss: and you try to mutate it?
06:54:08  heycam: it'd throw a TypeError, no setter
06:54:20  I'm saying "just have setting the value do nothing in that case"
06:54:21  plinss: what's the diff between it throwing an exception instead?
06:54:29  simon: throwing an exception idea is what the spec had a first
06:54:35  ... a hidden flag that says "this object is read only"
06:54:41  ... this is what TC39 folks were objecting against
06:55:31  alex: now that we have getters/setters, with  [[Writable]], it's easier to imagine plain JS coming up with htis design
06:55:43  ... dunno if that means if it's a good/bad API
06:55:47  ... is this idiomatic JS?
06:55:53  ... if setting the value is nonsensical?
06:56:09  ... why not have the object change in the bakground?
06:56:13  s/object/property?
06:56:24  ... why should we nail down the interfaces, when you wouldn't in JS?
06:57:01  You can't have the object change in the background (in at least some cases).  (Unless I'm misreading the minutes.)
06:57:03  krit: would be great if you could raise these issues on public-script-coord
06:57:43  Topic: fill and stroke on text decorations
06:57:59  krit: hoped Tab would be here -- he could call in, or we could delay the topic
06:58:12  Calling in is a giant fail.
06:58:16  Never worked yesterday.
06:58:16  fantasai: haven't got around to adding it to the spec
06:58:19  simonstewart has joined #css
06:58:21  krit: fine to defer it
07:00:16  r12a has joined #css
07:00:57  r12a, we'll want to discuss Text soon, let us know if that works for you or you have other constraints
07:01:01  kennyluck: ^
07:01:05  starting with css3-background for now
07:01:09  Topic: Background & Borders
07:01:18  fantasai: we had some substantive edits to this over the last year
07:01:23  ... we wanted to publish a LCWD
07:01:28  ... get it back into CR after
07:01:29  fantasai, ok heading down there
07:01:37  ... one other issue was raised -- two
07:01:51  simonste_ has joined #css
07:02:03  ...andrew fedouniak raise an issue that if you have a spread radius on box shadow, and border radius is very small like 0.1, you run into rounding differences between implementations
07:02:12  ... because the spec says that at 0, the corners are sharp when you ahve a spread
07:02:19  ... if it's non-zero, the corners get curved by the radius
07:02:23  simonstewart has joined #css
07:02:28  danielki_ has left #css
07:02:28  ... it wasn't the best idea to have discontinuous behaviour
07:02:32  ... but that's been in the spec for a while
07:02:41  ... and implemented for a while
07:02:53  ... maybe have a none keyword for border-radius, and that would mean sharp corners -- that's the initial value
07:02:59  ... with 0 you could get the rounded behaviour
07:03:00  dbaron: Yeah, that led to the wiki page that now says "DON'T DO THIS".
07:03:05  http://lists.w3.org/Archives/Public/www-style/2013Apr/0109.html
07:03:07  ... downsides of that is the initial value would be detectable in the OM
07:03:24  ... if somebdoy set border-radius to 0 and had a spread radius, their spread would no longer be square
07:03:35  ... 3rd detectable case is you can no longer animate from the initial value to some other border radius value
07:03:40  ... those are the 3 detectable diffeerences
07:03:50  ... leah and I both thought it would make sense tnot to make a change to the spec
07:03:55  ... wnat to see if the WG had other opinions
07:03:57  jehoochen_ has joined #css
07:04:11  dbaron: i would complain if we made the initial value not animatable
07:04:23  simon: if we do the keyword thing I don't understand why would couldnt animate it
07:04:26  s/complain/jump up and down screaming
07:04:29  kennyluck has joined #css
07:04:30  dino: transition from none to 5?
07:04:33  simon: so?
07:04:38  ... waht's the difference now?
07:04:43  ... you can animate from a square to round
07:04:47  fantasai: this is the point
07:04:55  ... you can animate frmo 0, but 0 would no longer tbe hte initial value
07:05:03  s/frmo/from/
07:05:04  simon: we could specify that nimating from none would mean the same as 0
07:05:09  ... don't understand why that is impossible
07:05:13  plh has joined #css
07:05:16  kurosawa has joined #css
07:05:21  s/nimating/animating/
07:05:21  fantasai: you could say as soon as you step away from none, it can be animated
07:05:38  dbaron: I say this despite that spread is kind of silly, but we could make it continuous in other wways
07:05:58  ... e.g. we could say something like the amount of additional rounding you get --
07:06:02  kimwoonyoung has joined #css
07:06:23  ... normally the radius of curvature of the outer edge of the spread is the sum of the border radius and the spread value
07:06:28  ... so you get concentric circles or ellipses
07:06:53  ... you could intsead say that it is the max of that and double the border radius, or something like that
07:06:56  ... to cap that effect
07:07:00  ... and thus make it continuous
07:07:04  ... probably a bit silly though
07:07:20  fantasai: no comment on that...
07:07:34  plinss: I'd be in favour of an approach like david describes to avoid the discontinuity
07:07:41  ... don[t think we're helping anything by having none
07:07:52  ... still would be discontinuous as we step off it
07:08:00  leah: would be good to see some examples to see
07:08:09  ... I could make some
07:08:10  s/don[t/don't/
07:08:23  fantasai: let's say we can solve that problem
07:08:30  s/that/the animatable/
07:08:41  dbaron: I don't want to mess with the values of border-radius
07:08:51  ... I think it's important to leave them as they are, more improtant than any spread use case
07:08:57  ... the thing I'm proposing is purely related to spread
07:09:01  ... I think we should leave teh spec as it is
07:09:12  fantasai: any other comments on this?
07:09:37  krit: if we don't change the values, can we still animate it in the future?
07:09:41  fantasai: you can animte it today
07:09:51  krit: leave it to 4?
07:09:59  fantasai: we'd need to errata 3 in that case, as we're changing behaviour
07:10:08  r12a has joined #css
07:10:19  bert: I have a strange idea for making it continuous
07:10:33  ... the outer edge of the spread, rather than making the corern the sum of the border-radius and spread, just make it the same as the border-radius
07:10:39  ... maybe looks too msall
07:10:45  leah: it would look horrible
07:10:49  ... ther was a bug in webkit
07:10:53  ... lots of complaints about it
07:10:58  s/leah:/Lea:/
07:11:51  dbaron: I think it's not that bad for large spreads, but just when the border radius is similar in magnitude or larger than the spread
07:12:04  Yeah, the "right" way to spread things is indeed to increase the radius by the amoutn of the spread.  That's how you do curved borders, frex.
07:12:04  fantasai: one thing we can do is go make some examples, to show off your suggestion
07:12:06  we can mitigate the discontinuity for some range of spreads; once a spread is large enough there will always be a point where the corner looks sharp and the spread rounded...
07:12:15  ... if that seems reasonable we can change how spread behaves near 0 border radii
07:12:20  (In reverse - the inner curve is equal to the outer curve minus the border width.)
07:12:23  ... or not make a change
07:12:32  fantasai: next issue was the expansion of shorthands
07:12:36  kurosawa has joined #css
07:12:46  [later]
07:12:57  Topic: css3-text
07:13:08  fantasai: there are two minor things on auto hyphenation
07:13:29  ... one was if hyphenation was turned on, and you have no appropraite resource, is the UA required to hypheante or turn on auto hyphenation?
07:13:34  ... I think the answer to that should just be yes
07:13:38  ... since that was unclear in the spec
07:13:45  teoli has joined #css
07:13:48  dbaron: for a known language?
07:13:50  fnatasai: yes
07:13:57  s/for a/appropriate resource implies/
07:14:11  ... if you have a soft hyuphen in the word, the text we inherited was that that takes priority over auto hyphenation
07:14:18  ... some implementations mix soft and autohyphenation
07:14:30  ... if the auto is one point away with soft hyphen, it might choose the auto one
07:14:34  ... which doesn't make sense
07:14:49  ... I propose if there are soft hyphens, you only hyphenate there, not auto
07:15:06  richard: wonder if there are languages with words so long youwouldn't want to do that
07:15:20  fantasai: if you want to put soft hyphens, you should put them at all points in the word
07:15:30  ssapin: can you break more than once?
07:15:32  krit: yes
07:16:02  richard: if you only had one soft hyphen, you'd be taking away the other break points in a long word
07:16:10  ... it'd need to be clear that's what's happening
07:16:20  ... sometimes you copy text and it has soft hyphens in it
07:16:22  ... and you're not aware
07:17:00  ... not sure that's what people would expect
07:17:10  ... don't know whether that's a significant objection
07:17:26  bert: people who are used to TeX/LaTeX, that's how it behaves
07:17:38  ... so there is precedent
07:17:43  rossen: same in Word
07:17:46  alan: and InDesign
07:17:51  rossen: it's a well known behaviour
07:18:04  simonstewart has joined #css
07:18:27  davecramer: we discovered implementations that allowed auto hyphens as well as soft hyphens, and that confused users
07:18:38  ... if you're going to the effort of adding soft hyphens, that's the most importnat thing
07:18:57  plinss: I think if people put a discretionary hyphen it's because they dont like what the auto hyphenation would doi
07:19:00  s/doi/do/
07:19:19  koji has joined #css
07:19:23  ... otherwise you'd need o put ZWNBSP between all other characters to disable
07:19:34  dbaron: another use might be adding soft hyphens for implementations that dont have auto hyphens
07:19:41  ... and only on words where they notice where words are long
07:19:45  alan: that's a mistake
07:19:51  ... you should place them on all places they could occur
07:20:06  richard: there's no issue about existing text that's now goign to break is there?
07:20:16  dbaron: people have to explicitly enable the auto hyphenation
07:20:26  ... I think the resolution is fine, just wanted to point that out
07:20:39  davecramer: the only impl I know that has hthis problem is not used by millinos of people
07:20:52  richard: I'm convinced at the moment
07:20:57  s/millinos/millions/
07:21:06  ijongcheol has joined #CSS
07:21:22  fantasai: there was one relatively significant issue with text align, text align last
07:21:37  ... we got feedback from digipub wg
07:21:56  cwdoh has joined #css
07:22:00  ... one comment was a suggestion that text-align be a shorthand
07:22:16  ... and perhaps there should be a separate property for first line alignment, and then text-align could become a shorthand
07:22:28  ... another thing Bert asked me yesterday was, what if I want to justify the only line of a para
07:22:48  zakim, shut up
07:22:48  I don't understand 'shut up', TabAtkins
07:22:50  ... wasn't obvious that you should use text-align-last
07:22:59  zakim, anything
07:22:59  I don't understand 'anything', TabAtkins
07:23:04  Obviously.
07:23:09  ... so while it is the last line, it's the only line, it doesn't seem a logical place to look for that feature
07:23:26  ... makes more inclined to consider text-align being a shorthand taking justify-all
07:23:33  ... rather than it be an independent property
07:23:46  ... seems usability would be better if we do that
07:23:48  mz-modeltaxi has joined #css
07:23:55  davecramer: I was confused by text-align when I first encountered it
07:24:07  ... that it affected lines in the para with line breaks too
07:24:14  alan: that's about the break, not this property
07:24:18  fantasai: that aspect wouldn't change
07:24:26  ... sometimes we use a froced line break because there wasn't one in the text
07:24:41  ... and we don't want the text before the line break to use text-align-last
07:24:57  ... in other cases, you do want the text-aling-last behaviour
07:25:10  davecramer: I think it's a UA problem
07:25:19  fantasai: it's al ine breaking problem that shouldb e handled with ZWSPs
07:25:32  davecramer: they'd add letter spacing so you don't have a big gap
07:25:41  fantasai: my proposal is we do the opposite of what we said in paris
07:25:42  s/al ine/a line/
07:25:44  ... make text-align a shorthand
07:26:01  alan: didn't we determine the resolution we had in paris was it's the behaviour that Word, InDesign has?
07:26:04  fantasai: it's not about that
07:26:16  ... it's about an interfae problem on teh CSS side
07:26:24  shepazu has joined #css
07:26:24  ... is text-align last an indepenent property from text-align?
07:26:27  ... or is it a longhand?
07:26:33  ... either way, you get various aesthetics
07:26:44  s/interfae/interface/
07:26:49  bert: the issue is we had an impl of text-align-last that would sometimes give different results
07:27:00  fantasai: we looked at content compatibility and determined there wouldn't be a problem
07:27:04  ... at the F2F I was ambivalent
07:27:07  ... about which way to go
07:27:15  ... but I'm finding these usability problems
07:28:00  kennyluck: is this issue related to adding text-align justify-all?
07:28:14  fantasai: yes, if we want text-align:justify-all we must make text-align-last a longhand of text-align
07:28:20  dbaron has joined #css
07:28:29  ... any other comments on this issue?
07:28:51  I'm in favor of making text-align a shorthand containing text-align-last
07:29:01  ... there was acomment in the message from markus bert forwarded
07:29:03  ... two days ago
07:29:18  RRSAgent, pointer?
07:29:18  See http://www.w3.org/2013/11/12-css-irc#T07-29-18
07:29:31  fantasai: my recommendation is to go the shorthand route
07:29:38  ... can write a separate thread email if people want
07:29:46  ... stil waiting on i18n's comments anyway
07:29:51  ... happy to discuss this at the next telcon
07:29:53  (I am not very convinced that 'text-align: justiy-all' implies that 'text-align' should be a shorthand, but I support whatever would make 'text-align: justify-all' in.))
07:29:54  s/stil/still/
07:30:09  plinss: in that email can you refresh our memories and a comparison?
07:30:19  ACTION: fantasai to mail www-style with the text-align shorthand issue
07:30:20  Created ACTION-597 - Mail www-style with the text-align shorthand issue [on Elika Etemad - due 2013-11-19].
07:30:33  koji: text-align: each-line renaming
07:30:49  ... to each-paragraph, or after-line
07:30:51  s/line/break/
07:30:57  ... I have no opinion
07:31:11  fantasai: the bproblem with after-break is it also applies to the first line
07:31:18  ... don't think it's a better name
07:31:33  ... my concern about each-paragraph is that first the use case is really abotu logical lines
07:31:36  ... lines of code, poetry
07:31:41  ... which wrpas to multiple physical lines
07:31:48  ... those are not paragraphs in any sesnse of the word
07:31:50  s/abotu/about/
07:32:04  ... second is that a paragraph is for HTML thought of as 

07:32:10  ... this would be having units of a paragraph within a 

07:32:18  ... my inclination is not to make a change here
07:32:37  kenny: my qn is the use cases for logical lines, why don't you use padding?
07:32:57  fantasai: because it allows you to indent each line hanging, say
07:33:08  ... the first line not indented, but all of the lines that line wraps to would be indented
07:33:14  ... also typical for long lines of code
07:33:20  ... which are wrapped due to the page width
07:33:47  ... any other comments on that?
07:34:09  RESOLUTION: We won't rename text-align: each-line
07:34:27  koji: second issue, for line break behaviour CSS requires to honour UTR14
07:34:40  s/UTR14/UAX14/
07:34:51  s/text-align/text-indent/
07:35:11  ... after a NBSP, a replaced element -- UAX14 defines it to be GL+CB
07:35:22  the case is basically this  
07:35:26  ... the other pair is CB, which CSS does not rrequire to honour
07:35:36  ... is there a break opportunity between the two?
07:35:48  fantasai: we should do that on the list
07:35:54  koji: last one from james clark
07:36:10  ... he's saying that letter-spacing applying to grapheme clusters is a bad idea
07:36:26  ... he's raising a few examples, Thai, other complex scripts, that sometimes letter-spacing should not be applied between grapheme clusters
07:36:33  ... or one grapheme clusters should be split into multiple glyphs
07:36:44  ... he's not suggesting how to fix this, but just raising some examples that don't work
07:37:01  fantasai: I think the way I'd fix that would be to allow the UA to modify the unit used for letter-spacing and justification in what way is appropriate
07:37:10  s/appropriate/typographically appropriate/
07:37:17  and leave that not defined any further
07:37:35  ... start with UAX14, and then tailor as appropriate as we find it
07:37:40  ... either in UAX14 or css-text
07:37:46  koji: I agree with fantasai
07:37:56  ... I repliedsaying this
07:38:10  ... I want to make sure the WG is fine to base on grpheme clusters, btu allow script specific modifications if needed
07:38:13  s/UAX14/UAX29/
07:38:24  richard: my ugess it's a worse idea to use grapheme clusters most of the time
07:38:35  (that substitution applies to 7 and 8 lines up, but not 20 lines up!)
07:38:38  ... if you start splitting off acute accents from Es etc., you'll have a big mess
07:39:02  fantasai: any other comments?
07:39:20  ... koji and I will continue to make comments
07:39:33  ... we'll come back with DoC after resolving these and getting i18n feedback
07:39:39  ... the action for text-align we can discuss at the next telcon
07:39:49  richard: I should point out we asked for an extension due to the Unicode conference
07:40:07  -- break until 4pm --
07:40:48  glazou has joined #css
07:40:56  What's left after the break?
07:41:14  bobby has joined #css
07:41:15  teoli_ has joined #css
07:42:20  koji has joined #css
07:42:39  s/richard: my ugess it's a worse idea to use /richard: my ugess it's a worse idea to not use /
07:42:58  ijongcheol has joined #CSS
07:43:40  cwdoh has joined #css
07:45:13  wilhelm has joined #css
07:45:19  tantek has joined #css
07:45:36  s/ugess/guess/
07:46:10  dwim has joined #css
07:46:28  cwdoh has joined #css
07:47:15  kurosawa has joined #css
07:55:53  Jirka has joined #css
07:56:51  shepazu has joined #css
08:04:42  dwim has joined #css
08:06:43  cwdoh has joined #css
08:06:54  zcorpan has joined #css
08:08:33  glenn has joined #css
08:09:11  plh has joined #css
08:11:37  glenn_ has joined #css
08:11:54  mgylling has joined #css
08:12:12  myakura has left #css
08:12:13  myakura has joined #css
08:12:32  hayato_ has joined #CSS
08:13:02  glenn__ has joined #css
08:14:56  nvdbleek has joined #css
08:15:58  michou has joined #css
08:16:43  zcorpan_ has joined #css
08:19:19  cwdoh has joined #css
08:22:35  koji has joined #css
08:24:28  dbaron has joined #css
08:25:37  jehoochen_ has joined #css
08:31:37  stakagi has joined #css
08:32:35  birtles has joined #css
08:37:27  scribenick: dauwhe_
08:38:17  sgalineau has joined #css
08:39:30  http://lists.w3.org/Archives/Public/www-style/2013Aug/0178.html
08:40:02  dbaron: I think it's worth testing browsers before defining the behavior here; seems worth doing but doesn't have to happen in this level
08:40:20  zcorpan: I think it's defined in CSS OM; browsers tend to disagree but the definition tries to align
08:40:30  http://dev.w3.org/csswg/cssom/#concept-declarations-specified-order
08:42:08  fantasai: don't define what happens if you expand something out.
08:42:34  zcorpan: we need to define orders of longhands
08:42:38  fantasai: The canonical order seems to define canonical order for serialization, not of longhands
08:43:08  jehoochen_ has joined #css
08:43:15  fantasai: what should I do with spec?
08:43:26  zcorpan: I want order defined in CSSOM.
08:43:43  ... I can take action item to test what browsers do and document it somewhere.
08:43:53  lmcliste_ has joined #css
08:43:57  fantasai: should there be a list of all properties in spec in an order?
08:44:16  dbaron: we should see what browsers do. I don't want to break interop.
08:44:21  teoli has joined #css
08:44:25  bobby has joined #css
08:44:29  fantasai: what does that spec look like?
08:44:48  dbaron: orderings might not fit with list in spec?
08:45:01  ... might be easiest to put in propdef
08:45:24  ... must define order resiliant to addition of new properties
08:45:42  fantasai: who's doing this?
08:45:48  ... and in what spec?
08:46:08  dbaron: do we have def of canonical order in propdef?
08:46:13  fantasai: in CSSOM
08:46:41  dbaron: CSSOM has canonical order, but does not define it.
08:46:47  s/has/uses the term/
08:47:01  fantasai: how to read propdef tables is not part of spec
08:47:03  Ah, I was wondering why it started in the middle of stuff.
08:47:36  fantasai: only def. is in CSS 2.1
08:48:04  rhauck has joined #css
08:48:06  fantasai: put how to read css propdef tables into snapshot?
08:48:12  dbaron: used to be in syntax
08:48:26  dbaron: or could be in values
08:48:35  I'm fine with either.
08:49:12  plinss: who edits these specs?
08:49:22  fantasai: does this need to be rec track document?
08:49:26  dbaron: yes
08:49:28  taocai has joined #css
08:49:43  ...really?
08:49:57  plinss: don't feel strongly about syntax or values but should be rec track
08:50:09  fantasai: not convinced about rec track; it's about document conventions
08:50:11  rhauck1 has joined #css
08:50:29  astearns: it's about document conventions?
08:50:33  kimwoonyoung has joined #css
08:50:37  Jirka has joined #css
08:50:43  fantasai: how to read a propdef table is largely about document conventions.
08:50:43  Are people talkinga bout the same thing?
08:50:48  stakagi has joined #css
08:50:54  plinss: it's meta-normative.
08:51:21  fantasai: snapshot is where you want to put it
08:51:22  I think we're talking about the format of a propdef table. It's just a compact representation - how to expand that into the normative def doesn't need to be Rec-track, just recorded.
08:51:51  tobie has joined #css
08:52:09  fantasai: did you see Tab's comment?
08:52:11  We don't need the property grammar in a rec-track doc either.  It was just convenient to put it into Values.
08:52:56  I don't understand, dbaron. :/
08:53:02  plinss: I suggest we put it in values
08:53:07  But the only thing that got minuted was "Yes" from you, so shrug.
08:53:17  fantasai: some of it is about values
08:53:24  ... is it inherited.
08:53:31  TabAtkins, It affects what some pretty important stuff in the spec means
08:53:34  astearns: I agree it should be in values.
08:53:38  TabAtkins, stuff that changes what an implementation is required to do
08:53:46  TabAtkins, it seems pretty odd to make something like that non-normative
08:53:52  glazou, interop on how to read a propdef table? Yeah, I guess so, but the implementations are people here...
08:54:06  i agree with dbaron
08:54:18  *if it needs to be in a rec track document
08:54:30  fantasai, yeah...
08:54:34  plinss: do we need a resolution
08:54:41  fantasai: we need an action
08:54:58  dbaron: No, the content inside of it is normative. How to read it is just descriptive.  But whatever, I'm fine with it in Values or Syntax, I just don't see that it *needs* to be in one of those.
08:54:59  plinss: who takes the action?
08:55:06  ACTION: fantasai put something somewhere
08:55:07  Created ACTION-598 - Put something somewhere [on Elika Etemad - due 2013-11-19].
08:55:18  lol
08:55:33  You're going to look at that later and be so confused, fantasai.
08:55:48  astearns: one other thing on backgrounds
08:55:57  ... remove three-value positions?
08:56:15  fantasai: we'd also have to remove one-value positions, including center
08:56:28  astearns: we would have to remove one value that is not keyword
08:57:04  fantasai: not something we can fix
08:57:16  ... what are Tab's thoughts?
08:57:24  e.g., 'center' would no longer be a valid 
08:57:29  so I'm less convinced this is a good idea
08:57:43  Why do we have to also remove 1-value?
08:57:51  when it was just 3-value syntax, well, that seemed unpopular enough to get rid of... but not 1-value
08:58:00  TabAtkins, because it's ambiguous
08:58:00  plinss: do we want tab to call in?
08:58:09  The problem with 3-value is that "left top 5px" is maybe a  and maybe a  .
08:58:12  dbaron: if he does, would he hear us?
08:58:17  But "left 5px" isn't ambiguous.
08:58:23  it is
08:58:25  No, I won't hear anything.
08:58:32  it can be  , too
08:58:40  or it can be  with 2 values
08:58:50  Aw man, I thought I remembered the 2-value as being either 2 lengths or 2 keywords.
08:58:54  Sigh, okay.
08:59:01  Close no change?
08:59:52  Oh.
09:00:22  nsakai has joined #css
09:00:39  Given that this is *not* intending to be a backwards-compatible change (we'll define the old position syntax as  and still use it in the older properties), what about making the 2-value change to have it only be lengths or keywords, not both?
09:00:58  I think this is getting more confusing than helpful
09:01:01  Then we could allow 1-value as keywords only, and no ambiguity.
09:01:08  I'll write it up.
09:01:13  astearns: this has no effect on backgrounds
09:01:20  Right.
09:01:20  ... for backgrounds we close no change
09:01:24  Yes.
09:01:29  fantasai: that we'd have to do anyway
09:01:39  ... syntax that's almost but not quite the same
09:01:44  ... that might be confusing
09:01:48  What we name the grammar term in bg-position isn't important anyway.
09:01:55  ... whether it's valid in one case or the other
09:02:06  astearns: use different terms for left and right
09:02:16  fantasai: don't have any cases
09:02:24  ... where it make a significant difference
09:02:31  ... not worth pursuing
09:02:41  Yeah we do - we can't use something position-like for 3d.
09:02:46  Because of the ambiguity.
09:02:48  s/astearns: use different terms for left and right//
09:03:11  But anyway, I'll write this up.
09:03:11  TabAtkins, then let's make transform-origin a special snowflake
09:03:44  TabAtkins: it's special in having 3 dimensions of position already
09:03:46  Ms2ger has joined #css
09:04:04  I'm rather less convinced that we should be altering gradients(), shapes, et al.
09:04:11  to be different from background-position
09:04:19  than altering transform-origin in that way
09:04:30  It probably doesn't matter much, but whatever.
09:05:18  fantasai: thoughts on altering transform-origin() to allow to expand to
09:05:36  ,.. so the problem is that it only takes this length arg. that represents third dimension
09:05:45  ... so we're stuck with css1 backround positioning
09:06:02  ... that's the problem case we have
09:06:54  ... since this is a 3-d position
09:06:58  ... it's less bad.
09:07:12  astearns: dirk has strong opinions about transform-origin()
09:07:17  ... that I can't channel
09:07:21  cwdoh has joined #css
09:07:21  s/()//
09:08:06  ACTION: fantasai write up with Tab potential changes to transform-origin to reduce/alter inconsistencies with background-position
09:08:06  Created ACTION-599 - Write up with tab potential changes to transform-origin to reduce/alter inconsistencies with background-position [on Elika Etemad - due 2013-11-19].
09:08:21  fantasai: anything else?
09:08:56  fantasai: can we make spread continuous is still an issue
09:09:09  ... working on formula so we can have continous animation
09:09:16  ... starting from zero
09:09:27  ... or we can decide we won't change and publish LC
09:09:39  nvdbleek has joined #css
09:09:51  plinss: set time limit on new solution
09:09:57  ... I don't feel strongly
09:10:07  fantasai: neither do I. I'll respond to mailing list.
09:10:29  Dean: I've proposed border-image-like slicing for backgground image
09:10:35  ... some support on mailing list
09:10:43  ... is this enough for a real proposal?
09:10:51  fantasai: we can do backgrounds 4.
09:10:52  I find the 9-slice function idea interesting.
09:11:00  dbaron: don't add to level 3
09:11:10  Dean: don't delay progress in level 3
09:11:18  dbaron: hesitant about property explosion
09:11:24  Dean: haven't thought through
09:11:31  ... could be like border-image
09:11:35  ... before the comma
09:11:43  Ted: what about a new function?
09:11:54  Dean: Tab wanted a new function.
09:12:23  Lea: very different
09:12:35  fantasai: consider for level 4 of images
09:12:40  ... we have feature for fallbacks
09:12:44  ... an image function
09:12:50  ... takes comma seperated list
09:12:57  ... lots of crazy discussion of image set
09:13:07  ... tied to media fragments and slice
09:13:26  ... UA's that don;t understand media fragments removing image
09:13:33  ... people want to implement media fragments
09:13:37  ... drop fallback
09:13:45  ... only new functionality would be media fragments
09:13:51  ... make it more enticing to implement
09:13:55  Ted: sounds good
09:14:11  plinss: shouldn't be issue to put fallbacks back
09:14:19  fantasai: put in image sets
09:14:22  ... push to level 4
09:14:42  plinss: don't preclude doing something in future
09:14:43  TabAtkins, ok with that?
09:14:45  I don't get it.  What's the value of using image() just for media fragments? You can do that in url().
09:14:47  ... other opinions?
09:14:51  nsakai2_ has joined #css
09:14:52  Ted: sounds reasonable
09:15:09  ... I'm worried that I'm not thinking of something
09:15:11  The point of the special image() bheavior wrt fragments was *because* you could do fallback.
09:15:19  .... I'd love to see concrete proposal
09:15:29  TabAtkins, no that was image slicing via media fragments
09:15:44  TabAtkins, talking about removing the comma-separated multiple urls funmctionality of image()
09:15:55  Yeah, why?  The minutes above don't make sense.
09:16:05  dbaron: what are you proposing?
09:16:09  Fallback is the whoel point of image().
09:16:28  TabAtkins, well, not really. We have two features in the image() function
09:16:35  fantasai: there's 2 features in image function
09:16:42  one is fallback urls, so image(foo.svg, foo.png, foo.gif)
09:16:49  other is media framgents
09:17:01  image(foo.png#xywh=20,20,30,40)
09:17:06  No, media fragments is not a feature of image().  It's a feature of URLs.  They're usable in url(), too.
09:17:13  There's much interest in the first one
09:17:15  but in the second one
09:17:19  We just happened to shove in a requirement that image() *must* support media frags.
09:17:27  Yeah, which is what makes it usable
09:17:42  Explain?
09:17:49  Also, given the desire for image-set(), would want to co-design fallback URLs with that
09:18:08  Maybe this should go to the mailing list?
09:18:09  See http://drafts.csswg.org/css-images-3/#image-fragments example 4
09:18:09  If you have an old UA and you use url() with media frags, it will display the whole image
09:18:18  ...yes?
09:18:28  so it's not really usable atm
09:18:32  what was tab saying yes to?
09:18:35  image() makes it possible to transitioning
09:18:36  fantasai: fine to move to next topic
09:18:43  Okay, I think I understand now.
09:18:49  Sure, whatever, reduced implementation.
09:18:56  plinss: take issue to mailing list?
09:19:03  fantasi: tab says ok
09:19:12  dbaron: I think it was OK to something else
09:19:16  I'd like to keep the color fallback if possible at this level.
09:19:20  ah
09:19:30  dbaron: It was a questioning yes, like "yeah?"
09:19:33  plinss: mark as at risk or take out?
09:19:38  fantasai: take to mailing list
09:19:42  kk
09:19:44  Topic: transitions
09:19:45  http://lists.w3.org/Archives/Public/www-style/2013Nov/0192.html
09:19:57  dbaron: made edits we agreed on in Tokyo
09:20:19  ... and would like review of edits, want to publish WD sooner rather than later
09:20:25  ... hope there's nothing big left
09:20:33  ... still need to troll mailing list
09:21:01  ... first, are people OK with new WD for transitions
09:21:16  ... then take both to LC soon
09:21:24  yes, trawling :-)
09:21:26  Hehe, I know.  Near homophones.
09:21:28  Dean: I support publishing
09:21:33  +1 to publish
09:21:49  Dean: undecided was reversing behaviour
09:21:54  dbaron: 2 big edits
09:22:00  ... reversing behaviour
09:22:09  ... and starting of transitions, which was scarier change
09:22:16  ... implemtations all disagreed
09:22:24  ... that's been in spec for a few months
09:22:33  ... shane said in Paris he'd implemented it
09:22:38  ... and thought it worked
09:22:53  ... if people are happy to resolve to publish that's fine
09:23:22  RESOLVED: publish new working draft of CSS Transitions
09:23:34  Topic: CSS Shapes
09:23:40  astearns: i've updated spec
09:23:55  ... some clarifations to interpolation I need to add
09:24:04  ... add section describing box keywords
09:24:09  ... esp. margin box
09:24:24  ... minor changes to inset circle and ellipse to clarify
09:24:30  ... will ask for last call
09:24:35  fantasai: sounds good
09:24:48  ... would be OK with LC
09:24:59  astearns: interpolation stuff doesn't work
09:25:12  fantasai: other things?
09:25:46  Topic: backgrounds and borders 4
09:26:13  Lea: border clip property
09:26:19  ... show only corners, etc.
09:26:25  ... wondering about syntax and names
09:26:31  ... border clip is confusing
09:26:36  ... doesn't draw and then clip
09:26:42  ... doesn't show 2/3 of a dot
09:26:48  ... maybe call it border parts?
09:26:57  fantasai: couple of proposals
09:27:06  ... border parts property
09:27:18  ... awkward for common cases
09:27:36  ... need lenght for both what is shown and what is hidden
09:28:14  ... do we want low level syntax or easier way to handle common cases
09:28:25  s/lenght/length/
09:28:34  I think common cases are sufficient, surely. Complex cases, just use border-image.
09:28:39  Lea: border-corner-shape
09:28:47  Need to show only corners, and no corners, and that's about it.
09:29:02  ... scoop, notch, bevel
09:29:19  ... I've built a demo of that property
09:29:28  plh has joined #css
09:29:47  http://leaverou.github.io/border-corner-shape/
09:29:51  koji has joined #css
09:30:00  Lea: only accepts one keyword
09:30:15  ... wondering about the name
09:30:20  ... border-corner-shape is long
09:30:33  ... corner shape isn't obvious that it's related with border radius
09:30:48  ... good idea to have border radius defined the fallback
09:31:03  ... fallback for diamond is ellipse
09:31:23  ... bigger the corner, the more unrelated having border radius as fallback is
09:31:51  stakagi has joined #css
09:31:55  ... you often want rounding where straight edge join shape
09:32:03  ... maybe cubic bezier function
09:32:10  ... instead of only four keywords
09:32:21  leaverou, clean, simple, understandable at first glance by anyone, probably possible to find better keywords for values
09:32:38  Dean: where are these?
09:32:48  fantasai: ED of backgrounds and borders 4
09:32:51  -> http://dev.w3.org/csswg/css-backgrounds-4/#border-corner-shape  bg-4
09:33:04  Lea: according to ED it only accepts one keyword
09:33:08  I wanna ask implementors about that.  Curves are already complicated/slow to implement, dunno if cubic-bezier is lots slower or about the same.
09:33:29  s/about that/about cubic-bezier feasibility/
09:33:30  zcorpan: if you want rounded corners on bezel, would it make sense to use border-radius for that rounding?
09:33:52  ... what are the different shapes for corner shape?
09:34:07  ijongcheol has joined #CSS
09:34:10  Lea: scoop which is like negative border radius
09:34:18  ... also notch
09:34:55  zcorpan: you might want a little radius on corners of the shape
09:35:00  TabAtkins, yes
09:35:01  Lea: we don't know how to do that
09:35:04  kk
09:35:14  zcorpan: you should use border radius
09:35:19  Lea: that seems complex
09:35:32  That seems *very* complex. (zcorpan's).
09:35:37  ... if you just want some rounding, do you need complexity of border radius
09:35:42  ... like elliptical?
09:35:45  What if you want to bevel your notches?  Use border-image.
09:35:45  shepazu has joined #css
09:35:48  nvdbleek has joined #css
09:36:03  koji_ has joined #css
09:36:15  zcorpan: you're saying too much weight in border radius? Only have one value?
09:36:22  Lea: could apply to one corner
09:36:45  zcorpan: how would it result in elliptical border radiius?
09:37:00  Lea: would have to apply to all three joints
09:37:11  fantasai: bezier function would get you everything you want?
09:37:21  ... how do you join different colors etc.
09:37:37  Magic, presumably.
09:37:43  Bert: notch just works--it's really simple
09:37:51  fantasai: one other feature
09:37:58  ... for repeat there'd be an extend keyword
09:38:04  ... if you have gradient somewhere
09:38:11  ... you clip it
09:38:20  ... the color ends at the end of the gradient box
09:38:24  ... it doesn't keep going
09:38:39  ... fills background margin area but then stops
09:38:52  ... if image has property of paint outside boundary, it would keep painting
09:39:02  "background-repeat:extend" lets you size a gradient with background-size but still have it fill the background area.
09:39:03  ... rather than ending at the boundary of the image
09:39:21  ... that's one of our random ideas for the spec
09:39:44  ... does anyone have other ideas? Multiple borders?
09:39:45  Probably low-value, but it's been some time since I recalled why I wanted it originally.
09:39:51  border-colors!
09:39:51  Lea: I'd vote for that
09:40:07  tobie has joined #css
09:40:14  multiple borders have been in Gecko for ages
09:40:35  fantasai: should we work on multiple borders?
09:40:39  border-colors: green 1px, red 5px, yellow 3px; Something like that.
09:40:40  dauwhe: yes!
09:40:56  Would probably take some pressure off 'outline' to be a second border.
09:40:57  Bert: use grid and allow regions to have holes in them
09:41:01  ... with nested regions
09:41:23  fantasai: that's pretty complicated
09:41:33  Dean: yes!
09:41:45  see https://developer.mozilla.org/en-US/docs/Web/CSS/-moz-border-top-colors
09:41:50  dbaron: does multiple borders mean multiple colors within a border?
09:42:02  ...or multiple border styles?
09:42:04  Probably. Dont' see requests for mutliple border styles.
09:42:20  People just want some friggin rainbow borders.
09:42:26  dbaron, not sure the latter is needed
09:42:28  Lea: make it a list
09:42:34  Or more seriously, 2 or 3 tone borders.
09:42:41  Without the limitations of using inset/outset style.
09:42:50  Dean: make a proposal
09:42:53  TabAtkins, old iOS style buttons required 3 or 4 IIRC
09:42:55  ... lots of little dragons here
09:43:04  I propose we copy Moz's current behavior. ^_^
09:43:04  ... which won't happen until you try to write spec
09:43:19  TabAtkins, +1
09:43:22  Bert: multiple everything!
09:43:30  TabAtkins, border-colors? No, you really really really don't want that
09:43:36  dbaron: no, only one border radius
09:43:37  Bert: what about border-clip?
09:43:38  TabAtkins: god no, that's awful
09:43:42  Hey hey, someone talk about *-1, *-2 longhands for every list-valued property.
09:43:44  Hahaha
09:43:54  plinss: may be interesting holes there
09:44:19  fantasai: action item to write up a proposal
09:44:35  kimwoonyoung has joined #css
09:44:58  Topic: longhand for list properties
09:45:35  just wait until we put zero-width non-breaking spaces in all the things
09:46:05  fantasi: if you have a list valued property, then dash-number represents that position in the list
09:46:22  plinss: what if you have -47 with a list of 3 items?
09:46:31  s/fantasi/fantasai/
09:46:38  Need to make sure that every list has a "null" value.
09:46:40  fantasai: dash ones won't take comma
09:46:53  So unfilled values between explicitly-given ones get the null.
09:46:54  plinss: concerned about cascade
09:47:10  Why concerned about cascade? This is standard longhand expansion.
09:47:27  (I think most (all?) list-valued props alreayd have null values.)
09:47:38  glenn has joined #css
09:48:04  plinss: going back and forth about the proposal
09:48:14  ... not time or place for serious discussion
09:48:27  ... let's adjourn. Thank you everyone
09:48:28  The list-valued shorthand expands into an infinity of indexed longhands. You only serialize up to the last explicitly-given index.
09:48:41  This solves some use cases, but not all
09:48:59  Never try to solve all use-cases.
09:49:08  Gotta keep 'em hanging on for more.
09:49:10  Quite often you don't have knowledge of all the items in the list and just want to add something in the beginning or end (sort of like a .push() in arrays)
09:49:23  Yeah, but that's impossible here. :/
09:49:37  We just don't have the structure for it.
09:49:40  so you'll end up with stuff like how people do z-index: 100000000000000000 to be at the top
09:49:55  and no solution for how to add something to the beginning (unless negative indices are allowed)
09:49:56  Yes.
09:50:08  Correct, these are limitations.
09:50:18  these are very serious limitations
09:50:36  "Put me at the top" is always a self-defeating desire.
09:50:46  As soon as two places want to be on top/bottom.
09:50:48  obviously, it's better than nothing, but I think it's worth it to try and find a solution that covers at least, I don't know, half the use cases :P
09:50:53  kennyluck has joined #css
09:50:56  we should figure out additive cascading instead
09:50:58  Mine covers half!
09:51:09  dbaron++
09:51:11  dbaron: If you think that's feasible.
09:51:33  TabAtkins: Obviously it's difficult to prove that, but I doubt it even covers 1/3
09:51:59  cwdoh has joined #css
09:51:59  leaverou: While we're throwing around arbitrary numbers, I'll assert that it covers at least 4/5
09:52:07  shepazu has joined #css
09:52:29  Which hits the 80/20 rule and means we don't have to try any more.
09:53:02  you just pulled that number out of your bum, just like I did :P
09:53:17  then you'll need variables for the position of the thing of interest
09:53:20  so property-name-variables
09:53:33  koji has joined #css
09:54:20  leaverou: I thought that's what we were doing!
09:54:30  fantasai: Nah, only if you want readability.
09:56:27  nvdbleek has joined #css
09:56:54  SimonSapin: ping
09:57:03  rrsagent, generate minutes
09:57:03  I have made the request to generate http://www.w3.org/2013/11/12-css-minutes.html dauwhe_
09:58:46  glenn has joined #css
10:01:56  teoli_ has joined #css
10:02:37  teoli has joined #css
10:03:54  zcorpan has joined #css
10:07:46  zcorpan has joined #css
10:09:21  leif has joined #css
10:13:19  koji has joined #css
10:14:54  glenn has joined #css
10:22:34  TabAtkins: you're missing this totally awesome conversation about performant asymptotic functions
10:23:48  koji has joined #css
10:25:07  shepazu has joined #css
10:26:14  plinss, you asked to be reminded at this time to get some sleep
10:28:40  myakura has joined #css
10:32:30  koji has joined #css
10:35:22  antonp has joined #css
10:36:12  nvdbleek has joined #css
10:38:15  zcorpan has joined #css
10:41:16  Zakim, bye
10:41:16  Zakim has left #css
10:41:54  sr = br + s * (2 / pi) * arctan (K * (br / s))
10:42:04  sr = radius of curvature of spread
10:42:06  br = border radius
10:42:08  s = spread
10:42:16  K = a constant, probably worth testing in the range 3 - 20 or so
10:42:32  want to look at drawings with various ratios of br / s
10:42:32  best represented as a multiple of pi
10:42:34  :)
10:42:46  the goal is that if br is around or greater than s, sr = br + s
10:42:52  but that if br << s, sr = br
10:45:42  koji has joined #css
10:46:19  koji_ has joined #css
10:48:22  darktears has joined #css
10:49:08  koji has joined #css
10:58:26  dauwhe has joined #css
11:02:32  dbaron has joined #css
11:33:29  koji has joined #css
11:35:38  teoli_ has joined #css
11:38:59  jet has joined #css
12:06:41  nvdbleek has joined #css
12:08:49  Ms2ger has joined #css
12:48:57  Zeke_ has joined #css
12:55:56  darktears has joined #css
12:58:01  teoli has joined #css
12:58:43  teoli_ has joined #css
13:30:02  zcorpan has joined #css
13:37:58  zcorpan has joined #css
13:39:02  myakura has joined #css
13:48:12  liam has joined #css
13:48:48  Ms2ger has joined #css
14:08:28  zcorpan has joined #css
14:10:10  Zeke has joined #css
14:18:09  tantek has joined #css
14:35:05  zcorpan has joined #css
14:39:45  Zeke_ has joined #css
14:54:35  nvdbleek has joined #css
14:55:56  nvdbleek has joined #css
14:57:26  nvdbleek has joined #css
14:58:18  leif has joined #css
14:59:00  dauwhe has joined #css
15:00:50  nvdbleek has joined #css
15:03:33  nvdbleek has joined #css
15:05:28  nvdbleek has joined #css
15:21:42  nvdbleek has joined #css
15:24:15  nvdbleek has joined #css
15:40:24  nvdbleek has joined #css
15:41:49  nvdbleek has joined #css
15:55:50  nvdbleek has joined #css
15:57:52  nvdbleek has joined #css
15:59:44  dauwhe has joined #css
15:59:48  nvdbleek has joined #css
16:01:33  nvdbleek has joined #css
16:03:19  nvdbleek has joined #css
16:07:06  nvdbleek has joined #css
16:08:01  nvdbleek has joined #css
16:15:01  Zeke has joined #css
16:18:30  cwdoh has joined #css
16:33:09  cwdoh has joined #css
16:43:29  dauwhe has joined #css
16:50:24  jcraig has joined #css
16:58:02  dbaron has joined #css
17:02:44  myakura has joined #css
17:03:09  masatakayakura has joined #css
17:11:18  rhauck has joined #css
17:12:54  rhauck2 has joined #css
17:23:06  Ms2ger has joined #css
17:36:17  teoli has joined #css
18:18:11  jcraig has joined #css
18:53:39  bobby has joined #css
18:54:20  bobby has left #css
19:00:25  dauwhe has joined #css
19:43:42  bobby_ has joined #css
19:50:42  cwdoh has joined #css
19:55:16  bobby_ has left #css
19:58:26  jet has joined #css
20:00:59  dauwhe has joined #css
20:15:36  florian has joined #css
20:20:27  fharper has joined #css
20:26:20  florian1 has joined #css
20:29:00  Guest has joined #css
20:33:09  Guest has joined #css
21:01:25  dauwhe has joined #css
21:06:30  jcraig has joined #css
21:07:45  glenn_ has joined #css
21:20:27  glenn has joined #css
21:26:42  glenn_ has joined #css
22:16:38  nsakai has joined #css
22:18:42  teoli has joined #css
22:21:24  cwdoh has joined #css
22:33:19  Guest has joined #css
23:08:26  jcraig has joined #css
23:09:11  tantek has joined #css
23:18:47  florian has joined #css
23:25:33  florian has joined #css
23:27:21  jcraig has joined #css
23:32:01  SimonSapin: Now that I'm using railroad diagrams frickin everywhere, I find that it's kinda terrible to have to use actual Python syntax.  Trailing parens and commas are hard to manage, especially when you're rearranging things.
23:32:12  This makes me want to do a DSL more.
23:33:26  Argh, I just got bit by it again.
23:34:51  jdaggett has joined #css
23:36:56  
23:36:56  #T (
23:36:56  #Or
23:36:56  	#Sequence
23:36:56  		[feature name]
23:36:56  		:
23:36:56  		[feature value]
23:36:57  	[feature name]
23:36:57  	#Sequence
23:36:57  		[range form]
23:36:57  		#Comment (see below)
23:36:57  #T )
23:36:57  

23:37:42  (#T is optional, and used for clarity or when you want to use a significant character at the start of a line.
23:37:46  )
23:38:10  [foo] is a microsyntax for non-terminals, or just use the #NT command maybe?
23:38:59  Yeah, nuts to that.  Just have an #NT command.
23:39:03  It reads fine.
23:39:23  No string escaping or commas or parentheses, just nice significant whitespace.
23:39:26  cwdoh has joined #css
23:46:37  Ooh, even better, distinguish commands as (\w+:)
23:46:50  So it looks like Python, woo!
23:47:03  It makes the nesting look very natural.
23:56:56  jet has joined #css