00:01:01 Kazutaka has joined #CSS 00:01:28 Rossen has joined #css 00:02:52 lmclister has joined #css 00:03:13 cabanier has joined #css 00:07:04 myakura has joined #css 00:09:35 trackbot, start meeting 00:09:37 RRSAgent, make logs member 00:09:37 Zakim has joined #css 00:09:39 Zakim, this will be Style_CSS FP 00:09:40 Meeting: Cascading Style Sheets (CSS) Working Group Teleconference 00:09:40 Date: 06 June 2013 00:09:43 I do not see a conference matching that name scheduled within the next hour, trackbot 00:09:44 Zakim, remind us in 9 hours to go home 00:09:44 ok, dbaron 00:09:46 rhauck has joined #css 00:09:54 RRSAgent, make logs public 00:10:50 Meeting: Cascading Style Sheets (CSS) Working Group Face-to-Face, Tokyo, Japan 00:11:09 SimonSapin has joined #css 00:12:26 glazou has joined #css 00:14:14 ivan has joined #css 00:14:28 but yes please for this afternoon 00:17:07 ScribeNick: fantasai 00:17:13 plh has joined #css 00:17:47 leif has joined #css 00:18:35 Round of intros 00:18:53 plh, W3C 00:18:58 fantasai, Mozilla 00:19:02 Slides: http://www.w3.org/2013/Talks/0606-css-plh/#/ 00:19:13 Ivan Herman, W3C 00:19:21 glazou, Disruptive Innovations, csswg co-chair 00:19:25 Simon Sapin, Mozilla 00:19:28 Jet Villegas, Mozilla 00:19:32 Rossen Atanassov, Microsoft 00:19:35 Alan Stearns, Adobe 00:19:48 whatever, scribe gives up 00:19:53 rhauck1 has joined #css 00:19:57 lol 00:20:35 plinss: jdaggett can't be here this morning, ishida can't be here this afternoon 00:21:23 jdovey has joined #css 00:21:29 Topic: CSSWG Priorities 00:21:36 plh projects title slide 00:21:52 next slides lists RECs and dates 00:21:53 link? 00:22:03 http://www.w3.org/2013/Talks/0606-css-plh/#/ 00:22:06 thx 00:22:35 plh: Only 6 RECs 00:22:51 Last 12 months: 1 REC (MQ), 2 CRS (flexbox, conditional rules) 00:22:54 18 WDs updated 00:23:00 FPWD x 5 00:23:16 liam has joined #css 00:23:38 Bugs: last 12 months 00:23:52 plh: Huge controversy over these, staring with Opera suggesting to remove prefixes 00:23:57 Transforms, bugs from 11 to 6 00:23:59 shans__ has joined #css 00:24:00 transitions from 29 to 25 00:24:04 animations from 45 to 20 00:24:10 glazou corrects the record 00:24:21 Present: Phillipe Le Hegaret (W3C), Elika Etemad (Mozilla), Ivan Herman (W3C), Daniel Glazman (Disuptive Innovations), Simon Sapin (Mozilla), Jet Villegas (Mozilla), Rebecca Hauck (Adobe), Rossen Atanassov (Microsoft), Larry MacLister (Adobe), Alan Stearns (Adobe), Israel Noto (Adobe), Dean Jackson (Apple), Dirk Schultze (Adobe), Rik Cabanier (Adobe), Masataka Yakura, Leif Arne Storset (Opera), Kazutaka Yamamoto(NTT), Koji Ishii (Rakuten), Liam Quin (W3C), Just 00:24:21 in Erenkrantz (Bloomberg), Cameron MacCormack (Mozilla), Shane Stevens (Google), Jim Dovey (Kobo), Bert Bos (W3C), Richard Ishida (W3C), Peter Linss (HP), David Baron (Mozilla), Glenn Adams (Cox), Tab Atkins (Google) 00:24:21 plh: Decided to move faster, but this is the result 00:24:33 plh: Only 5 bugs fixed for Transforms, 4 for Transitions, 25 for Animations 00:24:45 plh: Animations is more than 50% better 00:24:56 dbaron: some metrics are a little funny. Went through bugs, most deferred to next level 00:24:59 plh: Why not in LC? 00:25:02 dbaron: Because 2 left 00:25:51 plh: Fact is, drafts still not in LC despite controversylast year 00:26:09 plh: If we look at priorities from December 2011, these are top 3 drafts: css3-background, css3-ui, css3-values 00:26:12 plh: Still in this cycle 00:26:33 plh: Think css3-background still held up on implementation issues and tests 00:26:39 plh: css3-ui went backwards rather than forwad 00:26:43 plh: css3-values went forward 00:26:46 plh: One metric, not only one 00:26:55 plh: Last fall, CSS chairs committed a survey 00:27:18 plh: In terms of priorities, top 5 were flexbox, transforms, animations, conditional rules, transitions 00:27:54 plh: Coremob profile 00:28:29 plh: CSS2.1, MQ, Selectors 3, Color, Flexbox, Transforms, Animations, Transitions, CSS3 Text, CSS3 Fonts, CSS3-backgrounds and Borders, CSS3 Images, CSS3 Values, CSS Device Adaptation, CSSOM 00:29:32 plh: Normative references HTML5.0 00:29:50 plh: Fonts, Images, Values, Selectors 4, CSSOM, CSSOM View, css3-ui, Style Attr, Fullscreen (?) 00:30:58 plh: Some of this can be tweaked 00:31:10 plh: But some, e.g. View Module, can't break the dependency 00:32:06 plh: Style Attributes 00:32:12 fantasai: Style Attributes stuck on one failed test 00:32:17 plh: Is it important test? 00:32:19 fantasai: No. 00:32:22 plh: Then send a PR request soon 00:33:00 glazou: Whatever you do, browser vendors will implement and ship it. What's the point of breaking the dependency? 00:33:25 glazou: Browser vendors will implement, ship, try for workable interop, and the spec describing the behavior of the current market will not be available 00:33:29 glazou: I find it a little bit sad 00:33:41 glazou: We had this discussion in AC form, chairs, wrt what is a normative reference 00:33:56 glazou: I said a spec like HTML5, which is based on living standard, needs an intermediate status between informative and normative 00:34:01 glazou: That is another way of solving your issue 00:34:19 glazou: If I take that list, to finish everything including tests, is enough work for this WG for the entire year 00:34:28 glazou: You want us to do everything by 2014? 00:35:02 glazou: Each member of this WG has individual strategy and priority. if I read your slides, I think you forget it. 00:35:11 dbaron: Another problem is that REC track doesn't reflect how industry really works 00:35:17 dbaron: Talk of reforming REC track for a while 00:35:45 plh: Several ways to approach this. One is to remove dependencies from HTml5 00:36:03 plh: Third question is what does it mean to be normative ref for HTML5 00:36:18 plh: Some of those references, perhaps part referenced by HTMl5 is perfectly stable and implemented 00:36:37 Koji has joined #css 00:36:53 sgalineau, let me get the lash 00:37:06 fantasai: you could solve most of this is to allow REC to normatively reference CR, treating PR like transitional phase just like LC. 00:37:19 fantasai: This is relatively minor change to the process, would solve the problem. 00:37:30 plh talks about stability 00:37:53 dbaron: This is a discussion in the TAG list 00:38:01 dbaron: I think the way W3C manages normative references is broken 00:38:11 plh: Do believe this has process problems 00:38:15 sgalineau, sure :-) 00:38:27 plh: If I look at F2F agenda, this is list of things that were on the agenda 00:38:29 sylvaing, and I will make sure plh understands that, no worries 00:39:37 plh projects some questions 00:39:47 1. Are we getting the right balance between day-to-day borwser implementers needs and what's needed? 00:39:53 2. What's happening with Fall 2012 Priorities? 00:40:01 3. Will CSS prevent HTML5 from moving to REC by 2014? 00:40:07 4. What is WG expectation for its next Charter? 00:40:37 plh: Last, main question we have, 00:40:50 plh: This group needs to be rechartered, what's the expecations? 00:41:26 glazou: First one, you should define better what's needed. What's needed for who? This WG? Other WGs? The Press? I don't care about the Press. We make technology for billions of people. I don't care about their opinion. We should make sure everythign works. 00:41:37 plh: browser vendors are the deciders in this WG 00:41:41 s/plh/glazou/ 00:41:55 glenn: We have input from others 00:42:06 TabAtkins: input, yes, but ultimately what browsers implement is what we spec 00:42:21 glazou: 2nd point, TTA and Flexbox were highest priorities during most of our conference calls during 12 last months 00:42:40 plh: Only 6 bugs? 00:42:49 glazou: Do you have any idea how complex these bugs are? 00:42:56 glazou: Take a look. Don't rant. 00:43:12 glazou: 3rd point, well, the day the HTMLWG pings us to tell us they need that spec to be a REC, maybe it will change 00:43:31 glazou: I told HTMLWG and W3C more than a year ago that we have problems with normative refs of HTML5. No response. 00:43:43 glazou: WG expectation, I don't know. We did not discuss next charter yet 00:43:49 glazou: Mine is to reduce the nubmer of specs we're working on 00:44:01 glazou: Priorities can change a lot, and strategies can change a lot, over 2 years. 00:44:13 glazou: E.g. Firefox was not in mobile space before. now they are working a lot on apis 00:44:26 glazou: If I knew what was going to happen in CSS world 2 years from now, would be billionnaire 00:44:40 glazou: So, do some cleanup, try to serve best CSS and the Web, help the HTMLWG if we can. But don't know if we can solve everything. 00:44:50 glazou: Date of 2014 has been set by HTMLWG without looking at the dependencies. 00:45:08 glazou: After choosing date, look at dependencies. It is not fair. 00:45:26 TabAtkins: Even if we ignore dependencies, there is no way HTML5 can hit REC in 2014 without bending rules. 00:45:36 TabAtkins: You're going to need like a million tests. it's not going to happen in 1.5 years. 00:45:49 glazou: They lowered expectations. 00:46:01 TabAtkins: By honestly reaching REC like everyone else does, will need to lower what it means to be REC. 00:46:19 TabAtkins: Doesn't make a difference if we are a process-holdup. They have a process-holdup anyway. 00:47:14 glenn: I don't agree with Daniel's characterization of how this group should work. Should take into account people who are using our specs, including ppl who normatively reference our specs. 00:47:20 glenn: Think it's impractical perspective 00:47:32 glenn: Would encourage us to not take that we work in a vacuum 00:48:07 glenn: Of course, since volunteer activity, depends on people putting their energy into specs customers care about. Should request customers to bring resources to WG if what we do isn't funded. 00:48:22 glazou: One of the largest users is Ebooks. And we have an acceptable cooperation with IDPF 00:48:31 glazou: I think not perfect, but acceptable cooperation. 00:48:40 glazou: They send us requests, they discuss CSS on their group. 00:49:02 Bert: You and I are working on it, but not rest of WG 00:49:28 [discussion of css3-page, css4-page] 00:49:37 glazou: Where is HTMLWG to discuss with us their needs? 00:49:46 glenn: Problem is communication 00:50:15 glenn: I find it easier to ping users, outside W3C, than to ping some other committees. 00:50:29 s/glenn/glazou/ 00:51:51 [discussion about cross-wg communication and HTML5 date] 00:52:08 plh: If you tell me none of those specs reach REC by 2014, that's one kind of input 00:53:08 ... 00:53:20 dbaron: Why do members care about pushing to REC? 00:53:25 dbaron: Doesn't have any benefit for us 00:54:02 ... 00:54:18 TabAtkins: REC and interop don't have a strong correlation 00:54:38 plh: That's one reason, other people have other reasons 00:54:47 dbaron: It's the reason why people here do the work. 00:55:18 plh: You're trying to get the documents perfect before REC. You won't get there. 00:55:41 glazou: Documents that don't move now are blocked on difficult technical issues (other than style attr) 00:55:49 glazou: Open issues for TTA are really complex 00:56:07 glazou: Question of availability of people. Only a few experts on each topic. 00:56:15 glazou: Even if a large group, made of subgroups. You seem to forget that. 00:56:45 i do think we lack the ability to prioritize some specs 00:57:09 we seem to work as a group on whatever individual members are interested in working on 00:57:11 Bert: Why don't we finish things we promised to finish 5 years ago? 00:57:19 glazou: Ask them! (gestures to WG) 00:57:50 and that effectively crowds out work on other things 00:57:52 ... 00:58:17 TabAtkins: Can't go to PR without testing everything in the spec 00:58:20 myakura has joined #css 00:58:25 glenn: No, don't need to test everything in the spec 00:58:35 TabAtkins: Then I have no idea what you mean by test suite. 00:59:02 plh: I've never seen browser vendor that has full test suite for everything they implement 00:59:04 why don't you need to test what's in the spec?!? that makes no sense 00:59:30 ... 00:59:41 dbaron: Philippe admits that REC doesn't need to be perfect 00:59:50 existing browsers have lots of legacy stuff 00:59:53 dbaron: One problem we have with process is that we want to maintain specs, and continue to maintain them as ppl bring up issues 01:00:06 dbaron: Problem with process is that it's much harder to update a REC 01:00:14 but the quality of testing efforts is vastly improved over the past five years 01:00:47 plh: Don't see why 01:00:53 plh: Just need to have a test for each change 01:01:02 plh: You are setting a bar for REC that is way too high 01:01:11 dbaron: You act as though publishing a doc is trivial thing 01:01:29 dbaron: Publishing CR requires editor to spend days pinging various people for permission 01:01:36 dbaron: It's not worht a week of my time to get document published on /TR 01:02:21 glazou: Pages of spec: 01:02:23 12 pages for CSS1 01:02:29 258 for CSS21 01:02:36 4000 for CSS3 01:03:10 glazou: It's a lot of work 01:03:47 Bert: Seems like we always want things to be in flux 01:04:04 TabAtkins: Want to always be refinining / correcting things. 01:04:17 TabAtkins: 100% stability is an illusion 01:04:34 [discussion of bureaucracy] 01:04:47 [and how to allocate resources to it] 01:05:51 glazou: 2 passing implementations for each testable assertion 01:06:01 glazou: That's the way it should be. Otherwise test suite has no value. 01:06:15 glazou: I understand HTML5 has different requirements. And I agree with Tab that that test suite has no value. It's just marketing. 01:06:22 /just/pure/ 01:07:28 ... 01:07:38 jet: Sounds like W3C wants REC documents 01:07:50 jet: Group says cost to REC is too high, and CR is good enough 01:08:02 jet: Perhaps the product expected of this group should change 01:08:20 plh: If I go to AC and say CR is the new REC, AC will not happy 01:08:52 Bert: We used to have no testing requirement 01:08:56 Bert: process changed 01:09:06 glazou: So process can change. These people are telling you process needs to change. 01:09:53 plh: You're saying we should have no test suite requirement, other say they want more testing requirement 01:11:06 .. 01:11:22 glazou: HTML has lower expectation because want to release fast, because marketing impact and press, releasing HTML5 01:11:28 LC of css3-conditional took 28 days from publication request (November 15) to publication (December 13) 01:11:45 so it's not just CRs 01:11:47 glazou: You lowered the bar to meet that date 01:12:04 dbaron, that was largely because I didn't notice that the document wasn't published when it was requested to be published 01:12:25 dbaron, and so wasn't able to follow up and get it published the next day 01:12:42 ... 01:13:08 jdovey describes IDPF process, which is fast and loose 01:13:21 it didn't help that there was a 5 day delay from 15th to when it was supposed to be published, and then a week from noticing that it wasn't published to it actually being published 01:13:54 liam: Pragmatic, and on programming end pragmatism is imporant. But e.g. governmental standards requirements are different 01:13:56 isra has joined #css 01:14:00 glazou: These 4 questions 01:14:18 glazou: To answer these 4 questions, we need to know what you want. 01:14:24 glazou: What does W3M want about the priorities? 01:14:33 glazou: What do you think we should do wrt dependencies 01:14:42 dbaron: Why does W3M have to make those decisions 01:14:50 glazou: Don't say they make decisions, just want their input. 01:15:48 plh: ... 01:15:58 r12a: IDPF has been really keen on vertical text and ruby 01:16:08 r12a: Ruby CSS module is way off the bottom of the scale in terms of work being done 01:16:16 r12a: I know that's partly because ppl don't ahve time to work on it 01:16:30 r12a: But what's the process the WG has, for discussing with IDPF, and allowing them to raise what they want 01:16:40 glazou: Question I discussed with Markus Gylling 01:16:44 glazou: We don't have a real process 01:16:59 glazou: We discuss technical issues sometimes, but not really how can we answer, address improtant requests from their point of view. 01:17:02 glazou: E.g. ruby, which is best example 01:17:06 glazou: We have no one 01:17:40 glazou: When we tell them we have no resources to work on that right now, they say they'll wait. Members unwilling ot join this group 01:17:54 ivan: digital publishing interest group ... 01:18:11 ivan: Not chartered to develop sepcs, but may come up with priorities and requirements, and maybe find ppl to do the work here. 01:18:32 r12a: What is the process for CSSWG for re-evaluating priorities and discussing stakeholder requirements? 01:20:26 ... 01:20:52 dbaron: Need to communicate that we don't have resources, and let them work on it if they want to put those resources in. 01:21:11 Bert: ... 01:21:17 glazou: Strategy of the market changes 01:21:28 Ivan: Whole issue of membership fee etc. 01:21:42 Ivan: Let's say 3-4 ppl form task group within this wg to develop technolgy XYZ 01:21:47 Ivan: Do you have structure of task forces? 01:21:55 Ivan: What's the decision procedure? 01:22:11 glazou: We have FXTF with SVGWG 01:22:23 Ivan: Can they work on it and push to REC? 01:22:25 glazou: Sure 01:22:52 jdovey: What happens if TF comes back to WG and 80% WG says they don't like it? 01:22:56 um, i don't think task forces are magic, you need people capable of actual tackling issues with developing something 01:23:01 dbaron: Need to get feedback earlier 01:23:24 the epub of coming up with a laundry list of "we needs" is actually very disruptive 01:23:34 s/epub/epub way/ 01:23:37 Ivan: We have a community not browser vendors, willing to do work, will they be shot down because browsers don't care? 01:23:48 s/Bert: .../Bert: Daniel and David refer to new requirements that we don't have resources for. But in many cases people are just waiting for things that we already had in our charter./ 01:23:53 dbaron: If you have a need for something in 6 monts, but don't care about quality for stability of long term, that's an issue 01:24:37 jdovey: talks about implementing ? in WebKit and politicking and sitting on the patch and stuff. 01:24:55 jdovey: We keep running into roadblocks 01:25:06 dbaron: I think you can't say you want something in 6 months and then not put the work into it 01:25:14 dbaron: to really do it right 01:25:36 maybe because shoving code for a feature into webkit before ironing out the spec is not a constructive approach...! 01:25:39 dbaron: Having a patch in WebKit is different from having a standard that can be interoperably implemented and everyone agrees with 01:25:50 jdovey talks about JLREQ requirements 01:25:59 and trying to implement those 01:26:30 jdovey: [..., ruby, ...] 01:26:37 dbaron: Don't see how you can implement a requirements document. 01:26:45 dbaron: If you want a technical spec, need to describe what the technology is 01:26:55 jdovey: Desribes how characters should be laid out 01:26:59 dbaron: Gives requirements, not a model 01:27:26 and you have to make that fit into existing features!!!!!!!!!!!!!!!!! 01:27:40 plh: Current charter is coming to expiration 01:27:45 example: webkit's crazy two-path text handling structure 01:27:47 plh: Could say, perfectly happy way we are working 01:27:51 plh: You guys are doing the work 01:28:03 plh: I cannot just say, this is what you will do, you have no choice. You'll walk away if I do that. 01:28:10 SimonSapin1 has joined #css 01:28:13 plh: Think you need to figure out what you need to achieve 01:28:37 s/need/want/ 01:29:00 plh: If the group's believe they're doing what they want to achieve, and AC doesn't agree, then AC has to figure out how to appoint to the WG 01:29:11 dbaron: he's talking about how WG members are appointed by their AC reps 01:29:16 dbaron: Which is mostly an administrative fiction 01:29:46 plh: Ok, I don't want to hold this group further. You guys have work to do 01:30:01
01:30:21 dino: what was the point of this discussion? 01:30:29 dino: Not trying to be rude, really want to know 01:30:56 plh: Just wantto make sure you understand what you're doing and are happy with how you're operating 01:31:11 plh: And if ppl come to me with complaints, I will rediret them to you saying your'e doing this intentionally :) 01:33:55 cabanier has joined #css 01:35:04 i think lots of folks will always be dissatisfied because their individual feature request isn't satisfied 01:35:18 しょがない 01:37:11 Present+ Thierry Michel 01:48:37 Rossen has joined #css 01:55:25 http://www.quickmeme.com/meme/3uqllg/ 01:56:02 sylvaing, please upload the URL above to w3cmemes 01:57:40 isra has joined #css 02:01:03 Topic: Syntax 02:01:13 TabAtkins: Rewriting from grammar approach to parser approach 02:01:33 http://dev.w3.org/csswg/css-syntax/ 02:01:40 TabAtkins: grammar tried to match everything, not just well-formed things, and was too complicated and didn't quite handle everything anyway 02:01:56 TabAtkins: Tokenizer, then Parser 02:02:08 TabAtkins: Includes hooks for other specs to include a certain type of thing 02:02:18 TabAtkins: I would like to review some things with group, then ask for FPWD 02:02:34 TabAtkins: Probably as correct as 2.1 at this point 02:03:17 TabAtkins: WebKit uses augmented grammar to parse, and it's horribly broken. 02:03:42 TabAtkins: Wanted to go over changes from 2.1 02:03:49 TabAtkins: First batch of changes are about parsing 02:03:59 TabAtkins: 2.1 defined some interesting rules for detecting @charset 02:04:17 TabAtkins: Brought into line with charset handlign in rest of platform 02:04:29 we're reviewing http://dev.w3.org/csswg/css-syntax/#changes as of 4ce7b66b553a 02:04:39 r12a: Does that mean it doesn't handle UTF16 02:04:56 TabAtkins: Can use UTF16 by having BOM, but won't recognize @charset 02:05:13 fantasai: How interoperable is this, compared to 2.1? 02:05:30 TabAtkins: Dropping some obscure encodings probably ok, since implementations' don't support them 02:05:51 TabAtkins: Wrt web-compat, shoudl be just fine 02:06:01 TabAtkins: dropping things like EBCDIC 02:06:15 liam: Did you check for corporate intranet stuff? 02:06:27 TabAtkins: I think likelihood of EBCDIC is close to zero 02:06:38 RRSAgent, make mintues 02:06:38 I'm logging. I don't understand 'make mintues', MikeSmith. Try /msg RRSAgent help 02:06:43 RRSAgent, make minutes 02:06:43 I have made the request to generate http://www.w3.org/2013/06/06-css-minutes.html MikeSmith 02:06:49 r12a: I thought same thing wrt bidi things, but ppl came back with supercomputers and stuff in Hebrew that were using old encoding systems 02:06:49 jet has joined #css 02:06:59 Bert: It was there. You're trying to remove it? 02:07:07 TabAtkins: Browsers didn't recognize it? 02:07:12 Bert: You can't remove thing 02:07:37 Bert: This is supposed to be stable 02:07:43 FWIW, IBM keeps ensuring that EBCDIC support is working in httpd. Someone at IBM would be able to give an idea of its reach. 02:07:50 Bert: We promised not to make versions to CSS, just to add things 02:08:06 Bert: Don't think we should remove features just because not used on the Web 02:08:11 Bert: Remove features when they're wrong. 02:08:51 [discussion of changes] 02:08:58 Bert: Not an argument to keep on making mistakes 02:09:15 r12a: When HTML5 did some charset stuff, wanted to do it to stop people using non-UTF-8 02:09:21 r12a: Is that your motivation? 02:09:34 TabAtkins: Highly sympathetic to moving to UTF-8, but main issue is making this much simpler 02:10:01 glazou: If all style sheets were UTF-8, would be much easier for authoring environments 02:10:44 q+ 02:10:56 dbaron: Checking for UTF-16 rules were widely tested 02:11:15 dbaron: We changed recently. Ran into no web-compat problems, but ran into certification problems. 02:11:27 ack SimonSapin 02:11:36 SimonSapin: Would like to point out that this is only about @charset. Can do anything you want with HTTP headers 02:12:12 SimonSapin: Also, relevant part of CSS2.1 gives a table of byte patterns. Allows UAs to remove some, or to add some 02:12:22 dbaron: Sorry, what I said is opposite. 02:12:46 dbaron: When we implemented what this draft sayse, and this caused us to start passing th GCF certification suite 02:13:18 dbaron: It has a test of a UTF-16 file that claims an encoding name that doesn't exist 02:13:36 r12a: What did you say was the first step in detecting charset? 02:13:43 r12a: Thought we changed so that BOM is first 02:13:51 the thing I was just describing was https://bugzilla.mozilla.org/show_bug.cgi?id=859706 being fixed by https://bugzilla.mozilla.org/show_bug.cgi?id=796882 02:13:57 TabAtkins: BOM is checked first by decoding algorithm, before @charset 02:14:06 TabAtkins: this list finds the fallback encoding 02:14:50 ... 02:15:04 r12a: Do you forbid use of @charset in UTF-16 documents? 02:15:08 TabAtkins: No, you just ignore it 02:15:19 er, actually, the encoding name does exist but it's an alias for UTF-16BE, while the file is UTF-16LE 02:15:22 TabAtkins: Never invalid to put @charset 02:15:38 plh: What if UTF-16 without BOM but with @charset? 02:15:47 TabAtkins: Defer to encoding standard... 02:15:53 r12a: you can do it, but say you shouldn't 02:16:53 s/plh/plinss/ 02:17:25 TabAtkins: Specifying anything other than ascii-compatible encoding is not useful 02:17:34 r12a: Since already defined, why not keep them? 02:17:39 r12a: I share bert's unease here 02:17:49 r12a: I agree it would be great to move to UTF-8 everywhere 02:18:21 TabAtkins: If implementations get bug reports on things should ask for standard to be updated 02:18:29 plinss: Would prefer to include this table 02:18:38 plinss: I know there are implementations that implement that entire table, because i made one 02:18:52 TabAtkins: Gecko doesn't anymore, don't think WebKit does either 02:19:09 dbaron: Gecko only implemented ascii-compatible cases and UTF-16 cases. 02:19:09 WeasyPrint implements that table 02:19:15 dbaron: never did UTF-32 or EBCDIC 02:19:26 dbaron: Might've done UTF-32 long ago, but that cod eripped out a long time ago 02:19:36 dbaron: ripped out support for UTF-32 entirely 02:19:57 TabAtkins: My preferred approach is to keep it as-is right now. if there's a problem, we'll see bug reports 02:20:01 TabAtkins: Alter as necessary 02:20:18 plinss: Not really happy with that approach. Break it and see who complains? 02:20:33 TabAtkins: Don't want to include rows that browsers don't implement it 02:20:51 plinss: But some that are significant 02:21:19 TabAtkins: Leave this in, with an issue maybe? 02:21:30 TabAtkins: Issue that we may need to add additional charset encoding patterns? 02:21:48 plinss: Maybe add onto that that we're explicitly requesting feedback on this 02:21:49 tlr has joined #css 02:22:02 WeasyPrint implements part of that table because I didn’t know any better. Some cursing was involved. 02:22:03 plinss: Agree we probably don't need EBCDIC, and a private browser could implement that for an intranet 02:22:17 plinss: But more concerned wrt UTF-16 issues 02:22:35 plinss: Web is huge. Small percentage is still a lot of pages 02:22:47 TabAtkins: encoding will detect 02:22:52 plinss: Shouldn't be sniff it 02:23:15 plinss: If there's a document that doesn't have BOM and has @charset, shouldn't be sniffing it. Should use @charset 02:23:46 SimonSapin: Can also rely on HTTP headers 02:23:56 plinss: We have problems e.g. in our test suite, file sthat work on the server, but not locally 02:24:20 plinss: CSS should not, don't think that we require style sheet to be served over HTTP 02:25:36 (The issue can ask which @charset lines can be deprecated.) 02:25:53 TabAtkins: Step 4, where you take charset from encoding document. Should that only work for same-origin? 02:26:54 s/4/3&4/ 02:27:20 r12a: Value of 4 is ppl who don't understand charsets or setting http headers 02:27:50 ... 02:28:09 TabAtkins: So, take charset from referring document only if it's same-origin. Yay/nay? 02:28:24 TabAtkins: Ok, I'll say yes for now, object later 02:28:27 Bert: what's issue? 02:28:45 TabAtkins: Sometimes if you can force a document into a different encoding, can extract info from it 02:28:55 TabAtkins: This would prevent that kind of thing 02:29:01 Bert: What could you do with a style sheet in wrong encoding? 02:29:41 TabAtkins: Don't have specific example, but this kind of problem has been an issue in other technologies 02:30:07 Bert: But you're only changing your own document, not someone else's 02:30:24 dbaron: Suppose has wiki, where input CSS that shoudl be sanitized 02:30:39 dbaron: Could have fun encoding , maybe UTF-7 or Shift-JIS or something, that can create cross-site scripting vulnerabilities 02:31:05 dbaron: Encode control characters for programming languages as benign ascii chars 02:31:32 TabAtkins: Can't give a specific attack scenario, just know there's problems in other languages 02:31:52 arno has joined #css 02:31:53 Bert: Concerned about people putting stylesheet on one server, seems to work, then moves it to other server, doesn't work. 02:32:04 TabAtkins: If you have a charset problem, use UTF-8 02:33:08 dbaron: Either way I'd prefer to leave an issue in there until we're confident it's stable. 02:33:21 (w.r.t. the same-origin thing) 02:33:27 RESOLVED: Make it same-origin, leave issue 02:35:00
03:22:22 jdaggett has joined #css 03:25:27 anyone in the room now? 03:25:33 only a few 03:25:42 (i am) 03:25:44 tab or dbaron? 03:25:50 nope - they are still eating 03:25:56 ok, thx 03:28:32 jdaggett: Yo. 03:28:52 hey, did you see the note about taro? 03:29:00 he'll be coming at 1 03:29:22 remember him? he was at kyoto f2f 03:33:15 I don't remember him, but sure. 03:33:30 Hm, I wonder how I should meet him. 03:37:05 he'll be at reception at 1 03:37:16 jdaggett: Okay, that works. I'll be downstairs then. 03:37:19 can you just tell the reception to expect him 03:37:29 cool, thanks! 03:38:49 leif has joined #css 03:43:57 rhauck has joined #css 03:47:02 jdaggett: Have you been to the shabu-shabu place? 03:47:11 nope 03:47:26 glazou has joined #css 03:47:27 were you able to reserve? 03:52:04 rhauck1 has joined #css 03:52:10 glazou: can we wait for taro to start the fonts discussion? 03:52:28 jdaggett, supposed to arrive when ? 03:52:34 1pm 03:52:47 i think tab is downstairs waiting at reception for him 03:53:18 no tab is right next to me, reminding him now 03:53:47 jdaggett: Yeah, I reserved it last night. 03:53:54 cool! 03:53:58 jdaggett: Just wanting to make sure I can get to it easily. ^_^ 03:54:14 it's pretty close when i looked on the map 03:54:15 did the full unlimited shabu-shabu, drinks, and sushi meal. ^_^ 03:54:19 Yeah, real close. 03:54:23 wow! 03:54:41 that's time-limited to 2 hrs... 03:54:44 Yeah. 03:54:51 Okay, running downstairs. 03:54:55 cool 03:57:07 plh has joined #css 03:58:20 is shane there today? 03:58:31 need to hook up the zakim connection again 04:03:27 ok, dbaron; conference Team_(css)04:03Z scheduled with code 26631 (CONF1) for 300 minutes until 0903Z 04:03:32 r12a has joined #css 04:03:37 waiting for shane and tab now 04:03:50 r12a: are you here for the fonts discussion? 04:03:57 shane went to look for Tab, so we can't set up the call now :-P 04:04:00 and r12a is here 04:04:04 yep 04:04:07 cool 04:04:16 lmclister has joined #css 04:04:23 shane back 04:04:35 phone bridge magic? 04:05:30 shane is casting a spell on the telephone right now 04:06:00 myakura has joined #css 04:06:54 Team_(css)04:03Z has now started 04:07:02 +[IPcaller] 04:07:10 zakim, ipcaller is me 04:07:10 +jdaggett; got it 04:07:22 ok, waiting for shane magic... 04:07:31 Rossen has joined #css 04:07:58 ScribeNick: Bert 04:08:03 Topic: Fonts 04:08:55 heh 04:09:20 sorry in advance, i'm in the visitor's room with a tv on in the background... 04:10:20 tab and taro arrive yet? 04:10:41 not yet 04:11:11 hmm, he says he's stuck on the third floor 04:11:31 can't come up to the 26th floor 04:11:33 argh 04:11:38 +??P0 04:11:53 both are here now 04:12:01 jdaggett, taro is here 04:12:12 Zakim, ??P0 is Meeting_Room 04:12:12 +Meeting_Room; got it 04:13:06 jdaggett: italic in vertical: 04:13:18 ... I recommend that Koji come to the mic 04:13:28 shans__ has joined #css 04:13:38 ... Background is that in Japanese there is no real tradioton of italic. 04:13:55 ... UAs just oblique synthetically. 04:14:12 ... When 'font-style: italic' on vertical text, what should it do? 04:14:27 ... If you have a normal italic font, you just use it. 04:14:35 ... Should the slant be different in vertical? 04:14:46 http://koji.ec/wp-content/uploads/2013/05/italics-vertical2.png 04:14:55 ... Example [see URL] 04:15:07 ... This is the options. 04:15:33 -Meeting_Room 04:15:33 ... figure 2 is normal italics. 04:15:43 jdaggett, we dropped off 04:15:52 ... Some in Japan have [lost phone] 04:16:10 One sec while we reconnect. 04:16:17 http://lists.w3.org/Archives/Public/www-archive/2013May/att-0027/synthetic-italics-tategaki.png 04:16:24 argh 04:16:57 +??P0 04:17:02 Zakim, ??P0 is glazou 04:17:02 +glazou; got it 04:17:04 Murakami-san's take: http://lists.w3.org/Archives/Public/www-style/2013May/0405.html 04:18:04 [Trying to reconnect to Zakim] 04:18:15 +??P2 04:18:18 -glazou 04:18:19 Zakim, ??P2 is Meeting_Room 04:18:20 +Meeting_Room; got it 04:18:37 http://koji.ec/wp-content/uploads/2013/05/italics-vertical2.png 04:18:55 [example on screen] 04:19:00 dino has joined #css 04:19:08 http://lists.w3.org/Archives/Public/www-archive/2013May/att-0027/synthetic-italics-tategaki.png 04:19:08 jdaggett: Koji and Elika propose figure 3 04:19:17 current fonts spec has #2, Koji and Elika propose #3 04:19:27 jdovey has joined #css 04:19:30 [new image on screen] 04:19:30 (move jdaggett's last URL to here) 04:19:46 jdaggett: Mixture of 2 with a real italics font. 04:19:53 ... I don't say which is better. 04:20:12 ... Slope down to the right in 3 04:20:25 ... All kinds of arguments possible about what is better in diff. cases. 04:20:41 ... But there is no tradiotn of italic in Japanese. 04:20:56 ... But Koji brought up that there is tradition of obliquing 04:20:58 http://lists.w3.org/Archives/Public/www-archive/2013May/att-0032/harrypotter-7-193.png 04:21:33 [example on screen] 04:21:50 jdaggett: This is oblque to the left. 04:22:04 ... Koji found this. 04:22:27 ... There should not be a distinction between real italics and synthetic case. 04:22:31 ... Bad inconsistency. 04:22:41 ... If we want oblique in eneral then we need better control. 04:22:54 ... We are still fighting arouhnd the edges. 04:23:12 ... Comments? Koji,Taro? 04:23:24 Koji: Not agaisst your opitinion 04:23:45 ... I want consistent for sideways characters, that's were moset italic will be. 04:23:54 Taro: Why you don't agree? 04:24:05 ... Historically there haven't been any slanted Japanese 04:24:25 ... Limited to display type, headlines etc. One line only. 04:24:44 ... We have Times Roman and it has italic. 04:24:58 ... It is possible to apply automatic transform, slanting. 04:25:07 ... Not in Japanese context. 04:25:14 ... Two notions. 04:25:24 ... There is no [missed] 04:25:40 Koji: Progessionls say there is no italic, but authors stll want it. 04:26:00 jdaggett: Give them the option if they want something like Harryt Potter example. 04:26:10 ... It has down slant on the left. 04:26:24 ... Authors cannot do that. 04:26:45 ... Putting behavior in general behavior doens't give authors the control. 04:26:51 Koji: I discussed with authors. 04:26:56 ... They udnerstand. 04:27:05 ... They stil prefer synthetic italics. 04:27:16 ... Too many points too discuss. 04:27:21 .. Do them one by one. 04:27:39 ... 1st is synthesize or not? 04:27:44 ... 2nd is which direction. 04:28:01 jdaggett: Spec now says synth happens based on whether there is italic or not. 04:28:18 ... Whether synth italic is good or not is separate matter. 04:28:35 ... If we have to have synth italic, and we do, then it has to be consistent with real italic. 04:28:46 . Not based on horiz or vertical or other factors. 04:28:51 q+ 04:29:00 ... I dont' agree with the way your quoting me. 04:29:11 ... We have font-syyle in CSS and it allows synthesize. 04:29:18 ... We have to continue that. 04:29:47 Taro: If proper true slanting operations for Japanese is not defined, 04:30:07 ... I have to object allowing [???] 04:30:25 ... It will make it easier for user to get accustomed to current deteriorated situation., 04:30:27 s/[???]/synthesizing italics by slanting/ 04:30:35 ... People will continue current and that is not good thing. 04:30:42 ... In Harry Potter case, 04:30:51 ... Where slanting neessary, we should do that, 04:30:59 ... But we have no correct diefitionn yet. 04:31:05 ... Once defined and documented, 04:31:16 ... Yes allow some kind of algorithm, 04:31:24 ... Slanting may be necessary. 04:31:49 ... Without knowing wjhat Japanese slanting shuld bem it is very risky to link between existing and cjose slantoing operation. 04:31:56 ... Look at ROmand and japanese char 04:32:03 ... Maby metrics differemt. 04:32:18 ... You have beedn accustomied to switching italic and roman. 04:32:34 ... Always assumed that you will find an italicfont. 04:32:45 ... That doesnt exist in japanese world. 04:32:55 ... My recomendation is to do nothing. 04:33:03 ... That is best becase there is no italic in japanese. 04:33:15 ... Doing something is OK, but please define what the shearing oepration should be, 04:33:35 ... Oherwise popel will just be happy with the current stats eand think is is fine. 04:33:47 ... That will not guarntee good graphic and visual effect. 04:33:53 ack r12a 04:33:59 r12a: Asking for clarifiction: 04:34:07 ... In Harry Potter is is down to the left, 04:34:14 ... What would happin in horizontal? 04:34:24 Koji: No, it would be to the right. 04:34:38 jdaggett: This is a pblished example. 04:34:48 .. Koji and Elika proposed slanting down to the right. 04:35:11 Koji: I'm proposing the number 3, jdaggett propose 2 04:35:17 [Harry Potter is 1] 04:35:42 Koji: Japanese authors want 1 if combined with ltin text, otherwise 3. 04:35:52 ... I asked publishers what they want. 04:36:02 ... After discussion they said 3 works best for now. 04:36:08 ... Until we get more precise control. 04:36:22 jdaggett: 3 introcudes inconstency when there are real italics. 04:36:40 koji: Japnese font will not have real italics. 04:37:06 jdaggett: But western author miing text will get 3, that does not look right. 04:37:33 ... [Confusion over which number 3] 04:38:04 ... [Looking at tategaki image] 04:38:12 ... That will look bad. 04:38:20 Koji: There is no single way to solve all issues. 04:38:29 ... Not in level 3. 04:38:35 in http://koji.ec/wp-content/uploads/2013/05/italics-vertical2.png , #1 is skewY(-10deg) for Japanese, #2 is skewX(-10deg) for Japanese, #3 is skewY(+10deg) for Japanese (note +- and XY changes) 04:38:47 ... Latin upright use case is less important. 04:39:03 jdaggett: Japanese italic is difficult to find. 04:39:22 fantasai: The examples are not real italcis, they re some diffirent feature. 04:39:35 ... Fndamental question is direcion of shearing. 04:39:42 ... [drawing on whiteboard] 04:40:08 liam: q for Koji: 04:40:21 ... We often say that dureing standards and it comes back to bite us. 04:40:27 ... "until we have more control" 04:40:35 ... We're often stuck with that. 04:40:45 ... Don't precluse anythign in the futre. 04:41:00 Koji: Yes, with more control authors will be happy. 04:41:07 ... But even now they ar ehapy with 3. 04:41:13 Taro: Do not agree. 04:41:14 in http://lists.w3.org/Archives/Public/www-archive/2013May/att-0027/synthetic-italics-tategaki.png , #1 has skewX(-10deg) for ja and en, #2 has skewY(+10deg) for ja and en, #3 skewY(+10deg) for ja and skewX(-10deg) for en 04:41:14 s/precluse/preclude/ 04:41:28 ... Hary Potter exmaple is not italic. It is slanted, yes. 04:41:36 ... Iv'e done slanting myself. 04:42:12 ... [fantasai tries to draw. Taro doesn't'thnk the drawing is right] 04:42:37 ... It is necessary to align line direction and angle. 04:42:48 ... Japanese phototypesetting at slanted line. 04:42:55 ... Possible, I know. 04:43:08 ... Sometimes people ant that, but it is not italic. 04:43:27 Rossen: For mcirosoft, I'm not an expert in this area. 04:43:38 ... From talking to Office team: 04:43:49 .. Feedback was that we had italics in word for 20 years. 04:43:55 .. Since MS Gothic. 04:44:05 ... Regardless of how good or bad, there is adoption of it. 04:44:14 ... People ar eusing italic in vertical. 04:44:22 ... How mny make it to the Web I'm not sure. 04:44:34 ... If nedded I can find examples. 04:44:38 Present+ Taro Yamamoto (Adobe) 04:44:43 ... Expected that these document will become HTML. 04:44:52 jdaggett: How many are using th feature? 04:44:55 Rossen: I don 04:44:59 ... t have data 04:45:13 jdaggett: There were certain assumption made a long time ago. 04:45:25 ... The initial Word model was simple. 04:45:36 ... Should not look at that backwards compt. 04:45:44 Koji: Used for 20 years. 04:45:50 jdaggett: How often? 04:46:01 Rossen: As often as anybody wants to use italic in vertical. 04:46:17 Taro: Adobe Indesign since 10 years ignores italic in Japnese script. 04:46:26 ... It seems to be a script property. 04:46:50 ... Adobe's Japanese fonts have italic glyphs for Latin. 04:47:01 ... You can do tru italic with Adobe fonts. 04:47:15 ... But not to any Japanses font. 04:47:22 ... Only if glyphs included in the font. 04:47:32 ... IS this really a font property? 04:47:39 ... Western context OK. 04:47:48 ... OK with font property there. 04:48:04 ... You can assume that Times Roman has italic. 04:48:11 ... But no such assumption in japanese context. 04:48:22 Koji: So we're back to synthesize or not. 04:48:42 ... Make a spexil rule for japanese to not synthesize if font not available? 04:48:53 r12a: Only Japanses or CJK? 04:49:09 Taro: Any script that have no italic semantics. 04:49:23 Koji: In Unicode often difficult to know script. 04:49:33 ...Should not depend on codepoints for scripts. 04:50:05 ... If we can resolve this, than we candecide how to synthesize (if we decide to synth). 04:50:17 fantasai: What do Koreans do? 04:50:44 jdaggett: Easy way is to use an italic font. But I'm interested in the fallback case. 04:51:07 r12a: Russina also a pb. 04:51:21 ... Shapes in italic very different from romanan. 04:51:28 .. Slanting won't work. 04:51:31 +1 to less faux italic magic 04:51:41 dbaron: Spec says *may* synth, isn't it? 04:51:50 jdaggett: Yes, but users will expect it. 04:51:57 jdaggett: but all UA's do it, so users expect it 04:52:25 Koji: Yes, spec says that. I want consistency *when* the UA synthseses. 04:52:40 glenn: Conditional required spec text 04:53:02 jdaggett: UAs do that, but users should have way to turn it off. 04:53:04 s/Conditional required/conditional mandatory/ 04:53:27 glazou: I think we have to resolve and move on 04:53:47 jdaggett: Strawpoll and move on. 04:53:56 ... Let me get the example. 04:54:09 sgalineau has joined #css 04:54:15 ... Tategaki figure 04:54:43 [Tategaki figure now on screen] 04:54:48 proposals: 04:55:20 [vertical2 now also on screen] 04:55:31 1. synthetic italics follow actual italics (glyphs slanted to the right independent of orientation/vertical/horizontal) 04:55:36 dino has joined #css 04:55:56 2. synthetic italics in the vertical case are slanted down to the right 04:56:07 isra has joined #css 04:56:19 kawabata has joined #css 04:56:50 ["LETTERS 123" on the left, "Italics 123" on the right] 04:56:59 proposal 1 == tategaki example #1 04:57:03 proposal 2 == tategaki example #2 04:57:05 jdaggett: red #1 is prposal 1 04:57:18 red #2 is proposal 2 04:58:02 dean: 1 and 2 talk about latin text, rotated or upright? 04:58:22 jdaggett: Proposal is to follow actual italic. 04:58:35 ... [scribe confused] 04:58:48 …[not only the scribe...] 04:58:55 dbaron: So apply to all italci tetx, incl latin and ideog? 04:58:58 jdaggett, can we use Koji's example? it is so much easier 04:59:16 jdaggett: I think we had no disagreement. 04:59:45 Koji: Your prop is red 1 and sideways 2? 04:59:54 .. My prop is red 2 and sideways 3 05:00:06 jdaggett: Fine 05:00:26 ... Synth italic and real italics are going to be different in Koji's propoosal. 05:00:36 [Koji to jdaggett mapping] 05:00:41 Koji: Depends on which consistency you want. 05:01:01 ... Your picture shows more consistency with upright letetrs. 05:01:08 ... Mine more against baseline. 05:01:32 glazou: There are other vertical writing systems, such as Mongolian. 05:01:38 ... Will tjis apply there? 05:01:55 jdaggett: Yes, but hose systems do not have tradition of italics. 05:02:02 ... So less need for authors. 05:02:16 glazou: I have a set of Mongolian fonts with italics in front of me. 05:02:26 [People gathering arounf glaxou] 05:02:46 r12a: Maybe becaus eit is basically rtl system. 05:02:55 #1 has skewX(-10deg), #2 has skewY(+10deg) 05:03:14 Koji: [...] best beahvour in CSS and acceptable. 05:03:22 ... If one face is not available... 05:03:51 glazou: I want to make sure proposals are fit for other writing systems. 05:03:59 jdaggett: Only the synthetic case. 05:04:13 .. If user uses italic font, he gets it. 05:04:18 jdovey: ding ding ding 05:04:30 dbaron: We shoul;dn't hold up LC over a fallback case. 05:05:05 fantasai: If you use Koji style, you will break connecions in Mongolian [scribe not sure] 05:05:18 ... Mongolian glyphs sudeways 05:05:40 ... If Mongilian were to be defined in terms of upright,as jdaggett wants, than this would break connections. 05:05:47 jdaggett: There is no use case for that. 05:06:17 ... The examples you brought up. There is no [...] italic context. 05:06:24 .. Thin air, no real use case. 05:06:32 Koji: No, it exists. 05:06:43 glazou: strwapoll. 05:07:08 Option 1 = red 1 05:07:12 Option 2 = red 2 05:07:16 TabL abstain 05:07:25 koji 2 05:08:10 ivan: ab 05:08:13 glazou: abs 05:08:16 SimonSapin: abs 05:08:22 Jet red 1 05:08:52 taro: 1 05:08:57 Rossen: sen 2 05:09:02 Alan 1 05:09:10 Rebecca: abs 05:09:12 dean 1 05:10:00 dirk: abs 05:10:09 rik: abs 05:10:12 leif: abs 05:10:24 (dirk and Taro would have voted for the third drawing for the whiteboard, which has no synthesis in vertical Japanese) 05:10:26 ??: 2 05:10:33 s/??/Kazutaka 05:10:41 s/??/Kazutaka/ 05:10:48 liam: 1 05:10:57 justin: 2 05:11:02 shane: abs 05:11:06 jim: abs 05:11:11 bert: abs 05:11:33 r12a: abs in favor of futher evidence, as westerneer prefer 1 05:11:42 plins: abs 05:11:45 dbaron: abs 05:11:49 glen: 1 05:11:53 fantasai: 2 05:12:19 ... problems not as often . 05:12:38 [6 to 5 in favor of 1] 05:13:07 13 abs 05:13:26 jdaggett: 1 05:13:33 [7 to 5 in favor of 1] 05:13:56 [discussion about live with and object...] 05:14:31 jdaggett: Weak consensu os to do something because we do not have a real property to allow obiquing. 05:14:45 ... Not do this as a substitute for doing somethjing else. 05:14:53 glazou: So leave it undef? 05:15:09 jdaggett: No, go with 1, because 2 is relly advocating for a new feature. 05:15:23 Koji: No, then we have to define for Ruby, etc. 05:15:28 ... Those conflict. 05:15:31 jdaggett: [missed] 05:15:58 glazou: We have 7 to 5, so option 1 or leave undef. 05:16:05 jdaggett: Either is fine. 05:16:17 ... But not option 2 05:16:32 [hands up for udnefined] 05:16:37 [Some hands up] 05:16:46 RESOLVED: Leave undefined. 05:17:15 jdaggett: Netx issue. 05:17:25 ... fantasai 's issue on sub/superscript 05:17:30 http://lists.w3.org/Archives/Public/www-style/2013May/0285.html 05:17:33 My concerns with 1 are that there are cases that break with it, even though it is typographically better. Since the correct solution is to use an italic font, this fallback case should just be the option that works adequately in the most cases. And #2 does that: it doesn't create overlapping problems, it doesn't break multi-glyph constructs, and it doesn't break cursive scripts or fonts. 05:17:51 ... What to do about text decorations in superscript variant glyphs. 05:17:53 http://lists.w3.org/Archives/Public/www-archive/2013May/att-0025/superscript-underline.png 05:18:07 ... Let me explain the example. 05:18:23 [Looking at e-mail msg] 05:18:28 [Looking at image] 05:18:42 jdaggett: Different kinds of sub & super 05:18:56 ... Using HTML, font shrink and vertical align 05:19:07 .. Second uses Unicode codepoints for super and sub 05:19:20 ... 3rd is suing feature in draft. 05:19:28 ... What an undelrine looksk like 05:19:48 ... 2nd has underline just to superr 05:20:05 https://coreldraw.com/cfs-filesystemfile.ashx/__key/CommunityServer.Components.PostAttachments/00.00.17.55.90/workaround.jpg 05:20:08 .. Difference in baseline 05:20:26 ... Metrics same as surronfing text for Unicode superscript glyphs. 05:20:39 ... FOnt has metrics for syntheseis 05:20:51 ... This pb exists with Unicode code points already. 05:21:00 ... My point is that we don't need to do anythign special. 05:21:10 ... You get what you get in 2nd example. 05:21:17 ... You don't get detailed control. 05:21:32 fantasai: The one we want is what matches the HTML example. 05:21:38 .. Thatos what people want. 05:21:58 ... Take info from font, and use that to position underline. 05:22:07 jdaggett: That doenst match where the glyphs are. 05:22:14 ... Cannot have magic. 05:22:24 ... Fallback won't work. 05:22:29 ... etrics are different. 05:22:38 fantasai: But it will match synthesized glyps. 05:22:46 jdaggett: No, not close enough. 05:22:56 fantasai: he bottom examples don't look right at all. 05:23:01 ... We can get closer. 05:23:09 jdaggett: Just wrong in a different way. 05:23:20 ... Adobe's font all have same metrics. 05:23:29 ... Aling will be differne tbase don font. 05:23:47 http://dev.w3.org/csswg/css-fonts/#font-variant-position-prop 05:23:59 glazou has left #css 05:24:02 [looking at figure 22] 05:24:27 jdaggett: Showis diff ebtween real superscript on left and synth version in middle. 05:24:32 ... Baseline is not the same. 05:24:44 ... Will have unerline in middle. Not look right. 05:24:58 .. We hav ebeen trying to come with magic for a year and a half. 05:25:09 ... Text decoration same issue coming back all over again. 05:25:17 ... We kust don't have it, it i snot available. 05:25:35 Leif: Can the font p[rovide metrics? 05:25:44 fantasai: Yes, they could. 05:26:11 jdaggett: Not the right answer. The metrics are meant fo rthe synth case. 05:26:25 ... Example 22 shows that synth superscript is larger. 05:26:36 ... Designer made it so. 05:26:44 ... Metrics work with synth. 05:26:54 ... Not so well fo rthe designed glyphs. 05:27:03 ... Which is what you propose to use them for. 05:27:09 I still think it's better to use those metrics than to use the base size metrics 05:27:28 ... Complex content [...] 05:27:44 ... It is not meant as complet ereplacement for HTML mark-up. 05:27:53 ... There are limitations, noted in the spec. 05:28:15 fantasai: I'd like to edit text deco spec to say we use font metrics in font. 05:28:32 jdaggett: What are doing? 05:28:35 glenn: I agree 05:28:42 ... The metrics don't match what you want to sue them for. 05:29:02 glenn: If the font *doe* have metrics, they should be used. 05:29:14 ... Agreed? 05:29:37 jdaggett: The metrics are used for synthesis. 05:29:45 ... If you resize, 05:29:58 ... The metrics don't matchs the actual glyphs. 05:30:16 ... Sure, if you design a font with metrics, but that is a big "if." 05:30:22 .. Not common practice. 05:30:49 ... Other comments or questions? 05:31:17 glazou has joined #css 05:31:18 Leif: Seems fantasai 's suggestion works in exmaple 22, but maybe not for subscript. 05:31:23 ... Maybe not in gemeral. 05:31:36 fantasai: Metrics of base size is not any better, propbably worse. 05:31:56 Leif: I don't really know how fantasai 's uggestion will turn out for subscripts. 05:32:06 ... Better result more often than not? 05:32:45 glenn: If font designed specs a sub or super feature, but without glyphs, you suggest we synthesize? 05:32:55 jdaggett: Spec ahs wording about that. 05:33:07 ... We do include wording for fallback, we will synthesize. 05:33:28 ... If user adds elements or images, or sub-spans, then they should use the HTML way. 05:34:01 ... We pretty much resolved on the feature not being a complete replacement for HTML mark-up, and it shuldn't be one. 05:34:15 glenn: Is there consistency among UAs for fallback? 05:34:32 jdaggett: Nobody implemented it, no cmparison to make. 05:34:48 ... Gecko has impl ebhind a flag, but without the fallback behavior. 05:34:55 glenn: Mark fallback at risk? 05:35:02 jdaggett: Why? 05:35:17 glenn: Lack of implem experience. 05:35:34 jdaggett: No strong case, spec is just not finsihed yet. 05:35:56 glenn: No early implementers either. 05:36:10 glazou: Can the people discussing now find a compromise? 05:36:37 jdaggett: What do ypu want me to compromise on? 05:36:42 ... There si nothing. 05:36:53 fantasai: Cannot live with John's option. 05:37:16 jdaggett: You're propisng magic, not a real proposal. 05:37:57 plinss: If metrics available, use them, but seems there are none. 05:38:20 jdaggett: Based on what research? 05:38:35 plinss: Metrics are for something else, acoording to jdaggett 05:38:54 ... So if the metrics don't exist, [...] 05:38:56 Rossen, and jdaggett a longsword ?-) 05:39:10 fantasai: But if they exists it will be right, and otherwise they will be slighty off. 05:39:30 plinss: Fine with a note in text decoration about if there are metrics. 05:39:37 fantasai: We have to put the underline somewhere. 05:39:46 ... Which metrics do you use. 05:40:00 glazou, Nooo just a swiss knife 05:40:11 ... Just because Unicode glyohs have this pb, doesn't mean we have to copy the pb. 05:40:17 liam: Proposal: 05:40:27 ... WebFonts WG has liasion with ISO Opentype 05:40:34 ... Chair of WG. 05:40:44 ... Ask them about a new metric. 05:40:55 ... Not invent something ourslelves. 05:41:16 jdaggett: Shors delay, are you joking? 05:41:38 liam: If we have to wait for a new feature, that would be long. But not long to ask the question. 05:41:47 jdaggett: We have been trhought this. 05:42:12 Liam: In that case redraw suggestion. 05:42:21 plinss: Still useful to talk to Opentype. 05:42:34 glenn: Truetype has different tables. 05:42:55 glenn: ... bsln (Truetype) vs BASE (OpenType) 05:42:56 ... Are we too specific to OpenType. 05:43:00 jdaggett: [missed] 05:43:06 jdaggett: superscript metrics are in OS2 table 05:43:13 glenn: Asking because you also mention baseline offsets. 05:43:19 ... Just wondering... 05:43:45 ... You and Elika get together. 05:44:17 glazou: strawpoll. 05:44:43 fantasai: Proposal is for when superscripts or subscripts are decorated, use superscript/subscript metrics to position decoration 05:44:52 plinss: Are you taling about synth *and* non-synth case? 05:44:57 jdaggett: The text underline follows the surrounding glyphs (for both in the synthesized case and the actual glyphs case) 05:45:01 fantasai: jdaggett's proposal is that instead, use the metrics of full-size glyphs 05:45:05 jdaggett: Yes, behave same way, nortmal baseline, not shifted. 05:45:23 TabAtkins: [pointing to figures] 05:45:49 dbaron: jdaggett only refers to Unicode codepoints, not to the HTML version. 05:46:23 fantasai: That means underline the whole thing as the full size chars, 05:46:24 fantasai: in the example, jdaggett wants the OpenType version to match the Unicode version rather than the HTML ersion 05:46:42 fantasai: People do not undelrine the degree char, but they do underline superscripts. 05:47:20 TabAtkins: jdaggett 's proposal is the lower half of the current projected screen. 05:47:43 [7 hands for jdaggett proposal] 05:47:54 [7 for fantasai 's proposal] 05:47:58 [rest abstain] 05:48:24 [8 hands for jdaggett proposal] 05:48:26 [plus 1 for jdaggett , jdaggett himself] 05:48:34 s/jdaggett only refers to Unicode codepoints, not to the HTML version/we're talking about what happens with the new feature for using font features, not using vertical-align/ 05:48:54 jet: Does this hold up LC on fonts? 05:49:03 fantasai: No, it is an issue for text decoration. 05:49:28 jet: We should really resolve this, cannot keep on fighting. 05:50:17 plinss: If is not on fonts, let's leave it open issue on text deco and move on with fonts. 05:50:46
05:50:49 [break 15 mins] 06:03:40 Rossen has joined #css 06:04:38 zakim, mute jdaggett 06:04:38 jdaggett should now be muted 06:04:58 ooops, sorry 06:10:50 jdaggett, about to start again 06:11:58 Zakim, unmute jdaggett 06:11:58 jdaggett should no longer be muted 06:12:02 zakim, unmute jdaggett 06:12:02 jdaggett was not muted, plinss 06:12:19 [glazou and fantasai discuss which issue to treat next] 06:12:26 not hearing you... 06:12:35 zakim, who is on the phone? 06:12:35 On the phone I see jdaggett, Meeting_Room 06:12:43 is your phone muted? 06:12:49 Zakim, unmute Meeting_Room 06:12:49 Meeting_Room was not muted, glazou 06:12:59 wait 06:13:26 OM representation of @font-feature-values rule 06:13:29 Topic: font feature at-rule in OM 06:13:57 http://dev.w3.org/csswg/css-fonts/#om-fontfeaturevalues 06:13:59 jdaggett: [looking for URL] 06:14:34 ... fantasai posted that it should be different, ensued a thread. Tab prposed a subclass of grtouping rule. 06:14:53 ... And then make each feature block another subclass. 06:15:07 ... I'd like to gauge group's opinion. 06:15:15 ... Whos is interested in implementong? 06:15:42 glazou: comments? 06:15:45 Heres the comment http://lists.w3.org/Archives/Public/www-style/2013May/0580.html 06:15:54 dbaron: Mixed feelings 06:16:19 ... If it looks like an 2rule it should behave like an at rule. On other hand an awful lot of pieces to make. 06:16:46 fantasai: I know Tab has comments, wait for him to come back into the room. 06:17:02 jdaggett: Let me look for Tab's stuff. 06:17:04 http://lists.w3.org/Archives/Public/www-style/2013May/0596.html 06:17:34 jdaggett: Follow on from that is that grouping rule often [missed] 06:17:50 example 06:17:54 @font-feature-values Bongo { 06:17:55 @swash { 06:17:56 swishy : 1; 06:17:57 SimonSapin: Independent of whether descriptors or declarations are involved 06:17:58 wavvy-gravy: 2; 06:17:59 } 06:17:59 } 06:18:36 dbaron: Hesitant to reopne discussion, but makes me wonder if there is too many levels of nesting. 06:18:48 @font-feature-values Bongo { @swash swishy 1; @swash wavvy-gravy 2; } 06:18:52 ... Why in that example, not like this [see above] 06:19:13 jdaggett: That was original proposal, but we switched to more at-rule-like version. 06:19:23 fantasai: Both are at-rules. 06:19:35 plinss: Don't see why not a group rule. 06:19:44 ... But don't want ot separate i/f classes 06:19:50 ... for each class. 06:20:06 TabAtkins: I proposed to match them. 06:20:16 ... Should be on m-list. 06:20:23 s/match/map/ 06:20:29 ... Just expose the at-swatch as properties of feature-values 06:20:33 ... js-maps 06:20:37 ... Or maybe a string 06:20:49 ... they'll merge 06:20:55 plinss: Makes sense. 06:21:07 fantasai: [question] 06:21:16 jdaggett: [bad sound] 06:21:23 fantasai: Didn't you have a simplifying proposal, that we could expand later? 06:21:26 ... My proposal is at-rule with nothing in it. 06:21:41 TabAtkins: [explains proposal] 06:21:55 fantasai: could go with that, and than make a css3 font extensions spec. 06:22:00 ... Needs more work. 06:22:12 dbaron: We're not ready to conclude that yet. 06:22:21 jdaggett: font load events is not the approriate place. 06:22:31 dbaron: What Tab described sounds fine. 06:22:45 [tab writes on wboard] 06:23:01 dbaron: TAG is going to review APIs. 06:23:13 ... Tab's propal fits what TAG expects. 06:23:23 interface CSSFontFeatureValuesRule { attribute Maplike swash; ... } 06:23:31 glazou: example with Bongo, what would be value text? 06:23:40 (Maplike is proposed for WebIDL.) 06:23:44 ... from @swatch to closing brace. 06:23:53 Tab's proposal is in http://lists.w3.org/Archives/Public/www-style/2013May/0781.html 06:23:56 ... That is painful for editor. 06:24:03 [two people talking] 06:24:16 jdaggett: When I asked you you said it was no pb. 06:24:36 s/you you/you in Tucson you/ 06:24:43 jdaggett: tab, is it writable? 06:24:46 TabAtkins: Yes 06:24:55 I said I could live with it, I did not say it is perfect 06:25:06 plinss: values are always potential list of numbers? 06:25:09 jdaggett: Yes 06:25:29 plinss: Then lets not make everything a string when it can be a primitive in JS. 06:25:35 ... So an arry of numbers. 06:25:38 plinss: should be a map of string -> number or string -> array of number 06:25:40 jdaggett: yeah 06:25:45 tab: no pb 06:25:54 ... Any objections to my proposal? 06:25:58 glazou: I like it better. 06:26:10 dbaron: Is this ready in next month or so? 06:26:17 http://lists.w3.org/Archives/Public/www-style/2013May/0781.html 06:26:20 TabAtkins: Cameron is going to add map-likek thing. 06:26:28 ... Porposed a few weeks ago. 06:26:32 interface CSSFontFeatureValuesRule { 06:26:33 attribute Arraylike familyList; /* An array of family 06:26:35 name strings. */ 06:26:36 attribute Maplike swash; /* A map of feature 06:26:38 names -> feature values */ 06:26:39 ... Cannot be string, ... 06:26:39 attribute Maplike styleset; /* Ditto */ 06:26:40 attribute Maplike ornaments; /* Ditto */ 06:26:41 ... 06:26:42 } 06:26:44 plinss: [missed] 06:26:47 fine by me 06:26:54 better than just one large string 06:27:02 cabanier has joined #css 06:27:08 tab: Yes, could just manually put it all in by hand, but ideally use IDL. 06:27:25 glazou: Resolve on Tab proposal? 06:27:34 jdaggett: Is that the one in IRC? 06:27:40 plinss: without string. 06:27:55 jdaggett: Others are interested in implem,enting it? 06:28:15 dbaron: you, tab? 06:28:29 TabAtkins: maybe, probabaly not, working on syntax... 06:28:40 dbaron: fine with proposal, worried that nobody implements it. 06:28:56 Ms2ger has joined #css 06:28:59 plinss: what is dbaron's q precisely? 06:29:11 dbaron: New IDL concept, or add a lot of hand writing JS 06:29:19 ... Maybe 2 months of work. 06:29:36 plinss: You have to do that soon anyway. 06:29:46 jet: hand-written bindings nowadays. 06:29:52 TabAtkins: More verbose. 06:30:00 plinss: WebIDL is on its way up. 06:30:02 s/jet:/jet: we don't write/ 06:30:24 dbaron: I think we can resolve. 06:30:35 RESOLVED: Tab;'s proposal for OM 06:30:50 FWIW: WebIDL replacement: https://github.com/w3ctag/jsidl 06:30:52 jdaggett: next issue is 06:31:02 ... feauture value blocks in spec, 06:31:12 ... fantasai says they should just be called at-rules. 06:31:21 ... But I think they are different. 06:31:28 ... User defined identifiers. 06:31:38 ... The way they compound is an issue. 06:31:54 ... I tink it is important to day this is different form other at-rules, with descriptors. 06:32:09 Tab: That is just about terminology. 06:32:22 whttp://www.w3.org/TR/CSS21/syndata.html#at-rules 06:32:25 is the resolved proposal the one from: http://lists.w3.org/Archives/Public/www-style/2013May/0781.html ? 06:32:32 ... It starts with an 2-keyword, all at-rules ar edifferent already. so it is just an at-rule. 06:32:34 " At-rules start with an at-keyword, an '@' character followed immediately by an identifier (for example, '@import', '@page'). 06:32:37 An at-rule consists of everything up to and including the next semicolon (;) or the next block, whichever comes first. " 06:32:38 s/2/@/ 06:32:54 glenn: Confusing for users to try and distinguihs them. 06:33:09 jerenkrantz: yes, with a change from string to numbers (as far as I understood) 06:33:11 fantasai: CSS 2 calls it an at-rule when it starts with an at-keyword. 06:33:24 jdaggett: Yes, parses like an at-rule. 06:33:33 ... Shoild we not call it something else? 06:33:36 stearns: Thanks. 06:33:47 TabAtkins: Within the spec, call it what you want. 06:33:57 ... Whatever makes sense. But technically it is an at-rue. 06:34:06 fantasai: Must be clear that it parses like one. 06:34:17 TabAtkins: ; But "font feaure value block" or whatever is fine. 06:34:22 ... It expresses the concept. 06:34:23 zcorpan has joined #css 06:34:46 jdaggett: So I need to say somewhre thet at-feature-value blocks aare at-ules. 06:35:18 jdaggett: issue on font load postpone to tomoorow? 06:35:36 fantasai: Other issue is override. 06:35:41 jdaggett: Tomoorow, too? 06:35:44 fantasai: sure 06:36:06 jdaggett: Than that is it for fonts for now. 06:36:18 s/Than/Then/ 06:36:28 Topic: Syntax 06:36:40 TabAtkins: tokeinzation changes 06:36:56 ... To match HTML, NUL chars are converted into replacement chars. 06:37:17 ... Don't know why HTML does it, but at least it means CSS inside HTML is same as CSS in a file. 06:37:34 fantasai: Replacement char is valid identidier char, could be weird. 06:37:44 TabAtkins: Nobody puts NUL in a style sheet.... 06:38:04 RESOLVED: NUL gets turned into Replacement char. 06:38:28 tab: non-ascii range 06:38:36 SimonSapin: We already changed that. 06:39:02 glenn: Isn't the name non-ascii wrong then? 06:39:10 s/changed/resolved on/ 06:39:18 TabAtkins: No it now it includes *all* non-ascii. 06:39:35 TabAtkins: comments 06:39:49 ... tokenizer never emits them. 06:40:03 plinss: What about comments between idents? 06:40:18 TabAtkins: Yes, serialzier forces an empty comment there. 06:40:25 zcorpan has joined #css 06:40:33 plinss: OK, but does it change parsing behavior anywhere? 06:40:54 [tab draws on whiteboard] 06:41:08 r12a has joined #css 06:41:22 Tav has joined #css 06:41:24 tab: It should just be an internal simplifvation 06:42:09 Bert: Not sure what you mean. 06:43:47 Bert: there is no tokenization process 06:44:23 [argument between Bert and Tab/peterl/etc.] 06:44:34 ivan has joined #css 06:44:39 bert: [worried about how people interpret "not emit"] 06:44:54 TabAtkins: It describes hwo you serialize. 06:45:04 Rossen has joined #css 06:45:18 cabanier has joined #css 06:45:23 glazou: We said in the paast that one way to preserve comments was to preserve them combined at the end. 06:45:29 ... Important for editors. 06:46:21 glazou: comments should be in original position, but cnnot always be done. 06:46:37 RESOLVED: loosen the rules describing the way comments are serialized 06:47:49 http://dbaron.org/css/test/2013/urange-token 06:47:53 TabAtkins: CSS 2 defines unicode range tokens in lazy way 06:48:06 fantasai: The difference is detectable. 06:48:14 dbaron: By means of counter increment. 06:48:47 fantasai: No real reason to not keep the same. 06:49:00 ... Do not chnage the token. 06:49:14 ... nder your rules some old are not longer valid, and it is detecatable. 06:49:21 tab: No, not detectable. 06:49:42 ... U+2?3?4? 06:49:54 fantasai: We have to range chaecking. 06:50:01 s/to/to do/ 06:50:23 TabAtkins: No, [describes three cases] 06:50:35 dbaron: css3-fonts doesn't say it gets thrown out. 06:51:00 jdaggett: what gets thrown out? 06:51:02 U+400-3ff 06:51:07 dbaron: fonts spec not clear 06:51:16 unicode-range: U+100-1ff, U+400-3ff 06:51:17 ... Is [above] a syntax error? 06:51:38 ... Is that empty range or invalid and throw away whole line? 06:51:55 [tab and fantasai disagree on previous discussions] 06:52:03 TabAtkins: Invalidate whole descriptor. 06:52:14 dbaron: Is it just an empty range or invalid? 06:52:29 jdaggett: Wording to say that range has to contain valid chars. 06:52:40 dbaron: No implementation conformacne requirement. 06:53:18 http://lists.w3.org/Archives/Public/www-style/2013May/0564.html 06:53:20 jdaggett: you say wording is unclear. 06:53:27 dbaron: I can send comment about that, later. 06:53:50 TabAtkins: The only relevance of my change os for mixture of digits and digits. 06:54:08 ... CSS 2.1 created invalid range, which was then thrown away. 06:54:17 ... Fnal behavoir is the same.. 06:54:29 fantasai: why chage. Let's not do tokenaztion changes. 06:55:01 TabAtkins: Easier to parse. 06:55:11 bert: depnds on parsing suystem. 06:55:25 tab: In mine token is always correct. 06:55:47 TabAtkins: Unicode range token only valid in one property. 06:56:02 plinss: Then I'm not so bothered. 06:56:29 Bert: But why change it. 06:56:34 fantasai: Current is fine. 06:56:46 dbaron: I don't believe the change is undetectable. 06:56:55 Gecko implements the 2.1 definition 06:56:57 Tab: Maybe in future. 06:56:58 I also don't mind the change. 06:57:20 plinss: That's is why it gets important. 06:57:39 TabAtkins: But I have to write more text to accept the old syntax. 06:58:22 glenn: Font family quoted string that is empty: seems not prohibited. 06:58:33 dbaron: You might have a font with that name. 06:58:44 glenn: Far fetched, but itis an answer... 06:58:54 TabAtkins: Not a sybtax question, question for fonts. 06:59:24 plinss: Whether you can test the unicode range syntax difference now is not the question. 06:59:57 ... You're change maybe gives us more flexibility to not add white space in future properties. 07:00:09 fantasai: Not really, some unicode rabges end in digits, so not helpful. 07:00:34 dbaron: No, not helpful, there are too many different kinds of unicode range tokens. Often require a space anyway. 07:00:46 plinss: Then the change is irrelevant. 07:01:31 I agree the change is safe, and I agree it's pointless. 07:01:32 ... bert: But why chage it if is not broken? 07:02:16 [3 hands for tab's proposal 2 against] 07:02:43 TabAtkins: bad_url token and bad_string token. 07:02:58 plinss: What we talked about yesterday? 07:03:02 TabAtkins: Yes. 07:03:17 liam: Current UAs. 07:03:32 TabAtkins: Our parsing is wrong I believe. 07:04:07 glenn: doesn't seem right. 07:04:14 ... Wouldn't call it valid. 07:04:38 plinss: It is not gray. We know when to throw a property away. 07:05:18 TabAtkins: New attribute matching operatore are imported into tokenizer. 07:07:43 Bert: The new attribute operatores are not tokens, they are two tokens. 07:07:50 Tab: But selectors defiend them as tokens. 07:08:05 Bert: No, selectors defiend how to parse selecotrs, not how to parse css. 07:08:57 plinss: Don't agree with bert's argument, but accept the point. 07:09:35 ... They will always be atoken if we take tab's proposal, and we remove the possibility of useing them as as part of differnet symntax 07:09:46 TabAtkins: : Reduces ossibilities, yes. 07:09:56 plinss: There is an impact. 07:10:21 TabAtkins: it doesn't reduce possibilities, but it might complicate grammars in the future 07:10:27 s/Reduces ossibilities/makes futre syntax to have to be defined slightly differently/ 07:10:40 s/futre/future/ 07:10:48 plinss: there is a general pont about selecor syntax leaking into rest of syntax. 07:11:10 TabAtkins: "||" is used in selectors 4 07:11:17 ... Made it into a token. 07:11:27 ... Because it clashes with namespace selectors. 07:11:45 plinss: Are we giving up too much to avoid 2-token look-ahead? 07:11:55 TabAtkins: I don't know. 07:12:02 ... I heard 1-token was nice. 07:12:23 plinss: How important is it. You build it and forget about it. 07:12:29 dbaron: It is slower. 07:13:11 dbaron: There's a small performance cost to more lookahead, and I don't think it's worth it. 07:13:11 ... I tend to think more lookahead is slower. 07:14:19 TabAtkins: I added a comma token. 07:14:41 ... There was a colon and a semicolon already. 07:16:18 [Discussion about where COMMA is used. It is used in other modules, not in syntax itself] 07:16:59 TabAtkins: numebrs include sign, scie notation is allowed 07:17:05 url(foo bar) 07:17:33 TabAtkins: bad uri 07:17:34 bad-url("url(foo ") 07:17:37 justin has joined #css 07:17:39 -Meeting_Room 07:17:58 (I don't see why we need tokenizer for number) 07:18:01 can someone stitch up the phone again? 07:18:13 url(foo bar[baz) 07:18:18 jdaggett, shans is working on it 07:18:21 thx 07:18:43 TabAtkins: this case [above] will be different. 07:18:56 +??P0 07:19:05 cool, thanks!! 07:19:29 ... this is unlikely to have any bad effects. 07:19:40 ... Have no bug reports. 07:19:50 fantasai: You're parsing invalid stuff anyway. 07:20:14 dbaron: It is about parens *after* the piece that already makes it invalid. 07:20:39 fantasai^: So if someone found a problem with your behavior, they'd be fixing their style sheet, not filing a bug 07:20:49 plinss: I want the token to close according to error recovery rules. Respect paren matching. 07:21:20 dbaron: this is recent, but it simplifes. 07:21:27 ... Matches some implementations. 07:21:44 dbaron^: We've fiddled with this multiple times during 2.1 cycle 07:21:45 s/recent/recent -- something we were fiddling with to quite late in CSS 2.1/ 07:22:45 Bert: I don't udnerstand yet... 07:22:50 [dbaron explains] 07:24:46 url(foo bar[) 07:24:49 url(foo "bar[) 07:25:16 peterl: ok, I'm happy with it too 07:27:58 [discussion about where the error recovery picks up] 07:28:49 Ok, this makes sense to me seeing this example 07:29:00 Bert: I don't care about error recovery, si I'm fine, but be aware that you change the measning of existing style sheets. 07:29:18 Tab: Yes, we had no bug reports, so don't think it is a problem. 07:29:45 tab: CSS 2 grammar doens't cover all inputs. 07:29:53 ... Error recovery not defined. 07:30:05 ... So I'm defining error recovery. 07:30:11 dbaron: I'd like to review this more. 07:30:36 dbaron: Did you fix the cases where CSS 2.1 didn't allow CDO and CDC in some places? 07:30:41 ... What about CDO CDC? 07:32:06 Bert: As long as it is only about error recovery for CDO/CDC in more places, fine with me. 07:32:25 ScribeNick: fantasai 07:32:34 An+B notation 07:32:50 TabAtkins: The notation is incompatible with CSS tokenization 07:33:13 TabAtkins: For example, 5n-3 tokenizes as a dimension 07:33:26 TabAtkins: But we need to split it up into 5, n, -, 3 07:33:39 TabAtkins: Implementations right now have to guess where it ends ... so far easy because of close-parens 07:33:46 TabAtkins: Then reserialize and reparse 07:33:54 TabAtkins: Wanted to redefine an+b in terms of CSS tokens 07:34:01 TabAtkins: I can get it almost identical to defined behavior 07:34:09 TabAtkins: But there are two changes 07:34:16 s/two/two small/ 07:34:20 dbaron: Think the WS change is not small 07:34:35 TabAtkins: First change is that +n or +n+2 ok 07:34:40 TabAtkins: but + n not ok 07:34:53 TabAtkins: Similarly -n vs. - n 07:35:06 TabAtkins: Issue is that when you tokenize these, +n becomes 2 tokens 07:35:11 TabAtkins: so does + n 07:35:26 TabAtkins: -n and - n tokenize differently 07:35:38 TabAtkins: Property grammars ignore white space 07:36:08 TabAtkins: So can't distinguish 07:36:12 fantasai: I don't think ths needs to change. 07:36:18 dbaron: Tab just made up this idea of property grammars 07:36:24 TabAtkins: propdef grammars don't talk about ws 07:36:39 dbaron: I don't want to change the space rules here 07:37:20 TabAtkins asks how parsers work 07:37:30 dbaron says Gecko has a flag about whether ws is paid attention to 07:37:54 In WebKit, apparently WS tokens are omitted automatically when you ask for a token 07:38:04 fantasai: how can be possible in selectors? 07:38:04 div*p 07:38:33 Bert: Also numbers, numbers with a sign can't have space between number and sign 07:39:07 side discussion of NUMBER tokens 07:39:54 dino: White space is gone by the time you try to parse things 07:40:09 TabAtkins: How do you parse calc() and selectors then? 07:40:37 krit: ... something about whitespace and ident 07:41:14 RESOLVED: No spacing changes in An+B syntax 07:41:33 s/something about whitespace and ident/something about whitespace and ident in WebKit/ 07:41:53 TabAtkins: +n-\33 07:42:04 TabAtkins: parses as "+" "n-3" 07:42:12 TabAtkins: which looks like An+B 07:42:55 TabAtkins: So, change to allow escaping in cases where the tokenization derives from idents 07:43:02 TabAtkins: Which probably matches implementations 07:43:46 Bert: So escaping before reparsing? 07:43:49 TabAtkins: no reparsing 07:43:51 RRSAgent: make minutes 07:43:51 I have made the request to generate http://www.w3.org/2013/06/06-css-minutes.html jerenkrantz 07:44:02 TabAtkins: escaping was handled much earlier in parsing process 07:44:13 TabAtkins: Disallowing it would create a major layering violation 07:44:29 TabAtkins: By the time you care about whether something is an+b, you've lost the original representation 07:44:52 plinss: So this scenario produces a valid ident, with content "n-3" as the string 07:45:08 plinss: How does that become an an+b? 07:45:22 dbaron: Spec says if you have ident "-n-" followed by digits, then it's valid an+b 07:45:36 dbaron: I think this is far saner than the route we went down with URL, where we made it a separate token 07:45:58 TabAtkins: All three of these are equivalent, except they tokenize completely different 07:46:02 n - 3 07:46:09 n- 3 07:46:11 n -3 07:46:14 n-3 07:46:31 discussion of parsing mechanics among Bert, plinss, and Tab 07:49:07 [discussion of something else between fantasai and glazou] 07:50:39 RESOLVED: escaping in An+B falls out of tokenization 07:50:50 TabAtkins: That's all the syntax changes that we've reviewed now 07:50:55 TabAtkins: So, can I publish yet? 07:51:32 dbaron: I think the efforts here are worthwhile, but I would like to review the bracket-matching part before FPWD. I haven't had time yet 07:51:52 dbaron: I'm worried because I think once we have FPWD, people will only look at this, not at CSS2.1 07:52:11 dbaron: So if we don't fix something now, it will b ehard to fix later 07:52:24 dbaron: And I'm worried because it was originally reverse-engineered from the worst implemenation (WebKit) 07:52:27 TabAtkins: I won't deny that. 07:53:07 Bert: I can't understand this draft, apart from the railroad diagrams. Can you put more of those, or put grammar rules? 07:53:17 TabAtkins: I think I have diagrams for everything in the spec 07:53:55 fantasai: does your spec define what a style rule is, what a declaration is, what these things mean? 07:53:58 TabAtkins: yes 07:53:59 SimonSapin: No, it doesn't 07:54:31 fantasai: I think we need to add such a section, since this part of 2.1 logically belongs here. 07:54:56 (Seems all the production rules have diagrams.) 07:55:18 plinss: You asked for FPWD, but there's an existing css3-syntax draft 07:55:28 what is peter saying? he's speaking in "peter quiet voice" again... 07:55:34 fantasai: From process POV, no. But effectively yes. 07:55:43 plinss: Just making sure that we plan to replace what's out there and is 10 years old 07:55:46 TabAtkins: yes 07:56:23 TabAtkins: (to fantasai) Maybe I'll expand the Description of CSS's Syntax section 07:56:26 SimonSapin: And make it normative 07:56:37 fantasai: We need something that defines how to interpret a CSS style sheet. 07:56:52 Topic: Regions/Shapes/Exclusions 07:57:07 stearns: Events and Fragmentation 07:57:19 stearns: In fragmented flows, comes up in regions, but also issue in other types of fragmentation... 07:57:40 stearns has drawn some boxes 07:58:09 There is a big box, which represents the thing that contains the fragmentainers. 07:58:19 Inside are two fragmentainers, FC1 and FC2 07:58:26 stearns: These could be regions, pages, column boxes, whatever 07:58:42 stearns: Crucial thing is that fragmented flow has an article, which contains a paragraph, and there's a break at some point in the paragraph 07:58:49 (represented by boxes A and P) 07:59:01 stearns: Issue is when you click in one of the fragments of the P 07:59:07 stearns: The fragmentainer never hears about it 07:59:30 stearns: The event goes out from P to A to the outer box, skips FC boxes 07:59:49 SimonSapin: Are the two FC boxes generated from the same element? 07:59:56 dbaron: In overflow fragments, yes, but not in Regions 08:00:17 dino: You said it doesn't matter, but is FC1 or FC2 regions, or columns... is A a child of that? 08:00:35 stearns: In overflow fragments A would not be a child of either container, would be a child of outer box 08:00:43 dbaron: In overflow fragments not that distinction, just the one level 08:01:06 stearns: If I said :nth-fragment(2):hover, I want that fragment container to respond to hovering over this part of the paragraph, and not respond to hovering over the other part of the paragraph 08:01:13 Bert: Could have :hover on the outer box 08:01:18 stearns: I want the container to change 08:02:24 stearns: Only when it's hovered inside, not when the other fragment is hovered inside 08:02:31 stearns: And in Regions these can be different elements 08:02:45 dino: In A have one region element you're flowing into. Events don't get seen by region element 08:02:46 (DIV:hover::slot(fc2) {... highlight... }.) 08:02:48 stearns: No 08:03:00 dino: you can't write a rule that says ::region:hover 08:03:05 stearns: right, and I want to 08:03:06 dino: me too 08:03:21 stearns: Regions has an API that allows you to determine which region got clicked. 08:03:28 stearns: Doesn't work for hover but works for click events 08:03:33 (Forget what I just said.) 08:03:47 stearns: That workaround only works for events, doesn't work for :hover styling 08:03:58 stearns: But that workaround also doesn't work for fragmented elements 08:04:28 http://wiki.csswg.org/spec/css3-regions/user-event-handling 08:04:43 stearns: There are two proposals for handling this 08:04:48 stearns: First is for fragmented flows in general 08:04:53 stearns: When you have event bubbling in a fragmentation context 08:05:11 stearns: Event goes up through the chain as normal to the fragmentation root 08:05:19 stearns: The thing that contains the content that is fragmented 08:05:29 stearns: At that point, the fragment container is inserted in the bubbling 08:05:45 stearns: And the bubbling continues with whatever contains the fragment container, up through the hierarchy. 08:06:11 dbaron: Are you talking about event bubbling because you want to change :hover, or because you want to change what event handlers get? 08:06:14 stearns: Yes. 08:06:23 jdaggett: Issue on columns as well 08:06:30 s/Yes./Yes. Both./ 08:06:39 stearns: Once we get to point of having addressable columns, can be done for columns 08:06:40 -jdaggett 08:06:50 stearns: If you want to know what page an even twas on, would have page inserted in event/style loop 08:06:53 s/jdaggett/djovey/ 08:07:02 stearns: I'm actually not sure whether bubbling for CSS :hover is actually defined anywhere 08:07:02 s/djovey/jdovey/ 08:07:07 stearns: I assume it does the same 08:07:14 dbaron: It's not really bubbling, but it's defined 08:07:15 +[IPcaller] 08:07:23 zakim, ipcaller is me 08:07:23 +jdaggett; got it 08:07:42 http://dev.w3.org/csswg/selectors4/#the-hover-pseudo 08:07:46 "The parent of an element that is :hover is also in that state. " 08:07:58 was there a question? 08:08:09 i'm muted... 08:08:12 stearns: One way to solve this, is, in a fragmentation context, insert the fragmentainer at the appropriate spot 08:08:18 stearns: One more thing in the appropriate spot 08:08:42 dino: If it's a region, then does it bounce back to the ancestor chain or go up the region's ancestors? 08:08:47 stearns: Goes up the region's ancestors 08:09:03 This essentially circumvents the element's own ancestor chain 08:09:18 TabAtkins: Problem you're describing is virtually identical to problem with Shadow DOM and events 08:09:28 TabAtkins: Shadow DOM can rearrange content in a similar way 08:09:37 TabAtkins: Regions is slightly more general issue, but can be safely generalized under this as well 08:09:50 TabAtkins: Don't know precise details of what we do, but if you want details will have to ask Dmitry, who just went home 08:09:59 stearns: Shadow DOM describes it as DOM manipulation 08:10:04 stearns: follow reordered DOM hierarchy 08:10:12 TabAtkins: After reordering and following up 08:10:33 TabAtkins: Things that aren't in the Shadow DOM have no way of telling that the event passed through the Shadow DOM 08:10:46 stearns: That's very important to shadow DOM, not so important here. 08:10:58 TabAtkins: Could break things if you add pseudos you didn't expect 08:11:11 stearns: It will continue to multicol element, just one added stop 08:11:39 RRSAgent, make minutes 08:11:39 I have made the request to generate http://www.w3.org/2013/06/06-css-minutes.html MikeSmith 08:11:41 ... regions ... 08:12:03 fantasai: In case of regions, you might wind up not hitting your ancestors, because going up region's ancestor chain now. 08:12:16 fantasai: whereas other cases, you always walk up all your ancestors, just might make extra stops along the way 08:12:47 stearns: If you go through email thread linked from wiki 08:12:59 stearns: Went through number of iterations tryng to figure out how to preserve event bubbling chain 08:13:02 stearns: or dealing with this osmehow 08:13:08 stearns: everything got way too messy 08:13:43 stearns: Once you've put content into this fragmented flow, makes more sense to me for events to follow region's ancestor chain 08:13:59 fantasai: Depends on what you're trying to do 08:14:35 fantasai: Depends on how much you're scrambling the tree, and how much you are handling events locally vs. talking to things higher in the document tree 08:14:43 dino: Think it's very confusing to go up region chain 08:14:51 dino: If you wrote selector parent-element > child-content 08:14:56 dino: Expect that selector to apply 08:15:08 dino: wrote parent-element:hover > child-content to work 08:15:15 dino: But break that expectation 08:15:30 stearns: ... 08:15:40 stearns: But named flow, taking boxes from parent, putting them over here 08:15:51 stearns: these boxes should be ones responding to user events because you made that disassociation 08:15:57 dbaron: I find it really weird to have events not follow the DOM 08:16:02 dbaron: They're a DOM structure 08:16:20 dbaron: And I think separation of content and presentation makes it really weird for box-tree structure to mess with DOM structure 08:16:28 stearns: Have a response to hover styling? 08:16:35 dbaron: I think hover styling is separate from events 08:16:51 TabAtkins: Can be easier to handle :hover going two directions up the tree, than events going up the tree 08:17:03 TabAtkins: Could do complicated thing now with pseudo-classes, rather than events 08:17:22 dean: what happens with elementFromPoint()? 08:17:38 dbaron: it depends if there's content at that point in the region -- you get the most deeply nested thing 08:17:56 dino: Want to understand why :hover and events could be different 08:18:11 dbaron: :hover is a CSS concept 08:18:22 dino: Base don mouse events 08:18:29 dbaron: That's changed over time. It happens to be true now 08:18:45 plinss: We have whole dichotomy of things like mouse events, that deal with geometry of presentation 08:18:53 plinss: These fire at the DOM tree, kindof broken 08:19:12 dbaron: We could have another type of mouse event that doesn't bubble, but that you fire at everything in that geometry 08:19:19 dbaron: We do sortof have that for mousover and mouseout 08:19:36 stearns: Another solution is to add a mode to pointer-events property 08:19:50 stearns: So you could say for e.g. relpos'd box, events will follow box tree 08:20:04 Rossen: Going through iterations, another idea for adding region as a separate target 08:20:29 stearns: Other mode, other solution is to have this switch, where for certain elements that you choose, you have the event just run through the visual layers 08:20:46 TabAtkins: element with fragment parent, goes to fragment parent rather than real parent? 08:20:59 stearns: Goes to whatever's displayed underneath it, which in fragment case would be fragmentainer 08:21:08 dino: One option is following DOM tree 08:21:13 dino: second is following box tree 08:21:18 dino: Third is following painting order 08:21:26 stearns: Second solution is not doing the middle event 08:21:33 stearns: Right now pointer-events can be normal, they go up the DOM tree 08:21:46 stearns: Can say pointer-events: none;, which ignores pointer events 08:21:55 stearns: Switch would trigger just painting order 08:22:06 stearns: You'd get the relpos box and whatever is underneath it 08:22:51 TabAtkins: So third one is elementsFromPoint() and walk that list 08:23:06 plinss: Where are you setting this switch? 08:23:23 The target of the element will decide on the path of the event 08:23:37 followup on the subscript/superscript metric discussion, here's the example from hamburg: 08:23:38 http://people.mozilla.org/~jdaggett/tests/subsupermetrics.png 08:23:40 dino: If you did something like this, set it on ancestor, does ??? 08:24:00 dino: Doing propagation based on painting order is quite complicated, because implementations might forget exactly the order for perf reasons 08:24:17 rssagent, make minutes 08:24:45 some concerns about implementation all around 08:25:04 TabAtkins: We have elementsFromPoint() already, regardless need to be able to get at that list 08:25:10 rrsagent, make minutes 08:25:10 I have made the request to generate http://www.w3.org/2013/06/06-css-minutes.html leif 08:25:31 stearns: For pointer-events: none, still need to have that info as well; that requires one answer, this case needs the whole stack 08:25:55 ivan has joined #css 08:26:15 TabAtkins: For the case that shoudl hop through the fragment order, should that just be a generic box order movement? 08:26:27 TabAtkins: Anything else outside fragmentation would also affect that 08:26:34 stearns writes out options 08:26:38 1) Fragment container insertion 08:26:42 2) Painting order switch 08:27:16 stearns: for #1, issue of where to put the fragmentation container in the order 08:27:29 stearns: Painting orde rswitch is more general, works for other positioning things as well, also works for any type of fragment conatiner 08:27:40 TabAtkins: Do have to define that the event path includes fragment containers 08:27:48 TabAtkins: So can't lean on that concept entirely 08:27:53 fantasai: We don't have those eyt 08:27:57 s/eyt/yet/ 08:28:13 TabAtkins: So, suggesting go with paint order one for now, possibly also introduce box tree 08:28:22 plinss: what's diff between paint order and box tree? 08:28:31 TabAtkins: paint order just go through layers under that point 08:28:48 TabAtkins: box tree would jump from element to its containing block, not hit things underneath it necessarily 08:29:07 Rossen: ... 08:29:20 Rossen; Final transformed position, thus actual behind element is the furthermost ? 08:29:33 Rossen: Subtle difference, but makes a difference once you factor in transforms 08:29:41 Rossen: and relpos I guess 08:29:47 TabAtkins: Fine with leaving out box-tree 08:30:16 asking about who implements elementsFromPoint() 08:30:26 krit: Suggested couple months ago, not sure that anyone implements it 08:30:32 dbaron: Dont' see it in CSSOm or CSSOM View 08:31:29 ... 08:32:49 (Other issue: If '::foo' is a region, then '::foo:hover' would be the expected synntax to select it in hover state... but that syntax is not allowed by css3-selectors.) 08:32:53 stearns: So if I'm reading the room correctly, people leaning towards pointer-event switch 08:34:32 Bert raises issue against Selectors 4 08:34:40 ::first-line:hover e.g. makes sense, and would work 08:34:48 ::first-line:nth-child() doesn't make sense 08:34:58 fantasai points out that each pseudo-element has to define what it accepts 08:35:15 Bert points out that we need to define which selectors are invalid (cause selector to be thrown out) and which simply don't match anything 08:35:46 08:36:10 dbaron: This is pretty scary, don't think we should make a change without checking with WebAPI folks 08:36:58 RESOLVED: Work on pointer-events: elements-from-point solution 08:37:09 that will walk the elementsFromPoint chain instead of the ancestor chain 08:37:25 stearns: One of the issues... 08:37:37 stearns: Shapes specification 08:37:44 stearns: Whether we should allow shapes from rendered content 08:37:52 stearns: Think we should, but would like to push it to level 2 08:38:00 http://www.w3.org/mid/CDD64C22.3AD08%25stearns@adobe.com 08:38:06 stearns: CSS Shapes atm defines getting shape from an image, and from shapes from basic shape syntax, and I think that is sufficient for first level 08:38:19 stearns: already pushed off SVG elements. Would like to push off rendered content for now. 08:38:23 dbaron: what is it? 08:38:37 http://lists.w3.org/Archives/Public/www-style/2013May/0389.html 08:38:45 stearns: E.g. you have an A rendered large, or repeated background, etc. 08:38:55 stearns: I think it's useful thing to do, but very complicated 08:39:20 Rossen: Think original motivation for that was around time when we were proposing shapes to begin with. One of the use cases was a type of article that becomes a shape 08:39:31 Rossen: extracting shape from rendered text 08:39:38 Rossen: drop-cap, with tight-wrap around it 08:39:53 Rossen: That was original motivation. Agree it's advanced feature for current level of spec 08:40:00 Rossen: If we want to move spec quicker and have big bang for our money 08:40:09 Rossen: Having simpler shapes, easy to define 08:40:26 Rossen: That would hold implementations for quite some time. 08:40:46 fantasai: Makes sense to me. I would prioritize SVG shapes over this feature. 08:40:50 TabAtkins: me too 08:40:57 stearns: Any objections to moving this over? 08:41:02 plinss: Images? 08:41:14 stearns: No, they stay. That's biggest ask aside from SVG 08:42:01 dino: At what resolution do you derive the shape? 08:42:04 ... 08:42:08 stearns: We'll solve that as we get to it 08:42:27 ... 08:42:48 dino: You might have an image that's displayed 100x100 but it's 10000x10000 image, as you zoom you see more pixels, shape might change and suddenly impact layout 08:43:24 TabAtkins: other changes due to not aligning to pixel boundaries too 08:43:39 dino: Need to define exactly the operation you use, masking whatever 08:43:41 stearns: agree 08:43:57 liam: Could get almost effect of text-wrapping around A, by making path in SVG and wrapping around it 08:44:07 stearns: could make polygon with basic shape syntax 08:44:22 stearns: Aren't guaranteed to get the glyph you're expecting, though 08:44:44 stearns: Other issue, in spec, that says ... 08:44:51 krit: ??? 08:45:30 RESOLVED: Move contours from rendered content to next level 08:45:45 stearns: Issue on spec on shapes from images 08:46:10 stearns: Security concern of being able to determine contours of alpha channel of image 08:46:24 TabAtkins: Could extract cross-domain info 08:46:29 TabAtkins: Reasonably efficient attack, too 08:47:08 plinss: Imagine image you're putting in page is bar graph of your account balances of your bank 08:47:33 Same-origin or CORS 08:47:47 TabAtkins: Work with Anne, he'll tell you what to do correctly. 08:48:14 annevk is working on http://fetch.spec.whatwg.org/ which makes these things easier to define 08:48:15 krit: Same-origin may not protect you if open redirectors are used. 08:48:26 TabAtkins: That is always a concern for *everything* that's SOR. 08:48:56 dino: I'm not sure SOR is enough. 08:49:14 ScribeNick: TabAtkins 08:49:16 dino: [describes an attack that I didn't understand] 08:49:30 stearns: You're assuming that a site is wrapping content around a secure image. 08:49:59 dino: I'll describe the scenario better in the mail list. 08:50:27 krit: For SVG images, that's one of the reasons SVG images aren't allowed to reference images from another domain. 08:51:37 -jdaggett 08:52:06 TabAtkins: The SVG issue is different. That's about beinga ble to detect when an image is viewed, by including an external ref in that image. 08:52:15 krit: It's a different attack, but same scenario. 08:52:23 [please describe the attack better] 08:52:43 stearns: New topic. The idea is that we should add floats to exclusions, so we have one way of wrapping things around each other. 08:53:11 stearns: I propose we dont'. Floats work within the wrapping context, and are their own crazy thing. 08:53:24 TabAtkins: Does that mean we lose the "exclusions can auto-avoid each other" switch? 08:53:30 stearns: No, this is unrelated. 08:53:41 Rossen: The two things are kind of joined... 08:53:53 stearns: No, they're disjoint. They work differently - it's defined in the spec. 08:54:15 Rossen: INline content at the same level as the float will avoid both floats and exclusions, but exclusions penetrate much higher. 08:54:33 Rossen: So they really are disjoint in terms of geometry, and in the stack they have different behavior. 08:54:53 Rossen: So keeping them separate is way easier. From an impl point of view, I approached keeping them together with floats, but it started becoming a mess quickly. 08:55:46 Bert: Is this just an impl issue? 08:55:58 stearns: No, spec issue. The spec says how to construct the wrapping context. 08:56:15 stearns: The spec defines that floats create areas that content avoid. 08:56:34 stearns: Question is to keep that, or to try and fully harmonize floats with exclusions so they act identically (rather than just similarly). 08:57:04 Rossen: It will hypothetically allow you to have an impl with just exclusions, no floats. 08:57:31 Bert: If you can explain how they'd behave differently, it would be appreciated. 08:57:46 stearns: In the wrapping behavior, they behave the same, for a single flaot and a single exclusion. 08:58:45 RESOLVED: Close the flaot/exclusion harmonizing issue. 08:59:26 Topic: Syntax editor 08:59:33 TabAtkins: I propose adding Simon as Syntax co-editor. 08:59:44 RESOLVED: Simon Sapin is Syntax co-editor. 09:00:22 RESOLVED: Exclusion wrapping context does not include floats. (Clarifying two resolutions ago.) 09:02:27 Meeting closed for the day. 09:02:27 lmclister has joined #css 09:08:00 disconnecting the lone participant, Meeting_Room, in Team_(css)04:03Z 09:08:01 Team_(css)04:03Z has ended 09:08:01 Attendees were jdaggett, Meeting_Room, glazou 09:08:21 leif1 has joined #css 09:09:45 dbaron, you asked to be reminded at this time to go home 09:10:19 Heh 09:10:38 lol 09:13:38 fantasai, go and have some dinner ;) 09:27:50 Ms2ger: That seems to have worked 09:30:13 :) 10:55:31 darktears has joined #css 11:29:56 Zakim has left #css 11:31:55 dino has joined #css 12:50:53 dbaron has joined #css 12:52:20 lmclister has joined #css 13:00:41 glenn has joined #css 13:01:19 rhauck has joined #css 13:04:25 rhauck1 has joined #css 13:06:09 liam has joined #css 13:13:42 cabanier has joined #css 13:20:22 SimonSapin has joined #css 13:45:12 leif has joined #css 13:50:23 isra has joined #css 13:58:00 leif1 has joined #css 14:02:48 leif has joined #css 14:41:52 arno has joined #css 15:21:32 Bert has joined #css 15:33:09 arno has joined #css 16:42:31 zcorpan has joined #css 16:43:28 zcorpan has joined #css 17:01:06 arno1 has joined #css 17:04:00 arno1 has joined #css 17:48:07 nvdbleek has joined #css 18:04:23 arronei_ has joined #css 18:06:07 arno has joined #css 18:12:37 arno has joined #css 18:15:00 arronei has joined #css 18:19:25 arronei_ has joined #css 18:24:11 arronei has joined #css 18:26:44 arronei_ has joined #css 18:31:30 arronei has joined #css 18:38:31 arronei_ has joined #css 18:43:17 arronei has joined #css 18:45:41 arronei_ has joined #css 18:49:06 ivan has joined #css 18:50:27 arronei has joined #css 18:52:52 arronei_ has joined #css 18:57:38 arronei has joined #css 19:05:54 arronei has joined #css 19:17:26 zcorpan has joined #css 19:23:39 cabanier has joined #css 19:39:32 arno has joined #css 19:45:56 arronei_ has joined #css 20:00:06 arronei has joined #css 20:02:35 ivan has joined #css 20:03:10 zcorpan has joined #css 20:05:50 zcorpan_ has joined #css 20:06:11 nvdbleek has joined #css 20:07:36 arronei_ has joined #css 20:10:00 arronei has joined #css 20:10:05 zcorpan has joined #css 20:14:45 arronei_ has joined #css 20:15:03 nikos1 has joined #css 20:15:58 krit has joined #css 20:17:09 arronei has joined #css 20:21:55 arronei_ has joined #css 20:24:18 arronei has joined #css 20:25:40 arno has joined #css 20:41:22 zcorpan has joined #css 21:17:40 zcorpan has joined #css 21:20:29 Tav has joined #css 21:39:48 r12a has joined #css 21:41:25 ivan has joined #css 21:55:28 lmclister has joined #css 22:01:09 arno has joined #css 22:03:58 zcorpan has joined #css 22:05:56 dbaron has joined #css 22:10:13 sgalineau has joined #css 22:10:26 sgalineau has joined #css 22:25:23 arno has joined #css 22:31:26 glenn has joined #css 22:58:01 SimonSapin has joined #css 23:00:23 zcorpan has joined #css 23:51:55 shans__ has joined #css 23:53:40 jdaggett has joined #css 23:58:34 glenn has joined #css