to clear the float here, even though the float would be inside the clearing element 11:13:22 s/clearing element/clearing box/ 11:14:59 dbaron: We could fix this by adding a parenthetical to the float rules talking about floats inside the clearaing element to explicitly include the contents of run-in elements 11:15:12 Inside "The 'clear' property does not consider floats inside the element itself or in other block formatting contexts." in 9.5.2 11:16:20 to something like "The 'clear' property does not consider floats inside the element itself (including floats inside a 'display:run-in' element that runs in to the element) or in other block formatting contexts." 11:16:23 dsinger: Is it completely clear what "inside" means in that section? 11:16:25 everyone: noe 11:16:27 s/noe/no/ 11:17:35 We also need to fix the float positioning rules in 9.5.1 11:17:39 because they also go by source order. 11:17:42 bert: So what if you have a float in between the run-in and the block also? 11:21:04 and if the float not in the run-in has 'clear' on it then you have an explicit contradiction 11:21:11 we need a box tree 11:22:03 discussion of float placement rules 11:22:34 steve: So instead of saying that the float is inside the element that the float is inside a run-in rendered inside the principal box. 11:22:40 dbaron: how does that help? 11:23:06 dbaron: .. old problem. Doesn't help the new problem. 11:23:10 dbaron: The new problem is if you have 11:23:23 11:23:27 11:23:36 11:23:44 dbaron: The floats are both left 11:24:05 floatA, floatB { float: left; } 11:24:15 floatB, block { clear: left; } 11:24:25 dbaron: The definition of clear on floats says that floatB has to be below floatA 11:24:38 dbaron: Because it has to clear any elements earlier *in the source document* 11:25:09 dbaron: The definition of clear on blocks says that the block has to be below floatB 11:25:35 dbaron: And the float positioning rules say that floatA has to be even with the top of the block that contains, i.e. at or below the top of the block 11:26:25 steve: So say for a run-in, that combines with the following block, it is considered a reordering in the source docuent 11:27:28 so if "below" is "greater than", then floatB < floatA, block < floatB, and floatA <= block, which is a problem 11:27:45 tab: The more and more we try to patch the definitions here, the more of a mess it's going to get 11:27:57 tab: Maybe we can patch it here in 2.1 and make a CSS3 Box Tree module 11:28:17 ChrisL: We don't have to expose the box tree to the dom or anything, but we need to be clear about how it works 11:29:18 Bert: Another option is to say that floats inside the runin disable the runin 11:30:17 steve: What if I'm using float to get an initial drop-cap? 11:30:19 lstorset2 has joined #css 11:31:39 steve: We should go with run-in reordering the source tree in certain circumstances, and limit the circumstances where this occurs 11:32:05 steve: for layout purposes only 11:32:39 miketaylr has joined #css 11:32:42 dbaron: We'd have to go through the whole spec and decide which instances would use the actual source order and which would use the virtual source order 11:32:52 dbaron: Which is what we mean by defining the box tree 11:33:31 alex: You'd also need to update Appendix E 11:34:43 fantasai: so for chapter 8 and above you pretend the source has been reordered 11:36:40 but ... what happens if you need to be able to say something on the run-in that applies *without* this re-ordering, because then you would not be able to? 11:37:08 steve: the def of run-in box says that it's rendered as if it were an inline element in the next block box 11:37:29 steve: you could just clarify that the contents, including floats and abspos, are includedin this move 11:38:51 steve: you might need a note that you need an apparent reordering of the source 11:40:00 http://www.w3.org/TR/CSS21/visuren.html#run-in 11:40:06 "the run-in box becomes the first inline box of the block box" 11:40:37 http://www.w3.org/Style/Group/css2-src/visuren.html#run-in 11:40:37 http://www.w3.org/Style/Group/css2-src/visuren.html#run-in 11:41:59 steve: So we need a note to clarify 11:42:26 ACTION: Steve write note to clarify that run-in's contents are reordered by rule 2 in 9.2.3 11:43:26 Could not create new action (failed to parse response from server) - please contact sysreq with the details of what happened. 11:43:26 Could not create new action (unparseable data in server response: local variable 'd' referenced before assignment) - please contact sysreq with the details of what happened. 11:43:58 RESOLVED: Add note to be written by Steve for CSS2.1 issue 198 to clarify that this effectively causes a reordering of the source tree as far as all of the layout rules are concerned 11:46:41 http://wiki.csswg.org/spec/css2.1#issue-199 11:48:05 so line boxes should be created for inline-level content and potentially marker boxes 11:48:14 collapsed-away whitespace does not create a line box 11:49:01 jdaggett: so you have a line box with no text in it. What font metrics do you use for it? 11:49:07 dbaron: known problem 11:49:18 Bert: We need to pick a font for finding the 'ex' unit 11:50:02 jdaggett: We don't have a font-finding algorithm that works without text 11:50:19 several you want to check against the first available font 11:50:33 steve: match against the empty string. Every font will match 11:50:54 http://lists.w3.org/Archives/Public/www-style/2010May/0698.html 11:53:31 discussion of the phantom line boxes in 9.4.2 11:53:34 http://lists.w3.org/Archives/Public/www-style/2010May/0698.html 11:54:34 ... 11:55:29 fantasai: You need the phantom line boxes to handle abspos static positioning 11:56:02 fantasai: but you need to ignore it for margin collapsing 11:56:47 calling it 'potential' line box (which later resolves to no line box, or a real line box, may be better than 'phantom' 11:59:48 ACTION: Tab propose text for CSS2.1 Issue 199 11:59:48 Created ACTION-255 - Propose text for CSS2.1 Issue 199 [on Tab Atkins Jr. - due 2010-08-30]. 11:59:51 ScribeNick: mollydotcom 12:00:03 I feel that potential is a better term than phantom 12:00:36 Daniel: Last issue on the radar, then we will decide to stop on these issue or not 12:01:07 http://lists.w3.org/Archives/Public/www-style/2010Aug/0401.html and http://lists.w3.org/Archives/Public/www-style/2010Aug/0403.html 12:01:20 table-wrapper-box 12:01:26 RESOLVED: Accept proposal for CSS2.1 Issue 201 with "table wrapper box" as the term 12:02:29 szilles and fantasai discussing vertical-align 12:02:51 szilles: undefined is fine 12:03:54 Daniel: CSS 2.1 issues freeze 12:04:17 Daniel: stop registering issues now 12:04:31 David: As long as we keep a list of them 12:05:00 dsinger_: Will likely end up in errata or moved to CSS3 12:06:03 fantasai: We are publishing a last call working draft, we are required to accept comments. FOr this round of editing, there's no reason why we shouldn't close down, publish, and consider anything else last call issues 12:06:18 fantasai: they will have four weeks to comment 12:06:48 RESOLVED: CSS 2.1 issues: FROZEN 12:07:02 (no objections, very strong support) 12:08:23 Glazou: if we have interop shown by reports, we go directly to pr 12:08:31 (no objections) 12:10:01 Glazou: Everything relies on implementation reports - completion of test suites, so let's discuss 12:10:12 RESOLVED: LC->PR if we have exit criteria for 2.1 12:10:18 Glazou: What remains on the radar with the test suite and when are we able to say it's ready? 12:10:49 Fantasai: we have to have "no suspected" issues, when that's complete I can publish 12:11:11 jdaggett - there are tests that don't pass in any browsers 12:11:22 dbaron: a bunch of people did respond to the tests in that list 12:12:07 jdaggett: I've actively try to go to people I thought would care but I fear they will comment 12:12:15 Glazou: at some point we have to freeze things 12:13:21 Glazou: Browser vendors: you want css2.1 published but your teams have not evaluated the tests, have not already implemeted, even if we are going to CR/PR 12:13:39 Glazou: if you want it published, we rely on your implementations. The entire thing is in your hands, not the WGs 12:14:24 Fantasai: If there's a problem with the test 12:14:37 Fantasai: Email the list, and then we will take a look at the test 12:14:45 Fantasai: THEN we will push it to the WG 12:14:53 Glazou: Not an issue with the spec 12:15:10 fantasai: info on the wiki 12:15:25 Glazou: suggest 1 Oct. for test suite 12:16:28 Deadlines: Edits should be done for next conference call 12:16:35 Bert: I'll be able to do my edits 12:17:27 dsinger, fantasai: discussing automation of tests 12:18:31 +jgraham and gsnedders 12:19:22 gsnedders: Opera can help provide some help with that too 12:20:13 jdaggett, dbaron: discussing tests and windows limitations 12:20:46 Jdaggett: there are some tests that don't pass on any windows implementation but do pass on other platforms 12:20:49 dbaron: Aaron, could you share the list of which tests pass on which browsers? 12:21:33 jdaggett: for font tests this will be hard. Bold and non-bold versus bolder/lighter 12:21:47 jdaggett: On windows you only have bold and nott bold 12:21:59 jdaggett: you need to test on e.g. MacOS to get the full range of testing 12:22:07 jdaggett: Windows will allow trivial passes 12:22:34 glazou: The test suite isn't supposed to demonstrate interop, it'e supposed to demonstrate implementability 12:22:50 glazou: The tests aren't conformance tests, they're spec implementability tests 12:23:04 steve: You're testing for interoperable implementability 12:23:26 jdaggett: When I say font-weight 100, it should pick the 100 weight font not the 400 weight font 12:23:40 jdaggett: but on Windows you only get the 400 weight font 12:24:02 dsinger_: The problem is what if you have two section so fthe spec that can be implemented, but not at the same time 12:24:44 steve: The requirement is that there exist at least 2 impls 12:25:00 dbaron: You can also get tests that fail in all windows implementations, and you need to find non-Windows implementations to get passes 12:25:02 s/section so fthe/sections of the/ 12:25:50 glazou: Next step is writing the implementation reports.. 12:25:59 dbaron: Arron, can you share that list of which tests pass on which browsers? 12:26:03 JohnJansen: No, we can't 12:26:31 ChrisL: The full data is a matrix in a spreadsheet that shows which tests pass in which versions of which browsers. 12:26:55 JohnJansen: It's a very expensive process 12:27:43 And I would like to talk to Microsoft managers to get the relevant parts of that released to the working group. It will get us out of CR earlier 12:27:55 glazou: For Selectors, hixie and I had to write the implementation reports ourselves 12:28:21 glazou: It's always the case that some Members put in more resources into the WG on some things than others 12:29:08 ChrisL: We wouldn't be asking MS to provide the data if you didn't already have it. 12:29:34 dbaron: I don't consider it worth my time to go through the test suite. 12:29:53 dbaron: But if you provide a set of tests that we fail, then I will review those tests. 12:30:02 dbaron: So could you share the list of tests that fail in at least one browser? 12:30:16 Arron: I've shared the lists of tests that don't pass in any browser, and those that I think are invalid 12:30:35 Arron: Once we decide the test suite is solid, and we're getting there with Gérard reviewing a lot of the tests, 12:30:57 Arron: Then when you run the tests you can look more closely at the tests you fail 12:31:28 howcome: dbaron has 2 points I would like to emphasis 12:31:40 howcome: One is that the tests are too many and give us too little 12:31:58 howcome: We've all found ourselves in situations doing work on behalf of other browsers. 12:32:14 howcome: And you have done that -- all the tests you've contributed 12:32:21 glazou: It's perfectly normal. 12:32:32 glazou: Microsoft wants 2.1 to be released ASAP, because you rely on it. 12:32:44 glazou: Contributing the results of the tests will speed up the process. Not contributing it will slow us down. 12:33:01 glazou: It's in your interest to contribut the results. 12:33:07 Steve: The issue isn't the test results, the issue is the implementation reports 12:33:19 I would like to see Arron's list of 'tests passed by no windows browser' on the wiki, then remove tests that are passed on other platforms 12:33:38 Steve: So we're not asking for a contribution of test results, we're asking for contribution of to the implementation reports 12:34:01 Arron: These are only the HTML test results, not the XHTML tests 12:34:27 dbaron: So there could be additional tests that don't pass in any browser. 12:35:18 JohnJansen: We shared a lot of the data we have. The list of suspected invalid tests, and the list of tests that don't match. 12:35:23 s/match/ pass/ 12:35:56 howcome: Can you provide the list of tests that fail in any one browser? 12:36:22 glazou: A few years ago the only company interested in print was YesLogic. 12:36:27 glazou: And afterward HP 12:36:35 glazou: But not the other vendors were interested in print 12:36:45 glazou: But we contributed time to working on those specs 12:37:02 JohnJansen: The tests we contributed are available to anyone to run 12:37:15 JohnJansen: We're not hiding anything. 12:37:40 Arron: It's our time and money that we've put into creating the test results 12:38:14 dsinger_: I'm grateful if he gives me the data, I don't think I can ask him to do that work for me and save me that time and money. 12:38:35 JohnJansen: I wouldn't want you to trust our results either. 12:40:24 dsinger_: Can we keep a page on the wiki of tests that are suspected to be wrong? 12:41:48 ACTION: fantasai make said wiki page 12:41:48 Created ACTION-256 - Make said wiki page [on Elika Etemad - due 2010-08-30]. 12:41:52 howcome has left #css 12:42:47 fantasai: People can start on implementation reports now. I can even throw out a beta 4 on Monday 12:43:00 fantasai: But whenever I publish a release now I list all tests that have changed 12:43:14 fantasai: So between releases you'd only have a handful of test results you might need to run 12:43:43 glazou: I am requesting browser vendors to start implementation reports now. 12:44:28 Arron: It takes 16 hours to run the tests by hand 12:44:39 dsinger asks about automating them 12:44:48 fantasai and Arron say it will take much longer to automate them 12:45:07 dsinger_: How good is the coverage of the test suite 12:45:28 gsnedders: Automating the tests isn't just a one time thing, because everyone would want to run them as regression tracking 12:45:36 gsnedders: if they're manuall, they won't be run very often 12:45:44 gsnedders: Automating the tests wont' just save time once 12:46:57 jdaggett: For CSS3 modules do we have to follow this pattern? 12:48:13 glazou: If we don't get your implementation reports, things are going to slow down. 12:48:41 glazou: It relies on you. 12:48:46 glazou: The sooner we get it, the better. 12:48:51 dsinger_: Coverage? 12:49:01 gsnedders++ 12:49:20 dbaron: There's questions of how you measure test coverage 12:49:32 dbaron: you'd have to measure e.g. code coverage 12:49:41 gsnedders: exactly. 12:51:19 fantasai explains what we have 12:51:34 dbaron: The spec has lots and lots of interactions among features, many of which are not obvious 12:51:45 dbaron: We don't have good coverage of those interactions. 12:52:08 dbaron: There are sentences in the spec that require hundreds or thousands of tests just for that sentence. And we don't have that coverage. 12:53:00 glazou: Anything else on the test suite and the roadmap? 12:53:10 glazou: I remind you that the goal is still PR before the end of the year. 12:53:18 glazou: This is important for both the WG and the W3C itself. 12:53:27 glazou: We started this roughly ten years ago 12:53:51 ChrisL: If the CSS2.1 can get to PR by the end of the year, there's still a chance that SVG 1.1 can normatively point to CSS2.1. 12:53:55 ChrisL: I'd like that to happen. 12:54:14 glazou: if we move 2.1 to PR, Selectors can move to REC, we solve a lot of dependencies. 12:54:35 s/1.1/1.1 Second Edition/ 12:54:50 JohnJansen: If we got to PR by the end of the year, does that put REC at the end of January? 12:56:21 scheduled charter discussion for after the break 12:56:22
13:06:04 dstorey has joined #css 13:06:52 dstorey_ has joined #css 13:07:59 szilles has joined #css 13:17:26 szilles has joined #css 13:23:13 Next topic is WG Charter 13:24:06 note: answer to earlier question from JohnJansen about REC at end of January: Yes. 13:26:10 dsinger has joined #css 13:26:21 glazou has joined #css 13:26:21 tantek has joined #css 13:26:28 jdaggett has joined #css 13:26:38 szilles has joined #css 13:26:40 dstorey has joined #css 13:28:12 Topic: Charter 13:28:23 glazou: Current topic ends at the end of November 13:28:32 glazou: We need to discuss the charter itself, goals, deliverables, scope, etc. 13:28:38 glazou: Make sure everyone in the WG agrees 13:28:49 TabAtkins_ has joined #css 13:29:49 http://www.w3.org/Style/2008/css-charter 13:30:00 glazou: http://wiki.csswg.org/planning/charter-2008 13:31:30 fantasai: Propose to add Media Queries to 2007 snapshot text and call it Snapshot 2010 13:31:40 WG reviews the Scope section of CSS Charter 13:32:33 ChrisL has joined #css 13:32:48 Everyone happy with 1.0 13:32:56 rrsagent, here 13:32:56 See http://www.w3.org/2010/08/23-CSS-irc#T13-32-56 13:33:49 note to ChrisL - http://dev.w3.org/csswg/css3-color/ has been updated per your request to make edits to Dependencies section, replacing "predefined" with color keywords, and removal of n/a rules in suggested style sheet that were using dropped attr() function. 13:34:04 Now looking at 1.1 -- list of modules 13:34:13 glazou: I think we need to shuffle soem of these items 13:34:14 szilles has joined #css 13:34:20 glazou: We should preserve CSS2.1? 13:35:12 ChrisL: How about a 2 month extension to the current charter, then move it into maintenance 13:35:34 Tantek: And consider 2.1 Errata as the work item 13:37:16 Going through the list one at a time 13:37:30 CSS2.1 - expect PR by end of year 13:38:24 CSS3 Backgrounds and Borders - CR within 1.5 months, have implementations, need test suite, no PR by end of year, likely to REC within next period 13:38:31 CSS3 Color - PR by end of this year 13:38:41 CSS Mobile Profile - nobody here cares 13:39:30 http://www.w3.org/TR/css-mobile/ 13:39:37 It's in CR right now 13:40:35 No testing done 13:40:47 Tantek, Bert: To exit CR, you need two complete implementations. 13:41:44 dsinger: Send OMA a liaison asking if they have finished it 13:42:02 dbaron: It depends on specs not in CR 13:42:40 fantasai: css3-marquee is in CR right now 13:43:36 miketaylr has joined #css 13:43:39 RESOLVED: Move to low priority, send OMA liaison about this 13:44:09 CSS Namespaces - Almost ready for PR, waiting for a pass on one test 13:44:54 remains high priority 13:45:00 CSS Object Model View - ask anne 13:45:13 I'd say cssom-view is medium priority, but anyway... 13:47:20 CSS Paged Media Level 3 - needs a lot more work to get to LC, then back to CR 13:48:26 high priority for several industries, but we are low on resources b/c we the editors are booked with other things 13:48:33 assigned medium priority right now 13:48:48 szilles has joined #css 13:48:53 CSS Snapshot 2007 - rename to CSS Snapshots 13:48:55 keep high priority 13:49:05 CSS Variables - drop to low priority -- hasn't changed in 2 years 13:49:53 dbaron: Some of what stopped variables' progress is a misunderstanding 13:50:05 dbaron: We wanted more data on it, to show that we're going in the right direction 13:50:21 dbaron: rather than using up core bits of syntax wrongly 13:50:27 dbaron: That got interpreted as we don't want it 13:50:28 ChrisL has joined #css 13:50:50 howcome: There's also complexity -- e.g. dom access to variables is more complicated than constants 13:50:59 howcome: It's not just a question of signing up an editor 13:51:44 dsinger has joined #css 13:51:52 Daniel: I could do the editorial work, ibut I need implementors who want to do this. [A 13:51:55 glazou has joined #css 13:51:56 tantek has joined #css 13:51:59 dstorey has joined #css 13:52:00 jdaggett has joined #css 13:52:22 szilles has joined #css 13:52:23 CSS Variables dropped to medium 13:52:29 Media Queries remains high priority 13:52:35 Selectors -> maintenance mode 13:53:04 Need to create a new one for maintenance 13:53:11 new group 13:53:20 glazou: Selectors 4? 13:53:28 dbaron, Tantek: Put it on low or medium priority 13:53:38 fantasai, Tab: We have items to work on, but it's not a high priority 13:54:06 moved to low priority 13:54:10 Selectors 4 13:54:21 szilles has joined #css 13:55:53 dbaron: HTML5 defines when CSS3 Selectors and CSS3 UI selectors apply to HTML 13:56:44 ChrisL has joined #css 13:56:57 dbaron: But does not introduce new ones 13:57:02 IIRC 13:57:15 TabAtkins_ has joined #css 13:57:21 http://www.whatwg.org/specs/web-apps/current-work/multipage/links.html#pseudo-classes 13:59:16 CSS3 UI added as high priority, edited by Tantek 14:01:17 CSS3 Basic Box Model 14:01:46 stays at medium priority 14:01:49 CSS3 Fonts 14:01:51 high priority 14:01:57 jdaggett aiming for LC by end of the year 14:02:01 hopefully REC by end of next year 14:02:46 szilles has joined #css 14:03:58 CSS3 Generated and Replaced Content 14:04:19 low priority 14:04:26 Tab Atkins 14:04:32 CSS Grid Positioning 14:04:40 low priority 14:05:40 jdaggett: I think there's a dependency from vertical text on Grid 14:05:53 fantasai disagrees 14:06:32 glazou: kept in charter, low priority 14:06:39 CSS Marquee - 14:06:44 Tab: That's only for mobile phones 14:06:55 Bert: That's indeed only for mobiel phones, the desktop browsers didn't want it 14:07:08 ask OMA 14:07:10 Bert: Maybe send in same liaison to OMA 14:07:34 low priority 14:07:39 WebKit implements a large part of it in Chrome/Safari 14:07:46 CSS Multi-column Layout - 14:07:52 high priority 14:07:57 CSSOM - ask Anne 14:08:03 CSS Ruby - 14:08:29 fantasai: medium priority; Mozilla is implementing 14:08:39 CSS Template Layout - 14:08:48 Tab: keep at medium 14:08:53 CSS Transforms - 14:08:55 high priority 14:08:58 CSS Transitions - 14:09:00 high priority 14:09:18 CSS Values and Units 14:09:38 fantasai: medium priority 14:09:40 glazou: low 14:09:45 dbaron: high 14:10:09 dbaron: I'd like to see it in CR by the end of next year 14:10:53 howcome doesn't want to finish it 14:12:07 howcome: What happens if e.g. grid module needs a new unit? 14:12:13 jdaggett: rev the module 14:12:18 fantasai: or define it in the grid module 14:12:22 -> high priority 14:12:42 CSS3 Extended Box Module 14:12:53 discuss low or dropped? 14:13:16 dropped. 14:13:30 CSS Flexbox 14:13:35 medium priority 14:14:13 http://wiki.csswg.org/planning/charter-2010 14:14:15 Please update! 14:14:38 CSS GCPM 14:14:44 howcome: We have 2 implementations 14:15:00 dbaron and fantasai are skeptical of whether it's ready 14:15:49 kubal has joined #css 14:16:02 for CR 14:16:37 fantasai: I think it should be at least medium priority, but it's not ready for CR 14:17:01 fantasai: Much of it is underdefined 14:18:15 ChrisL: high priority 14:18:29 jdaggett: We have a lot of high priority items 14:18:40 JohnJansen: So what's the definition of high priority? 14:18:48 glazou: We need to list everything we want to work on 14:19:09 glazou: The high priority ones are the ones that we need to be in a good state, that the AC reps will check on 14:19:13 GCPM -> medium 14:19:16 CSS Lists 14:19:18 medium 14:19:21 CSS Tables 14:19:29 glazou: Any work done on Tables? 14:19:44 dbaron: Lots of work 2 years ago, but nothing since really 14:20:12 Alex: That was Markus. The work being done was trying to define existing behavior 14:20:43 dbaron: I would go for low priority, and keep it on the list. It's very similar to 2.1 maintenance -- it's an issue we deferred it because it was difficult, but it's 2.1 level work 14:21:44 dbaron, alex: if someone comes to work on it, should be able 14:21:44 to 14:21:50 CSS3 Text and CSS3 Text Layout 14:21:54 medium priority 14:21:58 needed for EPUB in Japan 14:22:05 glazou: Anything else not in the list? 14:22:37 Tantek: CSS4 UI 14:22:55 glazou: We can just write CSS UI under high priority, and nott list the level 14:23:11 dbaron: We should add Transforms 3D to the list 14:23:16 dsinger: add it to low priority 14:23:25 dbaron: We're implementing 3D, so we're getting to 2 implementations 14:23:29 dbaron: suggest medium 14:24:28 howcome: CSS Backgrounds and Borders Level 4 14:27:34 jdaggett: Line Box module? 14:27:54 jdaggett: I'd like to have something that's clearer on how text with different baselines is aligned 14:28:14 CSS Line Box 14:28:16 -> low priority 14:28:48 dbaron: The current draft is Michel Suignard's draft from 2001 14:28:59 dbaron: Plus a half-finished pile of edits I made to make it match 2.1 better 14:29:14 dbaron: And then some new features, we may or may not want 14:29:35 Tab: CSS3 Images 14:29:52 fantasai: we probably want that high priority 14:30:20 nimbupani has joined #css 14:31:04 Bert: Speech? 14:31:20 dbaron: There's an incubator group working on speech 14:31:28 dbaron: Not sure if they'd be interested in this 14:32:51 kept off 14:33:04 dbaron: Scoping? 14:33:22 dbaron: HTML5 has scoped style sheets. We might want to put it back in the charter in case we need to work on it 14:33:29 dbaron: It's probably a feature at risk in HTMl5 14:34:02 s/Line Box/Line Layout/ 14:34:11 smfr has joined #css 14:34:30 fantasai: style attribute, high priority 14:35:26