00:17:16 cabanier has joined #css 00:21:26 zcorpan has joined #css 00:40:52 koji has joined #css 02:02:45 myakura has joined #css 02:46:49 myakura has joined #css 03:01:41 lmclister has joined #css 03:29:48 krijnh has joined #css 03:39:03 jdaggett has joined #css 04:05:51 myakura has joined #css 04:20:27 lmclister has joined #css 04:26:15 myakura has joined #css 04:35:19 shans__ has joined #css 04:40:23 shans__ has joined #css 05:28:49 ian has joined #css 05:53:47 teoli has joined #css 06:00:56 myakura has joined #css 06:24:58 dbaron has joined #css 06:50:57 tantek has joined #css 06:54:46 dbaron: you guys are starting soon? 06:56:19 jdaggett_ has joined #css 06:59:31 dbaron: so you fiddling with the camera? 06:59:54 jdaggett_, not taht many people here yet 07:00:36 jdaggett_ has joined #css 07:03:06 glazou has joined #css 07:03:38 zcorpan has joined #css 07:09:39 dbaron: quorum yet? 07:10:42 shans__ has joined #css 07:15:18 astearns has joined #css 07:16:31 tantek has joined #css 07:18:45 jdaggett, nah room 1/2 empty :-( 07:18:53 even peter running late 07:19:18 well, can we just resolve on everything i'd like to resolve...? 07:19:32 glazou: ^ 07:19:55 ian has joined #css 07:25:54 liam, you did not tell me if i can attend workshop... 07:26:34 see msg (sorry) 07:27:27 jet has joined #css 07:28:06 dbaron: almost? 07:30:26 teoli has joined #css 07:31:20 cyril has joined #css 07:34:00 SteveZ has joined #css 07:35:20 leif has joined #css 07:35:44 ScribeNick: fantasai 07:35:52 Topic: Font Load events 07:35:54 jdaggett, starting 07:36:21 dbaron: can you enable the camera? 07:36:59 jdaggett, reviewed it, I have no real comment, no I don't find it strange 07:37:10 hmmm 07:37:25 document.fonts.clear() isn't a tad odd? 07:37:36 the name yes, the feature, no 07:37:42 um 07:37:54 so you have n @font-face rules and you call that 07:37:55 projector has joined #css 07:38:01 sgalineau has joined #css 07:38:16 trackbot, start telecon 07:38:18 you'll have n @font-face rules in your om 07:38:18 RRSAgent, make logs member 07:38:18 Zakim has joined #css 07:38:20 Zakim, this will be Style_CSS FP 07:38:20 I do not see a conference matching that name scheduled within the next hour, trackbot 07:38:21 Meeting: Cascading Style Sheets (CSS) Working Group Teleconference 07:38:21 Date: 12 September 2013 07:38:23 RRSAgent, make logs public 07:38:29 Zakim, remind us in 9 hours to go home 07:38:29 ok, dbaron 07:38:36 jdaggett, and it clears the fonts loaded in the layout engine, yes 07:38:45 despite of rules 07:38:54 super useful 07:39:50 TabAtkins: Quick intro on new spec for font load events 07:40:16 TabAtkins: John just sent a bunch of really nice comments on improving spec prose, but nothing major iirc 07:40:27 jdaggett: Last part of mail suggests fundamental change 07:40:32 TabAtkins: Iteration order? 07:40:44 jdaggett: Yeah, and just how add and delete should throw for CSS-connected font base objects 07:40:50 TabAtkins: Ok, think that's reasonable to discuss after intro 07:41:12 TabAtkins: Recall original proposal John made at last F2F, FontLoad interface, 5 interfaces related to all fonts, 3 for individual fonts 07:41:23 ChrisL has joined #css 07:41:24 TabAtkins: Based on consensus, redesigned around Future 07:41:40 TabAtkins: Roughly based on blog post, but made some changes based on thinking of how to make this work in Workers 07:41:50 TabAtkins: Have no story of how to ship a font face over to Workers 07:42:13 TabAtkins: So, start with FontFaceSet 07:42:19 TabAtkins: Closest analogue to John's proposal 07:42:34 TabAtkins: It's a set class, which while not defined in WebIDL quite yet, but similar to Map class that is defined there 07:42:36 yamamoto has joined #CSS 07:42:42 TabAtkins: Acts like a JS set, containing a bunch of Font faces 07:42:48 TabAtkins: Methods and events 07:43:01 TabAtkins: To address original issues, still retained 3 of the events: loading, loadingdone, and loadingerror 07:43:09 TabAtkins: These fire with regards to every single font load 07:43:37 TabAtkins: onload fires as soon as doc starts loading fonts, loadingdone when it's done, simultaneous with loadingerror if there was a failure 07:44:00 TabAtkins: Past events, there are promise-based functions 07:44:21 TabAtkins: load() function, give it font value and optionall some text you want to render with it 07:44:22 Rossen_ has joined #css 07:44:36 TabAtkins: check() just checks, not async 07:44:47 TabAtkins: ready() promis fulfills once all fonts are loaded 07:44:59 TabAtkins: In blog post and F2F dicussion 07:45:15 TabAtkins: I also added a match() function as well, which exposes CSS font matching algorithm. 07:45:16 s/In/This was previously described in my/ 07:45:36 TabAtkins: Returns list of what fonts would be used for some text 07:45:43 jdaggett: The match() method won't work 07:45:57 jdaggett: You can have platform fonts in there, so unless you create font entries for platform fonts, won't work 07:46:12 jdaggett: Honestly, don't think you really want to expose nitty gritty of font matching, unless you have a good reason 07:46:17 glazou: Isn't it security/privacy hole? 07:46:25 exposing platform fonts is a privacy/profiling issue perhaps 07:46:55 glazou: Web page could discover which fonts you have installed on the system 07:47:14 fantasai: You could figure that out by just ask for local before webfonts, then see which fonts got loaded 07:47:41 dbaron: ... 07:48:03 jdaggett: When you have explicit name of a platform font in the match list. I assume your method doesn't pull in fallback fonts 07:48:10 TabAtkins: Why don't I want to expose fallback fonts? 07:48:11 s/.../the only way to prevent that would have been to prevent browsers ever loading local fonts 07:48:15 jdaggett: Would be really system specific 07:48:31 s/.../I don't think we can solve the fingerprinting issue without having browsers ship with a set of fonts and then allowing only those and downloadable fonts, and not arbitrary local fonts/ 07:48:40 fantasai: Are you talking about system fallback font, or falling back down the list? 07:48:43 jdaggett: System fallback font 07:48:45 (I think we should be able to restrict local() to browser and user style sheets.) 07:48:58 jdaggett: That method really needs to have some justification 07:49:19 jdaggett: Use case is just, here's a string that I want to render, just want to make sure that all fonts needed are loaded 07:49:33 TabAtkins: I went through the spec trying to figure out what primitives are needed 07:49:46 TabAtkins: This method was really useful for describing other algorithms 07:49:59 TabAtkins: Although we could make it just a spec-internal method 07:50:09 jdaggett: Anyway, I think we can move on. Just want to note that I think it's a bad idea. 07:50:20 TabAtkins: Ok, if it winds up beign a bad idea, I'll just shift the algorithm to being spec-internal 07:50:31 TabAtkins: Anyway, that's the entire FontFaceSet interface, what we discussed at F2F 07:50:39 TabAtkins: Past this is what I had to invent to make ti work well with workers 07:50:44 TabAtkins: One is the FontFace interface 07:51:05 TabAtkins: It is a rough analogue of CSS font-face rule 07:51:15 TabAtkins: But doesn't have any connections to document / style sheet 07:51:19 TabAtkins: So safe to ship to a woker 07:51:34 TabAtkins: load() and ready() methods 07:51:57 TabAtkins: Has also a match() function, which returns bool. John explained why he doesn't think it'll work, so might drop that. 07:52:11 TabAtkins: FontFace can be generated from @font-face rules, or can be constructed via JS 07:52:33 TabAtkins: And that's the entire spec 07:53:00 TabAtkins: Only place I haven't written out yet is the itneraction between CSS and these interfaces 07:53:20 TabAtkins: As I said, each @font-face rule should automatically generate a FontFace object, separate from CSSOM object, and insert into document.fonts 07:53:33 michou has joined #css 07:53:38 israelh has joined #CSS 07:53:40 TabAtkins: This is connected up with font-face rule, so that CSSOM and FontFace object reflect each other 07:53:56 TabAtkins: Adding or removing @font-face rules will automatically add/remove FontFace rules 07:54:17 TabAtkins: Intention is that font matching algorithm will iterate over FontFaceSet, not just @font-face rules and local fonts 07:54:30 TabAtkins: jdaggett has a whole bunch of comments, which I'll need to address 07:55:08 jdaggett: The main concern I have about what you specc'ed out already is that while adding a new font-face rule automatically populates into FontFaceSet, if you remove it from that, @font-face is not updated reflect that 07:55:16 jdaggett: So posted restrictions on how that shoudl work 07:55:31 TabAtkins: While I did say that FontFace and font-face rules are connected, there's no connection between them and the style sheets 07:55:47 TabAtkins: So an @font-face rule could still be present in CSSOM after FontFace is removed from FontFaceSet 07:56:00 glazou: Comments on iterating over FontFaceSet 07:56:07 glazou: Seem a little inconsistent 07:56:28 glazou: clear() seems like "unloadAll()", while size() is more like ? 07:56:34 jdaggett: That's the pattern in JS 07:56:55 TabAtkins: clear() doesn't unload, just removes everything from the set 07:57:08 TabAtkins: fonts are still there, if you pulled them out of the set and have reference to those FontFaces 07:57:22 jdaggett: inconsistent from existing DOM APIs 07:57:29 TabAtkins: delete() is fine? 07:57:39 jdaggett: But it is consistent with other JS apis 07:57:45 jdaggett: So for Workers case, this might be more appropriate 07:58:06 SteveZ: So clear() removes items from the set, but doesn't delete them 07:58:12 glazou: You may want to add a note clarifying this. 07:58:22 TabAtkins: Think it might be confusing b/c JS sets are new 07:58:45 jdaggett: Could define collection object that matched [?] 07:58:54 TabAtkins: No, people hate collections. With reason. Bad idea. 07:59:24 TabAtkins: Do you have suggestions for better integration between FontFaceSet and CSS @font-face rules 07:59:27 ? 07:59:43 TabAtkins: CSS font-face rules still generate FontFace objects, but can't be removed from FontFaceSet 07:59:54 krit has joined #css 07:59:55 jdaggett: In other words, if CSSOM is created, would have to remove it from OM 08:00:18 jdaggett: Trying to remove it from FontFaceSet would throw an exception 08:00:41 TabAtkins: Seems reasonable to me 08:01:01 TabAtkins: As long as FontFace object is in FontFaceSet, would be connectd to style sheet 08:01:12 jdaggett: Tab, are you thinking this going to be transferrable? 08:01:22 TabAtkins: Whichever one doesn't neuter, just copies over 08:01:27 jdaggett: Seems like this should be cloned 08:01:51 TabAtkins: So, you agree, after you transfer it is like normal FontFace and can be added to Workers set like normal? 08:01:54 jdaggett: Sure 08:01:56 TabAtkins: I'm ok with this, simplifies some things 08:02:11 jdaggett: Yeah, bc way you were trying to manage collection seemed really weird 08:02:14 TabAtkins: OK 08:02:20 TabAtkins: Any other changes besides clarifications? 08:02:27 jdaggett: Haven't looked carefully at other parts of spec 08:02:38 jdaggett: e.g. haven't looked at Promises part 08:02:50 TabAtkins: Promises prose is up-to-date with latest spec 08:02:53 jdaggett: Not so worried about that 08:02:57 TabAtkins: Any other comments? 08:03:18 krit: I want Futures instead 08:03:24 ChrisL: In the Future 08:03:32 ... 08:03:44 TabAtkins: Promises spec is in GitHub atm, expecting it to move over to WHATWG at some point 08:03:59 https://github.com/domenic/promises-unwrapping 08:04:09 jdaggett: Also I think we need heycam to add set class to WebIDL 08:04:12 TabAtkins: Agreed 08:04:38 TabAtkins: Review by others would be great, because we are chomping at bit to implement this 08:04:55 israelh: Do you have eventing model here to be replaced by Promises model, or co-exist? 08:05:03 TabAtkins: Will co-exist. Events and Promises do different things 08:05:22 TabAtkins: A lot of things are better off as Promises, but things that fire multiple times are better done as events 08:05:41 israelh: ... Do you get promise and event simultaneously? 08:05:43 TabAtkins: Yes 08:05:52 TabAtkins: One is right before other, but adjacent steps in algo 08:06:05 israelh: Will there be a suggestion of which to listen for? 08:06:12 ChrisL has joined #css 08:06:15 TabAtkins: I expect individuals to use different things 08:06:27 TabAtkins: If you want to do something after fonts load, Promise is better 08:07:14 tabatkins: more typey less talky 08:07:17 TabAtkins: but if you want to have e.g. an indicator of whether fonts are loaded or not, event is better 08:07:32 Everyone is cool with this. 08:08:21 Topic: TPAC and F2F Scheduling 08:08:37 plinss: Sent email wrt space for Sunday meeting, but no response back 08:08:51 SteveZ: There is I believe an event put together by the sponsors that day 08:09:01 jdaggett: Anyone have an office in Shenzhen? 08:10:17 ...peter is mumbling... 08:10:19 plinss: Doesn't seem like anyone can offer space atm 08:10:29 I think our closest office to Shenzhen with a conf room big enough for the CSS WG is... Paris! :-) 08:10:30 plinss: If you find out about space, let us know 08:10:39 plinss: We have a request from SVGWG for joint meeting on Tuesday 08:10:59 dbaron, I can live with that :-) 08:11:01 TabAtkins: Alternately, b/c our schedule is usually packed, could overlap with them on Thursday 08:11:03 google hong kong? 08:11:16 fantasai: could do half and half 08:11:30 dbaron: Note that AC meeting is Tues afternoon / Thurs morning 08:12:13 plinss: Any fxtf people not going to be around on Thursday? 08:12:15 silence 08:12:20 ChrisL has joined #css 08:12:26 plinss: Next topic would be F2F meetings for next year 08:12:32 sylvaing: We can host in Seattle 08:13:03 http://wiki.csswg.org/planning 08:13:11 i put strawman proposals in there 08:13:24 plinss: Were thinking East Coast in Feb. Works for folks? 08:13:42 didn't someone offer nyc? 08:13:53 cmon, the buildings are heated... 08:14:01 jdaggett, justin erenkranz did 08:14:33 [unminuted discussion] 08:15:07 jdaggett, who were you thinking of as host for Taiwan? 08:15:23 dbaron: moztaiwan 08:15:30 jdaggett, I don't remember a room big enough 08:15:31 narrowing to 1st week of Feb 08:15:36 asking wrt preferences on days 08:15:47 teoli has joined #css 08:15:54 proposal: Feb 4-6 08:15:55 well, we can propose it, then investigate the possibility 08:16:04 RESOLVED: plinss should always be miked. 08:16:10 :P 08:16:12 YES!! 08:16:20 I read that as milked 08:16:25 shans__ has joined #css 08:16:30 anytime in feb is good for me 08:16:38 oh, very nice... 08:16:50 proposal is 4-6 feb 2014 08:16:54 yes 08:17:27 s/miked/mic'ed/ 08:17:29 nyc is fine 08:17:32 plinss: NYC or West coast? 08:17:47 snow is pretty 08:17:57 and we can have a css hockey game 08:18:29 jdaggett, the what? 08:18:52 w3c office at mit 08:19:12 interesting interaction with tech folks at mit? 08:19:15 koji: that week conflicts with UTC 08:19:16 koji: UTC is Feb 3-7 08:19:39 proposal: 10-12 Feb 08:20:52 proposal: jan 28-30 08:20:53 what's the proposed location? seattle? 08:20:55 NYC 08:20:57 http://www.unicode.org/timesens/calendar.html 08:20:58 good 08:21:17 krit: Seattle could do joint with SVG 08:21:31 (and http://www.unicode.org/L2/meetings/utc-meetings.html ) 08:22:06 krit: CSS/SVG split the week, fxtf on wed 08:22:19 krit: in Seattle 08:23:07 Tentative resolution: Jan 27-31, joint meeting with SVG, in Seattle, hosted by Adobe 08:23:26 nice feedback 08:25:02 Discussing locations for May 08:27:23 Thinking Asia in May, Sophia in Sept 08:28:18 fantasai: Maybe we can meet in Korea for May, and trap some Korean typesetters for interrogation 08:28:38 dbaron: May is always a crunch of conflicts 08:28:54 glazou: I have to check wrt hosting in Korea 08:28:56 first week of may is holidays in japan 08:29:14 oh, that's right, mr. samsung!! 08:29:22 glazou: Not sure Samsung can offer the facilities we need, access to conference rooms / open internet. Security there is super strong 08:29:54 dbaron: ok, gotta run 08:30:02 dbaron: back after 2:30 your time 08:30:23 (Cannes Filem Festival, if you think of coming to the French Riviera, is 14-25 May 2014) 08:30:55 (WWW2014 in Seoul is April 7-14) 08:31:09 koji has joined #css 08:32:18 plinss: Mark out May 12-16, several folks to investigate locations in Asia 08:32:25 plinss: Sophia in September, pick dates later? 08:32:30 OK 08:33:03
08:35:08 koji - http://www.w3.org/Style/CSS/members.en 08:42:46 astearns has joined #css 08:43:47 astearns_ has joined #css 08:44:04 TabAtkins: Simon was asking about alternate chars for token markup, how about white tortoise shell brackets? 08:44:32 http://www.fileformat.info/info/unicode/char/3018/index.htm 08:44:39 ChrisL has joined #css 08:46:52 liam has joined #css 08:51:49 tantek has joined #css 08:56:55 〘url〙 08:58:23 jet has joined #css 09:02:08 Scribe: Bert 09:02:15 Topic: CSS Masking 09:02:47 krit: [moves to whiteboard]] 09:03:11 ... Three topics. 09:04:02 http://www.w3.org/TR/css-masking/ 09:04:30 ... For mask image, compat with SVG 09:04:44 ... 2nd option is to list an image, (like bg image) 09:05:03 ... List of mask images, compose togther, than mask 09:05:28 ... But impls actually mask each image individually. 09:05:43 ... (drawing on wboard) 09:06:14 draws union of shapes as a single mask versus using shapes masking each other 09:06:38 ... (result is typically smaller) 09:06:56 ... I suggest to use this mode, as it is already implemented. 09:07:09 ... Yu can do the other already in a different way. 09:07:15 ... So you get more options. 09:07:25 fantasai: Not obvious how to get the other, though. 09:07:29 krit: Agree 09:07:46 ... Webkit and blink impl like this. 09:08:01 fantasai: Can we define the property as accepting just one value, not a list? 09:08:13 ChrisL: Then you get less functionality. 09:08:26 krit: Alpha mask abd lumi mask are different. 09:08:29 Rossen_ has joined #css 09:08:45 ... Lumi mask needs to be converted. (Usually by hardware.) 09:09:16 Jet: (About drawing:) is it an intersection. 09:09:25 krit: That is effetc of masking in sequence. 09:09:40 jet: Diffeeren order of images gives same result? 09:09:48 krit: same result, yes. 09:10:08 dbaron: It's multiplication alpha, in fact. 09:10:22 s/It's/Is it just 09:10:28 lea: Anything in Cmpositing that allows people to compose images for masks? 09:10:31 dirk: could just do it with multiplication of alpha 09:10:42 krit: You mean if mask only accepts one image? 09:11:04 ChrisL: If it were implemented... 09:11:19 leaverou: Is it really useful to have multiple masks? 09:11:36 advanced compositing is a more recent addition so less supported. masking has been in svg forever 09:11:43 tab: thumbs up from Blink :-) 09:11:55 hober: and webkit 09:12:22 krit: You can control. Compose and mask first. 09:12:39 fantasai: Logically similar results, but confusing to authors. 09:12:52 ... I'd limit it to one layer. 09:13:13 ... If we allow multiple layers, then we should also allow operations on them. 09:13:23 ... So no need to use SVG as well. 09:13:46 krit: USe case of repeating mask pattern and then a single mask for the whole image. 09:14:09 ... There are use cases, but fine to restrict to one mask for now. 09:14:28 fantasai: I don't like to have just one way of compositing images. 09:14:44 ChrisL: Could add ... 09:14:45 ChrisL: doesn't prevent adding a new property later whose default is intersection 09:16:08 fantasai: So i'd either limit ot on elayer, or allow operaitons on layers, or at least say that that is where we're going. 09:16:11 ChrisL: Reasonable. 09:16:22 krit: OK to limit to one layer for now. 09:16:44 ChrisL: Any suggestions for how extension might look, krit? 09:17:11 krit: Not a comma separated list of operations, just one kwyword, on an extra proeprty. 09:17:32 plinss: Or what Lea said, extend the image() type. 09:17:53 krit: You could in fact already use the crossfade() today. 09:18:19 TabAtkins: But percentages must add up to 100%. 09:18:27 plinss: But could create another type for that. 09:18:47 fantasai: Yes, but also whether the image is stretched to box or not, and other operations. 09:19:18 ... UNion and intersection are just two examples of the oeprations, there are more. 09:19:42 ... Order of layers doesn't matter, right? We could have different separateors: slash, comma,... 09:19:48 krit: HArd to implement. 09:20:12 ... exclusions is already easier than the union to implement. 09:20:22 ... One operation only is easier. 09:20:54 liam: As soon as you have union and interesection, you also want difference. 09:21:15 TabAtkins: So a compositing function miht be reasonable in the future. 09:21:38 krit: resolve on restricting to one layer for this level? 09:22:09 ChrisL: If we decide just a simgle image as mask, will BLink then change its impl? 09:22:34 ... If they continue, then when we add functionality, we're stuck. 09:22:46 hober: Single layer case would not change, right? 09:22:52 krit: Correct. 09:23:25 hober: Prefixed propeerty can cntinue, unpereficed would ,match spec. 09:23:49 s/lea:/leaverou:/ 09:24:00 RESOLVED: Just one layer. 09:24:46 krit: I want ot combine two cases: 09:25:54 ... combine masked referenced with CSS images as a list in the mask-image property. 09:26:13 TabAtkins: Yes, that is possible. 09:26:25 krit: Resolve on that? 09:26:44 ... Example: filter proeprty: 09:27:05 ... can combine in a list. I want the same for mask property. 09:27:24 ChrisL: Yes, reasonable. 09:27:36 fantasai: Works for me. 09:27:47 ... So can have masked image that points to SVG image? 09:27:54 krit: Yes, or to CSS image. 09:28:26 RESOLVE: combine CSS images and CSS mask references in th emask-image property. 09:28:43 krit: last issue is mask shorthand. 09:28:55 ... fantasai suggested 'none' as value. 09:29:07 ... THat disables mask box as well. 09:29:13 ... "Super-shorthand" 09:29:38 krit: With 'mask: none' you disable all mask oeprations. 09:30:27 dbaron: Still invariant that any value of 'mask' diables mask-box? 09:30:42 krit: Yes, you can reset mask-box, not set it to any particulat value. 09:31:09 dbaron: OK, shorthand always set all theoir properties, even if that cannot set all values. 09:31:15 krit: OK, reasonable. 09:31:28 ChrisL: Spec needs example for this, for 'none' 09:31:40 ... Not example, actual text. 09:31:46 krit: Yes, and example as well. 09:31:59 ChrisL: Yes, define what it does. 09:32:07 makes it testable 09:32:22 fantasai: mask-repeat defaults to repeat. Should that change? 09:32:34 krit: Was for smilarity to background. 09:32:49 ... but expect that most people indeed want to change it. 09:32:59 fantasai: More common to have no-repeat, 09:33:01 ChrisL: Agree 09:33:04 krit: Agree 09:33:31 RESOLVED: default value for mask-repeat is no-repeat. 09:33:44 RESOLVED: Add keyword 'none' to 'mask' 09:34:06 fantasai: Should mask-position be center by default? 09:34:14 lea: Yeah! 09:34:31 krit: makes sense... 09:34:44 RESOLVED: Default for mask-position is 'center' 09:34:51 s/lea:/leaverou:/ 09:35:15 fantasai: mask-origin... 09:36:11 krit: use mask-clip (scribe missed) 09:36:40 fantasai: Say you non symmetrical borders and want to center it. 09:36:50 plinss: Change that, too? 09:37:05 krit: mask-oroign should idefault to border-box. 09:37:18 s/oroign/origin/ 09:37:41 RESOLVED: default for 'mask-origin' is 'border-box' 09:38:15 plinss: next agenda topic? 09:38:53 yamamoto has joined #CSS 09:39:07 Topic: naming of DOMpoint and matrix 09:39:19 s/DOMpoint/DOMPoint, Quad,/ 09:39:45 krit: Suggestion was to use "CSS" as prefix. 09:39:52 ... I have no preference. 09:40:19 ... Another question form hixie was about calling it Matrix. 09:40:26 ... We have history of SVGMatrix. 09:40:35 ... Also MSMatrix. 09:40:47 ... SVG wants to combine them and make new name, 09:41:06 ... Hiie suggest just using SVGMatrix. 09:41:29 ChrisLilley has joined #css 09:41:31 Tab: No pb with SVGMatrix as such, but pb with inconsistent prefixes. 09:41:48 krit: duplicate the names. 09:42:10 TabAtkins: Use "SVG" on everything in geometry. 09:42:22 krit: Not sure we can come up with solution here. 09:43:00 SimonP: Precedent for having two names, e.g., Document and HTMLDocument, as alias. 09:43:15 ... Could do the same trick. 09:43:30 ... Have SVGMatrix point ot same i/f object. 09:43:49 krit: Anybody preferences? 09:43:57 TabAtkins: Fine with that. 09:44:19 ... I just want all objects to have the same prefix. 09:44:31 ... Can use "DOM" prefix. 09:44:55 fantasai: Start with an "X" :-) 09:45:17 ... common prefix for geometry things makes sense. 09:45:34 x marks the point 09:45:42 simonp: Any objection to "DOM"? 09:45:56 ... With SVGMAtrix an alias? 09:46:22 ChrisL: SVG didn't want to pretend to have the global Matrix, so "SVGMatrix" instead. 09:46:54 simonp: If you change prototype of SVGMatrix, than pointer would not work, but alias would. 09:47:15 fantasai: So action the TAG to bikeshed us? :-) 09:47:43 RESOLVED: Provisonally go for DOM prefix. 09:49:22 [Agenda discussion, lunch expected in 25 minutes] 09:49:50 Topic: Sticky position 09:49:54 https://etherpad.mozilla.org/yqbijwrHI6 09:50:16 dbaron: A feature that someone at Apple proposed a year ago. 09:50:37 ... A bunch of people find it useful. 09:51:20 ... Use case is things like in iOS UI, such as calendar, with headers above, and header will stay when you scroll, 09:51:31 ... but be replaced by next header when that appears. 09:51:49 TabAtkins: I could show demo... 09:52:15 Rossen_: Related to Position spec? 09:52:21 dbaron: Not sure which spec. 09:52:33 https://air.mozilla.org/intern-presentation-ford/ 09:52:36 Useful in general for cases wher eyou have a header followed by some content (e.g. table rows) where you want the header visible, but the entire content below the header doesn't fit on one screen 09:52:54 Rossen_: Was in San Diego ftf when people proposed Positing spec. 09:53:00 ... But no edits ever made. 09:53:15 ... I'll get some tetx I got yesterday into the spec, 09:53:38 dbaron: See my URL above. 09:53:55 hober: Russel yesterday sent diff. 09:54:10 dbaron: So I guess this is moving along. 09:54:26 ... Gecko has it mostly implemented. 09:54:38 ... (picture on screen) 09:55:01 ... Sticky is a bit like relative, like fixed is to absolute. 09:56:20 Bert: (describes case of target of link being underneath fixed pos elt) 09:56:34 dbaron: Not the same case, that is bug in fixed pos impl. 09:56:42 fantasai: Maybe related after all. 09:56:51 s/Russel yesterday sent diff/I sent a css3-positioning diff to Rossen yesterday/ 09:57:22 dbaron: You need to know the height of the header. 09:57:55 ChrisLilley: But 'em' may be be different depending on header, so 2em not always the same. 09:58:07 dbaron: People do sticky in JS a lot. 09:58:22 fantasai^: gives example of 3-level stacked sticky headers 09:58:45 dbaron: Don't do multi-level sticky so much 09:58:57 (JS emulations make jumpy heeaders) 09:59:39 hober: CSS define when a scrolling box happens, and I expect to see Overflow or Box. Sticky refers to nearest ancestor. 09:59:47 ... Even if not scrolling mechanism. 09:59:58 ... Closest content defined somewhere, bit not the right thing. 10:00:10 ... Should be definition of a scrolling box. 10:00:16 s/CSS define/CSS should define 10:00:24 liam: Some UAs have that behaviour for table headers, right? 10:00:34 hober: Tbale headers a bit different. 10:01:00 ... But can apply sticky to table rows, obviously. 10:01:16 s/Tbale/Table/ 10:01:34 ChrisLilley: Is the link from dbaron the same text as hober referred to? 10:01:40 dbaron: no different. 10:02:05 Rossen_: I will work on it. 10:02:16 ChrisLilley: So this is notes rather than spec text? 10:02:37 dbaron: Not as formal as spec text, but good attempt by college student with no prior experience. 10:03:13 ACTION: Rossen to get text about sticky into Position spec. 10:03:13 Created ACTION-579 - Get text about sticky into position spec. [on Rossen Atanassov - due 2013-09-19]. 10:03:34 dbaron: Cory's last day as intern is tomorrow... 10:03:54 RESOLVED: Add Rossen as editor to Position module. 10:04:51 s/Cory/Corey/ 10:05:25 and the thread on sticky from July started with http://www.w3.org/mid/51E030E2.4020608@mozilla.com 10:05:29 (Agenda discussion, but nothing can be done in 10 minutes, it seems.) 10:06:01 Topic: text-combine naming 10:06:12 fantasai: The name isnot super-obvious 10:06:21 fantasai: text-combine-horizontal doesn't seem like a very obvious name 10:06:49 ... glyph-orientation-horizontal applis only in hor., but text-combine only applis in vertical. 10:07:14 SteveZ: 'horizontal-in-vertical' is theobvious name. 10:07:33 Rossen_: mumble mmble 10:07:45 ... One of the proposed names in Tucson 10:08:06 ... but was way too generic 10:08:20 ... Only applies to tatechuyoko 10:08:51 fantasai: text-combine-upright? 10:08:53 ... We also expored 'tatechuyoko' 10:09:20 fantasai: with "upright"? John said we should clrify that the text was upright. 10:10:18 fantasai: EPUB uses 'text-combine' 10:10:48 ChrisLilley: How about ?? 10:10:57 fantasai: It's not about a specif number of characters 10:11:17 Rossen_: 'all' could be any number. 10:11:27 shans__ has joined #css 10:11:31 SteveZ: digits and all do two different things. 10:11:45 ChrisLilley: ASCII digits only it says? 10:12:16 fantasai: There was discssion with John about fullwidth feature in Fonts. 10:12:33 [Lunch] 10:20:22 jet has joined #css 10:30:58 astearns has joined #css 10:35:32 astearns has joined #css 10:46:15 darobin has joined #css 11:02:36 TabAtkins, I'm getting fatal errors when trying to regen writing modes. It's kindof a blocker? 11:06:09 er, thinks 11:07:02 dbaron, is this the one? http://store.xkcd.com/products/i-know-regular-expressions 11:07:13 yes 11:08:44 glazou has joined #css 11:12:07 shans__ has joined #css 11:20:06 curvedmark has joined #css 11:23:09 http://w3cmemes.tumblr.com/post/61012799999/berts-having-a-bit-of-trouble-scribing-rossen 11:26:02 shans___ has joined #css 11:30:07 leif has joined #css 11:31:59 ScribeNick: TabAtkins 11:32:06 Topic: GCPM 11:32:25 howcome: Yesterday's Napoleon rule still applies today. 11:32:31 howcome: We have a WD from 2011. 11:32:36 howcome: It shoudl probably be updated. 11:32:41 howcome: Lots of thigns have happend to the ED. 11:32:52 howcome: Main focus was to document and track impls. 11:33:18 howcome: This is a chart that lists the features/main sections in the draft, then the implementations, tests, and example rendering. 11:33:48 http://people.opera.com/howcome/2013/tests/css-gcpm/coverage.html 11:34:13 howcome: Two main impls are AH and Prince. 11:34:23 howcome: They're in the process of changing the way books are published. 11:34:46 howcome: 2 of the 4 top new york times bestsellers are published with Prince, and Lea is writing a book now in Prince. 11:34:55 howcome: It's possible to write a book in those formatters today, but it's hard. 11:35:05 s/Lea is writing a book now in Prince./Lea is writing a book now in AntennaHouse./ 11:35:35 howcome: A lot of work went in to make sure the two do things the same way. 11:35:49 howcome: The differences between them has been the main focus of gcpm edits. 11:36:44 howcome: So this spec is a little different from other specs. 11:37:00 howcome: Applying the normal rules to this spec could lead it to being kicked out of the gruop, which I hope doesn't happen. 11:37:19 ChrisLilley: Do you expect the unarchived discussion to continue, or transition to a more public forum? 11:37:30 howcome: There's some healthy discussion on www-style now. 11:37:37 ChrisLilley has joined #css 11:37:40 howcome: But my communication with the vendors is private email. 11:37:53 howcome: I have no problem publishing that, but it seems like I get better responses when I talk to them privately. 11:38:04 howcome: Documentation is usually sparse, but asking them tends to work. 11:38:09 ChrisLilley: Do they consider the info private? 11:38:16 howcome: Not to my understanding. 11:38:41 ChrisLilley: Proper WG discussion happens in an archived forum. How can we encourage this, so people other than those impls can contribute their pov? 11:40:07 plinss: I'm concerned about patent policy when technical info is coming from outside the consortium. 11:40:12 peterl: They're also not members of the WG and thus not under the patent policy. 11:41:03 where do these external panent grants go? 11:41:06 howcome: I believe Prince has signed *something*, which might be a patent policy thing. 11:41:14 s/panent/patent/ 11:42:12 glazou: The fact that Hakon serves as a proxy for AH and Prince slows down the comm. process. We don't have direct access to the implementors, and can't discuss given technical points. 11:42:50 liam: We had AH in the xsl-fo group, but their implementors were japanese and didn't speak or write English (or at least not well), so we rarely ever got feedback from them. 11:43:03 liam: When we closed the group, we found out they'd implemented most of the draft. 11:43:09 darobin has joined #css 11:43:23 liam: So while I'd like to have a venue for them to participate, I recognize that in the past this has been a practical difficulty for them. 11:43:39 kawabata has joined #css 11:43:40 howcome: And they have a fantastic impl. I think documenting and getting it out will make the world a better place. 11:44:16 howcome: If you go back to the table, the msot complex part of the spec is page flaots. 11:44:21 howcome: And the bottom of the table is page floats. 11:44:40 howcome: I'd say the focus in this should be to make these impls converge. 11:44:47 howcome: I'd like to have a good forum for that. 11:45:16 howcome: So my goal is to get another WD out. 11:45:31 TabAtkins: Never say no to a WD. 11:45:47 fantasai: I think one of the problems is that the discussion isn't archived. 11:46:07 fantasai: So somebody else coming up with the same discussion can't see it. 11:46:26 fantasai: Maybe www-style is intimidating, too high traffic. Would it help to have a separate list just for this? 11:46:27 Rossen_ has joined #css 11:46:59 howcome: Maybe. 11:47:13 steve, israel and I are stuck downstairs again :/ 11:47:41 krit: If AH and Prince could give public feedback for this implementation table, that would be great. 11:47:53 glazou: We've always had trouble with communication based on language. 11:47:58 glazou: It's not going to change easily. 11:48:06 glazou: Problem is documenting features that you have little input on. 11:48:51 glazou: If I take some sections of GCPM, like page floats, misses a lot of layout details. Some examples, but not enough detail. 11:49:07 glazou: How does it interacct with other layout features, etc. Too light as a spec. 11:49:19 howcome: I don't disagree. Part of the reason is that we dont' know what those rules should be. 11:49:30 howcome: And I've had experience that the rules aren't actually followed. 11:49:52 howcome: AH/Prince implement based on customer requests, and then try to align it with the spec, but it's not really their first concern. 11:50:06 plinss: But the spec isn't really describing what impls are doing. 11:50:18 plinss: "Put it at the top of a column", for example, still doesn't let me know what it's doing. 11:50:42 darobin has joined #css 11:50:55 israelh has joined #CSS 11:50:59 liam: AH had a poster at the balisage conference, listing approx 200 custom CSS properties they've added. 11:51:07 liam: That's like 50% more, quite a bit. 11:51:27 liam: Some are rather ad-hoc, because they came direct from a customer request. Proper design would probably end up with fewer. 11:51:40 -> http://antennahouse.com/CSSInfo/property.html AH property list 11:51:47 liam: Second, we have now at W3C a publishing interest group, where a number of major publishers have come to discuss their requirements. 11:52:10 Rossen_ has joined #css 11:52:14 liam: Their problem si that the CSSWG is too technical for most of them, but it might be that that's a good place to take some of this work, and discuss with them how it meets their reqs. 11:52:21 liam: I wonder if that might be a more productive way forward. 11:52:35 liam: Work with those people, and then come back to CSS having established something with both publishers and implementors. 11:52:47 howcome: I can't say there's anything wrong with your proposal. 11:52:49 jdaggett has joined #css 11:53:05 howcome: I'm just worried about giving people false expectations here. Listen to them, put it in the spec, and then nothing happens. 11:53:29 ChrisLilley: Precedent - the JLTF reviewed stuff, produced a req document, but then the relevant groups did nothing with that document. 11:53:33 jet has joined #css 11:53:53 SteveZ has joined #css 11:54:00 glazou: O'Reilly isn't going to just change their engine if we come up with a compromise that is different form their impl. 11:54:01 koji has joined #css 11:54:11 glazou: This is a big issue - you're forced to spec what they've done even if it's suboptimal. 11:54:11 s/did nothing with/decided how to implement thos requirements based on/ 11:54:25 glazou: Even if we have a much better idea how to integrate it with CSS. 11:54:36 glazou: So standardizing what the impls do is okay when what they do is good. 11:54:49 glazou: I've carefully looked at Prince/AH additions, and some are really hacky. 11:55:34 Rossen_: So is the point of documenting this just to validate their properties, or is it to try and work with us to come up with a solution, even if things change? 11:55:40 howcome: I think it's something between there. 11:56:05 howcome: But they're going outside of where CSS has gone before, and coming up with solutions that I think fit within the CSS space. 11:56:20 howcome: AH and Prince are different, but not *that* different. We can gently move to a common foundation. 11:56:46 plinss: I think the win comes when we get these features in CSS that everyone implements in browsers, etc. 11:56:59 plinss: If all we're doing is documenting how they've shoehorned something into their impl, that won't help the web at large. 11:57:12 howcome: Absolutely. And speaking as a browser vendor, I'm interested in this too. 11:57:39 howcome: The things that haven't been implemented with AH/Prince (blank spaces in the table) came out of discussion with Opera and Blink. 11:57:58 plinss: I'm not sure there shoudl be an exercise in trackign impls, but rather in designing these features. 11:59:06 plinss: These features aren't being designed as part of the platform. The fact that you have two implementations in Opera isn't enough, because I htink you said it's the same person. 11:59:25 plinss: What we're missing here is specification prose that allows different people to read the spec and come up with impls that are compatible. 11:59:44 plinss: If we can't get that, these shouldnt' be in the spec as features, but just as ideas of things that we might like. 11:59:59 +1 12:00:29 astearns: And the point of doing this in the group is to get other implementors interested, so one day O'Reilly doesn't have to be stuck with AH, they can get their books rendering in browsers, or any other place. 12:00:45 ChrisLilley: That was one of the failures of XSL-FO - every feature was optional, so it was very hard to get interoperable. 12:01:00 [not every feature, of course] 12:01:23 howcome: But until browsers do real paged projections, there's no reason for browsers to read this. 12:01:39 my point was that many stylesheets were aimed at, and only usable on, a single processor 12:01:39 glazou: Not true. Some things, like string-set, are useful regardless of printing, and can happen at any time. 12:02:07 plinss: In Hamburg a year ago, we had every browser around the table to agree to make printing a priority. 12:02:08 plh has joined #css 12:02:25 [agree with the point, yes] 12:02:27 plinss: I think having some of this discussion not taking place in this group is part ofthe problem. 12:02:47 howcome: The resource constraint is implementors. 12:02:59 plinss: And you have companies like Adobe here, which work in multiple engines. 12:03:11 astearns: We haven't seen the right solutions yet. 12:03:21 howcome: I disagree - this spec has enough detail. 12:03:26 glazou: I disagree. 12:03:47 glazou: I read the spec in deep details. A name of a value and a one-line description doesn't give you info about the feature. 12:04:36 krit: You were concerned about the platform in general. 12:04:46 krit: Our WG in particular is about the we bplatform. 12:05:05 krit: The book people may be interested in some of the web platform, but extending to fill all of their needs may not be necessary for the web. 12:05:24 krit: Our WG is quite sensitive about defining properties not defined in the CSSWG. 12:05:28 krit: So what do we do? 12:06:04 glazou: So, two options. These people are extending CSS. These people can use vendor prefixes, and claim you are "CSS-like" forever. We can't do anything. Or two, do what Hakon does, and try to build something standardized and get everyone to implement. 12:06:14 glazou: And if it's in this WG, it has to obey the rules of spec production. 12:06:28 glazou: And that's an issue - we can't discuss with them. Thus, the feature descriptions are extremely light. 12:06:55 glazou: I agree that some of these features *work*. I think I would have designed things different myself, but this is the start of a compromise that never happened. 12:07:17 glenn: I think Dirk's point was a good one - where does work occur on future specs that this group doesn't focus on? 12:07:37 glenn: Maybe for a long time this group has been focused on the web platform, but there are other applications where the web is not where they live. 12:07:51 glenn: I don't think we should make a decision today that this isn't appropriate to work on. 12:08:02 glazou: It's not just about the web. epub has been interacting for a long time. 12:08:12 glazou: And ebooks are not the web platform. Still very static. 12:08:24 glazou: Very specific requirements that differ from the browser world. 12:08:37 glazou: HTML is used on TV, will be used on cameras, etc. everywhere. 12:08:54 plinss: "web platform" doesn't necessary mean "what you see in the browser". 12:09:08 ChrisLilley: You could shrink down the "web platform", or you could extend it out. 12:09:14 ChrisLilley: Advantages to both. 12:09:33 szilles: It seems the problem si not the size or th escope, but getting eyes on the doc that are interested. 12:09:49 szilles: Part of what I'm hearing is that hakon putting it in the spec doesn't generate views and doesn't generate impls. 12:10:12 szilles: This is the hardest part. It's easy to get a proposal, it's hard to get people to look at it. 12:10:29 szilles: In part, the lack of participation by AH/Prince is making that process more difficult in this case. 12:10:42 szilles: That's not a comment on the validity of it, just that you need to market and sell something to get the uptake. 12:10:52 howcome: I've been trying - I've been putting substantial efforts into this. 12:11:14 howcome: The participation problem is that in a couple cases, the WG has decided to remove functionality that is essential for those implementors. 12:11:32 glazou: This WG works on consensus - we agreed to remove two things, and you didn't comply. 12:11:54 glazou: For example, Regions and Exclusions we're chartered to work on in two docs. Anything about those should be in those documents, not in GCPM. 12:12:05 howcome: They're there because I think the current specs lack some functionality. 12:12:56 plinss: You're saying this is a scratch space, but you're also asking to publish as a WD. 12:13:07 plinss: Scratch space is one thing, publishing a WD is saying it's the work of the CSSWG. 12:13:20 howcome: I'm happy to move those sections somewhere else - a note, for example. 12:13:30 ChrisLilley: I noticed that those sections dont' figure in the impl table. 12:13:40 ChrisLilley: I assumed that meant you wanted to publish only the things in the table. 12:13:48 ChrisLilley: And meant to remove the other things. 12:14:00 howcome: No, they're lacking just because they don't have implementations. 12:14:07 dbaron: I disagree strongly with what daniel said. 12:14:21 dbaron: About regions/exclusions being chartered, and so all related work is in those documents. 12:14:50 dbaron: Particularly since there have been many objections, and the actions of the editors has been to repeatedly ask to remove the issues without addressing the udnerlying issue. 12:15:01 dbaron: And second, I want to *agree* with what daniel said. 12:15:11 dbaron: We should be able to have multiple proposals for a tech. 12:15:28 dbaron: To respond to hakon, the comment of "oh, this is just an ED" is part of what prevents this spec from advancing. 12:15:52 dbaron: You keep adding to it and changing what is in it, such that we don't really know what it is, or what any plan for it in the future would mean. 12:16:12 glazou: I said both that we were chartered, and decided to remove the two sections from gcpm. 12:16:13 that would be helpful, to see exactly what you plan to publish 12:16:25 dbaron: I dont' remember this, and probably would have objected. 12:16:38 glazou: You've made a lot of edits in the last year to the draft, hakon, that we haven't seen. 12:17:03 glazou: You've posted only a few small details, almost too late to comment on. 12:17:19 glazou: I think the ED is a living spec for whatever AH and Prince are doing, and that's not the standardization process is for. 12:17:30 howcome: If you don't care, you should kick it out. 12:17:43 plinss: It's not that we dont' care. It's that they're not trying to make this tech part of the open web platform. 12:17:54 ChrisLilley: You said you had a presentation about what you want to publish? 12:18:01 ChrisLilley: I think that might help. 12:18:31 dbaron: IN repsonse to Peter, I think the level of precision and detail needed to move forward with features like this in browsers, is much higher than what's in the spec. 12:18:42 dbaron: I think there's a relation to that and the lack of interop between Prince and AH. 12:19:13 dbaron: I think that one of the steps to actually getting this implemented is (1) there's a bunch of existing paged media stuff we haven't implemente dyet, and some of it's actually pretty hard and not well-specified. 12:19:43 dbaron: To build more features on top of that... the bigger the pile of features is, the scarier it looks, especially when those features aren't very clearly defined and explained in terms of how they work and interact with other features. 12:20:12 dbaron: One of the things that's often lacking in this spec is a description of an underlying model that makes it clear, not just how the feature works in simple cases, but how it works in interaction with everything else. 12:20:27 ChrisLilley: Relevant to the web paltform, I think Paged Media has been more about things that aren't document-like. 12:21:14 ChrisLilley: So naturally, Paged Media seems more appropriate - it if was sold properly, about there being lnots of useful things where "paged" presentation was an ideal fit, I think it would be better. 12:21:27 howcome: I wish I could agree, but even simple things like page numbering haven't been taken up. 12:21:48 s/like/like, such as webapps 12:21:58 glazou: What david said about models, though - for example, the 16 margin boxes are complicated, and go against the print options exposed by browsers. So we have a lot of things to expose. 12:22:04 s/expose/talk about/ 12:22:37 howcome: The problem is getting layout people to actually work on it. Of course the spec shoudl always be better, but I don't think that's the stopping point. 12:22:48 howcome: Simon, what's your understanding? Is the lack of specificity the problem? 12:23:13 SimonSapin: I think in the last few years, there were a lot of problems that were basically impossible to implement, like the layout of margin boxes. fantasai and I worked to fix that, so I think it's better now. 12:24:15 glazou: Even though the model requires some deep changes, it's not really juste the single feature, but how it works with everything else in CSS. 12:24:28 glazou: page-float: bottom? What if I put something else inside - another flow, or a grid? 12:25:06 howcome: You could argue that since float:bottom has been there for 10 years, it's Grid that should have specified things. 12:25:13 ChrisLilley has joined #css 12:25:39 howcome: I don't think it's the quality of the spec that's stopping this, it was the implementor interest, or else they'd have done simple things like page numbers. 12:25:51 howcome: A lot of the spec has been pruned. 12:26:15 howcome: Useful things we liked, like aligning leaders, have been removed for lack of impl. 12:26:41 howcome: The regions and exclusions stuff has been put at the end. I want to move them, but not remove them - I think they're useful to provide alternate ideas for how to implement them. 12:26:48 glazou: To move the document along the rec track... 12:26:52 in my "it's better now" earlier, "it" is css-page, not GCPM 12:27:17 glazou: This document has been on the table so long, everyone who would like to see it published asap is gone. 12:27:35 glazou: You'll have to do some major cleanup - put things into another level if you want. 12:27:38 glazou: I listed a few actions. 12:27:51 glazou: 1) if a property isn't already interoperable for two impls, remove from this version. 12:28:03 glazou: 2) a property that is implemented by two, but not interoperably, retain but mark at-risk. 12:28:16 glazou: 3) sections that conflict with other specs, remove and put elsewhere. 12:28:30 glazou: Like color module for cmyk(). 12:28:37 glazou: 4) test suite has to be started. 12:28:48 glazou: If you want this to progress, it nees to progress with Rec in mind in the next 6 months. 12:28:58 s/cmyk/device-cmyk/ 12:29:10 plinss: With regards to the testsuite, this isn't something yet that I can bring up in a transition request. 12:29:26 plinss: You're only asking for WD now, but you have to keep in mind what will be needed in the future. 12:29:37 plinss: Are the tests in our format, in our repo? 12:29:58 howcome: No. But these tests are useful for me. 12:30:14 plinss: Right there, you're describing the disconnect. You ahve tests useful to you, we need tests useful for the WG. 12:30:33 plinss: If this is going to continue being published by the WG, it needs to be a product of the WG, working together with the WG. 12:30:52 plinss: Is it a fair requirement to make this document in accordance with the WG's policies? 12:31:07 plinss: You're currently producing this document in isolation by yourself. 12:31:19 howcome: No, I'm doing it in greater concert with implementors than ever before. 12:31:43 plinss: You're not doing it with concert with anyone in this WG. 12:31:59 howcome: And if Daniel says that anything needs two impls to get in a WD... 12:32:15 glazou: Not for general specs. This is a special case. This spec has been around for *so long*. 12:32:26 glazou: I want these features in a Rec as soon as possible. I'm not the only one. 12:32:39 glazou: To reach Rec asap, we have to take what can be a Rec now, and the rest can wait. 12:33:06 Bert: I think we've heard a number fo speculations about why this hasn't been dsicussed, but I don't think we need to talk about that. 12:33:10 Bert: How *can* we get this discussed? 12:33:35 glazou: Have Hakon more on our calls. Last time was like a year ago. 12:33:47 glazou: When you're on the conf call, you can request things. 12:33:52 Bert: It's not on the agenda. 12:34:14 plinss: First thing Daniel has always said, after getting a scribe, is to ask for additional agenda items. 12:34:34 plinss: Hamburg you definitely got time. I remember a previous meeting where you asked for time and didn't get it. 12:35:16 ChrisLilley: I heard comments about the test format. Hakon said he has tests, and is willing to put them in whatever format we want. I don't think that got minuted. I think that's a good point. 12:35:24 howcome: Absolutely. 12:35:47 [let's do the timewarp again] 12:36:42 fantasai: So what's the plan here? 12:36:54 howcome: I plan to try and publish a WD, and continue to get interest. 12:37:03 fantasai: Can we get those plans minuted? 12:38:03 szilles: Exclusions offers an example of how to go faster and further - it was thought to be too broad at first. In several successive revisions, it's been cut down to the point where people *do* agree on the scope, and people are now working on implementations now that it's at a reasonable size. 12:38:22 szilles: So I suggest that th efastest way to get this implemented is to cut it down, get it implemented, and then move on from there. 12:38:28 szilles: Paper-pile phenomenon. 12:38:56 szilles: So I suggest cutting out everything you dont' need *immediately*. And probably rename what's left to get out of the gcpm hole. 12:39:06 SimonSapin: Have you heard interest from AH and Prince to converge? 12:39:13 SimonSapin: You said you wanted Prince and AH to converge. Have you heard interest from them in converging? 12:39:23 howcome: mumble mumble 12:40:25 SimonSapin: I implemented css 2.1 floats in weazyprint. It was *hard*. But because the spec has enough detail, I coudl do it based on the spec. 12:40:39 SimonSapin: Based on what I read in gcpm, the examples show what it does, but I have no idea how to implement it. 12:40:55 howcome: You're probably right. The two impls didn't go to the spec first. 12:41:02 howcome: Now I have to reverse-engineer. 12:41:20 glazou: If you agree, I can come up with a list of sections in your document that could go to rec in 6 months time. 12:42:04 glazou: So that tomorrow it can be a WD, a CR in 3 month, a Rec in 6. 12:42:06 SimonSapin: IMO the whole purpose of a spec is to allow new implementations based on it 12:42:16 glazou: And I think that's much better than arguing about process or whatever. 12:42:36 glazou: That way you'll have a minimal set of features standardized by this WG, under our process, that you can show to your vendors that can make them converge. 12:42:52 glazou: If you don't do that, I'm afraid we'll enter a WD/ED loop for 5 years. 12:43:03 Bert: How to get it discussed? 12:43:15 glazou: Be on the conf call. 12:43:24 howcome: I can't do that - the time is alway sbad. 12:43:40 plinss: Just request it. We're always willing to discuss,especially if someone else is willing to champion. 12:43:51 howcome: [discusses some sections that can be removed] 12:44:23 glazou: From my perspective, the only sections that are reasonable specified is 1,2,3, and maybe 4. Starting with 5, you have a one-liner of prose, and the rest is examples. 12:44:43 fantasai: I think 6 is straightforward too. 12:45:15 plinss: Pause. I think you're seeing this as a confrontation between you and the WG. 12:45:31 plinss: Please understand everyone at this table wants these features to advance. We're not trying to block. We're trying to get it *done*. 12:45:36 plinss: We're asking you to work with us to do it. 12:45:55 astearns: IN particular, speaking as the editor of Regions, I'd like to see your version advance as well as mine. 12:46:11 fantasai: The sections that Daniel calls out are the only ones that are actually generated content. 12:47:11 howcome: I think the overhead of going to Rec is significant. Splitting things up would make it too annoying to work with. 12:47:17 ChrisLilley has joined #css 12:47:30 jdaggett, sorry, important discussion that needed to happen 12:47:45 no worries 12:47:57 plinss: I'm sure that if this got broken up into smaller pieces, each piece could go to Rec in a year each. 12:48:26 howcome: I don't think I agree, or have the motivation to do that. 12:49:26 glazou: We never had a say in what these vendors implemented. 12:49:29 glazou: Vendors for the last 10 years have gone off and done things on their own, and not asked us. 12:49:48 Bert: I don't agree. They've asked. They may not like working in our mode, but they still asked. 12:51:35 Tab: The overhead for publishing rec's isn't great, but it's not that bad. 12:51:45 Tab: It's mainly ... . 12:52:02 glazou: Please list the sections you want to include. 12:52:16 (I actually disagree with tab, I think the delays in the publication process are *major* overhead because they require splitting tasks up by months when they're best done together.) 12:52:51 howcome: Everything from section 1 to 13. 12:53:00 tantek has joined #css 12:53:04 howcome: I feel it would be a betrayal of the implementors to do anything less. 12:53:25 ChrisL: I think 14 could go in selectors4. 12:54:57 liam: I think section 15 is just an idea, not a spec, even though I included it. 12:55:01 howcome: So now 1-15. 12:55:39 jet: Abstain 12:55:41 howcome: yes 12:55:44 Bert: yes 12:55:47 koji: abstain 12:56:29 leaverou: I want many of these features, but I also see how many of them are underspecified. 12:56:33 leaverou: I want more time. 12:56:36 glazou: No more time. 12:56:39 leaverou: Abstrain 12:56:44 jdaggett: Abstain 12:57:06 dbaron: I think no, but not sure. 12:57:08 Rossen_: No 12:57:11 krijnh: no 12:57:16 michou: abstain 12:57:20 israelh: abst 12:57:32 leif: no, but a smaller set I could say yes to 12:57:52 shane: no 12:58:21 TabAtkins: All options at once. 12:58:23 liam: Yes 12:58:28 Tab: Can't make a decision now because I'm minuting and can't look at the document. 12:58:52 kawabata: abstai 12:58:57 yamamoto: abstain 12:58:59 glenn: yes 12:59:05 fantasai: defer to dbaron 12:59:09 SimonSapin: With 15, no. 12:59:32 ChrisLilley: Yes, if 8, 14, and 15 are marked as "this will move to another document". 12:59:34 glazou: That's a no. 13:00:02 zcorpan: no 13:00:05 er 13:00:07 zcorpan: yes 13:00:09 zcorpan: yes 13:00:13 astearns: yes 13:00:19 plinss: absta 13:00:21 glazou: no 13:00:27 szilles: abstain 13:01:07 howcome: I think what we're voting about is whether this work will continue in w3c or not. 13:01:20 fantasai: I think that 1,2,3 seem to be straightforward. problaby need a bit of tightening. 13:01:24 fantasai: 4 is a bit underspecified. 13:01:33 fantasai: 5 is *vastly* unspecified. And these two interact with lyout. 13:01:38 fantasai: 6 should move to page dmedia. 13:01:42 fantasai: 7 seems okay 13:01:47 fantasai: 8 should move to color 13:01:54 fantasai: 9 is already in paged media (so remeoved from this spec) 13:02:07 fantasai: 10 is cool, but not generated content, and needs more specifying. 13:02:10 fantasai: 11, likewise. 13:02:12 q+ 13:02:20 fantasai: Those two I think are godo to explore, but not fleshed out. 13:02:34 fantasai: 12 needs more detail, but I really think it should be its own independentmodule. Floats level 5 or something. 13:02:36 israelh_ has joined #css 13:02:42 ChrisLilley has joined #css 13:03:01 fantasai: 13, I'm not sure where they should go, but probably part in multicol. Needs to be worked out a bit more. 13:03:20 fantasai: 14 makes sense. I dont' know where it should go. Interacts well with overflow module. We don't currently have a pseudo-elements module to put it into. 13:03:24 fantasai: 15 is not a spec. 13:03:47 howcome: I agree with all of this. But I'm just looking for a Working Draft. 13:04:15 fantasai: What I'd like to say is that for the things that need to move to another spec, we can take actions to move them. 13:04:22 ChrisLilley has joined #css 13:04:24 action tab to move device-cmyk() to colors 4. 13:04:24 Created ACTION-580 - Move device-cmyk() to colors 4. [on Tab Atkins Jr. - due 2013-09-19]. 13:04:36 action fantasai to move page marks and bleed area to css3 page 13:04:36 Created ACTION-581 - Move page marks and bleed area to css3 page [on Elika Etemad - due 2013-09-19]. 13:04:41 q+ SteveZ 13:04:59 fantasai: Can you split page floats into a separate module? 13:05:02 [note, the heartbeat requirement howcome mentioned is per WG, not per spec] 13:05:11 howcome: No, I don't think so right now. 13:05:34 Zakim, ack astearns 13:05:34 I see SteveZ on the speaker queue 13:05:44 q? 13:05:46 astearns: I voted to have a WD because I think this is the right direction to go - paring it down to have a better chance of ipmlementing. 13:05:56 astearns: To get the feedback that fantasai just gave. 13:06:16 astearns: I've had experience dealing with multiple documents over a monolithic one, and I find it *much* easier to deal with, and to get comments on. 13:06:31 astearns: Rather than ahving people walk away because it's too much reading. 13:07:07 q+ glenn 13:07:11 Q- 13:07:12 ack SteveZ 13:07:14 SteveZ: In some sense, Alan said what I wanted. 13:07:24 glazou: 9 no, 7 yes 13:07:29 SteveZ: I voted to give you a guiding function to actually do the decomposition. 13:07:48 SteveZ: My perception is that the WG has given you a lot of input to move more effectively, and you've said no. 13:07:54 my no was only because my yes with 3 sections marked with editorial notes was not accepted 13:08:43 glazou: 10 no, 7 yes 13:08:56 howcome: If it's so important to move page floats to a separate spec, I'll do it. 13:09:08 TabAtkins: With page flaots moved, and the other moves that fantasai suggested, I"ll do a yes. 13:09:27 SteveZ: Normally we operate by getting the docs first, then agreeing to publish, rather than publishing based on promise to produce docs. 13:09:50 howcome: I don't want to spend time splitting without consensus to publish. 13:10:29 SteveZ: I think you've heard consensus on the first six sections. 13:10:39 Zakim, ack glenn 13:10:40 I see no one on the speaker queue 13:10:49 glenn: The negative consequence of not publishing is not getting the early chance to get a clal for exclusions. 13:10:59 fantasai: This has already been WD, so we've gotten that. 13:11:32 glenn: I think WDs have a low bar, and don't think we should hold things up to much. 13:12:03 ChrisLilley: I heard several nos turning to yes with minor changes, so I'd like to see if we can find a straw poll that we can agree on. 13:12:35 howcome: So let's move out section 6 and 8, move 12 to a separate draft, and delete 15. 13:15:45 shans__ has joined #css 13:17:10 I think 11 belongs with 10, actually. 13:18:07 tantek: If your goal is to advance as fast as possible, you need to ship as little as possible. 13:18:38 I strongly agree with dbaron 13:20:00 proposal: publish sections 1-5, 7, 13 in a new working draft 13:21:47 Given the joking expansion of GCPM to "Garbage Collection Placeholder Module", it seems this is the working group's own mark-and-sweep. /ht hober 13:22:43 TabAtkins: we need to implement an incremental collector; this stop-the-world-and-run-a-full-gc stuff is too inefficient 13:23:24 We just need to increase memory sufficiently that we never run a GC. 13:23:34 I propose brain farms. 13:24:19 [by the way, non-minuted horse-trading discussion about what to publish] 13:26:14 Proposal: 13:26:23 1-5, 7, and 13 publish as GCPM WD. 13:26:50 Bert, we can keep the anchors in GCPM with "This has moved to …" 13:27:31 RESOLVED: Publish sections 1-5, 7, and 13 of GCPM ED as a new WD. 13:27:57 Proposal: 13:28:02 6 to CSS3 page 13:28:07 I think 14 should be in the pseudo-elements module instead. 13:28:07 8 to CSS color 13:28:09 9 to Page 13:28:16 10, 11, 14 to Overflow. 13:28:22 12 to Page Floats (new spec) 13:28:35 14 to Overflow (for now, Pseudo-Elements when we write it) 13:28:38 15 removed 13:28:42 ChrisLilley has joined #css 13:28:43 16 and 17 to Page Floats 13:29:41 RESOLVED: Accept the above publishing plan for distributing the rest of GCPM ED. 13:29:47
13:30:25 jdaggett, how was the audio during that discussion? 13:30:55 howcome was fine, i heard daniel when he was angry :P 13:31:11 so pretty much i heard everything... 13:31:25 :D 13:41:36 ChrisLilley has joined #css 13:41:48 astearns has joined #css 13:42:09 dbaron: am i making funny faces? tracking down a crasher... 13:42:16 ChrisLilley has joined #css 13:42:20 jdaggett, not particularly 13:50:06 Agenda Request: Go through my Colors spec and get a definite yay/nay on all the features for moving to the ED. 13:55:29 TabAtkins, +1 13:56:40 TabAtkins: You'll have to add device-cmyk() to that list now ;0 13:59:44 astearns has joined #css 14:00:14 TabAtkins, wouldn’t that we the third time we’re doing this, though? 14:01:35 astearns: hey, i figured out how to reproduce a crasher without using windows, i'm a happy camper... ;) 14:02:16 interesting listening to håkon talking about trolls... 14:02:18 you still have to test your fix on Windows 14:02:35 :P 14:03:03 no need to test, i will work perfectly 14:03:13 no bugs, no, no, no bugs... 14:03:18 leif has joined #css 14:03:27 SimonSapin: Last time it was just a surprising "Yeah, let's publish". I know that dbaron had objections, but don't recall if he was even on the call. 14:03:41 I just want to make sure there's no landmines that'll show up in the future. 14:05:22 we could split it into one doc for each color... 14:05:49 I don't want to publish 2^24 working drafts. 14:06:19 http://dev.w3.org/csswg/css-writing-modes/ 14:06:22 Topic: CSS Writing Modes 14:07:24 fantasai: Issue from jdaggett about text-combine-horizontal taking digits only in the range 2-4 rather than 1-4 14:07:34 jdaggett: 'digits 1' value doesn't have much meaning 14:07:57 jdaggett: so it means single digits will be upright, but not what the property is about 14:08:17 Rossen: ... 14:08:31 fantasai: key point is that it's rendering it upright 14:08:44 SimonSapin: not very useful, but well defined and not really problematic 14:09:00 fantasai: rossen, implementation? 14:09:12 Rossen: Yes, And I believe I've seen content that depends on it. 14:09:30 Rossen: ... expecting automatic tate-chuu-yoku will hit because it's falling into that range. 14:09:54 yamamoto has joined #CSS 14:10:09 dbaron: Issue is that t-c-h says if you have 14:10:21 1 0 2 年1月 14:10:42 you combine it into [102]年[1]月 14:11:04 or [102]年[11]月 14:11:15 dbaron: If you're saying combine at most 1 digit, you're not doing any combining. 14:11:37 SteveZ: Suppose I have Latin text, and I want digits upright 14:11:59 fantasai: That wouldn't work, because if you have a sequence of more than one consecutive digit, those digits won't be upright 14:12:25 jdaggett: If an author wants digits upright, they should use text-orientation: upright 14:12:51 jdaggett: yes, it does something in making things upright, but a side effect rather than combining 14:14:29 jdaggett: If somebody thinks it's valuable, they should come up with an example and post to list. 14:14:45 Rossen: is what fantasai wrote on IRC enough? 14:14:46 koji has joined #css 14:15:08 fantasai: no. You've seen cases with a single digit upright. If you're having single digits be upright you're usually also going to have pairs of digits be upright, and then you'd want digits 2. 14:15:19 fantasai: not a case we've known people doing 14:15:37 fantasai: can't think why people would want single digits upright but pairs sideways 14:15:50 fantasai: The number is maximum number in sequence that you'd turn upright. 14:16:08 jdaggett: Rossen, you want time? 14:16:14 tantek has joined #css 14:16:14 Rossen: Yes, I'll take some time and get back to you. 14:16:31 fantasai: related issue: we have text about fullwidth numbers that you said when we apply TCY to it it should convert out to ascii 14:16:42 fantasai: did you want digits to also include fulliwdth digits, or just ascii digits? 14:16:45 jdaggett: ascii digits 14:17:01 glenn: There's ... combinations of digits. Does that include fullwidth digits? 14:17:02 fantasai: no 14:17:16 fantasai: The only way you'd get fullwidth digits in TCY is if you specified the 'all' value. 14:17:56 jdaggett: What's in the spec... is the status of linking the text-orientation to UTR50. 14:18:04 fantasai: just need to update reference, everything else as it should be 14:18:16 jdaggett: dfn of text-orientation should be copacetic currently? 14:18:21 fantasai: [reads] 14:18:30 koji: we removed tx values 14:18:34 fantasai: we'll update that 14:18:42 ACTION koji update that 14:18:42 Created ACTION-582 - Update that [on Koji Ishii - due 2013-09-19]. 14:18:58 jdaggett: ... 20 ... example updated? 14:19:06 fantasai: I didn't see what you meant by the example being incorrect? 14:19:18 jdaggett: using width variants a normative requirement ... ? ... 14:19:38 fantasai: only required to use partial width characters if composition doesn't otherwise fit. 14:20:00 fantasai: say I have "'9". I can just put that without requiring turning on halfwidth glyphs. 14:20:05 jdaggett: there's no font that's like that 14:20:12 jdaggett: the minimum width is typically half the width 14:20:28 jdaggett: typically digits in japanese fonts are fixed width, not proportional. example just doesn't make sense. 14:20:40 fantasai: if the text fits without need for compression within 1em, the ua is not required to do any compression 14:20:59 fantasai: the implementation is allowed to check if it needs to use compression and then if it needs to use halfwidth glyphs 14:21:16 jdaggett: in the known universe of japanese fonts either you're going to have to do compression or the font by default has halfwidth glyphs 14:21:26 fantasai: ".9" will often fit without using halfwidth forms 14:21:36 jdaggett: that's only in the context of the all value, not in the context of digits 14:21:43 fantasai: compression algorithm not specific to digits 14:21:54 jdaggett: the cases you're talking about only in the all case 14:22:09 fantasai: ... 14:22:15 jdaggett: I'll look at it again and we'll discuss on the list. 14:22:33 fantasai: So we have one issue out on action from Rossen. 14:22:42 ACTION Rossen check if it's ok to drop support for text-combine-horizontal: digits 1 14:22:43 Created ACTION-583 - Check if it's ok to drop support for text-combine-horizontal: digits 1 [on Rossen Atanassov - due 2013-09-19]. 14:22:53 s/update that/update references to UTR50/ 14:23:01 jdaggett: what are we doing about inheritance of text-combine-horizontal 14:23:06 fantasai: we don't have a solution for it 14:23:18 fantasai: dbaron's proposed solution is that 'all' only takes effect if parent isn't all 14:23:45 fantasai: koji had some content with text with t-c-y all containing inside of it a span containing all of the text inside, expecting all the text combined. But this wouldn't be combined due to element boundary. 14:24:04 koji: what do you think about allowing elements within text-combine-horizontal 14:24:12 fantasai: what to do about inline-block with table and some images? 14:24:40 koji: tables not realistic, but are realistic html use cases 14:24:48 koji: allowing elements would be good 14:25:08 SteveZ: example of CO2 in a newspaper 14:25:11 (with subscript) 14:25:24 CO2 14:25:51 SteveZ: argument for allowing markup inside TCY 14:26:06 unless you use the opentype features so get a subscript 2, or use the unicode subscript 2 14:26:32 dbaron: non-replaced inline elements only? 14:26:52 SteveZ: plenty of examples in Japan with things with a trademark symbol of some kind embedded; not so likely inside TCY but possible 14:27:01 SteveZ: many signs that begin with a mark 14:27:20 koji: still inline, though 14:27:25 SteveZ: but an image, so replaced 14:28:06 dbaron: Not clear to me, if you're having variant font sizes between things that are supposed to go in TCY, what are you supposed to do to the different font sizes? 14:28:18 shans__ has joined #css 14:28:27 glenn: Similar problem in Arabic with eye-of-alla 14:28:42 glenn: A number of OpenType fonts substitute different sizes of digits to form groups that can fit into this 14:28:49 glenn: Maybe something that's dealt with in font itself 14:29:10 glenn: Looks for enclosing circle followed by N digits, and has entries for 1, 2, or 3 digits 14:29:23 glenn: so font itself might want to select digit variants 14:29:32 dbaron: I feel like we should not try to add complexity to this document right now 14:30:02 jdaggett: Examples koji brings up are relevant, but want to make sure it works without worrying about complicated cases. 14:30:21 SteveZ: Ok with that provided that the way in which we limit it would allow us to extend what's allowed in that in the future 14:31:09 SteveZ: I'm ok if the limitation on content of 縦中横 area is something we could relax in a future draft, and a note saying it would be nice to allow markup inside 縦中横 if we can figure out how to do that. 14:31:18 jdaggett: sounds fine to me 14:31:38 koji: I'm not strongly arguing allowing elements, but want to preserve what's working today. 14:31:47 koji: what's the downside of making this inherit? 14:31:56 koji: I'm happy of making this inherit and keep existing behavior. 14:32:04 fantasai: You get some very interesting behavior 14:32:30 dbaron: I think downside of having inherit makes it nearly impossible to extend to allowing markup in future 14:32:50 koji: but text-combine-horizontal only works in vertical context, and inside is horizontal context 14:32:58 tcy 14:33:31 fantasai: author expectation is that above markup should work 14:33:31 abc 14:33:35 a 14:33:37 [bc] 14:33:37 fantasai: but if insted something like above 14:33:47 fantasai: then I get a followed by [bc] as a unit, which is not expected behavior 14:34:13 koji: but if you rotate bc by not inheriting, it's still not expected 14:34:37 fantasai: if we do the case where pretend we're not an inheriting property, then [bc] will just be sideways and none of it will be upright 14:34:53 SteveZ: could we define the 縦中横 piece to behave like underline does? 14:35:04 SteveZ: so if it's turned on it's turned on for the entire span that it's on? 14:35:15 fantasai: the digits value needs to be inherited but the all value ideally should be inherited 14:35:23 ChrisL: sounds like you need two properties 14:35:35 fantasai: one property was that text-combine-horizontal a shorthand for 2 longhands that authors wouldn't use 14:35:42 s/property/proposal/ 14:36:01 ChrisL: what's the downside other than being 2 properties? 14:36:06 fantasai: it's 2 properties 14:36:12 ChrisL: then just do it 14:36:22 koji: it broke my case, right? 14:36:27 fantasai: yes, your case is still broken 14:36:50 dbaron: not any better than the other solution? 14:37:12 SteveZ: then outer one can behave like underlinne. Once you turn it on, inner levels don't add any more 縦中横. ... 14:37:16 koji: allowing elements inside? 14:37:20 SteveZ: yes. 14:37:25 koji: that's what dbaron doesn't like 14:37:37 SteveZ: once you turn on underline it applies to everything inside 14:37:47 SteveZ: if you define all to behave that way then make it inherit and it doesn't hurt 14:38:23 fantasai: david had suggestion that doesn't have separate properties. Look if your parent has 'all', then you pretend like you're none. And you just have the one property, and we could split later without breakin content. 14:38:38 fantasai: that solves the problem of what's establishing the 縦中横, but still have the problem of inline elements inside it. 14:38:56 ChrisL: the thing about "if your parent has this than do that" sounds like a UA rule using a selector 14:39:02 fantasai: can't select against properties 14:39:19 koji: if the solution is this complex then the only downside of keeping inherit is abc 14:39:29 koji: I don't think anyone would author abc 14:39:52 dbaron: If that's not a problem, then I'm not convinced why the other thing is a problem 14:40:11 fantasai: has to work because of content 14:40:19 koji: probably some converter generates that 14:40:26 koji: Some converter puts directly inside TCY span 14:41:35 dbaron: what if the rule disallowing inlines is changed to say that all the text has to be in the same element parent, but can allow inlines 14:41:46 fantasai: or could allow display:inline 14:42:05 SteveZ: I think dbaron's solution is fairly reasonable, solves koji's problem 14:42:39 Bert: somebody sees it, draws conclusion from that, and then finds it doesn't work anymore 14:42:44 Bert: the spec explains it, but... 14:43:03 [Bert gave example of multiple nested spans with all content, vs trying to make one char blue one char green] 14:43:16 dbaron: If we want to get a spec out the door, we sometimes need to solve a problem with a not very nice solution. 14:43:24 jdaggett: and keep in mind we're talking about 2-4 character spans 14:43:36 SteveZ: I just sent an email to the list with an 8 character span in a 縦中横. 14:43:47 Israel: Does the solution allow for H2O case? 14:43:50 Steve: no 14:44:24 Rossen_ has joined #css 14:44:26 fantasai: one thing we could do, maybe not ??? idea, if you have any kind of inline boundaries you still do TCY, but UA allowed to do graphical scale and not do anything smart. 14:44:38 fantasai: Then generator generating markup in Koji's case would not get pretty results, but would still work. 14:44:50 fantasai: Hopefully relatively straightfroward? 14:45:07 fantasai: Rossen, thoughts? you're an implementor. 14:45:12 Rossen: I'm pretty sure we inherit digits. 14:45:29 Rossen: and I believe we don't inherit 'all' so we have conditional logic based on the value 14:45:39 Rossen: not awesome ,but solves current problem 14:45:54 SteveZ: I like David's solution, all inherited but if you have parent that has all you ignore it. 14:46:11 Rossen: so you get correct layout but the property from OM is still inherited 14:46:26 SteveZ: the computed value in that case is none then it's effectively none 14:46:30 dbaron: computed value still all 14:46:40 Rossen: In our case we did by ... 14:46:57 SteveZ: I think either way is the right answer; the result seems to be the same. 14:47:06 SteveZ: basically saying nested alls don't have any effect. 14:47:13 SteveZ: just different ways of saying that 14:47:22 SteveZ: don't want to rotate internal one again 14:47:46 koji: won't combine again, having no effect is just fine 14:48:25 dbaron: My proposal was that you slightly relax restriction on not having markup inside, say that you can have markup inside if all of the text is in the same parent 14:48:41 dbaron: You could actually get same result by changing rule on when to void all 14:48:53 dbaron: You're limited to text and inline elements 14:49:00 (So 12 is OK, too) 14:49:01 dbaron: And all of the text has the same parent element 14:49:43 all text and all content are different rules 14:49:51 Alternative proposal: Allow 'display: inline' elements, but if there are any, scale-x the result instead of trying to do fancy things 14:50:16 dbaron: Alternative-alternative proposal is, void the all if your parent is also all unless you're the only child of the parent. 14:50:36 dbaron: not element-tree child, DOM-tree child 14:50:52 dbaron: though collapsible whitespace might be ok 14:51:09 fantasai: That makes sense to me. I can write that up 14:51:30 dbaron: One thing that makes TCY dangerous is that if you have things inside the markup, you have to worry about borders and padding on those inlines, backgrounds, etc. 14:51:42 dbaron: whereas if there's only text 14:51:55 dbaron: the element that establishes the TCY is still behaving as if it's vertical 14:52:02 DOM-tree child meaning that text also counts as a child? 14:52:12 dbaron: New proposal saying that in the case Koji wants to work, you end up with the TCY happening on the innermost element, rather than the outermost element 14:52:17 dbaron: which avoids all that complexity 14:52:51 rossen: If you put inline bg differently on 1, 0, 2, then, what would be effect? 14:53:12 Rossen: ... 14:53:19 dbaron: This is the thing we're trying to not deal with in this level 14:54:00 rossen: or say 'all' doesn't inherit 14:54:07 fantasai: that's a different problem, we already solving that 14:54:23 SteveZ: Why can't we format the string with whatever markup, and then possibly compressing it if I need to? 14:54:39 dbaron: I think jdaggett is better-placed to answer that. A lot of this will be implemented using font features 14:54:49 dbaron: You'll have calculations wrt does it fit, what scaling do we apply to the characters? 14:54:58 dbaron: If you have to deal with inline margins and padding, that makes it much more complicated 14:55:10 SteveZ: Agree it becomes more complex 14:56:32 SteveZ: One simple way out of that is, you simply try to set it to fit, and then squeeze it and live with whatever result is 14:57:17 dbaron: Does the spec require scaling in any other cases? 14:57:29 fantasai: Yes, if you don't get narrow enough glyphs to fit into 1em, you have to scale the result 14:58:17 SteveZ: ... 14:58:22 jdaggett: Up to the implementation 14:58:31 jdaggett: In the case of having appropriate variants for all glyphs, must use those 14:58:39 jdaggett: If not available, then UA does what it thinks is best 14:58:46 SteveZ: If I allow borders and backgrounds around components 14:59:03 SteveZ: I could just set it horizontally, see if it fits, and if it doesn't fit scale it down 14:59:26 SteveZ: borders will change, but oh well 14:59:34 jdaggett: borders inside TCY? really? 14:59:44 SteveZ: Not proposing that as a use case, just as a reasonable fallback 14:59:52 SteveZ: Question is, trying to limit what can be inside TCY 14:59:59 ChrisLilley has joined #css 15:00:03 SteveZ: Every time we try to limit, has some disadvantages 15:00:17 SteveZ: So question is, what if we don't limit? would it be a big implementation burden? Produce awful results? 15:00:50 SteveZ: If not too awful, and not so difficult... 15:00:55 koji: What about alternate heights? 15:01:04 kawabata has joined #css 15:01:04 SteveZ: might need to compress in height direction as well 15:01:07 koji: to 1em 15:01:51 SteveZ: Rossen? 15:02:38 koji: My first vote is just keep it inherited as it is right now 15:02:43 koji: second is dbaron's proposal 15:02:54 s/proposal/first proposal/ 15:07:09 jdaggett, they’re gathering around fantasai drawing on the whiteboard 15:07:33 yeah, i saw dbaron's camera view... 15:07:33 [fantasai is listing the options on the whiteboard] 15:08:33 Option A) Break TCY if contains elements, inherit to children 15:08:38 ScribeNick: TabAtkins 15:08:46 Option B) Break TCY if contains elements, inherit to only child 15:08:56 fantasai: [option a] 15:09:04 Option B) Accept all 'display:inline' content, scale to 1em square 15:09:09 s/B/C/ 15:09:20 fantasai: That means that Koji's case works, 15:09:43 abc 15:09:47 fantasai: But it also means that if you have an element with abc 15:09:59 fantasai: The presence of "a" means the outer one won't form tcy, but the inner one will. 15:10:21 fantasai: You have to rely on people not using tcy in cases like this. 15:10:28 SteveZ: But I can't, so it breaks. 15:10:57 fantasai: The only case you need to do this is when it's automatic, for accessibility. 15:11:30 xyz 15:11:36 fantasai: [option b] 15:11:57 fantasai: "if my parent has 'all', I won't form tcy, unless I'm the only parent of my child." 15:12:18 s/parent of my child/child of my parent/ 15:12:30 fantasai: [option c] 15:12:46 fantasai: Take all display:inline content and generate tcy. If it doesn't fit, we scale it to 1. 15:13:50 s/1/1em square/ 15:14:10 koji: We probably have to disable ??? or tcy ??? for option c. 15:15:05 [some discussion of examples on the board, which are way too small for me to see from this distance] 15:15:53 SteveZ: [something about text emphasis] 15:16:11 fantasai: No, it's an inherited proeprty, not like text-decoration. If you change font size, it'll move with it. 15:16:33 -> http://dev.w3.org/csswg/css-text-decor-3/#text-emphasis-property text-emphasis in ED 15:17:06 fantasai: The escape hatch to put arbitrary stuff in a TCY thing is to just use inline-block instead. 15:17:19 fantasai: Instead of actually using TCY 15:17:59 [???] 15:18:22 szilles: You'd have an inline-block where you're using font substitution to get squished digits. 15:18:37 [Discussion of differences between inline block and TCY 15:18:43 fantasai: It'll also be underlined, for example, as a single glyph - a strikethrough will be vertical. 15:18:59 fantasai: Other Koji point - text emphasis treats TCY as a single character. 15:19:09 fantasai: If you allow arbitrary content, you wont' get the right behavior. 15:19:12 fantasai: If you scale it. 15:19:52 fantasai: This is why we wanted to limit TCY only to text - all these issues start to crop up. 15:20:18 dbaron: I don't feel like we have use-cases for this. 15:20:26 stearns: CO_2 15:20:42 fantasai: That's solvable with unicode codepoints for superscript and subscript chars. 15:21:09 SteveZ: Not all fonts have those. 15:21:19 fantasai: If it doesn't, sub/sup will look ugly anyway. 15:21:31 SteveZ: If do C, with a couple of exceptions you don't have to do anything special. 15:21:36 SteveZ: The other require exceptions. 15:21:56 koji: Limiting to characters makes code 1 (?) simpler. 15:22:18 koji: Code only needs to measure text, not elements. 15:22:29 SteveZ: To do line-breaking, it already needs to do all that stuff. 15:22:42 SteveZ: You already have code to do inline text layout. That has everything you need. 15:22:55 Bert: You don't know how long the line is going to be, as you have no 'width' proeprty. 15:23:17 SteveZ: Layout as if the space was infinite, then see if it fits in the em. If it doesn't fit, you compress. 15:23:55 Bert: That doesn't work for floats, though - you need containing block size. 15:24:06 SteveZ: Yes, but it's typically just a few characters. 15:24:56 [agreement to do the rest of the tcy conversation on the side] 15:25:24 dbaron: This is what's holding up Writing Modes from CR? 15:25:37 fantasai: This, and some cleanup for orthogonal flows (but I don't think that should hold up LC). 15:25:47 SteveZ: Could you add these examples and discussion in the thread? 15:25:50 fantasai: Okay. 15:26:00 fantasai: I still think we should try and solve this in this f2f. 15:26:08 (I meant to say that we have to specify in case C what CB you use for the layout, before it gets scaled down.) 15:29:35 ScribeNick: fantasai 15:29:58 sylvaing: Issue 2 in compsoiting spec 15:30:04 sylvaing: specifically about background-blend-mode property 15:30:11 ChrisLilley has joined #css 15:30:35 lmclister has joined #css 15:30:38 sylvaing: feedback on that was that instead of specifying backgrounds and blending the backgrounds, could stack elements and blend those 15:30:39 koji has joined #css 15:30:49 sylvaing: so question is, whether property is worthit 15:30:59 sylvaing: basic scenario is, element, couple backgrounds, image and color, gradient, etc. 15:31:03 sylvaing: wnat to blend them together 15:31:20 sylvaing: suggest is maybe don't need background-blend-mode property 15:31:20 sy just do it with elements 15:31:21 sy That seems pretty sub-optimal 15:31:28 sylvaing: got to have a bunch of wrapper elements, psoition them together 15:31:40 sylvaing: thigns get more complicated if you want to change blending or backgrounds based on user interaction 15:32:01 sgalineau: we expect that use case for this in many cases will be changing backgrounds 15:32:23 sgalineau: similar to desire to apply opacity 15:32:34 sylvaing: ppl want bg color, something on top of it, graident, blend them, etc. etc. 15:32:45 sylvaing: if you have to do that with stack of elements, a lot more work 15:32:55 sylvaing: people will not do it, or use js plugin or something to do it 15:33:14 fantasai: So you want to remove issue 2 and close as no change. 15:33:20 fantasai: OK, so are there any objections to that? 15:33:38 dbaron: I guess not? 15:33:44 hober: Who raised the issue? 15:33:51 sylvaing: Don't know? 15:34:03 leaverou: Are there really that many use cases, can't wait until Level 2? 15:34:26 sylvaing: Doesn't seem that hard to implement 15:34:45 leaverou: This is for individual background layers, right? 15:34:58 leaverou: We had discusison on different modes for borders, backgrounds, etc. 15:35:04 sylvaing: Think that was for filters 15:35:21 krit: we had that in the spec at one point 15:35:25 that was for the different parts of the box model 15:35:41 there are multiple images so you need a list 15:35:47 sylvaing: It's very common for pages to update bg color on hover or active etc. 15:35:59 sylvaing: once you have blending, ppl still do that, say blend color graident + ? 15:36:08 sylvaing: If the only option to do that is stacing bunch of elements, add lots of divs 15:36:22 sylvaing: Question then becomes, is the implementation so heavy that we should force to another level? 15:36:28 sylvaing: Doesn't seem so 15:36:56 ChrisLilley: So you're saying that if we don't do this now, we ask ppl to make bad content 15:37:00 sylvaing: Yeah 15:37:18 sylvaing: [gives more examples, this time with scrolling] 15:37:33 fantasai: What were dbaron's reservations? 15:37:52 dbaron: I'm not convinced it's all that useful, but I guess it's easier than the other stuff in the draft, and therefore might be the only thing we get for awhile 15:38:43 the feature is about to land in mozilla 15:38:57 fantasai: So you're concerned that background-blemd-mode will be implemented and not mix-blend-mode, and so worried ppl will put too much content in backgrounds or something? 15:39:02 dbaron: ... 15:39:27 dbaron: Have lots of concerns wrt mix-blend-mode, but think that's where all the useful stuff is 15:39:34 s/.../I'm ok with it. My bigger concerns are with mix-blend-mode, but that's also where I think the useful stuff is./ 15:39:52 fantasai: Do you want to put a note telling implementers to work on mix-blend-mode first? 15:39:58 dbaron: Don't think mix-blend-mode is ready 15:40:02 dbaron: Fine to remove issue 15:40:13 RESOLVED: close issue 15:40:25 yes, would like to know the issues 15:40:46 dbaron: Some of issues with mix-blend-mode were on www-style, also wrote up some as a blog post 15:40:52 http://dbaron.org/log/20130306-compositing-blending 15:40:59 Rossen_ has joined #css 15:41:09 dbaron: What does mix-blend-mode apply to these days? 15:41:39 sgalineau: all elements? 15:41:42 sylvaing: All elements 15:41:44 dbaron: does it est. a stacking context? 15:41:49 sylvaing: yes 15:41:51 sylvaing/rik: yes 15:42:04 dbaron: If it forces them to establish a stacking context, I have fewer concerns 15:42:22 dbaron: Basic problem with mix-blend-mode is that, and i tried to explain in the blog post, we've been very precise about describing painting order 15:42:34 dbaron: But that assumes that compositive is an associative operation 15:42:54 dbaron: Which is true until you have blend-mode 15:42:57 rik: or opacity 15:43:03 dbaron: No, true with opacity 15:43:15 dbaron: True until you have the stuff in the spec 15:43:38 dbaron: Can get some rounding errors, but in practice ppl don't care about that 15:44:02 dbaron: My issue with this spec is that, in order for this to be interoperable, we need parenthese in Appendix E 15:44:13 dbaron: i.e. not just the list of layers, but which pairs composit in what order 15:44:27 dbaron: Might just be that we pretend it's a postfix op or a prefix op, and all one big operation like that 15:44:34 dbaron: But that's not really the way it works in implementations right now 15:44:48 dbaron: And for this to be interoperable, need to agree on grouping in Appendix E. 15:45:07 dbaron: Problem with doing that is that there are a lot of browser optimizations 15:45:20 dbaron: that interact with this stuff 15:45:39 dbaron: We could disable optimizations when you use this stuff, and probably will need to do that 15:45:42 dbaron: but 15:45:45 dbaron: [...] 15:46:08 krit: ... is defined in the spec 15:46:14 there is really no different of drawing with opacity and drawing with a blendmode 15:46:19 dbaron: 15:46:26 dbaron: where is it defined? 15:46:31 krit: Defined in CSS 15:46:39 dbaron: It's not defined in CSS. We define the layering, but not the grouping. 15:48:05 what is the different between drawing an element with opacity and an element with a blend mode? 15:48:25 there is a difference where you need to know what you draw onto 15:48:50 tobie has joined #css 15:49:04 dbaron: I think you're assuming that CSS implicitly defines grouping from the bottom up, in other words that the first composition is the lowest layer with the next lowest, and then the third lowest with that, etc. 15:49:04 dbaron: You're probably implicitly assuming that the defined layers are composited in order from the bottom up. 15:49:05 ok. I think that's what David is saying. you need to say that you have to draw in order in order for blending to work 15:49:28 (I think everyone basically does that) 15:49:32 dbaron: I think it is worth testing if that is actually what impls do. 15:51:06 dbaron: There are definitely some things in cSS that *have* to form a layer. 15:51:11 krit: Right. These form a stacking context. 15:51:18 dbaron: Right, but there are many other things that make a stacking context. 15:51:23 krit: Like transforms. 15:51:34 + is associative <=> (a+b)+c == a+(b+c) 15:51:35 dbaron: So do we want only the visual things to form groups, or all stacking contexts? 15:52:35 TabAtkins, fair enough 15:52:42 krit: Every property that creates a stacking context today creates a group as well. 15:52:56 TabAtkins: I think that's what we wanted to do when we last talked about this in SVG as well. 15:53:30 sgalineau: And the spec today defines that already. 15:53:48 cabanier: The statcking context of the thing you're blending creates a group too. 15:53:55 dbaron: Okay. I'll need to review this document. 15:54:07 dbaron: It's progressing. 15:54:33 cabanier: Can we go to LC? 15:54:41 dbaron: I'd like more time to review. 15:55:00 dbaron: Last I looked there were parts of the spec that were very difficult to understand, and I"d like to see if that was addressed. 15:55:06 dbaron: So I'd like to have more time to review. 15:55:14 dbaron: I can try to do it by the next telcon. 15:55:51 http://dev.w3.org/fxtf/compositing-1/ is the document you want to take to LC? 15:55:55 cabanier, ^ 15:57:03 I think "blend mode" is an existing term. 15:57:22 glazou has left #css 15:57:29 glazou has joined #css 15:57:36 RESOLVED: Everyone review Compositing/Blending, we'll take up the question of LC publication at next telcon. 15:58:02 Meeting closed. 16:04:26 darobin has joined #css 16:14:35 darktears has joined #css 16:22:00 shepazu has joined #css 16:29:57 cabanier has joined #css 16:32:40 zcorpan has joined #css 16:38:30 dbaron, you asked to be reminded at this time to go home 16:47:38 rhauck has joined #css 16:48:48 liam has joined #css 17:00:13 myakura has joined #css 17:01:13 tantek has joined #css 17:03:42 Zakim has left #css 17:03:46 krit has joined #css 17:41:17 rhauck1 has joined #css 18:01:02 darktears has joined #css 18:22:15 teoli has joined #css 18:31:59 dbaron has joined #css 18:33:17 tobie has joined #css 18:49:25 myakura has joined #css 18:50:59 myakura_ has joined #css 18:51:02 GPHemsley has joined #css 18:52:59 tantek has joined #css 18:54:28 rhauck has joined #css 19:14:19 lmclister has joined #css 19:31:05 zcorpan has joined #css 19:40:26 leif has joined #css 19:46:00 leif1 has joined #css 19:50:43 myakura has joined #css 20:05:52 lmclister has joined #css 20:17:29 sgalineau has joined #css 20:23:22 shans__ has joined #css 20:33:31 lmclister has joined #css 20:40:08 darktears has joined #css 20:55:14 florian has joined #css 20:58:32 teoli has joined #css 21:43:43 lmclister has joined #css 21:51:20 florian has left #css 21:54:54 <{Darktears}> {Darktears} has joined #css 22:06:54 rhauck1 has joined #css 22:23:09 zcorpan has joined #css 22:30:06 TabAtkins, I'm assuming that variable declarations should not work in @keyframes declarations. but should variable references within non-custom properties work there? 22:33:51 krit has joined #css 22:35:05 krit1 has joined #css 23:02:19 jdaggett has joined #css 23:12:43 lmclister has joined #css 23:14:05 tantek has joined #css 23:26:55 tobie has joined #css