18:15:52 RRSAgent has joined #CSS 18:15:52 logging to http://www.w3.org/2010/03/29-CSS-irc 18:16:37 anne: We have the problem for @page, for what goes inside of @page, that we need to solve one way or another. We can make it special or we can make it generic. 18:16:37 rrsagent, this meeting spans midnight 18:17:00 Bert: I proposed some time ago to create a 3rd type of block that would allow @page. 18:17:03 Present: Dean Jackson, Simon Fraser, Anne van Kesteren, Steve Zilles, Beth Dakin, Sylvain Galineau, Alex Mogilevsky, Chris Lilley, Bert Bos, Aaron Eicholtz, Elika Etemad, David Baron, Brad Kemper, Tab Atkins, Daniel Glazman, Peter Linss, Håkon Lie, David Singer 18:17:06 Bert: But I think people wouldn't want that. 18:17:15 (that was the list of who was present earlier; Dean Jackson and David Singer are not currently present) 18:18:01 anne: That wouldn't solve the earlier problem, the background wouldn't be green. 18:18:08 Bert: Right, but it would let you do what @page wants. 18:18:29 plinss: I'd prefer to see, if we see an @ rule, we parse it as a block, throw it away as invalid, and don't trash more than that. 18:18:58 Bert: But that's inconsistent. Any other unknown token would throw away until the next semicolon. 18:19:19 szilles: @ already has the role of being special. 18:19:52 glazou: I think we agree that if an @ occurs inside a value isn't an @ rule. 18:20:08 glazou: Frex, if the first token inside the brace is an @ token, we'd like it to be an @ rule. 18:20:23 Bert: If that's a change, we can't do it. 18:20:33 glazou: It's something new that wouldn't break anything. 18:20:36 dbaron has joined #css 18:20:38 Bert: It's in the spec. 18:20:58 howcome: This is a change in the eternal grammar. 18:21:12 anne: It doesn't change valid stylesheets. I think it's fine. 18:21:37 Bert: We have the error-recovery rules for consistency; you're changing the rules, so you're losing consistency. 18:22:08 glazou: We are fighting about extensibility all the time. 18:22:25 Bert: Things like adding to a shorthand is different, it fits in the grammar. 18:22:48 Bert: Show me a place in CSS3 that is incompatible with the forward-compatible rules. 18:22:52 plinss: @page 18:23:22 ChrisL: @page is interoperably implemented. I don't see the benefit of changing it; we should allow it, and use the extension point it allows to do new things. 18:23:52 howcome: This is a change in the eternal grammar, but we don't really have a great use-case. 18:24:01 howcome: A green background isn't a good use-case. 18:24:18 howcome: It's interoperable today, I'm not sure we should change it. 18:24:47 howcome: We're suggesting this change to get a generic extension mechanism. 18:24:58 plinss: We have @page, which allows intermingling of @ rules in a declaration block. 18:25:12 plinss: If it's *only* valid here, with special rules and special error recovery, that's very surprising. 18:25:31 howcome: Do we allow @page at the place where we're talking about? 18:25:45 adding a semicolon to the use case makes it green, interoparably: body { @foo {}; background: green; } 18:25:48 plinss: No, not right now. But @page acts like a declaration block, and allows more @ rules in it. 18:26:33 glazou: [gives an example showing @page] 18:26:36 plinss: If error-recovery from @foo inside @page's declaration block is different from in other declaration blocks, that's very surprising 18:27:18 glazou: In @page, if you see another @page{}, it parses to that } and throws it away, allowing the next rules to work. 18:27:29 szilles has joined #css 18:27:42 glazou: But if you have @page{ @foo {} background: green; }, the background is thrown away. That's very surprising. 18:28:34 plinss: The problem is that an unknown @ rule at one point in the stylesheet, it parses to the }. If you put it at another spot, and it doesn't parse to the }, that's weird. 18:29:05 dbaron: We already have that in some places. If an @rule appears in a value, or in a selector, it just makes an invalid value or selector. 18:29:16 ... never mind what I said 18:29:29 szilles: What anne just pointed out, if we have a single recovery mechanism, CSSOM can have a generic recovery mechanism. 18:29:46 glazou: Non-generic means one parsing impl for @page, and another for other @ rules. 18:29:50 We have different parsing of @keywords in different parts of the style sheet with or without the change we're proposing. 18:29:50 glazou: That's ugly. 18:30:03 For example, @keyword inside a declaration is still ignored as an invalid token 18:30:17 However, having different parsing rules within a declaration block 18:30:26 depending on whether the declaraiton block is inside @page or elsewhere, 18:30:28 that is confusing 18:30:34 alexmog: I'm agreeing with what Bert is saying. I'm not seeing use-cases, but we have interop against it. 18:30:37 and it is a burden on implementors to implement two different types of error-recovery 18:30:49 advantages: 1) consistent rules for authors 2) one code path for implementors 18:30:55 alexmog: We'll have syntax that is ignored in older browsers but paid attention to in newer browsers. 18:31:15 alexmog: We can just add a semicolon to the end of the @block and all browsers ignore it. It's not the prettiest, but it achieves the goal. 18:32:10 anne: Advantages is consistent rules for authors, and implementors. 18:32:26 alexmog: How much time until browsers have changed sufficiently to allow it? 18:32:48 TabAtkins: No more time than it would take for any new @ rule to be usable. 18:33:25 plinss: He has a good point. If we introduce a new @ rule, then authors using it will have their next declaration swallowed in older browsers. 18:33:41 anne: But can't it sometimes be a start of a selector then? 18:33:43 fantasai: No. 18:34:33 anne: If you recommend putting a semicolon after every @ rule, it is the start of a selector, and you don't get a green background. 18:34:55 anne: IE "@foo {}; body { background: green; }" kills the body block. 18:35:02 Bert: Oh, no, not ; after everything. 18:35:16 alexmog has joined #css 18:35:41 anne: I think we can just recommend that authors put the @ blocks at the end of the declaration block. 18:36:17 plinss: I think it will be really confusing if you would recommend putting ; at the end of @ blocks inside a declaration block, but not at the end of ones outside a declaration block. 18:36:42 Bert: I think we made a mistake on @page, not in the grammar. 18:36:51 plinss: I think we made a mistake in the grammar, instead. 18:37:29 fantasai: I think you can't stick an @ rule without braces is invalid inside a declaration block in the core grammar. 18:37:45 fantasai: We have some options. We could do nothing, which means no @ rules inside declaration blocks ever. 18:37:58 fantasai: And then just have Paged Media declare that @ rules have to be at the end. 18:38:22 plinss: The problem is that the longer we put it out, the more entrenched we'll get. 18:38:41 Bert: Not expensive? It's been in the spec for years! 18:38:56 anne: What kind of implementations are you thinking of? 18:39:05 Bert: TVs, etc. 18:39:28 glazou: They're all consistent right now, though, so nobody uses it anyway. It can't even be used as a browser selector. 18:40:09 plinss: The problem isn't that it's an error now, but in a few years when we have a spec that uses @ rules in that area. 18:40:26 anne: In a few years we'll have an upgraded set of browsers. 18:41:04 szilles: So older browsers will throw it away, so nothing weird. Anne observes that if you put them at the end, it will prevent any rules from being dropped. 18:41:08 Bert: So let's just put them at the end. 18:41:14 fantasai: It's still invalid by the grammar. 18:41:51 howcome: Eternal grammar isn't 'eternal', but I think it should still be harder to change than just writing a spec that says something different. 18:42:14 howcome: We should have a very good reason to do it, and I haven't seen that reason. 18:42:42 szilles: It simplifies the CSSOM model, for one. It simplifies parsing for CSS. It simplifies parsing for authors. 18:43:04 alexmog has joined #css 18:43:48 @mixin(border-rules)(n) { -moz-border-radius: n; -webkit-border-radius: n; border-radius: n; } div{ @mixin(border-rule, 8px) } 18:44:24 Bert: Why do you need an @rule in the one place where it's not allowed? 18:44:45 plinss: Because @rule already has rules for swallowing things to the end of a block. 18:44:58 glazou: If you remember the time before CSS2, we didn't have @page. 18:45:24 glazou: Declaration were *only* for style rules. When we came up for @page, we suddenly had a new place for declarations. 18:45:38 glazou: We want to be able to reuse an existing construct in the same way. 18:46:01 glazou: It would open up a new type of contributions for authors that we can't usually do. 18:46:47 Bert: Imagine changing XML. 18:46:56 glazou: We did that when we added @media. 18:46:59 Bert: That in 1998. 18:48:08 szilles: I recommend the chairs take a straw poll. 18:48:52 anne: And the options are 1) special handling of @page, or 2) generic handling? 18:50:22 ... and 3) require at-rules at the end for @page 18:50:24 plinss: Given the current definition of @page, legacy handling would mean swalling @margin rules inside of it, because @page contains a declaration block, which doesn't allow @ rules inside of it. 18:51:37 Bert: 3rd proposal, which has no chance, is to change Paged Media. 18:51:44 s/3rd/4th/ 18:51:57 Bert: And pull out @margin rules from the @page blocks. 18:52:15 fantasai: They should have probably been outside from the beginning, but right now we might as well remove them. 18:52:21 howcome: Where would you put them if they were outside? 18:52:26 ChrisL has joined #css 18:52:48 CSS the Eternal Temple http://i40.tinypic.com/2nlwrjn.jpg 18:52:59 howcome: [illustrates the change] 18:53:05 (One proposed change is in 13.2 say:... followed by a block of declarations and at-rules.) 18:53:15 fantasai: Yeah, but we've got multiple implementations in printers, and so it can't be changed now. 18:55:01 plinss: What's the point of putting @ at the end? It seems like an arbitrary place. 18:55:15 fantasai: It makes it clearer how inheritance works. 18:56:00 howcome: So how do we deal with @page containing @top-left and such? 18:56:10 Bert: Right now, we don't. It's just invalid. 18:56:23 Bert: We could create a special thing, not a declaration block, that would allow it. 18:57:00 plinss: I'm reading the parsing rules, and I'm not seeing anything in CSS that says special handling of @ rules depending on the position. 18:57:11 plinss: It doesn't say we only do this based on where it was. 18:57:25 Bert: Right, but we discussed that it should behave that way. 18:57:39 plinss: Please show me in the spec where it says it should behave the way you say it shoudl behave. 18:57:44 Bert: The two points above that. 18:57:58 Bert: The question is only if there is an exception if the @ keyword appears right after a semicolon. 18:58:11 dbaron: We don't specify what happens when the formal grammar disagrees with the prose. 18:58:27 plinss: But the formal grammar doesn't define the recovery rules, only the prose does. 18:59:26 dbaron: we usually go with whatever's more specific 18:59:32 howcome: What if we used ::top-left or something? 18:59:44 fantasai: Still invalid in a declaration block. Should have been @page::top-left, but shrug. 19:00:03 Straw Poll: 19:00:07 1) Generic Handling 19:00:17 2) Special handling for @page in any order (current spec) 19:00:23 3) Special handling, but @rules at the end. 19:00:54 4) Change Paged Media to nuke margin boxes and rewrite @page. 19:01:18 smfr: 1 19:01:20 anne: 1 19:01:25 szilles: 1 19:01:27 1 generic 19:01:27 dbaron: 1 19:01:38 s/dbaron/dethbakin/ 19:04:06 dbaron has joined #css 19:05:30 sylvaing: abstain 19:05:41 alexmog: 3 or 4, whatever doesnt' change CSS 2.1 19:05:49 ChrisL: 1 19:06:06 Bert: Prefer 4, second is 3. could also live with 2. Can't live with 1 19:06:11 arronei: 1 19:06:25 sylvaing abstains in the absence of a use-case 19:06:28 fantasai: anything but 4, defer to dbaron 19:06:31 dbaron: 4 19:06:53 bradk: 1 19:06:56 TabAtkins: 1 19:06:59 glazou: 1 19:07:01 plinss: 1 19:07:14 howcome: 3 19:07:23 dsinger: 1 19:08:09 I think HP would raise a formal objection for 4 19:08:24 glazou: Twelve for #1, three or four for 3 and 4. 19:09:49 dsinger: We have agreement on *not* 2. 19:10:00 plinss: And we cant' do 4 because of existing impls. 19:10:13 glazou: Existing impls do 2, so we're rejecting the current impls! 19:10:56 fantasai: Not sure if existing impls do 2, maybe they do 1? 19:11:02 ChrisL: How would you tell the difference? 19:11:33 fantasai: Just pop my testcase into a supporting impl. 19:11:41 19:12:03 it would be good to gather that implementation experience for printers that currently handle @page 19:12:33 body { 19:12:35 @foo { 19:12:37 } 19:12:39 background: green; 19:12:41 } 19:13:08 glazou: People will write it like Tab has, what will they expect? 19:13:26 howcome: Prince considers this an error, and doesn't show a green background. 19:13:33 fantasai: So it implements 2? 19:14:23 anne: Or 3, we can't tell. 19:14:36 plinss: Elika, can you test with your printers and get back to us? 19:14:47 fantasai: Would be good to get AH. Can we ping Murakami-san? 19:15:18 fantasai: 3 would just mean normal 2.1 error-recovery mode. 19:15:39 plinss: We'll come back when we get more implementations. 19:17:00 dbaron has joined #css 19:17:00 howcome: Is there anyone that can't live with 3? 19:17:10 anne: #3 is actually pretty weird. 19:17:45 anne: So if you had @ rules, normal rules, then more @ rules, presumably you should ignore all the normal rules since the appearance of the @ implies the end? 19:18:30 howcome: I think we can live with #3 now, and then make #1 valid later. 19:18:47 dsinger: Can we write that we can possibly allow #1 later? Warn people about it? 19:19:11 plinss: I don't think there's any point to saying "Sometime in the future, we might add future-proofing." 19:19:18 :) 19:19:33 dsinger: No, just that we might add a feature in the future that may require more generic handling, so don't depend on certain types of handling. 19:19:52 dbaron_ has joined #css 19:20:46 howcome: There is no hole right now. You're creating a hole and then insisting it needs to be filled. 19:21:01 anne: Paged Media doesnt' actually require them to be at the end. 19:21:24 plinss: In my perspective, it's a bug in 2.1. 19:21:45 plinss: In 2.1, we say when you see an @rule, swallow until the next block or semicolon. We don't say to do that only at the rule level. 19:22:08 plinss: We need to make this clear one way or another. Bert's proposal is to say that applies only at the ruleset level, most others are saying apply at all levels. 19:22:15 howcome: We have impl issues with that. 19:23:09 plinss: We have an existing spec that needs @rules like this, and at least two more ideas I know of want that. 19:23:21 Bert: But no one implements it like that anyway. 19:23:41 plinss: Right. But my reading of CSS is that you throw away an invalid @ rule as a unit. 19:23:47 Bert: Only at the toplevel. 19:23:59 plinss: But CSS doesn't say that. 19:24:30 howcome: This is a new situation. Bert is arguing *for* the browsers, Peter is arguing against? 19:24:59 plinss: This isn't progressing. We'll get more examples. Until then we're not convincing anyone. 19:25:21 szilles: Can we set a time for jdaggett's call? By my calc, 6am in Tokyo is 2pm here. 19:25:32 szilles: Is 3pm okay for us (7am for him)? 19:25:46 plinss: We have a lot of things for him to weigh in on. 19:26:02 plinss: I'd like him as early as possible. I suggest we ask him when he's comfortable. 19:26:12 dino has joined #css 19:26:17 szilles: And then I"ll ask another Adobe employee to attend. 19:26:33
20:00:52 dethbakin has joined #css 20:35:22 Lachy has joined #css 20:40:50 bradk has joined #css 20:40:56 sylvaing has joined #css 20:41:21 dbaron has joined #css 20:42:04 glazou has joined #css 20:42:23 plinss__ has joined #css 20:43:10 smfr has joined #css 20:43:16 Arron has joined #css 20:45:23 alexmog has joined #css 20:45:39 glazou has joined #css 20:45:44 ChrisL has joined #css 20:46:49 http://wiki.csswg.org/spec/css2.1#issue-114 20:47:03 http://wiki.csswg.org/spec/css2.1#issue-109 20:47:17 http://wiki.csswg.org/spec/css2.1#issue-26 20:48:10 dbaron: The way the spec currently says that vertical-align in table cells works is 20:48:14 ScribeNick: fantasai 20:48:17 dbaron: You have a table 20:48:38 dbaron: like this 20:48:51 dbaron draws a table with 2 rows 2 cols 20:49:09 dbaron: And you have a table cell likes this 20:49:17 dbaron draws a cell box in the upper half of the first cell 20:49:35 dbaron: The spec says ... and it says that the 'height' property sets the height of a cell box 20:50:05 dbaron: Suppose it says the cell height is 200px 20:50:10 dbaron: The cell box will be 200px 20:50:17 dbaron: and if the row is 200px high 20:50:38 dbaron: the cell box stays put, and its contents are clearly not vertical-align: bottom 20:50:49 dbaron: Nobody does this, everybody aligns the contents to the bottom 20:51:17 jer has joined #css 20:51:27 s/.../vertical-align aligns the cell box inside the cell/ 20:51:47 jer has left #css 20:52:09 dbaron: There are 2 possible solutions here, with different implications, and different browsers pick different ones 20:52:30 dbaron: One alternative is to say that instead of 'height' setting the height of the cell box, it sets a minimal height for the row 20:52:39 dbaron: The other solution is to say that you have two boxes 20:53:10 dbaron: one of which wraps around the content, the other one of which wraps around that, and vertical-align aligns both of them, but the height only sets the height of the outer one 20:53:28 dbaron: The tricky cases are where you have baseline alignment 20:53:59 dbaron: You can get a case where baseline alignment requires more space than either cell would require alone 20:54:41 dbaron: e.g. if you have a large-text box of auto height 20:54:54 dbaron: and a small-text cell of large height 20:54:58 dbaron: the baselines align 20:55:12 dbaron: but the second box extends way below the bottom of the first 20:55:18 dbaron draws this on the board 20:56:04 http://dbaron.org/css/test/2010/css21-issue-26 20:56:47 dbaron shows http://www.brunildo.org/test/td_height1.html 20:58:24 fantasai: I would not expect vertical-align to increase the size of the cell there 21:03:53 I would expect height to set the height of the same box that you paint borders and backgrounds on, not on the anonymous content holder inside it 21:04:55 http://www.w3.org/TR/CSS21/tables.html#height-layout 21:08:12 fantasai: Does height include the padding? 21:08:31 fantasai: border-widths? 21:09:55 Looks like height in Mozilla is a border-box height 21:11:54 ChrisL has joined #css 21:12:26 fantasai thinks we should say that the height sets the border-box height of the cell box 21:12:38 The contents of the cell are wrapped in an anonymous box, and that is aligned inside the cell 21:13:18 Alex: What do Mozilla and WebKit do for flexbox? 21:13:22 dbaron: I'm not so concerned with that 21:14:49 Steve: So you have two boxes, one that most properties apply to, and then the box that wraps the contents of the cell, that gets vertical-aligned 21:15:18 Steve: The first box has border, padding, etc. 21:16:54 dbaron: We should figure out what we want so that someone can write a proposal 21:17:04 dsinger asks a question 21:17:35 dbaron: baseline alignment is a relative thing. You take all the cells in the row and baseline-align their contents. 21:17:58 dbaron: If the height of the row is taller than the height of the aligned set of content, it's undefined what happens 21:19:17 Steve: So your question is that ... can we give names to these things? 21:19:33 dbaron: One of them is called the cell box, but it's not what you'd think of as the cell box 21:23:18 dbaron: The simplest change it to go with IE and Opera and say that 'height' on the cell sets the minimum height of the row 21:25:29 http://dev.w3.org/csswg/css3-tables-algorithms/Overview.src.htm 21:26:16 howcome talks about making a bar chart 21:26:46 dbaron: An explicit height on a table cell does not cause even the contents of that cell from increasing the height of the cell 21:26:51 dbaron: Everything's like minimum heights in tables 21:27:29 Alex agrees with Opera's interepretation 21:28:28 Steve: If you want the other behavior, you can put a fixed height on a
inside 21:28:42 plinss: Shouldn't require markup changes for layout 21:28:51 fantasai: This is the most intuitive interpretation. 21:29:45 fantasai: If I was an author, I'd associate the height of the table cell with the height of the box that has borders and backgrounds on it, not some invisible thing inside it 21:30:31 ACTION: dbaron write proposal for IE-Opera behavior for issue 26 21:30:31 Created ACTION-210 - Write proposal for IE-Opera behavior for issue 26 [on David Baron - due 2010-04-05]. 21:30:41 Simon: Hyatt doesn't really care which way this goes 21:31:02 http://wiki.csswg.org/spec/css2.1#issue-114 21:33:29 szilles has joined #css 21:34:39 fantasai explains that the spec is unclear about what is allowed and what is invalid 21:35:41 Arron has a bunch of testcases showing that results are very different across browsers 21:35:47 There are two proposals for clarifying the spec 21:35:57 one would make unquoted font names a series of identifier tokens 21:36:06 the other would make them a series of nmchars tokens 21:36:14 Chris suggests recommending quotes 21:36:20 The spec already recommends quotes 21:38:15 dethbakin has joined #css 21:38:42 dethbakin has joined #css 21:39:29 dbaron: right now in Gecko you have to escape or quote numbers 21:41:07 jer has joined #css 21:41:45 several: Let's allow everything 21:42:05 everything but comma 21:42:11 fantasai: I don't like that, because you have to have some exceptions, which is what we have already, and it's already causing interop problems 21:42:30 http://lists.w3.org/Archives/Public/www-style/2010Mar/0395.html 21:43:31 http://www.w3.org/TR/CSS21/fonts.html#font-family-prop 21:44:35 Chris: How about making a grammar for what the prose already says 21:45:24 alexmog has joined #css 21:47:47 discussion of what mistakes web authors are likely to make 21:47:56 some font families that might be useful for tests - "101 Dalmations" "3.14 Pi" "Twenty 4px" 21:49:11 dbaron: right now the spec has document conformance reqs but no ua conformance reqs 21:51:09 arron: If you run the testcases, you'll see a lot of constency except for numbers and brackets 21:51:56
21:55:24 Topic: CSS2.1 Test Suite 21:55:39 glazou: First issue is about inode strain on the server 21:57:00 bert: it's not about space, it's our mirroring system 21:57:19 Alex: Would adding another 15000 tests facilitate upgrading the system? :) 21:57:43 Chris: It's generating emails to the mirrors for each file 21:58:13 glazou: If solving this for w3.org involves more work for us on the test suite, let's just move. 21:58:26 glazou: I suggest we do nothing and wait 21:59:21 bert: I also have an action to get the issues list onto w3c servers 22:00:09 dbaron has joined #css 22:00:41 Chris: The SVGWG had its working its files off-site on a company server, then that company got bought and the files disappeared. TOok months to get the tar files back. 22:00:59 fantasai, plinss: Our server is not controlled by a company, it's a personal account, funded by HP, but under plinss's name 22:02:36 fantasai: We could create tarballs for the snapshots, just publish the latest expanded out 22:02:49 Topic: Reviewing testcases 22:02:59 Arron: We're not getting a lot of traction on review of testcases 22:03:10 Arron: It's something that needs to happen 22:03:56 Plinss: We decided we'd drive reviews by people generating implementation reports 22:04:32 plinss: And then people can object if they find test is wrong 22:05:52 glazou: When will the test suite be complete? 22:07:02 discussion between glazou and fantasai about scheduling test suite work 22:08:09 fantasai aims to publish ts beta 1 in mid-April 22:08:36 Arron: It should take each browser vendors 2 days of 8 hours each to run an implementation report 22:08:59 Glazou: We must be in PR by September, keep that in mind 22:09:10 Topic: Vendor prefixes 22:09:12 Bert: Why? 22:09:23 glazou: There's been a bunch of discussion on www-style 22:09:32 glazou: I don't think the current situation is satisfactory from the web authors pov 22:10:13 glazou: On filters and web-authoring tools side it's hell 22:10:30 Alex: Shouldn't be using experimental stuff until it's stable 22:11:09 dbaron: I think we should be able to find a way to declare things stable until CR 22:11:25 Steve: There is a way. It's called CR. It hasn't received enough review until then 22:11:44 It hasn't gone to last call 22:11:52 @mixin border-radius(radius: 8px) { 22:11:54 -moz-border-radius: var(radius); 22:11:56 -webkit-border-radius: var(radius); 22:11:58 border-radius: var(radius); 22:11:58 Steve: If you need to, make smaller modules. 22:11:59 } 22:12:01 .box-with-corners { 22:12:03 @mixin border-radius(12px); 22:12:04 border: 2px solid black; 22:12:06 } 22:12:10 ^^^ make an end-run around the issue with additions to syntax 22:12:34 glazou: I think we should have a frozen status for features 22:12:48 Steve: ... W3C process 22:13:04 dbaron: The versioning process of CSS isnt' a W3C process issue 22:13:16 anne: What impl do or not doesn't have anything to do with process 22:14:37 Steve: You should be at CR when you write the tests because that's when the spec is stable enough to write a test suite 22:14:58 dbaron has joined #css 22:15:01 Steve: We have good examples where removing the prefix would have been a mistake 22:15:29 Howcome: We have had decisions in the past, when we said they will never change again, even though they're not in CR. I think that makes sense 22:15:49 Steve: The reason it doesn't make sense is that part of Last Call, which is the part you're living out, is to get review from people /not/ in the WG. And you're not getting that review 22:16:06 Tab: I agree with Steve. I think we should stick with this model. 22:16:39 Bert: The problem is we do so many things simultaneously. We should focus on things that are stable and /finish/ them. Then we wouldn't have this problem. 22:16:54 Tab: We could make vendor-prefixes less painful for authors we could use a mixins syntax 22:17:08 glazou has joined #css 22:17:40 Tab: This example is simple one, for border-radius. 22:17:58 Tab: If one implementation had a slightly different syntax, you could just change it in the mixin definition 22:18:03 Tab: And you only need to write it once 22:18:23 Tab: every time you need border-radius 22:18:36 glazou talks about HTML5's versioning model 22:18:42 Tab: I don't like HTML5's model. It's much nicer in JavaScript 22:18:55 s/HTML5/HTML 22:18:57 / 22:19:20 Tab: JavaScript can afford to be ugly because you can layer a nice api over it 22:19:46 dbaron: I think the big problem is not the model, but the timing of how we've been advancing properties 22:19:49 alexmog has joined #css 22:20:06 ?: It's been a problem only for a few, more than one but only a few 22:20:26 s/?/howcome/ 22:20:50 glazou: Whether it's a problem for a property depends a lot on how popular it is 22:21:41 ... 22:21:57 Alex: Isn't it a problem that we have an unprefixed 'zoom' property? It looks like a regular standard property but it isn't 22:22:16 dbaron: We haven't changed our border-radius prefix because we don't yet match the current spec 22:22:39 dbaron: Most of those issues are not even syntactic 22:22:47 dbaron: There are a lot of requirements in the current spec that we don't implement 22:22:59 dbaron: I had questioned at the time whether the spec needed to require things in that much detail 22:23:46 howcome: I think you should drop the prefix anyway. Even if you have some bugs left. THey're just bugs 22:24:13 Brad: If we had dropped the prefix for border-image earlier, we'd be stuck with that 22:25:14 Brad: We wouldn't be able to make the changes I proposed. 22:25:17 Brad: We thought it was stable. 22:25:36 dbaron: I've heard comments from people who were unhappy that the prefixed versions didn't match the spec 22:25:39 ... 22:25:47 Steve: Why isn't macros, by any other name, a good solution to this? 22:26:43 glazou asks questions that were answered previously 22:26:57 the minute-taker will not repeat the answers 22:27:15 plinss: If they have different behavior? 22:27:20 (One way to do mixins, especially usefule if you work with Ruby: http://dev.w3.org/csswg/css3-tables-algorithms/Overvie w.src.htm 22:27:27 Tab: If it's just syntactic, you can work around it. If you can't, then you're screwed anyway 22:27:49 Wrong paste, I meant http://sass-lang.com/ ) 22:27:51 Steve: If they don't do what you want, dropping the prefix isn't helpful anyway 22:28:18 Plinss: The problem with this is, what if I change something via JavaScript? 22:28:27 Anne: Maybe you don't see it in JavaScript 22:28:31 ... 22:28:41 howcome: This saves people 30 seconds of copy-pasting. It's not really a problem 22:30:14 howcome: I think this problem is over-rated 22:30:29 I agree with howcome 22:30:56 Tab: If we want to drop prefixes on something not in CR, we should pull it out into another module 22:30:58 alexmog has joined #css 22:31:12 Bert: We did that with css3-backgrounds, we dropped box-shadow so we could move everything else forward 22:31:24 Tab: Yes. That would solve this while giving us all the benefits of CR. 22:32:15 Steve: We can solve this problem by focusing on what's important and pushing that forward 22:33:39 glazou: You don't know whether something's going to be succesful when you design it 22:33:53 some arguments that it doesn't matter, you'll find out quickly 22:34:02 others that you can predict it for some things anyway 22:34:12 Steve: Once you find out something is popular, then you progress it faster. 22:34:17 dbaron has joined #css 22:36:16 glazou: If we accept the extra work to extract properties and push it forward, then it's not a problem 22:37:13 Chris: Depends on how much of the spec is stable. If it's mostly stable, pull the unstable things out and move the whole thing 22:37:24 Chris: If it's mostly unstable, extract the stable parts and push that forward. 22:38:57 Anne: Other WG's have pseudo-stable drafts that are implemented and shipped, and only take small changes 22:39:03 Anne: It seems to work relatively well 22:39:05 Steve: Yes and no 22:39:11 -> offline 22:39:33 glazou: If we have a high-priority set of properties, let's try to extract them to move faster 22:54:10 Topic: Status-type Stuff 22:54:19 Topic: Style-attr spec 22:54:32 glazou: Last Call period ended. Need to check comments and write disposition of comments 22:54:55 fantasai: I'm waiting for a response from SVGWG, other than that it's pretty much done 22:55:38 http://dev.w3.org/csswg/css-style-attr/issues-lc-2009 22:57:40 dbaron has joined #css 22:57:56 dbaron: Should include tests for common problems 22:58:02 dbaron: like braces around the declaration block 22:58:12 Topic: Media Queries 22:58:19 glazou: CR period ended a few months ago 22:58:25 glazou: We dont' have a test suite, I think 22:58:34 Anne: a lot of tests submitted, but no suite 22:58:39 glazou: So, what do we do? 22:58:47 Anne: We find someone to go through the tests and make a test suite 22:58:54 howcome: We already found him 22:59:03 howcome: Can't you do that? 22:59:09 anne: I'm not sure I want to 22:59:15 howcome: That wasn't my question :) 22:59:44 anne: We have a lot of different tests, they're not all in the same format 23:00:47 Anne explains some of the types of tests that were submitted 23:01:59 discussion of how to test the 'grid' feature 23:04:52 glazou: Are you able to handle the media queries test suite, or not? 23:05:01 anne: I would rather not. I haven't done any work on it 23:05:12 anne: the tests are posted to various mailing lists 23:05:59 ACTION: Chris Find tests for media queries and check into test repository 23:05:59 Sorry, amibiguous username (more than one match) - Chris 23:05:59 Try using a different identifier, such as family name or username (eg. ChrisWilson, clilley) 23:06:11 Anne: I'm sort of swamped with editing 23:06:28 ACTION: clilley Find tests for media queries and check into test repository 23:06:29 Created ACTION-211 - Find tests for media queries and check into test repository [on Chris Lilley - due 2010-04-05]. 23:06:39 Topic: Namespaces 23:06:46 glazou: We're in CR, it is implemented 23:07:03 dbaron: I think we fixed the one parsing bug we had 23:07:37 glazou: We need implementation reports 23:09:36 dbaron: If the bug is in the 2.1 implementation, can we say that the bug is in the 2.1 spec implementation and for the purposes of Namespaces it's a pass? 23:12:39 Implementation report Firefox 3.6.2 Linux: all tests pass 23:12:40 dbaron: All tests pass on FF3.7 Linux 23:12:45 http://www.w3.org/Style/CSS/Test/CSS3/Namespace/current/ 23:12:52 ACTION: glazou make namespaces implementation reports 23:12:52 Created ACTION-212 - Make namespaces implementation reports [on Daniel Glazman - due 2010-04-05]. 23:13:32 Topic: CSS3 Page 23:14:36 fantasai: It needs a lot more work before another Last Call 23:14:46 Topic: CSS3 Backgrounds and Borders 23:16:17 fantasai: Planning to write 10-15 tests to set up, then will be easier to accept submissions. Probably nothing complete until August F2F at the earliest 23:16:20 Topic: CSS3 Color 23:16:37 dbaron: Some LC comments are non-trivial. We should go through the comments some time this meeting 23:17:09 dbaron: The current editor's draft addresses most, but not all, issues. Haven't sent responses yet. 23:17:24 http://wiki.csswg.org/spec/css3-color is the issues list 23:17:57 Topic: Background Shorthand Syntax, to slash or not to slash 23:22:05 fantasai: 4 issues, somewhat related. 23:22:12 fantasai: All effect the shorthand. 23:22:22 fantasai: sylvain's issue was background-clip. 23:23:10 arronei has joined #CSS 23:24:21 fantasai: Start with background-clip, do we allow content-box? 23:25:15 fantasai: As well, in the shorthand, I suggest that if *-box appears once, it sets both origin and clip, while if it appears twice, it sets origin *then* clip. 23:26:19 bradk: I wanted to do bg-size first, so I could bring up that we could use a slash to disambiguate this as well. 23:27:01 plinss__ has joined #css 23:27:23 bradk: [on board] Right now you've got like "/ ". 23:28:23 bradk: So apply that the same to origin/clip, so you could say, like "border-box / padding-box" or just "border-box" or just "/ padding-box". 23:30:33 TabAtkins: I want to avoid / whenever possible, though. 23:30:51 bradk: We're already using /s in various properties, border-radius, font, border-image. 23:31:27 TabAtkins: In a lot of those, though, you're splitting apart lists of numbers, and it's *impossible* to tell where things start and end without the /. With keywords you don't need to do that. 23:31:49 anne: Other places with keywords, like overflow, don't need a /. 23:32:01 anne: And background-repeat. 23:32:36 bradk: You need *something* to separate bg-position and bg-size. 23:32:40 anne: Yeah. 23:33:21 bradk: You get some freedom with how you write things with the / 23:33:27 anne: Is that freedom actually needed, though? 23:34:32 TabAtkins: I don't think we need to generalize in order to solve the position/size issue. Other places where we have a /, we definitely need it; other places where we don't, we definitely don't. 23:34:42 fantasai: I think separating them would make things more difficult. 23:34:54 fantasai: When you're parsing, you can just shove stuff into data structures directly. 23:35:08 fantasai: You don't have to remember what has come before. 23:35:57 fantasai: That's part of why Yves wanted to relax the restriction on ordering, so you just have to look at the previous token to see if it's valid to put in a bg-position, rather than having to remember that you had a size earlier in the rule. 23:36:29 fantasai: position is always a position. If size is completely absent, it's a position. 23:36:38 bradk: Don't you have to read ahead to see if there's a size? 23:37:07 fantasai: No, as soon as you hit lengths, you know it's a position. And then, later, you might see a slash denoting a size. 23:37:59 Bert: I think the main issue is just one of readability. 23:39:35 [discussion about human/machine parsability with a / anywhere in the rule versus / immediately before a size] 23:43:11 TabAtkins: So can we add content-box to bg-clip, and accept the shorthand? 23:44:38 strawpoll: Add content-box to background-clip? 23:45:03 Abstain? 6 23:45:10 Objections? 0 23:45:18 RESOLVED: Add content-box to bg-clip 23:45:36 RESOLVED: Allow setting bg-origin and clip in shorthand 23:48:55 fantasai: Disallow "/size position", definitely. 23:49:23 dsinger__ has joined #css 23:49:45 fantasai: Allow "position url /size" and "/size url position"? 23:50:29 fantasai: Or restrict it to *only* "position/size"? 23:51:54 RESOLVED: Change background shorthand to have " [/ ]". (Position is required if you specify size.) 23:52:13 http://lists.w3.org/Archives/Public/www-style/2010Feb/0238.html 23:52:15 fantasai: Small one about border-radius. 23:52:41 fantasai: 1) Define gradient stops in more detail. 2) Dont' define color-transitions at all. 23:53:05 howcome: So what was the problem before? 23:53:23 dsinger__ has joined #css 23:53:34 sylvaing: Today with different-colored borders, you get a sharp border. If we want a gradient, we need a way that's interop across browsers. 23:53:51 ChrisL: Currently the spec tells you where on the curve the midpoint is. 23:54:02 ChrisL: I think we should still be able to get that, and I think that's enough to get a gradient. 23:55:45 ChrisL: [describes a linear-gradient based one] 23:56:01 sylvaing: Could we get it back through CR quickly with that? 23:57:11 in fact i descriped two gradients, one from the start color to the midpoint color and one from the midpoint color to the end color; both linear wrt *angle* 23:58:15 sylvaing: I see it as a different issue. I want to control my corners, and then I want to control my borders. 23:58:33 fantasai: I think making it undefined is fine, and then we have an informative appendix. 23:59:28 szilles: The experience of leaving things undefined is that someone ends up defining them. 00:00:31 ChrisL: I understand the argument of doing the simple thing now and the complicated thing now. But what I don't like is some browsers having a sharp transition and you do a smooth transition because you think it looks better. 00:01:04 dbaron: I haven't seen authors complain about this yet, but authors *do* complain about performance, and sharp vs gradients has performance implications. 00:01:58 sylvaing: If we later do 45deg corners, you'll need a linear gradient, etc. 00:02:37 fantasai: I'm fine with leaving it undefined right now, and we'll define it in level 4 and we'll be good. 00:03:51 szilles: But we won't have that freedom after a little bit. 00:04:00 dbaron: I think I'm okay with that lack of freedom. 00:04:08 jer has joined #css 00:07:29 fantasai: If our browsers do something right now that authors don't like, we'll change. 00:07:59 dbaron: sometimes it's best to let the market decide 00:10:04 sylvaing: I'm fine with specifying sharp transitions, and I'm fine with undefined. 00:10:06 "It is not defined what these transitions look like." 00:11:01 Tab: I'm fine with explicitly undefined, being defined later possibly constrained by market forces 00:11:29 Chris: I would prefer it to be dfined, but I can live with the other options 00:11:41 arronei: From a testing perspective, I prefer defined. 00:13:18 dsinger: If someone *requires* a particular effect, they can use a border-image, right? I'm okay with leaving it undefined and waiting to see what people start hacking around it with. 00:14:13 dbaron: We can define the shape of the border, we can define the limits of the transition, we just won't define what it looks like other than that. 00:14:26 RESOLVED: proposal 3 accepted 00:14:52 szilles: So all existing hard-edged impls match that proposal? 00:14:55 glazou: yes. 00:15:07 glazou: howcome, you have the floor for box-shadow 00:15:17 howcome: box-shadow was removed to gain speed for the spec. 00:15:35 howcome: We now have 4 interoperable impls of box-shadow, so I think we should put it back in. 00:16:06 howcome: Or else put it in it's own spec. 00:16:37 glazou: I have some tests, and it looks interoperable. 00:16:56 howcome: [looking at MS people] I suspect they have something up their sleeve. 00:17:00 sylvaing: We'd like to see it back in. 00:19:25 howcome: So we have interop, why was it removed? 00:19:34 dbaron has joined #css 00:19:56 TabAtkins: There were significant complications being suggested, to the point where it *was* going to slow the draft. A very simple box-shadow, what we have interop on, would have been ok. 00:21:39 howcome: My position is that we add it back in. Simple list of lengths, a color, an inset/outset keyword. Purely rectangular (module border-radius). 00:21:57 RESOLVED: Put the simple version of box-shadow back into B&B. 00:22:07 Topic: GCPM - env() function 00:22:15 http://dev.w3.org/csswg/css3-gcpm/ 00:22:28 howcome has joined #css 00:22:31 miketaylr has joined #css 00:22:38 http://dev.w3.org/csswg/css3-gcpm/#string-set 00:23:01 howcome: If you print in most browsers, the browser will put the time of printing in the margin box. 00:23:12 howcome: The idea is to make it possible to get that info in CSS. 00:23:25 env(location.lattitude) 00:24:16 Is this going to gradually turn into strftime? 00:24:24 dbaron, yes. 00:25:21 2010年04月02日 vs. 2010-04-02 vs. 2/4/10 vs. 4/2/10 vs. 2/4/2010 vs. 4/2/2010 00:25:25 glazou: A long while ago, around CSS2, we had a proposal for a date() function, Michelle Wolfe (sp?) gave a long, excellent argument for why date is no good. 00:25:39 s/Michelle/Mischa 00:26:25 s/Michelle Wolfe/Misha Wolf/ 00:26:36 s/Mischa Wolfe/Misha Wolf/ 00:26:49 szilles: How does the system know what to output the date as? 00:27:19 glazou: From the system locale. 00:27:51 szilles: That assumes the locale it is printed in is the same as the locale it is read for. 00:28:17 glazou: That's the same problem that you *already have* with dates on printouts, you're just styling them now. 00:29:39 [discussion of how Word does stuff/locale bindings] 00:30:12 howcome: There is a way to just ask the system for the date, and env(date) would just give that. 00:30:43 szilles: What's the use-case for this? 00:31:04 howcome: Use-case is, when a browser prints a page today, they put the date on the printout. This would give you control over that. 00:31:27 szilles: I'm printing a document that's written in Armenian, and I'm going to distribute it to my Armenian friends. 00:32:24 howcome: By adding this feature, we allow ourselves to turn it off as well. 00:34:43 szilles: I could potentially turn it off with just a little checkbox in some preferences. 00:35:07 TabAtkins: No browser lets you do that right now. We can solve it through CSS. 00:36:18 Bert: Some javascript to get at things from your environment (such as if you are counting in the jewish date) that you may not want. 00:36:48 glazou: You already have (new Date()).toLocaleString(). 00:37:40 szilles: My issue isn't with whether you want url or date. My issue is more the discussion from Mischa, where the date is a very dangerous thing. 00:38:28 szilles: I don't think there's a such thing as the "date". 00:38:47 TabAtkins: You're trying to add things to what we just want to simply cssify. 00:38:50 javascript:(new Date).toLocaleString() 00:38:59 Monday March 29, 17:38:45 GMT-0700 2010 00:39:55 smfr: Is the intent to limit it to Paged Media? 00:40:11 howcome: No, it can go in content property, so it can go anywhere potentially. 00:40:48 anne has joined #CSS 00:40:54 smfr: When is the date set? Is it live? Does it update when the page is refreshed? What about if layout changes something? 00:41:01 glazou: More detail is needed there. 00:41:19 anne has joined #CSS 00:41:22 glazou: Sometimes when printing, the *username* is displayed on the printout. We shouldn't give access to that. 00:41:59 howcome: So it seems like this is potentially a useful thing, but there are security and i18n concerns. 00:42:03 bradk: Date, or date and time? 00:42:25 howcome: We can do env(date) and env(time). 00:43:04 plinss: Some printouts have the document title. 00:43:12 howcome: You can already pull that from using string-set. 00:43:31 <smfr> http://dev.w3.org/csswg/css3-gcpm/#turning-elements-into-footnotes 00:43:32 <TabAtkins> howcome: Small issue with footnotes. If you're in the draft, look at example XXIV 00:44:26 <TabAtkins> howcome: display footnotes stacked vertically, or flowed inline. 00:44:54 <TabAtkins> howcome: My first idea is to use display on the footnote element that determines what it does here. 00:46:04 <TabAtkins> howcome: But I think this is sorta inconvenient, as when you're floating an inline element you'd have to explicitly set display:block. 00:46:20 <TabAtkins> arronei: What about float:footnote and float:inline-footnote? Then you don't have to mess with display. 00:46:24 <TabAtkins> TabAtkins: I like that idea. 00:47:10 <TabAtkins> bradk: And could we then do display: list-item on the footnote to auto-generate the marker. 00:48:35 <TabAtkins> glazou: You cannot use list-item, because it precludes an inline footnote. 00:49:43 <TabAtkins> howcome: Suggestion: Put display:inline on the @footnote rule, to switch the display type of the footnotes. It's a bit of a hack, but display is otherwise unused in @footnote. 00:50:05 <sylvaing> sylvaing has joined #css 00:52:14 <TabAtkins> howcome: Input is great, we'll discuss more on the list. 00:52:22 <TabAtkins> howcome: I'd also like a new editor's draft. 01:09:29 <shepazu_> shepazu_ has joined #css 01:27:57 <Curt`> Curt` has joined #css 01:41:52 <TabAtkins> TabAtkins has joined #css 01:58:21 <karl> karl has joined #CSS 02:38:20 <plinss__> plinss__ has joined #css 03:53:13 <smfr> smfr has joined #css 04:11:20 <paul_irish> paul_irish has joined #CSS 04:14:36 <TabAtkins> TabAtkins has joined #css 04:53:15 <paul_irish> paul_irish has joined #CSS 04:56:39 <paul_irish> paul_irish has joined #CSS 05:14:45 <mib_a17avm> mib_a17avm has joined #CSS 05:15:55 <mib_a17avm> mib_a17avm has left #CSS 05:20:06 <findow> findow has joined #CSS 05:20:43 <findow> Anyone here? 05:24:39 <Arron> Arron has joined #css 05:31:06 <mib_mjip2q> mib_mjip2q has joined #CSS 05:47:16 <anne> anne has joined #CSS 06:22:54 <TabAtkins> TabAtkins has joined #css 08:16:50 <lstorset> lstorset has joined #css 08:17:03 <lstorset> lstorset has left #css 10:21:41 <lstorset> lstorset has joined #css 10:23:51 <lstorset> lstorset has left #css 10:35:00 <fantasai> fantasai has joined #css 10:47:51 <fantasai> fantasai has joined #css 13:10:11 <paul_irish> paul_irish has joined #CSS 13:11:41 <miketaylr> miketaylr has joined #css 13:24:40 <anne> anne has joined #CSS 13:45:37 <paul_irish> paul_irish has joined #CSS 14:13:32 <TabAtkins> TabAtkins has joined #css 14:19:04 <paul_irish> paul_irish has joined #CSS 14:30:06 <myakura> myakura has joined #css 15:10:56 <Arron> Arron has joined #css 15:28:13 <alexmog> alexmog has joined #css 15:44:48 <CSS-projector> CSS-projector has joined #css 15:54:04 <TabAtkins> TabAtkins has joined #css 15:54:58 <anne> anne has joined #CSS 16:01:04 <Arron> Arron has joined #css 16:01:55 <alexmog> alexmog has joined #css 16:02:11 <sylvaing> sylvaing has joined #css 16:04:33 <bradk> bradk has joined #css 16:05:01 <smfr> smfr has joined #css 16:05:52 <plinss_> plinss_ has joined #css 16:05:53 <smfr> http://wiki.csswg.org/planning/cupertino-2010 16:06:14 <dbaron> dbaron has joined #css 16:12:09 <glazou> glazou has joined #css 16:12:36 <glazou> RRSAgent, make logs public 16:12:47 <TabAtkins> ScribeNick: TabAtkins 16:13:35 <TabAtkins> Topic: Transitions of non-animatable properties 16:13:35 <glazou> RRSAgent, http://lists.w3.org/Archives/Public/www-style/2009Nov/0328.html 16:13:35 <RRSAgent> I'm logging. I don't understand 'http://lists.w3.org/Archives/Public/www-style/2009Nov/0328.html', glazou. Try /msg RRSAgent help 16:13:36 <dethbakin> dethbakin has joined #css 16:13:44 <szilles> szilles has joined #css 16:13:46 <smfr> http://wiki.csswg.org/planning/cupertino-2010 16:14:26 <TabAtkins> dbaron: Transitions spec currently has a special case for visibility. 16:14:56 <TabAtkins> dbaron: We may want to keep it despite this, but the idea for the special case is the if visibility has a transition from 'visible' to 'hidden', it's considered to be a property that can transition, where all intermediate states are transitionable. 16:15:16 <glazou> rrsagent, this meeting spans midnight 16:15:18 <TabAtkins> dbaron: So if you're transition from visible to hidden, the transition happens when a timing funciton ends. 16:15:35 <TabAtkins> dbaron: This makes sense if you're, say, shrinking something and then want it to disappear entirely. 16:16:00 <TabAtkins> dbaron: Somebody wanted this to apply in other cases; in particular, they were trying to convert the controls Gecko uses for HTML5 video, which has a number of animations. 16:16:42 <TabAtkins> dbaron: He was trying to do them using Transitions, but one thing that happens is a display change. He wants to be able to transition to display:none after an opacity transition happens. 16:17:18 <TabAtkins> dbaron: He ended up using the transitionend event, but he'd like to do this just with the transition support. 16:17:44 <TabAtkins> dbaron: So what we think we might do is that, for non-animatable properties, we don't have transition-duration support, but *do* have transition-delay support. 16:18:07 <TabAtkins> smfr: So you'd take transition-delay into account, and just do an instantaneous transition after that. 16:18:47 <TabAtkins> dbaron: If we did this, we might still want to keep this special rule for visibility, because it's a little bit harder to do things this way (you have to do delay for this one property rather than a duration). 16:19:07 <TabAtkins> dbaron: Now with visibility, we know that people want visible in the 'middle', but for other properties we don't know what people want in the middle. 16:19:35 <TabAtkins> dean: The next topic is discrete timing functions, which would also solve this and give you control over when the non-animatable property transitions. 16:19:43 <TabAtkins> dbaron: Yeah. 16:20:01 <TabAtkins> dbaron: Are you saying you want to do it the delay way, or the stepwise way, or both...? 16:20:04 <TabAtkins> dean: Your way. 16:20:27 <TabAtkins> smfr: But if you have stepwise timing functions, you don't necessarily need a delay trick. 16:20:51 <smfr> step-wise timing function proposal: http://lists.w3.org/Archives/Public/www-style/2010Feb/0212.html 16:20:53 <TabAtkins> dean: With a stepwise timing function, if you say something like "I only want a change at the end of the transition", you can control when, say, a display:none transitions. 16:21:30 <TabAtkins> dean: Basically I think we can make this decision *without* having to worry about stepwise functions first. 16:23:02 <TabAtkins> dsinger: Right. We just need to decide if we fix the transition to happen at the beginning or the end. 16:24:10 <TabAtkins> plinss: What about a transition from block to inline? There's no easy answer for start or end. 16:24:30 <TabAtkins> smfr: Right, stepwise timing functions have a start and end transition function, so you can decide which one to use. 16:26:58 <TabAtkins> dsinger: So if you're not using a stepwise timing function, 0 is start and 1 end, and what do we do in the middle? 16:27:29 <TabAtkins> dbaron: I think the rule that's most compatible is to have all non-0 round to 1. 16:28:08 <TabAtkins> dbaron: Now most of the time people will want to be able to reverse their transition, so that's a little hard. They'll have to make two different declarations. 16:28:21 <TabAtkins> smfr: We talked about the issue of not getting symmetry by default, and there's no easy solution I think. 16:29:04 <TabAtkins> dbaron: One thing that just occurred to me is that we could add a property that says "reverse all the timing functions". 16:29:35 <TabAtkins> dbaron: So when people transition to a hover state, they can put this property on the hover and make it work. 16:30:01 <TabAtkins> smfr: That gets into a weird bit of statefulness. 16:30:22 <TabAtkins> TabAtkins: Like what if you go to :hover and then click and activate an :active transition. 16:30:24 <glazou> Present: Dino, smfr, annevk, szilles, sylvaing, alexm, dethbakin, Bert, arronei, fantasai, dbaron, bradk, TabAtkins, glazou, plinss, howcome, dsinger 16:30:27 <TabAtkins> smfr: How are youd efining the states? 16:30:39 <TabAtkins> dbaron: Well, any change. :hover, :active, a class... 16:31:15 <TabAtkins> smfr: Tracking states kind of scares me. 16:31:28 <TabAtkins> dbaron: It requires the author to track states, not the implementation. 16:33:22 <TabAtkins> smfr: All the transitions are reversible, right? 16:33:40 <TabAtkins> TabAtkins: Yeah, but to do it right you have to set up, say, a :hover and then a :not(:hover) rule. 16:33:56 <dino> dino has joined #css 16:34:03 <TabAtkins> smfr: So I think we have two non-exclusive proposals. 16:35:08 <TabAtkins> smfr: One is to just let delay apply to all properties. The other is to add stepwise timing functions. 16:36:18 <TabAtkins> TabAtkins: The stepwise includes making all properties respond to delay, so I'm fine with just going all the way up and adding stepwise timing functions. 16:37:52 <TabAtkins> TabAtkins: Is anyone opposed to adding the stepwise timing functions? 16:37:56 <TabAtkins> [silenc] 16:39:00 <TabAtkins> anne: One question. The use-case we were looking at this morning was transitioning a display:none as well other properties. It can be solved with stepwise timings, but could we also do a transition-start event to activate it? 16:40:07 <TabAtkins> anne: Another advantage of making them all animatable is that if we add the ability to interpolate one of the non-animatable ones later, we can just do it. 16:40:24 <smfr> http://lists.w3.org/Archives/Public/www-style/2010Feb/0212.html 16:40:40 <TabAtkins> RESOLVED: Make all properties animatable. (non-0 values round to 1) 16:42:50 <TabAtkins> smfr: [explains full stepwise timing-function proposal] 16:43:57 <TabAtkins> smfr: You may want to control where an *animatable* property precisely step, so you can have it step, say, halfway through, or control how many steps take place. 16:44:43 <TabAtkins> smfr: A good example of this is the progress spinner on Mac OSX. It doesn't smoothly rotate; it does 12 discrete steps, and we can't do that right now with Transitions. 16:46:45 <TabAtkins> dean: We'd suggested a few things, like letting someone specify the timing function curve as an SVG Path, but I think this proposal hits the majority of cases very simply. 16:47:27 <TabAtkins> howcome: I like this stepwise function, but I don't know if I accept the value of full control of a bezier curve. I think a few keywords would just do it. 16:48:09 <TabAtkins> dean: [shows some example of where animation programs allow complex control of a curve] 16:48:32 <TabAtkins> dean: Writing a bezier function by hand is hard, but it's easy to understand when you see it. 16:49:07 <TabAtkins> howcome: Can we just say that if you want more control, just use SVG? Keywords are the 90% function, right? 16:49:42 <TabAtkins> dean: Well, we *also* have the 90% solution; we keep the keywords. But we also then add the bezier function. 16:50:00 <TabAtkins> glazou: I think this is an excellent first example of something in CSS that can't be really hand-authored. 16:50:11 <TabAtkins> howcome: I get worried when we say we don't care about complexity. 16:50:56 <TabAtkins> dbaron: 99% of the implementation complexity is just implementing 'ease'. Doing any other bezier curve is just plugging in two more numbers. 16:51:47 <dbaron> s/two more/four more/ 16:52:20 <TabAtkins> TabAtkins: This doesn't produce any long functions. A bezier is just four numbers. 16:53:17 <TabAtkins> szilles: Can't we just have a list of xy pairs? 16:53:38 <TabAtkins> smfr: That allows too much possibility of getting things wrong, accidentally defining invalid steps. 16:54:00 <howcome> howcome has joined #css 16:54:12 <TabAtkins> szilles: Sure, but you can do that with just the plain number in step-start(). 16:54:27 <TabAtkins> TabAtkins: Do you think we *need* that degree of control over the transition steps? 16:54:52 <TabAtkins> dean: What I like about the simple form we have is that you can leave off the number entirely and it's very intuitive what happens. 16:56:09 <TabAtkins> dean: [gives an example of using a step-start function to animate a second hand on a clock] 16:59:44 <TabAtkins> [some confusion about difference between step-start and step-end] 17:00:13 <TabAtkins> glazou: I would like it better with something like "steps(60) start" or "steps(60,start)". 17:00:54 <TabAtkins> dean: Yeah, that's fine, but we also want an author to be able to do the simple case without having to write much, like just "steps" or "steps(start)". 17:01:10 <Bert> (I don't believe you can animate a rotation: rotate(0) and rotate(360) look exactly the same, moving the box from one to the other is a no-op, isn't it? And 60 steps of no-op is still a no-op.) 17:01:14 <alexmog> alexmog has joined #css 17:02:10 <TabAtkins> glazou: No, they end up looking the same, but it's still a different thing. 17:02:46 <TabAtkins> Bert: Where is it specified that you transition the value of the rotate function? 17:02:59 <smfr> http://www.w3.org/TR/2009/WD-css3-2d-transforms-20091201/#matrix-decomposition 17:03:18 <TabAtkins> dean: In the Transitions spec, there's a big section defining how to animate Transforms. 17:04:39 <TabAtkins> Bert: If you had a rotate and a translate both? 17:05:09 <TabAtkins> dean: If the from state and the to state have the same transform functions in order, you pick them up in order and transition each one independently. 17:05:23 <glazou> glazou: no, 360deg and 0deg are not the same ; we all wrote our first draw-a-circle-on-screen program iterating from 0deg to 360deg 17:05:36 <TabAtkins> dean: If they don't match, you do the matrix decomposition and animate that, which is defined in Transitions spec. 17:06:29 <TabAtkins> Bert: Still a bit confused about transitions when the start and end state look the same. 17:06:51 <TabAtkins> dean: I think you're confused because you haven't read the transition spec yet. 17:07:07 <TabAtkins> Bert: Does this apply to color as well? If you transition from an rgba color to an hsl color? 17:07:21 <TabAtkins> smfr: Right now we define it as transitioning through rgb space. 17:07:32 <TabAtkins> dean: The problem is defining exactly how to transition the hue. 17:07:51 <TabAtkins> dean: But we may have control over this later. 17:08:17 <TabAtkins> dean: SMIL and SVG don't give you these controls either. 17:09:07 <TabAtkins> howcome: Some implementor told me there was some ambiguity. 17:09:19 <TabAtkins> dean: I think the spec might just say it in a single sentence or something. 17:09:36 <TabAtkins> dean: So, back to steps. 17:09:52 <TabAtkins> smfr: I'm happy with what daniel proposed ("steps() function") 17:11:37 <TabAtkins> dean: Maybe it should be step() instead, and we decide whether it goes at the start or end? 17:11:54 <TabAtkins> glazou: Just do step-start and step-end, and then steps(). 17:11:56 <TabAtkins> dean: Okay. 17:12:35 <TabAtkins> szilles: I think the usage of the words is inconsistent. [step "start" and "end" referring to different things] 17:13:03 <anne> step() and step-delayed() 17:13:08 <TabAtkins> howcome: Perhaps we can just write it down now, and come up with a better word later? 17:13:25 <bradk> align-steps(start|end)? 17:15:32 <Bert> Why 2 functions, why not just step(n) where n >= 1, 1 by default? 17:15:43 <TabAtkins> RESOLVED: Accept stepwise timing functions, with modifications suggested in minutes (step-start and step-end keywords, plus steps(number,[start|end]) function) 17:20:26 <Bert> (Actually, step(0) as the default is better, then n is the number of intermediate steps.) 17:20:59 <Bert> (or stepS().) 17:28:16 <Bert> (If you want the possibility of unequal steps, you could do steps(0%,0%,20%,50%,80%,85%,90%). But that may be unnecessary.) 17:32:15 <szilles> szilles has joined #css 17:34:25 <fantasai> +Tantek 17:35:37 <TabAtkins> Topic: Progressing Transitions (+ Animations? 17:35:55 <howcome> http://people.opera.com/howcome/2010/talks/03-csswg-cupertino-ta.html 17:36:10 <TabAtkins> howcome: Maybe I'm stupid... 17:36:31 <TabAtkins> howcome: In my mind, when I come to this [points to exmaple on screen] I see transitions and animations being the same. 17:36:56 <TabAtkins> howcome: I think animations are *great* for CSS, but I think we need to have the model clear. I don't think we've ever quite discussed if this is the right model. 17:37:16 <TabAtkins> howcome: We should have *one* set of properties, *-duration, *-timing-function, *-delay. 17:37:44 <TabAtkins> howcome: I wanted to do an animation and a transition, and I wanted them to do the same thing. They're basically the same code, except in one I specify a transition and in one I name an animation. 17:38:21 <TabAtkins> howcome: There are some minor differences. 17:38:35 <TabAtkins> glazou: They're not minor. In transitions the start is defined from context, not explicitly in the animation. 17:39:08 <TabAtkins> howcome: [shows Simon's example of combining transitions and animations] 17:39:50 <TabAtkins> howcome: In my head, it's arbitrary whether you write transitions or animations. 17:40:12 <TabAtkins> dean: I will raise you a head and say "Well, margin and padding are the same thing, so let's make them the same." 17:40:24 <ChrisL> ChrisL has joined #css 17:40:52 <TabAtkins> howcome: Good argument, but I could also say something about webfonts being completely different. But we found a model where they work together with local fonts. 17:41:32 <TabAtkins> dean: I think the major difference between transitions and animations is that transition is an effect you have happen whenever styles change, while animations are something you write specifically to happen when you change something. 17:41:43 <TabAtkins> howcome: I don't grok that as being so different that you need separate properties for it. 17:42:20 <TabAtkins> smfr: If you open that example in a legacy impl, the transition will make it still move, just instantaneous. The animation one, though, won't do anything. 17:43:02 <TabAtkins> smfr: I think it would be useful to add an iteration-count to the animation and see how it compares with transitions. 17:43:33 <TabAtkins> dean: dbaron raised the point on the list that you run into a cascade clash. In most cases you want to control transitions as a separate thing, separate from animations. 17:43:43 <TabAtkins> dean: [dbaron's issue of additive cascade] 17:44:46 <TabAtkins> dean: frex, for a transition you mkight want everything in a document to transition. You can say "* { transition-duration: 1s; }" and everything does it, no further difficulty. 17:45:15 <TabAtkins> dbaron: I wrote a strawman syntax proposal on the list that I didn't particular like. 17:45:40 <TabAtkins> dbaron: I think I'm in the middle of you guys. I think the cascade thing is something we need to solve a general. We need a way to do additive cascading. 17:45:55 <TabAtkins> dbaron: Combining them together makes it a little bit worse in this case, but it's already a problem. 17:46:26 <TabAtkins> dbaron: My strawman idea for combining them is - all the transition properties have an animation sibling, except transition-property and animation-name. 17:46:50 <TabAtkins> dbaron: Drop the individual properties, have a combined one that takes a function for either a transition property, or an animation name. 17:47:17 <TabAtkins> dean: That doesn't solve anything, it just maintains the current separation with a functional syntax. 17:47:56 <TabAtkins> TabAtkins: It does partially address howcome's issue, in that it would eliminate 3 nearly identical properties. 17:48:01 <TabAtkins> smfr: Is that a problem, though? 17:48:05 <TabAtkins> howcome: I think it is. 17:48:15 <TabAtkins> smfr: I think there's a fundamental difference there. 17:48:29 <TabAtkins> smfr: Transitions kick off when CSS properties change for any reason. 17:49:31 <alexmog> alexmog has joined #css 17:53:26 <TabAtkins> TabAtkins: [puts up an example of how transitions work] 17:54:13 <TabAtkins> plinss: I agree that there are enough similarities that it's *possible* to define animations as a type of transition, or vice versa, but I'm not sure it's worthwhile. 17:54:42 <TabAtkins> howcome: I think that's the key question. I want to raise awareness in the room about that possibility. 17:55:43 <TabAtkins> szilles: One thing that struck me is that Transitions are parametrized with the old value and new value. In the Animation, you've stuck in a specific value, but the transition has a "variable" of whatever the start and end values. 17:56:46 <TabAtkins> smfr: I also think you're missing is that Animations can have multiple properties. 17:57:12 <TabAtkins> plinss: Right, so if you key it to Transitions, you could have an animation started by a transition that changes other properties, and then you're into circularity issues. 17:58:21 <TabAtkins> [conversation shifts to hover/non-hover reversing] 18:03:20 <TabAtkins> http://lists.w3.org/Archives/Public/www-style/2010Mar/0266.html 18:04:31 <smfr> http://smfr.org/misc/tab.html 18:05:38 <dbaron> dbaron has joined #css 18:07:42 <TabAtkins> howcome: We agree that we want this sort of thing possible in CSS? [referring to example] 18:07:48 <TabAtkins> everyone: yes 18:08:11 <TabAtkins> TabAtkins: But I have a js hack to make that work properly. Without it, the reverse transition happens on page load. 18:08:18 <TabAtkins> bradk: :unhover! 18:08:25 <tantek> tantek has joined #css 18:08:26 <TabAtkins> tantek: :was(:hover)! 18:08:40 <glazou> in fact that's not what we need 18:08:51 <glazou> we need :will-be(:hover) :-) 18:09:10 <TabAtkins> :wants-to-be(:unicorn) 18:09:25 <tantek> is true on an element if it the selector inside the parens was ever true on the element since document load. 18:10:08 <TabAtkins> szilles: What seems implicit here is that, to combine them, you need an explicit way to refer to the implicit start and end values. 18:11:36 <TabAtkins> szilles: Some things seem simpler than others. Trigger an animation on a transition seems like a relatively simple thing to do. 18:12:02 <TabAtkins> dean: It doesn't help our case, but internally we call them 'implicit' and 'explicit' animations. We used a different name now because they really are quite different things. 18:12:27 <TabAtkins> dean: [example of how the dock works with both transitions and animations, with the zoom and the bouncing] 18:12:39 <ChrisL> ChrisL has joined #css 18:14:03 <TabAtkins> howcome: You could put them together, just have property names mean a transition and a keyframe name mean an animation. 18:14:17 <TabAtkins> TabAtkins: That's a problem if we add a new property that matches a common author keyframe. 18:14:31 <anne> to disambiguate you could use keyframe(<ident>) 18:15:06 <ChrisL> well, a keyframe name could have some syntax to always identify it. $keyframe or something 18:15:12 <TabAtkins> szilles: [talks about animations as a restricted subset of transitions, or viceversa] 18:15:32 <TabAtkins> dean: A transition could be considered an animation that's created automatically at the moment of the property change. 18:15:56 <TabAtkins> dean: That automatically fills in the start and end, and automatically removes itself at the end. 18:16:24 <TabAtkins> dean: We're not just concerned about the impl difficulty here, but about authoring simplicity, and that's definitely why we did them differently. But we'll try. 18:17:03 <TabAtkins> glazou: If you take the animation example, and remove the "from", it's equivalent to a transition. 18:17:43 <Bert> q+ to suggest 'transition-PLAY-count' instead of -ITERATION-, to match 'marquee-play-count' 18:18:21 <TabAtkins> dean: Not quite. Even if you remove the "from" and the "end", you're still saying you want a pulse, and there's nothing left to say what is being transitioned. 18:19:34 <TabAtkins> howcome: [doesn't like the names "Transition" and "Transform" being so close] 18:19:43 <bradk> trans(form|ition): 18:19:58 <TabAtkins> trans(former): robots-in-disguise; 18:20:09 <TabAtkins> [naming talk] 18:21:19 <bradk> metamorphosis-timing-function: 18:21:21 <TabAtkins> ChrisL: If you think of transitions as syntax sugar for an animation that is automatically created, it seems you can harmonize it. 18:22:16 <TabAtkins> glazou: The discussion was not about naming. It was about harmonizing transitions and animations. 18:22:43 <TabAtkins> dean: Ultimately what dbaron proposed is easy to implement; just merge all the properties together and have some way of telling apart transitions and animations. 18:23:04 <TabAtkins> dean: But I want to go back and look at content we have and see if this sort of change will make it easier or harder to write. 18:24:39 <TabAtkins> tantek: How many people have authored this on the public web? I found it confusing immediately, but as soon as I worked with it for a little bit it became very clear. 18:24:46 <TabAtkins> howcome: I had the opposite. 18:25:26 <TabAtkins> dbaron: I said I was in the middle before, now I'm leaning toward dean. 18:26:06 <tantek> transform makes sense from a mathematical functional sense 18:26:22 <TabAtkins> plinss: It is possible to make a superset, the question is if it will help. 18:27:35 <tantek> http://en.wikipedia.org/wiki/List_of_transforms 18:28:24 <TabAtkins> dean: A weird thing if you combine them is that you can have a transition and an animation both controlling the same thing they'll fight. 18:28:49 <tantek> whereas transition makes sense like "state transition" in science/chemistry/physics 18:28:50 <TabAtkins> glazou: I think you can possibly combine them, but at the cost of more complex syntax. 18:28:50 <tantek> http://en.wikipedia.org/wiki/Transition_state 18:29:08 <TabAtkins> glazou: I gave a demo with transitions and everyone got it immediately. 18:29:30 <TabAtkins> howcome: I think we need to try to *look* at the issue. 18:29:48 <TabAtkins> glazou: Sure, if someone can pull out a new proposal, great, but don't block the existing draft on it. 18:30:22 <TabAtkins> howcome: I think this problem [referring to the example with reversing an animation] needs to be solved. 18:30:43 <TabAtkins> plinss: Everyone agrees that that's a problem to be solved, but it's separate from this issue. 18:30:55 <TabAtkins> howcome: I'm happy to go away and see if I can come up with something smart, or if others can. 18:31:37 <TabAtkins> howcome: But also I'd like an action on the spec editors to deal with the reversible animation. This was the first simple thing I ran into that I thought I should be able to do. 18:32:28 <TabAtkins> tantek: I think this should be logged as an apparent hole, and I'm interested in Dean's input on other apparent holes . 18:32:37 <TabAtkins> dean: [talk about fill modes being added in nightlies] 18:32:41 <Bert> (One thing I don't understand about animations and transitions is how you can have both: an object ca only be in one place at one time (Heisenberg notwithstanding).) 18:32:56 <TabAtkins> ChrisL: Oh, you didn't have that? Definitely, that's necessary. 18:33:12 <TabAtkins> dean: Yeah, it prevents a lot of added complexity. 18:33:27 <TabAtkins> dean: All the holes are trying to avoid writing script. 18:33:34 <TabAtkins> dean: So another one is how to chain animations. 18:33:43 <ChrisL> Having fill mode is crucial. smil has post-animation fill, only. pre-animation fill is a useful addition 18:34:05 <TabAtkins> dean: So maybe say the end-time of one transition is the start of another. 18:34:49 <TabAtkins> ChrisL: So you can have animations keyed by a transition? Looks like that would solve the example problem. 18:35:22 <TabAtkins> smfr: ONe thing I'd like to have is for the keyframes to apply with the same specificity as the selector, as if they're sucked into the declaration block and can be overriden. 18:35:45 <TabAtkins> dean: We'd known about these things for a while, we just didn't put them in the proposal so we could have sometehing out in a reaonable time. 18:36:37 <TabAtkins> dean: Another is, if you have multiple transitions together, the latest one wins. We'd like to be able to combine animations without explicitly writing them together in a keyframe rule. 18:37:03 <TabAtkins> ChrisL: That seems crucial; you often want to run two animations that are simple by themselves but are rather complex to specify togethere. 18:37:21 <TabAtkins> Bert: Had a question about the name of one property - iteration-count. 18:38:29 <TabAtkins> Bert: But when we discussed marquee, Molly argued forcefully for play-count. Perhaps we can use the same type of name. 18:39:42 <TabAtkins> TabAtkins: I agree; I think it's shorter, easier to type, and jives with marquee's similar property. 18:40:02 <TabAtkins> fantasai: What about tantek's suggestion to change animation-duration to animation-period? 18:40:14 <TabAtkins> glazou: we need to close this for now. 18:40:23 <dbaron> dbaron has joined #css 18:40:40 <TabAtkins> ACTION: howcome to produce alternate proposal for handling animation and transition together 18:40:40 <trackbot> Created ACTION-213 - Produce alternate proposal for handling animation and transition together [on Håkon Wium Lie - due 2010-04-06]. 18:40:49 <dbaron> What about repeat-count rather than play-count or iteration-count? 18:41:00 <Bert> (Also 'marquee-direction' and 'animation-direction' are subtly different, but I haven't understood what the difference is yet...) 18:41:42 <TabAtkins> glazou: Steps to advance transitions 18:41:51 <TabAtkins> smfr: We'll add stepwise functions, and publish a new draft. 18:42:17 <TabAtkins> dbaron: I think we also need to handle the reversing business, and probably the details in the "animation of property types" section. I've been guilty of not sending comments about that. 18:43:19 <TabAtkins> dean: Can we settle on a goal for progressing to Last Call? 18:43:27 <TabAtkins> dbaron: I think it's doable to do LC in a few months. 18:43:40 <TabAtkins> tantek: Is there an issues page for this draft? 18:43:54 <TabAtkins> dbaron: I created an issues page, but didn't add anything to it for a while. 18:44:04 <TabAtkins> fantasai: Editors should be making the issues list. 18:44:50 <TabAtkins> ACTION: dean and smfr to produce issues list for Transitions and Animations, including comments from dbaron and howcome. 18:44:50 <trackbot> Created ACTION-214 - And smfr to produce issues list for Transitions and Animations, including comments from dbaron and howcome. [on Dean Jackson - due 2010-04-06]. 18:45:08 <Bert> -> http://www.w3.org/Style/CSS/Tracker/products/22 issues list for transitions (only has one issue currently) 18:46:05 <TabAtkins> [discussion of testing transitions/animations] 18:47:46 <glazou> transition-workin-group: lunch pulse 3mn 19:33:22 <jdaggett_> jdaggett_ has joined #css 19:34:02 <jdaggett_> jdaggett_ has joined #css 19:34:13 <jdaggett_> jdaggett_ has left #css 19:34:30 <jdaggett_> jdaggett_ has joined #css 19:39:18 <jdaggett> jdaggett has joined #css 19:44:25 <Arron> Arron has joined #css 19:44:58 <dethbakin> dethbakin has joined #css 19:45:40 <TabAtkins> TabAtkins has joined #css 19:46:48 <bradk> bradk has joined #css 19:47:44 <szilles> szilles has joined #css 19:49:05 <dsinger> dsinger has joined #css 19:49:08 <dino> dino has joined #css 19:50:00 <sylvaing> sylvaing has joined #css 19:50:13 <Zakim> Zakim has joined #CSS 19:50:22 <dino> zakim, list conferences 19:50:22 <Zakim> I see Team_MIT(SITE)2:30PM, WS_WSRA()3:30PM active 19:50:24 <Zakim> also scheduled at this time are GA_(Effects TF)3:00PM, INC_SSN()4:00PM 19:50:35 <smfr> smfr has joined #css 19:51:53 <glazou> glazou has joined #css 19:53:59 <tantek> tantek has joined #css 19:55:13 <dethbakin> dethbakin has joined #css 19:57:31 <dino> zakim, room for 5? 19:57:33 <Zakim> ok, dino; conference Team_(css)19:57Z scheduled with code 26631 (CONF1) for 60 minutes until 2057Z 19:59:14 <ChrisL> s/ http://www.dbaron.org/mozilla/visited-privacy/a mozilla proposal/ 20:05:34 <jdaggett> dino: so the dial-in number is the normal zakim number, then 26631? 20:05:42 <dino> jdaggett: yes 20:05:51 <jdaggett> great 20:05:59 <glazou> hi jdaggett 20:05:59 <dino> jdaggett: i'm not in the meeting room so I don't know if they have dialed yet 20:06:07 <glazou> not yet 20:06:10 <jdaggett> ok 20:06:12 <glazou> dbaron still speaking 20:06:16 <ChrisL> they haven't 20:07:02 <glazou> jdaggett: we have only one pod, so LOUD voice will be useful 20:07:23 <jdaggett> ok, will be a big mouth today 20:07:35 <glazou> Zakim, code ? 20:07:35 <Zakim> the conference code is 26631 (tel:+1.617.761.6200 tel:+33.4.89.06.34.99 tel:+44.117.370.6152), glazou 20:07:40 <jdaggett> my guess is i'll miss some of the mumbling that goes on 20:07:49 <glazou> probably yes 20:07:54 <glazou> we'll gather around the pod 20:08:20 <glazou> jdaggett: calling now 20:08:43 <jfkthame> jfkthame has joined #css 20:09:08 <Zakim> Team_(css)19:57Z has now started 20:09:13 <Zakim> +[IPcaller] 20:09:17 <Zakim> +[Apple] 20:09:20 <fantasai> ScribeNick: fantasai 20:09:34 <jdaggett> ipcaller is jdaggett 20:09:38 <fantasai> jdaggett joins from Tokyo via phone bridge 20:09:47 <jdaggett> zakim, ipcaller is jdaggett 20:09:47 <Zakim> +jdaggett; got it 20:10:12 <fantasai> testing voice range of mic 20:10:24 <Zakim> + +44.845.397.aaaa 20:10:38 <dbaron> Zakim, aaaa is jfkthame 20:10:38 <Zakim> +jfkthame; got it 20:10:46 <fantasai> Jonathan Kew has just joined 20:10:57 <fantasai> jdaggett: I wanted to go over one thing that was discussed yesterday 20:11:09 <fantasai> jdaggett: There was the question of CSS2.1 font-weight 20:11:22 <szilles> szilles has joined #css 20:11:22 <cslye> cslye has joined #css 20:11:34 <jdaggett> http://lists.w3.org/Archives/Public/www-style/2010Mar/0510.html 20:11:58 <fantasai> jdaggett: The wording of the 2.1 spec now, the 4 bullet points you guys were talking about 20:12:10 <fantasai> jdaggett: The 4th bullet point is not clear about 400 and 500 20:12:29 <fantasai> jdaggett: It's clear in case where 400 doesn't exist but 500 does, but not about other cases 20:12:41 <fantasai> jdaggett: I've clarified this in css3-fonts 20:12:57 <fantasai> Chris: In that case I suggest we adopt the CSS3 wording in CSS2.1 to keep these consistent 20:13:04 <mjs> mjs has joined #css 20:13:24 <fantasai> jdaggett: basically 400 and 500 map to each other, and then they map down 20:13:24 <jdaggett> http://lists.w3.org/Archives/Public/www-style/2010Feb/0279.html 20:13:46 <fantasai> RESOLVED: accept proposal to use css3-fonts wording about font-weight hole-filling in css2.1 20:14:04 <fantasai> jdaggett: ? posted about having an all-small-caps setting 20:14:20 <fantasai> jdaggett: It's very easy to add, I've added it to the current wording 20:14:35 <TabAtkins> s/?/Adam Twardoch (sp?)/ 20:14:36 <jdaggett> http://dev.w3.org/csswg/css3-fonts/#font-variant-caps-prop 20:15:16 <fantasai> jdaggett: The one tricky part about this is because of the bheavior defined in 2.1 for small caps, where UAs fake small caps, 20:15:27 <fantasai> jdaggett: to be compatible with 2.1 we need to continue to fake that behavior 20:15:57 <fantasai> jdaggett: I don't think this would work for petite-caps, so I didn't add simulation there 20:16:12 <fantasai> jdaggett: Because they are much smaller, and the size difference would be noticeable 20:16:47 <fantasai> Chris: So what you're talking about is fallback. I think you're correct that leaving petite-caps as lowercase is better than faking small-caps 20:16:51 <smfr> smfr has joined #css 20:17:06 <fantasai> jdaggett: So to summarize, we will fake small-caps and all-small-caps, but not petite-caps or all-petite-caps 20:17:17 <fantasai> howcome: Isn't all-small-caps the same as text-transform + small-caps? 20:18:06 <fantasai> jdaggett: It's very close, but since you're doing the casing in the font engine, the font can tweak things like parentheses because it knows there are no lowercase letters 20:18:23 <fantasai> howcome: Wouldn't it make sense to do the higher-quality rendering for text-transform + small caps as well? 20:18:57 <fantasai> jdaggett: You're not communicating to the opentype engine that it's all small caps 20:19:23 <fantasai> howcome: You could, though. If you know tet-transform: lowercase is applied, then you know that it's the same as all-small caps and you can request that from the engine 20:20:47 <fantasai> jdaggett: Adam posted an explanation explaining the rendering of text that has already been transforming 20:21:18 <fantasai> jdaggett: ... something about not knowing when things get transformed 20:21:46 <jdaggett> http://lists.w3.org/Archives/Public/www-style/2010Mar/0306.html 20:22:43 <fantasai> cslye: I do think some font developers do put extra stuff in these layout features, like numbers and currency 20:23:10 <fantasai> cslye: I don't know if it's good or bad, but some people use this as a way to pack more into a font. It's not just letters transforming, but an alternate look 20:23:50 <fantasai> jdaggett: I think what howcome is saying is that instead of the author explicitly requesting all-small-caps, the feature would be implied by a combination of CSS properties 20:23:54 <fantasai> ... 20:24:15 <fantasai> Steve: howcome's saying that affter you've done the transformation, you remember that fact, and then you pick up the c2sc 20:24:44 <fantasai> jdaggett: I think the implementation would be tricky because you'd have to see if the font has this feature enabled. *If* not, then you do the transformation yourself 20:25:25 <fantasai> cslye: Is it intuitive to split this? If you have an acronym, you usually want to transform to uppercase, then use all-small-caps to get a smaller version if that's available 20:25:34 <fantasai> cslye: Not to use a lowercase version 20:26:40 <fantasai> jdaggett: ... petite-caps is a different route than lowercasing and then petitecaps 20:27:04 <fantasai> howcome: I think that keyword is not necessary, so I would like to see this marked as an issue 20:27:11 <fantasai> Steve: My question is what is easier for the user 20:27:22 <fantasai> cslye: I think Adam addresses this in his email 20:28:45 <fantasai> Steve: What's the computed value? 20:29:03 <fantasai> ChrisL: What you get by copy-paste after transformation varies by UA 20:29:49 <fantasai> ... 20:30:20 <fantasai> Steve: If you want to use text-transform selectively, then all-small-caps is a better option 20:31:03 <fantasai> ChrisL: If a user agent understands and sees this combination of properties, it could hand off the combination to the font engine and ask it to do it all 20:31:07 <mjs> mjs has joined #css 20:31:19 <fantasai> Steve: The scope of the text-transform is different from the scope of the all-small-caps 20:31:54 <fantasai> dsinger: If you have a way of asking the font engine to do something directly, and you use a circuitous route, you should get different results 20:32:08 <fantasai> Bert: Shouldn't have two ways to do two things that are so closely related 20:33:06 <fantasai> Bert: We already have one way to get there 20:34:00 <fantasai> Bert: And the difference between the two is very subtle, most people won't notice but one way is definitely better 20:34:48 <fantasai> cslye: Our concern is that text-transform + small-caps is unintuitive 20:35:13 <fantasai> jdaggett: Sounds like we dont' have a conclusion, but we should keep track of the issue 20:35:20 <fantasai> SteveZ: you can put an issue in the draft 20:35:32 <fantasai> jdaggett: I will mark this as an issue, and the maybe ping Adam again 20:35:46 <fantasai> howcome: It's the same issue for all-petite-caps, too 20:36:56 <fantasai> fantasai: The fallback for petite-caps doesn't involve synthesis, so you could wind up with all lower case instead 20:37:09 <fantasai> fantasai: at least for small caps + text transform, you're guaranteed small caps even if they're not as pretty 20:37:22 <fantasai> Bert: Maybe the fallback for petite-caps should be small-caps? 20:37:27 <fantasai> cslye: It's a good question 20:38:05 <fantasai> cslye: Maybe you're better off faking petite-caps 20:38:18 <fantasai> jdaggett: I don't think we should have UAs fake the petite-caps 20:38:33 <fantasai> SteveZ: Which is why I suggest falling back to small-caps 20:38:50 <fantasai> jdaggett: I don't think it will work 20:38:59 <fantasai> jdaggett: The feature becomes so subtle, that ... 20:39:13 <fantasai> howcome: No this, is just to ensure that we can implement this in a non-OT environment as well 20:39:25 <fantasai> howcome: so that UAs in those environments can do something there 20:39:56 <fantasai> jdaggett: When you try to synthesize petite caps, the glyphs get so small that it's hard to read 20:40:08 <bradk> faked petite caps would look too fake and too light. Small caps/fake small caps would be a better falback. 20:40:57 <fantasai> jdaggett and dsinger think this is a slippery slope 20:41:14 <fantasai> jdaggett: I think going in this direction is diminishing returns 20:43:05 <jfkthame> using small-caps as the fallback for petite-caps makes sense .... like we use oblique as fallback for italic (or vice versa) 20:44:40 <fantasai> jdaggett: I would like to avoid artificial ways of doing font feature effects 20:45:05 <fantasai> cslye: That's fine, but then we can't implement the all-petite-caps feature with text-transform, because we'll wind up with unwanted lowercase 20:45:28 <fantasai> jdaggett: Ok, I'm going to record this as there are two separate but possibly related issues 20:45:44 <fantasai> SteveZ: Another point to record is that, it appears that some people believe petite-caps match the x-height of the font 20:45:55 <fantasai> SteveZ: And in fact in one place, they were called ex-caps 20:46:09 <fantasai> jdaggett: Petite-caps are below the x-height. 20:46:15 <fantasai> cslye and stevez don't agree 20:46:23 <fantasai> jdaggett: It's smaller than small-caps 20:46:25 <bradk> 'text-transform:lowercase;' + small caps = all small caps seems ituitive to me. 20:46:37 <fantasai> SteveZ: small-caps are typically above the x-height 20:46:48 <fantasai> jdaggett: next issue 20:46:56 <fantasai> jdaggett: Dealing with subscript and superscript 20:47:14 <fantasai> jdaggett: OT has features that allow font designers to put sub /super glyphs in the font itself 20:47:21 <fantasai> jdaggett: Issue is how to access it 20:47:25 <bradk> 'text-transform:lowercase; + all-small-caps = all-small-caps seems like a waste of a property 20:47:28 <fantasai> jdaggett: currently sub/super is done with a combination of properties 20:48:00 <fantasai> jdaggett: the question is how to work things so that use the font feature if available, otherwise fall back to altering properties as before 20:48:09 <jdaggett> http://lists.w3.org/Archives/Public/www-style/2010Feb/0245.html 20:48:19 <fantasai> jdaggett: that's the original issue 20:48:21 <jdaggett> http://dev.w3.org/csswg/css3-fonts/#character-transform-prop 20:48:36 <fantasai> jdaggett: This is how the spec currently words it 20:48:55 <fantasai> jdaggett: the idea here is that you use the subscript glyph if available, 20:49:05 <fantasai> jdaggett: and fall back to a synthesized version of that if that's not available 20:49:09 <howcome> http://people.opera.com/howcome/2010/tests/petite.html 20:49:23 <fantasai> jdaggett: and in this case I think it's better that the author see a simulated version 20:49:51 <fantasai> ChrisL: Yes, this is good, because the fallback and the feature don't get combined 20:50:14 <fantasai> ChrisL: It's a little weird that it resets the properties it simulates with, but I also think it's a good idea here. 20:51:01 <fantasai> SteveZ: What happens if I stack superscripts or stack subscripts? 20:51:07 <fantasai> SteveZ: This is common in mathematics 20:51:21 <dbaron> We probably don't want to break 2<sup>2<sup>x</sup></sup> 20:51:37 <fantasai> SteveZ: The reason I say super { font-size: 70% } is so that stacking superscripts works 20:52:01 <fantasai> Bert: It seems to me that we're using a feature in OT that we already have 20:52:41 <fantasai> SteveZ: We don't already have this. Simulated supserscripts are not nearly as correct typographically as real ones 20:53:06 <fantasai> jdaggett asserts that stacked subscripts are unusual 20:53:14 <fantasai> SteveZ and ChrisL disagree, it is a common case 20:54:15 <fantasai> you probably don't want character-transform to inherit... 20:54:52 <cslye> cslye has joined #css 20:55:15 <fantasai> jdaggett: the subscript or superscript is tied to a base font size 20:55:23 <fantasai> jdaggett: changing the font size changes the color of the glyph 20:55:59 <fantasai> jdaggett argues against something 20:56:20 <fantasai> Steve: Let me try another way 20:56:32 <fantasai> Steve: What I'm trying to get at is, the user decreased the font size 20:56:48 <fantasai> Steve: One way to deal with this is to reset the font size 20:57:04 <fantasai> Steve: The other way is to not reset the font size, but to use the font-size of the parent when selecting the superscript glyph 20:57:41 <fantasai> fantasai: The tricky part is, if you have nested elements, you don't want the parent 20:57:42 <Bert> (But then the author doesn't get what he asked for, does he?) 20:57:51 <ChrisL> s/common case/common case in mathematics/ 20:57:54 <fantasai> fantasai: you want the parent of the element on which character-transform was set 20:58:09 <fantasai> Steve: That would allow us to get nice superscripts all the way down 20:58:23 <fantasai> jdaggett: I think I understand what you're trying to say 20:58:41 <fantasai> jdaggett: I can see these two things being used in conjunction. Whatever it is, though, it should be understandable in the simple case 20:58:56 <fantasai> Steve: The simple case, they'll look exactly the same, so it didnt' really matter which way you did it 20:59:11 <fantasai> Steve: The result is you would use the subscript character in the size of the original font 20:59:19 <fantasai> jdaggett: As long as that's there, that's the key thing 21:00:55 <fantasai> Chris and Steve try to explain the use case for character-transform to Bert 21:01:22 <fantasai> Bert: What if there's an image in there? Or fallback fonts? 21:02:05 <fantasai> jdaggett: This is something that would make sense for the default behavior, but it doesn't make it impossible to use the old behavior 21:03:06 <fantasai> fantasai: Bert has a good point. If you have fallback, or if you have images, you don't know where the effective baseline is 21:03:12 <fantasai> fantasai: And you can't align things to it 21:03:53 <fantasai> SteveZ: In that case, you could say, if there is anything in the element that can't be substituted through the font, then you fake the whole thing 21:03:58 <fantasai> jdaggett: I don't think you can do that 21:04:08 <fantasai> jdaggett: I don't think it's practical to make the fallback behavior contextual 21:04:39 <fantasai> jdaggett: You're either affecting vertical-align or you're not 21:04:49 <fantasai> jdaggett: We have to know 21:05:04 <fantasai> SteveZ: my approach is that you odn't affect font-size or vertical-align when you do this 21:05:12 <fantasai> SteveZ: You just don't use them when rendering 21:05:35 <fantasai> ChrisL: I like that approach 21:05:39 <fantasai> peter says something quietly 21:05:53 <jfkthame> if you're applying an opentype superscript or subscript feature, and you need to know the baseline for some other alignment, you can ask the font for its superscript or subscript offset 21:05:57 <fantasai> jdaggett: I'm not crystal clear on what is being proposed, so what I'd ask you to do is to look at 6.2 and suggest specific changes 21:06:10 <fantasai> ACTION: SteveZ Propose changes to character-transform to address above concerns 21:06:10 <trackbot> Created ACTION-215 - Propose changes to character-transform to address above concerns [on Steve Zilles - due 2010-04-06]. 21:06:23 <fantasai> jfkthame, thanks! 21:06:28 <fantasai> jdaggett: new topic 21:06:30 <jdaggett> http://lists.w3.org/Archives/Public/www-style/2010Mar/0224.html 21:06:37 <fantasai> jdaggett: Talking about font-specific font features 21:06:43 <jdaggett> http://people.mozilla.org/~jdaggett/images/fallbackexamples.png 21:07:12 <fantasai> jdaggett: In the first page you have, say, two fonts 21:07:34 <fantasai> jdaggett: If you use the setting styleset(6), that's picking a specific font feature 21:07:50 <fantasai> jdaggett: typically styleset numbers' effect is not consistent across fonts 21:08:13 <fantasai> jdaggett: Last time we talked about this, there were a number of people were concerned that triggering a numbered styleset across font would not be good 21:08:33 <fantasai> jdaggett: The key point here is that htese are variations on the underlying font itself 21:08:42 <fantasai> jdaggett: they're not .. look coherent with the text that surrounds it 21:08:59 <fantasai> jdaggett: The concern about showing some crazy glyph.. that the resulting fallback will be ruinous 21:09:07 <fantasai> jdaggett: I think that's really far-fetched scenario 21:09:16 <fantasai> jdaggett: You'd have to have a pathological fallback situation for that to happen 21:09:34 <fantasai> jdaggett: Most platform fonts dont' have this feature, and they tend to be subtle 21:09:40 <fantasai> jdaggett: Authors would have to not know about (?) 21:09:54 <dsinger> is that (a) because fallback etc. is unlikely or (b) because styleset(6) (say) is likely to be there or not, but not very 'different' between fonts? 21:09:59 <jdaggett> http://people.mozilla.org/~jdaggett/tests/strangepresentationalligs.html 21:10:12 <jdaggett> http://people.mozilla.org/~jdaggett/tests/strangeligatures.png 21:10:39 <fantasai> on the left is safari, on the right is firefox 21:10:53 <dsinger> isn't it possible that styleset(6) in one font gives me a variant designed for great legibility at small sizes and in another, designed for swishy presentation in titling and at large sizes? 21:11:23 <fantasai> ChrisL: Could I interject an observation? 21:11:29 <fantasai> ChrisL: I think there's not very many of these ligatures 21:11:44 <fantasai> ChrisL: They're added mainly for codepage roundtripping between legacy encodings 21:11:54 <fantasai> ChrisL: They tend not to be supported in fonts 21:12:08 <fantasai> ChrisL: And they mess up other things like searching 21:12:17 <fantasai> ChrisL: As long as people have a more reliable method of getting the same effect 21:12:34 <fantasai> ChrisL: I think the use of these presentation ligature codepoints will be decrease 21:12:54 <fantasai> jdaggett: My comment isn't about whether they should be used, but that their fallback is different 21:13:22 <fantasai> jdaggett: My point is that when fallback occurs, strange things can occur 21:13:29 <fantasai> dsinger projects his comment into voice 21:13:59 <fantasai> dsinger: Style sets should be only applied to the font for which they're expected to apply 21:14:10 <fantasai> jdaggett: That's what you get with fallback. 21:14:13 <jfkthame> it's possible, but a very unlikely scenario - font features are the wrong mechanism for a designer to be using there, that's optical sizing 21:14:21 <fantasai> dsinger: Why do we wind up speciying a font-specific setting to a fallback font? 21:14:35 <fantasai> dsinger: Why don't we design the syntax so you only apply the font-specific setting to the font it was intended for/ 21:14:45 <fantasai> jdaggett: styleset is the most extreme example 21:14:54 <fantasai> jdaggett: but some other features may or may not be font specific 21:15:02 <fantasai> jdaggett: e.g. the annotation forms feature 21:15:03 <jfkthame> styleset may well behave consistently across a whole library of fonts, e.g., from a single designer/vendor 21:15:07 <fantasai> http://people.mozilla.org/~jdaggett/images/fallbackexamples.png 21:15:20 <fantasai> jdaggett: There is more consistency there 21:15:50 <fantasai> jdaggett: The author should be making the decision of whether it's a font-specific or font-generic feature. 21:16:03 <fantasai> ChrisL: One way to get around this is to put the style set selection in the @font-face rule 21:17:02 <fantasai> dsinger: Note also that the font that ends up being used might be something the author didn't select at all. It could be something specified by the user. 21:17:11 <fantasai> or on a system with limited fonts and no downloading 21:17:32 <fantasai> Steve: I may, with old eyes, want to use a high-contrast font 21:17:33 <ChrisL> While it may be sometimes true, or indeed often true, that opentype font features only make sense when applied to a specific font or to a spacific family, it is not clear that it is *always* true 21:17:42 <ChrisL> nd thus, authors should be able to choose whether to make this general or font specific. 21:18:10 <fantasai> jdaggett: You can't guarantee that the web page is readable with an alternate font 21:18:18 <jfkthame> if you want to use a personal stylesheet to force a certain font, you can also use it to override the features 21:18:29 <fantasai> jdaggett: The author could pick a set of CSS features in combination that would make the page unreadable with another font 21:18:44 <fantasai> dsinger: I'm not saying that all font features should be restricted 21:19:11 <fantasai> dsinger: But the ones where you're selecting by number, rather than by name for a generic feature, you're getting a random effect if you're getting one at all 21:19:16 <fantasai> dsinger: That doesn't seem right to me 21:19:27 <fantasai> jdaggett: You can already use @font-face if you really want 21:19:46 <fantasai> http://lists.w3.org/Archives/Public/www-style/2010Mar/0202.html 21:20:13 <fantasai> jdaggett argues that this and that is not that font-specific 21:20:51 <fantasai> peter: The problem is that the author may think that the feature is not font-specific, and they test it on their three fonts, but then some user 5 years downt he line uses a font that the author never expected 21:21:13 <fantasai> jdaggett: We're not changing the characters, we're changing the presentation 21:21:42 <fantasai> dsinger: styleset(6) doesn't say what the change in presentation is, and it might be very specific to the font 21:22:05 <fantasai> ... 21:22:16 <Arron> font-variant: styleset(gabriola, 6) styleset("poetica std", 3); 21:22:17 <fantasai> howcome: Couldn't we just say that the styleset(6) applies only to the first font in the list 21:22:28 <fantasai> howcome: and if you want to set it on other things, then you set it on @font-face 21:23:29 <fantasai> jdaggett: If we come up with clever syntax to make it font-specific, we increase the burden of the author 21:24:00 <fantasai> howcome: We increase the burden on the author to decrease the chance of something weird happening 21:24:26 <fantasai> Peter: Authors' aren't going to read the standard, and they're not going to know whether they should use it in the property or in the @font-face 21:25:05 <fantasai> Peter: It's going to work fine on their machine, and then the reader gets screwed down the line 21:25:17 <fantasai> jdaggett: It won't be unreadable 21:25:34 <fantasai> dsinger: If it were designed for 30pts in titles adn gets used in body text, then you might well get something unreadable 21:26:30 <fantasai> cslye: ... throwing baby out with the bath water 21:26:55 <fantasai> peter: We're not saying let's not have this feature 21:27:36 <fantasai> fantasai: It's not that hard to tie the feature to the font. We have at least 3 proposed ways to do it 21:28:03 <dsinger> I would prefer syntax that makes it unlikely, I would settle for a warning... 21:28:19 <fantasai> jdaggett: I think whether something is font-specific or not is not determined by whether it's numerical or not 21:28:35 <fantasai> dsinger: Yes, I accept a given foundry may use numbers consistently across fonts 21:28:46 <fantasai> jdaggett: I think authors should have this flexibility 21:29:15 <fantasai> We're not moving forward with this :( 21:29:23 <fantasai> jdaggett: The other issue was font-size-adjust 21:29:46 <fantasai> jdaggett: I'm not sure I would be the best rep for that issue 21:29:48 <fantasai> dbaron takes the floor 21:30:10 <fantasai> dbaron: The idea of font-size-adjust is that it's a way of specifying the font size by specifying the x-height 21:30:21 <fantasai> dbaron: it does it in backwards-compatible way so that old UAs get the font-size property 21:30:28 <fantasai> dbaron: It does this by having font-size-adjust take a number 21:30:52 <jdaggett> http://dev.w3.org/csswg/css3-fonts/#font-size-adjust-prop 21:31:00 <fantasai> dbaron: font-size: 20px; font-size-adjust: 0.45; gets you 9px x-height 21:31:07 <fantasai> dbaron: this is useful for two things 21:31:09 <Curt`> Curt` has joined #css 21:31:27 <jdaggett> example of how font-size-adjust works 21:31:28 <jdaggett> http://dev.w3.org/csswg/css3-fonts/fontsizeadjust.png 21:31:31 <fantasai> dbaron: Particularly at small font size [in bicameral scripts], legibility is related more to x-height than to font size 21:31:38 <ChrisL> and this is primarily useful when fonts are substituted, or changed on sub elements 21:31:45 <fantasai> dbaron: e.g. Verdana is readable at very small font sizes 21:31:50 <fantasai> even though most fonts are not 21:32:12 <fantasai> dbaron: One use case for font-size-adjust is when you have multiple fonts 21:32:24 <fantasai> dbaron: E.g. in computer docs, you are mixing normal font with monospace font 21:32:39 <fantasai> dbaron: and depending ont eh fonts, the x-heights might be very different 21:32:57 <fantasai> dbaron: So to get a consistent effective size, you'd need to size them differently (e.g. much smaller monospace font) 21:33:07 <Bert> s/ont eh/on the/ 21:33:15 <fantasai> dbaron: I wanted to make font-size-adjust work better in cases where the author wants to use the user's default font size 21:33:26 <fantasai> dbaron: but still equalize x-heights across fonts 21:33:36 <bradk> example of tiny x-height: http://www.fonts.com/FindFonts/detail.htm?pid=203205 21:33:56 <fantasai> dbaron: The secondary use case is that browsers do really weird things to equalize proportional and monospace fonts 21:34:02 <fantasai> dbaron: and this couldpotentially replace that 21:34:25 <fantasai> dbaron: Suggesting font-size-adjust: auto to mean, use the x-height of the user's default font 21:34:36 <fantasai> jdaggett: the tricky part is that the default font isn't always one font 21:34:43 <fantasai> dbaron: I would love to get this weird font pref setting thing 21:34:59 <fantasai> dbaron: It might require a little bit more, but that bit can be browser-specific 21:35:02 <TabAtkins> s/get this/get rid of this/ 21:35:14 <fantasai> dbaron: I would also like to allow authors to opt-into this world of consistent x-heights 21:35:29 <fantasai> dbaron: by aligning to a reasonable defautl font 21:35:40 <fantasai> dbaron: Authors can do something similar by font-size-adjust: 0.5 21:36:01 <fantasai> dbaron: But that changes the user's default size, even if they don't want to, by the amount by which that factor is off 21:36:22 <TabAtkins> szilles: I'm confused about what the "user's default font-size" is. 21:36:26 <fantasai> dbaron: There's the issue that the default font size does vary by language 21:36:48 <fantasai> dbaron: Some browsers have lang-specific font preferences 21:36:55 <fantasai> dbaron: so we might use those 21:37:02 <fantasai> szilles: If i set a font ... 21:37:38 <fantasai> dbaron: If you set a font, not use the user's default, you are likely to keep more closely to the effective font size of the user's default 21:39:09 <fantasai> dbaron: font-size-adjust: auto only depends on the default font-family, not on the default font-size 21:40:14 <ChrisL> useful discussion at http://www.emdpi.com/css3xheight.html 21:40:17 <fantasai> szilles: So.. 'auto' makes a bunch of assumptions about where to go look for things 21:40:28 <fantasai> szilles: And those assumptions work in pages where people use the default font 21:40:37 <fantasai> szilles: Seems it wouldn't work as well to change the default font 21:41:06 <fantasai> dbaron: If they change the font, then they can also set a different font-size-adjust 21:41:16 <fantasai> szilles: But the values are hard to figure out 21:41:28 <fantasai> szilles: It would make more sense to say "match my parent's ex-height" 21:42:28 <ChrisL> elika: no, we are just refining thr typographical color (priceless!!) 21:42:30 <fantasai> fantasai: That's an interesting idea. Setting it on the root would hit up the initial font 21:42:55 <fantasai> howcome: Are we proposing to change page layouts across the web? 21:43:00 <fantasai> ... 21:43:40 <fantasai> Bert, howcome: maybe be more useful as we see more fonts used 21:43:48 <fantasai> Alex: We have gotten requests for font-size-adjust 21:45:11 <fantasai> dbaron: font-size-adjust was in CSS2.10 21:45:13 <fantasai> er 21:45:16 <fantasai> CSS2.0 21:45:33 <fantasai> jdaggett: I think it's a somewhat cumbersome feature 21:45:50 <fantasai> jdaggett: But I see people saying "I want this!" and when I see what they describe, it's font-size-adjust 21:46:00 <fantasai> dbaron: It's implemented in Gecko 21:46:17 <fantasai> Alex: I'm not going to confirm or deny the plans for IE9 21:46:40 <fantasai> ChrisL: I think the proposal has merit 21:46:49 <fantasai> jdaggett: To me the big problem here is what you're calling the default font 21:46:58 <fantasai> jdaggett: Because that's something that's not defined normatively 21:47:09 <fantasai> jdaggett: ANd it's important for having this feature work consistently 21:47:25 <fantasai> dbaron: I Tried to leave a bit of latitude for determining what exactly the default font is 21:47:49 <fantasai> howcome: I think I like Steve's proposal to use the root element 21:48:06 <fantasai> dbaron: I don't quite understand how that proposal would work. 21:48:49 <ChrisL> a font example with a fairly small x-height http://www.fonts.com/FindFonts/detail.htm?pid=203205#waterfall 21:48:49 <fantasai> Steve: The value on the root element, unless one is specified, is going to be the default. 21:49:06 <fantasai> Steve: I can explicitly set a value on the root element 21:49:22 <fantasai> Steve: And have that used instead of the default font 21:49:42 <fantasai> Steve: So that could be the default font, but it doesn't have to be 21:50:18 <fantasai> dbaron explains something about overriding 21:50:33 <fantasai> dbaron: let's distinguish between user's default font-family and size 21:50:46 <fantasai> dbaron: This proposal gives a better way of matching the default font *size* 21:51:31 <fantasai> dbaron: It also gives users a better way to deal with the monospace-proportional harmonization problem 21:51:35 <fantasai> Steve: That case is handled either way 21:52:01 <fantasai> dbaron: example 21:52:11 <fantasai> dbaron: Suppose the author wants to preserve the user's size 21:52:15 <fantasai> dbaron: But wants to use verdana 21:52:30 <fantasai> dbaron: They'd need this feature to effectively preserve the size 21:52:45 <fantasai> dbaron: because actually preserving the size, without this adjustment, would result in a much bigger-looking font 21:52:52 <fantasai> howcome: initial value? 21:52:57 <fantasai> dbaron: initial value is none 21:53:20 <fantasai> dbaron: If we wanted to replace the current monospace hackery 21:53:53 <fantasai> dbaron: We would have to make the initial value be a value that if an element or one of its ancestors had a font size in absolute units, this special value would behave like none 21:54:00 <fantasai> dbaron: and otherwise the special value would be have like auto 21:54:09 <fantasai> dbaron: at least, in the way Gecko implement monospace pref 21:54:28 <fantasai> Steve: I'm confused why you think the default font size has anything to do with what I'm looking 21:55:45 <fantasai> fantasai: So there are three use cases here, and dbaron's solves one, steve's solves another, and both solve the third 21:56:26 <glazou> jdaggett, we'll brak for 15 minutes in 5 minutes from now, ok for you? 21:56:33 <glazou> s/brak/break 21:56:45 <fantasai> 1. Match the user's default size as well as possible, meaning ex-height matching 21:56:53 <jdaggett> glazou: yeah, i have to leave soon 21:56:56 <glazou> ok 21:56:59 <jdaggett> time to make breakfast 21:57:02 <glazou> eheh 21:57:11 <fantasai> 2. Consistent ex-heights across font-switching throughout the document, esp. mononspace vs. proportional 21:57:46 <fantasai> stevez: The third use case is to match the ex-heights locally 21:57:55 <fantasai> stevez: handle the 2nd case when the author has changed the font-size 21:57:57 <dbaron> 4. Move towards replacing separate browser monospace font size prefs. 21:59:36 <fantasai> fantasai and stevez try to work through stevez's case 22:00:25 <dbaron> dbaron: Just set font-size-adjust: auto (or some other value) on the root element 22:02:43 <Zakim> -jdaggett 22:02:46 <fantasai> 3. Keeping exheights consistent throughout the document (requiring use of font-size-adjust) but wanting to set an exact size for the main document font without looking up the ex-height 22:02:56 <Zakim> -jfkthame 22:03:04 <Zakim> -[Apple] 22:03:05 <Zakim> Team_(css)19:57Z has ended 22:03:06 <Zakim> Attendees were [Apple], jdaggett, +44.845.397.aaaa, jfkthame 22:03:20 <fantasai> e.g. Choose Palatino at 16pt, set font-size-adjust: foomatic 22:03:24 <fantasai> on the root 22:03:51 <fantasai> and foomatic looks up Palatino's ex-height and set's font-size-adjust to that 22:03:59 <fantasai> so that Palatino's font size doesn't change from 16pt 22:04:11 <fantasai> *and* font-size-adjust takes care of ex-height adjustment across the document 22:04:44 <dbaron> The problem with foomatic is that f-s-a inherits. 22:21:32 <Zakim> Zakim has left #CSS 22:29:05 <bradk> bradk has joined #css 22:33:22 <fantasai> Topic: i18n/bidi/ruby 22:33:47 <fantasai> Anne: HTML5 only includes simple ruby, which was implemented by IE 22:33:54 <fantasai> Anne: The module also has complex ruby 22:34:36 <fantasai> fantasai: I think Richard Ishida was planning to take that out of the CSS3 Ruby module 22:34:46 <fantasai> Anne: There was some discussion on www-international 22:35:06 <fantasai> Anne: It seems in general that the Japanese people think the simple model is adequate, because you can nest it 22:35:22 <fantasai> ChrisL: nesting is a hack 22:35:32 <fantasai> Anne doesn't particularly care 22:35:36 <ChrisL> s/is/was described as/ 22:35:39 <paul_irish> paul_irish has joined #CSS 22:36:09 <fantasai> Deferring entire discussion without ishida 22:36:30 <fantasai> Steve: There's ruby that's attached to individual characters, and ruby attached gto groups of characters. 22:36:43 <fantasai> Steve: Different ways of attaching to characters, and that's where most of the trouble lies 22:37:12 <fantasai> Steve: I think we should wait and see what Richard's draft says 22:38:20 <fantasai_> fantasai_ has joined #css 22:38:33 <fantasai_> Anne summarizes HTML5's rendering rules for ruby, which mostly defer to CSS by giving display types 22:39:11 <fantasai_> Steve: So most of the complexity on the ruby side comes from how you group the pieces 22:39:14 <fantasai_> and how you format across them 22:39:26 <fantasai_> howcome: Can you write CSS rules on the rt elements? 22:39:45 <fantasai_> Anne: The implementations so far have dedicated frame types in the rendering model 22:40:06 <fantasai_> howcome is asking if you can simulate ruby with existing CSS 22:40:11 <fantasai_> Alex and Steve think not 22:40:56 <fantasai_> SteveZ notes that there's a 96-page document that explains all the details 22:41:04 <fantasai_> by the JLTF 22:42:27 <fantasai_> Steve: I think Richard is going to produce a new draft that is consistent with HTML and the JLTF drafts 22:42:55 <fantasai> Steve: The plan is to wait until he gives us a draft to look at 22:43:04 <TabAtkins> TabAtkins has joined #css 22:43:16 <anne> http://lists.w3.org/Archives/Public/www-international/2010JanMar/ 22:43:45 <fantasai_> Anne: Search for 'ruby' 22:43:52 <anne> thread on ruby: http://lists.w3.org/Archives/Public/www-international/2010JanMar/thread.html#msg107 22:44:04 <fantasai_> glazou: Arron told me we still have CSS2.1 issues to discuss 22:44:14 <fantasai_> glazou: Since there's nothing else we can move to this time in the day, I suggest we move to 2.1 22:44:41 <fantasai_> http://wiki.csswg.org/spec/css2.1#issue-114 22:44:54 <fantasai_> Arron: I put all the results for the testcases 22:45:06 <fantasai_> ChrisL: I'm slowly converting those to SVG 22:45:21 <fantasai_> Arron: Each one of these testcases are slightly different. Several are parens/bracket/braces/quotes matching 22:45:31 <fantasai_> Arron: The first one is the most interesting, using invalid characters 22:45:40 <fantasai_> Arron: Trying to see if they match correctly 22:46:15 <fantasai_> Arron: There are lots of interop issues, but at least 2 impl for most results 22:47:57 <fantasai_> fantasai: I think we wrote the tests under the assumption that only nmchars are allowed in unquoted font names 22:48:33 <fantasai_> fantasai: brackets tests are more complex because they also test that they're matched correctly 22:48:51 <anne> 002.xht is fun 22:51:22 <fantasai_> dbaron: So, you're allowing idents, dimensions without + or decimal point, numbers without + or decimal point. 22:51:32 <fantasai_> Bert: you have to define in terms of tokens, not character sets 22:51:42 <fantasai_> Bert: Should allow periods 22:52:51 <fantasai_> dbaron: If we allow periods, we have the float round-tripping problem 22:54:27 <fantasai_> random discussion of various option 22:54:38 <fantasai_> Anne says we should just use ident+ 22:54:47 <fantasai_> Bert says it's confusing not to allow numbers unquoted 22:54:54 <fantasai_> dsinger says it's reasonable to quote them 22:55:47 <bradk> FYI, the third test (Invalid curly brackets and pair matching) passes in a recent nightly download of Webkit, even though it fails in Safari. http://test.csswg.org/source/contributors/microsoft/submitted/Chapter_15/font-family-invalid-characters-003.xht 22:56:18 <fantasai_> general consensus that the discussion is going nowhere 22:56:51 <fantasai_> 1. identifiers only 22:56:55 <fantasai_> 2. nmchars tokens only 22:57:05 <fantasai_> 3. try to come up with a grammar to make the current prose more clear 22:57:24 <fantasai_> ChrisL: I need to take this back to the SVGWG and get feedback from them 22:57:44 <fantasai_> 1. http://lists.w3.org/Archives/Public/www-style/2010Mar/0369.html 22:57:48 <fantasai_> 2. http://lists.w3.org/Archives/Public/www-style/2010Mar/0395.html 22:57:52 <fantasai_> 3. To Be Written 22:57:58 <fantasai_> Not By Me I Hope 22:59:36 <fantasai_> FF and Safari are almost ident+ 22:59:55 <fantasai_> or are ident+, but have bracket-matching bugs :) 23:00:09 <fantasai_> Opera is close to the current prose 23:00:13 <fantasai_> IE is somewhere in between 23:00:36 <fantasai_> but closer to Opera 23:00:49 <fantasai_> Anne: 1 23:00:50 <fantasai_> Steve: 1 23:00:52 <fantasai_> Sylvain: 1 23:01:15 <fantasai_> Alex: 2, but live with 1 23:01:18 <fantasai_> Beth: 2 23:01:20 <fantasai_> Bert: 3 23:01:26 <fantasai_> Arron: 2 or 3 23:01:38 <fantasai_> Elika: 2, live with anything as long as clear 23:01:40 <fantasai_> dbaron: 1 23:01:51 <fantasai_> Brad: don't care 23:01:52 <fantasai_> Tab: 1 23:01:57 <fantasai_> Tantek: Abstain 23:02:04 <fantasai_> Glazou: 1, but can live with everything 23:02:18 <fantasai_> ChrisL: 3, 2, 1 23:02:40 <fantasai_> Peter: 2 is slightly better for authors in that it would be a little surprising to not start with a number 23:03:00 <fantasai_> Peter: I don't like the fact that 2 introduces a new token type, so 1 23:03:04 <fantasai_> Bert: I think it can be done without 23:03:14 <fantasai_> Howcome: 3 23:03:52 <dbaron> http://test.csswg.org/source/contributors/microsoft/submitted/Chapter_15/font-family-invalid-characters-002.xht is buggy because it has ( { ) and expects the ) to match the ( while you need to find a } first 23:04:03 <fantasai_> Elika: Actually, I'm going to change my vote to 2, then 1 23:04:16 <fantasai_> dsinger: abstain 23:04:22 <fantasai_> Steve: I can live with 2 also 23:04:32 <fantasai_> Steve: I don't really see much difference between 1 and 2 23:04:37 <smfr> smfr has joined #css 23:04:44 <fantasai_> Peter: My real preference is that people quote things more 23:04:52 <fantasai_> Steve: That's why I voted for 1 23:05:04 <fantasai_> glazou: Can't go further, Chris has to take this to SVGWG first 23:05:38 <fantasai_> glazou: 7 for 1, 4 for 2, 3 for 3, and almost everyone can live with everything 23:05:47 <fantasai_> glazou: which is cool 23:06:45 <fantasai_> ACTION: clilley Discuss font-family syntax with SVGWG 23:06:45 <trackbot> Created ACTION-216 - Discuss font-family syntax with SVGWG [on Chris Lilley - due 2010-04-06]. 23:07:53 <Bert> (Minor flashback to 1996: font-face was modeled in part on Netscape's FACE attribute.) 23:08:42 <fantasai_> dbaron notes that Mozilla has seen only one bug, that dbaron could find, on this issue 23:08:56 <dbaron> I went through bugzilla.mozilla.org bugs with 'font-family' and 'quote'... there were 4 reported by users (also one internal code issue). 23:09:21 <dbaron> One was about this issue, two were complaining that font-family: 'sans-serif' didn't work, and one was complaining about font-family: 'Arial, Helvetica'; not working 23:09:45 <dbaron> The one that was about this issue was https://bugzilla.mozilla.org/show_bug.cgi?id=471300 23:10:33 <TabAtkins_> TabAtkins_ has joined #css 23:12:11 <fantasai_> http://wiki.csswg.org/spec/css2.1#issue-163 23:12:23 <fantasai_> dbaron: Anne, I don't understand why getComputedStyle is relevant 23:13:06 <fantasai_> Anne: http://dump.testsuite.org/2010/width-computed-value.htm 23:13:26 <fantasai_> Anne: If you set width: 10em on an inline, and then inherit it to a block, you get 10em 23:13:37 <fantasai_> Anne: But the spec says the computed value, the inherited value, should be 'auto' 23:14:02 <fantasai_> RESOLVED: Proposal accepted for Issue 163 23:15:16 <fantasai_> data:text/html;charset=utf-8,<!DOCTYPE HTML PUBLIC "-%2F%2FW3C%2F%2FDTD HTML 4.0%2F%2FEN">%0D%0A<html lang%3D"en">%0D%0A <head>%0D%0A <title>Test<%2Ftitle>%0D%0A <style type%3D"text%2Fcss">%0D%0A <%2Fstyle>%0D%0A <%2Fhead>%0D%0A <body>%0D%0A <ul dir%3Dltr>%0D%0A <li dir%3Drtl>Bullet%0D%0A <%2Ful>%0D%0A <%2Fbody>%0D%0A<%2Fhtml>%0D%0A 23:16:07 <fantasai_> FF renders the bullet on the right 23:16:09 <fantasai_> as does Chrome 23:17:08 <fantasai_> Opera renders on the right 23:17:15 <fantasai_> IE renders on the right 23:17:37 <fantasai_> dbaron: So this is a proposed change where every impl we've tested matches the current spec 23:17:43 <alexmog> alexmog has joined #css 23:17:49 <fantasai_> http://wiki.csswg.org/spec/css2.1#issue-162 23:18:41 <fantasai_> dbaron: Direction changes are a relatively rare case 23:20:29 <dbaron> ... especially in the middle of a list 23:20:33 <fantasai_> Daniel: If you have a <body dir=ltr> with <div display:list-item dir=rtl> then you wouldn't see the right direction for the marker 23:20:54 <dbaron> Yeah, I think this change seems wrong for the general display:list-item case. 23:21:08 <dbaron> Even if it might make sense for the way HTML li elements. 23:21:52 <fantasai_> Steve: the most obvious example I can think of this giving a list of phrases in different languages 23:22:16 <fantasai_> Steve: I'd want the bullets lined up 23:22:50 <fantasai_> dbaron: You don't want to change the block direction in Steve's case anyway. 23:23:08 <fantasai_> dbaron: Because the alignment will change 23:23:33 <fantasai_> Steve: Why can't I set text-align? 23:25:08 <fantasai_> ... 23:25:18 <fantasai_> Steve: I can't think of a case where you'd want the bullet on the right 23:25:28 <fantasai_> dbaron: You can have list items that are not using HTML list markup 23:26:24 <dbaron> http://www.w3.org/TR/CSS21/visuren.html#dis-pos-flo 23:26:26 <fantasai_> Peter: so are we rejecting this then? 23:26:29 <TabAtkins> TabAtkins: As a side point, markers clearly belong to the list-item, not the enclosing block. The color of a list marker comes from the list-item. 23:26:31 <dbaron> ... says list items can float 23:26:36 <dbaron> ... and keep their marker 23:26:38 <fantasai_> Steve: What I've heard is that we're already committed that the marker is part of the list-item 23:26:50 <fantasai_> (Tab explained that concept using color etc as an example) 23:27:45 <fantasai_> (fantasai also pointed out that it would create an inconsistency with list-item-position: inside items if we swapped the direction of the bullet based on the parent for outside ) 23:28:02 <fantasai_> dsinger: So we should resolve this and offer to i18n that we can add a note explaining how to get their desired effect 23:29:27 <fantasai_> RESOLVED: No change for Issue 162 23:29:49 <fantasai_> in normative behavior 23:31:52 <fantasai_> Bert and fantasai discuss ways to allow a switch in this behavior in CSS3, possibly using the bidi-isolate concept 23:32:04 <arronei> arronei has joined #CSS 23:33:27 <fantasai_> ACTION: fantasai move issue to css3-lists 23:33:28 <trackbot> Created ACTION-217 - Move issue to css3-lists [on Elika Etemad - due 2010-04-06]. 23:33:36 <fantasai_> http://wiki.csswg.org/spec/css2.1#issue-161 23:38:50 <TabAtkins> TabAtkins: [draws a picture with a containing block A, some number of descendants B, and a positioned descendant C. Any overflow on B has no effect on C, because A is C's containing block.] 23:39:34 <fantasai_> | In certain cases, a box may overflow, meaning its content lies 23:39:34 <fantasai_> | partly or entirely outside of the box, e.g.: 23:39:34 <fantasai_> | ... 23:39:34 <fantasai_> | A descendent box is positioned <del>absolutely</de>, partly outside the box. 23:39:34 <fantasai_> | Such boxes are not always clipped by the overflow property on 23:39:36 <fantasai_> | their ancestors. <ins>Note that absolutely positioned descendant 23:39:49 <fantasai_> | elements are not always clipped by the overflow property on their ancestors.</ins> 23:40:38 <fantasai_> dbaron: I thought the proposal was the replace the Such ... ancestors sentence 23:40:51 <fantasai_> fantasai: I think that makes a lot more sense 23:41:21 <fantasai_> apparently this was the original proposal 23:44:45 <fantasai_> Peter is concerned that "not always clipped" is unclear 23:45:44 <fantasai_> dbaron: I think the reason for the change from such to note is because we're removing absolutely from the first sentence 23:46:06 <bradk> "a positioned item is not affected by the overflow property of ancestors inside its positioning block." 23:46:09 <fantasai_> dbaron: And ambiguities in the second part of the sentence should be a new issue 23:47:21 <fantasai_> so s/are not always clipped by the overflow property/do not always cause overflow/ ? 23:48:04 <fantasai_> ACTION: Tab Rewrite proposal for Issue 161 23:48:04 <trackbot> Created ACTION-218 - Rewrite proposal for Issue 161 [on Tab Atkins Jr. - due 2010-04-06]. 23:49:07 <fantasai_> http://wiki.csswg.org/spec/css2.1#issue-160 23:50:23 <bradk> s/positioning block/containing block 23:50:29 <fantasai_> glazou: Melinda got it backwards 23:51:03 <fantasai_> ChrisL: Prefix the sentence with "For example", because Japanese top-to-bottom books start like rtl books do 23:52:02 <dbaron> css3-page says it the right way around in http://dev.w3.org/csswg/css3-page/#progression 23:52:06 <fantasai_> RESOLVED: Add non-normative for-example change 23:55:28 <fantasai_> Proposal Fix 96px per inch. Whether inches fixed to reality or pixels fixed to screen res / viewing distance / something else may vary by UA. (Print would match real inches, screens tend to align with viewing distance and/or screen res.) 23:56:26 <fantasai_> Peter holds up his iphone. 23:56:44 <fantasai_> Peter: You are constantly zooming in and out on this device. There's no guarantee you'll ever get a physical inch for an 'in' 23:57:26 <fantasai_> SteveZ: You have the canvas, and the window onto the canvas. 23:57:47 <fantasai_> SteveZ: You have controls to change the window onto the canvas 23:58:16 <fantasai_> ... 23:58:20 <Bert> (The problem is not zooming on the iPhone, the pb is that a very small percentage of people thinks that it is illegal to use px on font-size. We just need to tell them that is not so.) 23:58:48 <fantasai_> dbaron: Are any other browser vendors willing to change their implementation to match the 'pt' unit to match physical 'pt' using monitor detection settings? 23:59:00 <fantasai_> dbaron: Everyone assumes 96dpi. So there's pressure on us to do that. 23:59:19 <fantasai_> Steve: It's all your fault Tantek. 23:59:37 <fantasai_> Peter: You and I had a discussion in an elevator where we agreed that Macs would use 96dpi instead of 72dpi 00:00:10 <fantasai_> Peter: And you showed me UI that would allow the user the ability to set an inch correctly by holding a ruler up to the screen, which was cool. 00:00:17 <fantasai_> Peter: I'm happy to give users that capability 00:01:33 <fantasai_> Peter: If the UA wants to have a zoom factor of Actual Size, then it can use the OS info to get the most accurate 1in == 1 inch rendering it can 00:02:56 <fantasai_> lots of conversations 00:04:35 <bradk> If the UA decides on having an "actual size" mode, and the monitor is not really 96ppi, then GIF images and such would have their pixels interpolated. 00:07:12 <ChrisL> "The suggested reference pixel is the visual angle of one pixel on a device with a pixel density of 90dpi and a distance from the reader of an arm's length. For a nominal arm's length of 28 inches, the visual angle is about 0.0227 degrees. " 00:07:32 <ChrisL> http://www.w3.org/TR/REC-CSS1-961217#units 00:07:43 <fantasai_> Tantek talks about a meta-viewport problem 00:09:13 <fantasai_> Alex: For Facebook, I found that in the virtual viewport the bar at the bottom was fixed-positioned, but you couldn't get to it unless you scrolled down 00:09:45 <paul_irish> paul_irish has joined #CSS 00:10:17 <fantasai_> Tantek: Shouldn't the meta viewport tag be a CSS thing, not a proprietary meta tag? 00:11:10 <fantasai_> Tantek: The exact problem that meta viewport solves, that should be in CSS 00:11:37 <paul_iri_> paul_iri_ has joined #CSS 00:12:07 <fantasai_> glazou: What happens if you browse a meta-viewport page with Safari on the mac? 00:12:13 <fantasai_> smfr: It ignores it 00:13:00 <fantasai_> Anne, Sylvain: Meta-viewport is setting the size of the viewport 00:13:05 <fantasai_> and then the UA zooms in to that size 00:13:46 <fantasai_> Tantek: Most other mobile browsers display a page designed for mobile normally 00:13:57 <fantasai_> Tantek: But the iphone made it into this tiny box in the corner of the screen 00:14:26 <fantasai_> Tantek: Even if you do use a media query to select an appropriate styling, then it still doesn't behave appropriately 00:14:55 <fantasai_> Sylvain: It defines what a pixel is as a fraction of the viewport 00:15:33 <mjs> mjs has joined #css 00:15:54 <fantasai_> fantasai: So it's setting the size of the initial containing block 00:16:10 <fantasai_> fantasai: not the viewport 00:16:12 <fantasai_> smfr isn't sure 00:18:46 <fantasai_> Tantek: If I write a media query to serve appropriate style sheets for 350 pix, Safari scales the page down to a tiny thing in the corner 00:18:50 <fantasai_> smfr: That's a bug, and we have it filed 00:19:16 <tantek> http://developer.apple.com/safari/library/documentation/AppleApplications/Reference/SafariHTMLRef/Articles/MetaTags.html 00:19:43 <fantasai_> fantasai: If we don't have a proposal on this, then I think we should close this topic 00:19:51 <fantasai_> dbaron: Did we have a resolution on the 2.1 issue we were talking about? 00:20:29 <tantek> http://developer.apple.com/safari/library/documentation/AppleApplications/Reference/SafariHTMLRef/Articles/MetaTags.html#//apple_ref/html/const/viewport 00:20:59 <fantasai_> howcome: I want to see the proposal before deciding 00:22:14 <fantasai_> howcome: I think the spec already says this 00:22:19 <fantasai_> peter points out that it doesn't 00:22:24 <fantasai_> and we go around in circles again 00:22:27 <fantasai_> I'm so not minuting this 00:23:27 <anne> Bert, http://xkcd.com/386/ ;) 00:23:36 <fantasai_> Bert argues that we should evangelize the web 00:25:45 <fantasai_> Alex: In IE8 we tried matching px to in based on the resolution, and this broke lots of things so we changed back to pretending 96dpi 00:27:18 <glazou> aaaah PixaPowaaaaaa ! 00:34:09 <fantasai> http://wiki.csswg.org/spec/css2.1#issue-148 00:36:53 <dbaron> For issue 148, I'd like to figure out why we changed it in the other direction. 01:14:39 <plinss_> plinss_ has joined #css 01:21:40 <miketaylr> miketaylr has joined #css 01:33:11 <jdaggett_> jdaggett_ has joined #css 03:23:51 <mjs> mjs has joined #css 04:03:03 <fantasai> fantasai has joined #css 04:37:52 <glazou> glazou has joined #css 04:43:40 <dbaron> dbaron has joined #css 04:44:51 <Arron> Arron has joined #css 05:00:47 <dsinger> dsinger has joined #css 05:14:02 <alexmog> alexmog has joined #css 05:15:05 <tantek> tantek has joined #css 06:08:40 <TabAtkins> TabAtkins has joined #css 06:13:04 <myakura> myakura has joined #css 07:44:29 <alexmog> alexmog has joined #css 08:09:54 <lstorset> lstorset has joined #css 08:10:09 <lstorset> lstorset has left #css 08:43:14 <fantasai> fantasai has joined #css 10:51:09 <krijnh> krijnh has joined #css 12:20:12 <lstorset> lstorset has joined #css 12:27:10 <lstorset> lstorset has left #css 13:09:26 <miketaylr> miketaylr has joined #css 14:47:07 <TabAtkins> TabAtkins has joined #css 14:51:03 <anne> anne has joined #CSS 15:18:10 <plh-home> plh-home has joined #css 15:24:41 <Arron> Arron has joined #css 15:45:48 <apple> apple has joined #css 15:47:52 <dsinger> dsinger has joined #css 16:01:01 <dydz> dydz has joined #css 16:02:01 <TabAtkins> TabAtkins has joined #css 16:03:21 <anne> anne has joined #CSS 16:04:48 <smfr> smfr has joined #css 16:08:02 <plinss_> plinss_ has joined #css 16:11:23 <dbaron> dbaron has joined #css 16:12:51 <dethbakin> dethbakin has joined #css 16:14:24 <sylvaing> sylvaing has joined #css 16:14:51 <Arron> Arron has joined #css 16:18:17 <bradk> bradk has joined #css 16:18:42 <TabAtkins> ScribeNick: TabAtkins 16:18:44 <glazou> glazou has joined #css 16:18:51 <TabAtkins> plinss: First topic this morning is CSSOM. 16:19:00 <TabAtkins> plinss: And impact on other specifications. 16:19:22 <ChrisL> ChrisL has joined #css 16:19:32 <TabAtkins> anne: While editting the spec, I noticed a few problems. 16:19:37 <TabAtkins> anne: One is that there's no real data model. 16:19:48 <TabAtkins> anne: The CSSOM is supposed to have a represetnation of what the stylesheet is like. 16:20:00 <TabAtkins> anne: But in the CSS specifications there is no clear mapping from the syntax to the data model behind it. 16:20:04 <szilles> szilles has joined #css 16:20:08 <TabAtkins> anne: A clear example is the font-family property. 16:20:22 <TabAtkins> anne: I think most impls internally represent them as strings, but that's not stated anywhere. 16:20:32 <TabAtkins> anne: So when you try to design a value API, you have to state it there. 16:20:52 <TabAtkins> fantasai: The font-family syntax I put up said explicitly that Computed Value should be strings, so I agree. 16:21:08 <TabAtkins> anne: We need Specified Value too. Basically, what you get after parsing. 16:21:19 <TabAtkins> anne: Two, there is surprising lack of consistency in the interface names. 16:21:37 <TabAtkins> anne: Like, an interface named CSSStyleRule, that maps to a css ruleset, but that term isn't really defined in the grammar. 16:22:00 <TabAtkins> anne: I'm not sure if we actually want to change the CSS spec, so this makes sense, or what? 16:22:09 <alexmog> alexmog has joined #css 16:22:15 <TabAtkins> anne: What I'm asking is if we want to adjust the terminology so that it's consistent between CSS and CSSOM. 16:22:29 <TabAtkins> anne: I'm guessing we can't change the interface, so it would be CSS that changes in a few points. 16:22:39 <TabAtkins> anne: Also, CSS spec refers to a lot of things as just 'values'. 16:23:00 <TabAtkins> anne: But in CSSOM, that needs to be something separate, like a 'value component', because a property can have multiple of them. 16:23:08 <TabAtkins> anne: The CSS spec is kind of loose with those things. 16:23:20 <TabAtkins> howcome: I agree, the spec shoudl change there. 16:23:42 <TabAtkins> ChrisL: The spec is focused on taking text into CSS, not in reverse. The OM spec should define that. 16:23:53 <TabAtkins> fantasai: No, I think the spec is ambiguous in a lot of places. 16:24:28 <TabAtkins> Bert: There is context where we call many things values, and if we introduce multiple terms for these it would be too confusing. 16:24:44 <TabAtkins> glazou: I heard the same thing when I introduced the [multiple types of selector groupings] 16:24:58 <TabAtkins> dbaron: I objected to that at the time because a term was actually being *redefined*. 16:25:22 <TabAtkins> anne: There are other specs where there are multiple concepts being referred to as the same thing. And that's fine, as long as there's a disambiguation at some point. 16:25:55 <TabAtkins> Bert: That disambiguation is present in the <> forms. 16:26:15 <TabAtkins> fantasai: I recommend 'property value' and 'component value', so they both abbreviate as 'value'. 16:26:32 <TabAtkins> howcome: Agreed, we shouldn't be changing tons of terms in the spec, but the disambiguation is needed. 16:26:53 <TabAtkins> ChrisL: Question about CSS color component. Is that used a lot, and is it memory constrained? 16:27:04 <TabAtkins> anne: We can change it if necessary. Specifics are still mutable. 16:27:23 <TabAtkins> anne: I can work around the lack of terminology, or invent my own, but it would be nice if it matched up. 16:27:36 <TabAtkins> fantasai: Do you have a list of terms that you need? 16:27:38 <TabAtkins> anne: No. 16:27:55 <ChrisL> would prefer to see attribute long red; instead of attribute short red; - color bit depth is increasing now 16:27:57 <TabAtkins> fantasai: I think the next step is to come up with that list of terms, so we can make sure it's defined somewhere. 16:28:38 <TabAtkins> anne: The grammar uses the term "statement" to refer to @ rules or rulesets, and the CSSOM spec refers to them as "CSSRules". 16:28:49 <TabAtkins> fantasai: I think CSSOM should be changed there. 16:29:07 <TabAtkins> anne: [describes the terminology, and how it can't be changed at this point] 16:29:18 <glazou> Present: Sam Weinig, smfr, annevk, szilles, dethbakin, sylvaing, alexm, Bert, arronei, fantasai, dbaron; bradk, TabAtkins, ChrisL, glazou, plinss, howcome, dsinger 16:29:25 <ChrisL> http://en.wikipedia.org/wiki/Deep_Color 16:29:30 <TabAtkins> fantasai: I'm not saying change the interface name, but you can say that "CSSRule" refers to what CSS calls "statement". 16:29:39 <TabAtkins> anne: I tried to do that before, but it didn't make much sense to me. 16:30:19 <TabAtkins> TabAtkins: I'd heard you talking before that it would be useful for specs to define how they should be reserialized, frex how to turn a gradient back into a string? 16:30:35 <TabAtkins> anne: Yeah, something in the future is for the CSS specs to be aware of the CSSOM in their writing. 16:31:17 <TabAtkins> anne: Like when you serialize the margin property, do you do as few values as possible, or write it out fully? 16:31:39 <TabAtkins> ChrisL: I agree with anne that specs should be aware of the CSSOM and write things in respect to that. 16:32:07 <TabAtkins> Bert: I think that the CSSOM should refer to CSS, not the other way around. 16:32:15 <TabAtkins> anne: There are several CSS specs that include interfaces. 16:32:21 <TabAtkins> Bert: Yeah, I think those should be taken out. 16:32:55 <TabAtkins> anne: I think it would be acceptable for me to have an ever-growing OM spec, but that isn't compatible with how the w3c does recs. 16:33:08 <TabAtkins> plinss: I think we agreed that specs going forward would define interfaces. 16:33:38 <fantasai> fantasai: We agreed that they would define serialization, not that they would define interfaces 16:34:11 <TabAtkins> plinss: It makes sense for the OM to define interfaces that are common across many specs, but we also shouldn't wait for a monolithic OM to include all the specialized interfaces that a module might have. 16:34:16 <dino> dino has joined #css 16:34:45 <fantasai> Bert: it doesn't have to be monolithic, you can publish a separate spec for each module's OM 16:34:50 <TabAtkins> plinss: We can have two conformance classes, if you support the OM you have to support X and Y, if not you just have to support X. 16:35:37 <TabAtkins> arronei: It's just a few lines in the conformance section to add the conformance requirements. 16:36:15 <TabAtkins> fantasai: But we have several specs in CR that don't include an OM section, and I don't want to pull them back to add that. 16:36:27 <TabAtkins> fantasai: We could create new OM specs just for those. 16:36:34 <TabAtkins> dbaron: That's a lot of specs. 16:36:44 <TabAtkins> anne: I'm fine with including that stuff in OM. 16:37:13 <TabAtkins> fantasai: If you can give me a template that I fill in to add OM stuff, I can do it. But until then, I don't want to have to add them to the spec. 16:37:47 <fantasai> fantasai: Half the generic stuff isn't even defined yet, and as for me I have *no clue* what to put in for the OM section 16:37:49 <TabAtkins> plinss: The person editting a given module may have no clue what the OM requires, what's a good idea, and so in that sense it may make sense to have a separate OM module for it. 16:38:09 <TabAtkins> anne: For value APIs, new values, we do want interfaces. 16:38:19 <TabAtkins> Bert: But for new keywords or lengths or numbers, those already exist? 16:38:22 <TabAtkins> anne: Yes. 16:38:48 <TabAtkins> anne: And for backgrounds, it might be sufficient already since it's a comma-separated list. 16:38:52 <myakura> myakura has joined #css 16:39:17 <TabAtkins> anne: For transforms, animations, they all introduce properties with slightly more complex values that need new value interfaces. 16:39:50 <TabAtkins> plinss: Any new @ rule needs an interface. And depending on how granular we get with the API, we may need to extend it for more things. 16:40:28 <TabAtkins> anne: And the Images module, it would need to define new interfaces for the new things in there. 16:41:04 <TabAtkins> plinss: Any conclusions on this? 16:41:17 <TabAtkins> Bert: There was something about numbering, and them having to be unique. Is there any way to avoid this? 16:41:31 <TabAtkins> anne: The pattern that is used all over most APIs is to use numbered constants. 16:41:55 <TabAtkins> anne: For CSSRule we cant' change the pattern. For CSSValue I suppose we could, but we haven't discussed it yet. I think it makes sense to keep it with the familiar way. 16:42:02 <TabAtkins> Bert: Does every @ rule need a new number then? 16:42:13 <TabAtkins> anne: If it exposed the same information as another @ rule, it can reuse a number. 16:42:57 <TabAtkins> plinss: @page introduces multiple different @ rules, which would all need a number. 16:43:35 <TabAtkins> anne: We have @page and friends, @font-face, @media, @import, and stylerules, all with different numbers. 16:44:04 <TabAtkins> anne: So far new @ rules probably want a new number. 16:44:16 <TabAtkins> anne: Like all the @margin rules might share a single number. 16:44:20 <alexmog> alexmog has joined #css 16:45:16 <TabAtkins> Bert: Numbers need coordination, which I think we should try to avoid if possible. 16:45:24 <TabAtkins> anne: I think we should just try to coordinate. 16:45:40 <TabAtkins> anne: We managed to do it pretty well for DOM Exceptions. 16:45:55 <TabAtkins> Bert: Who do we have to coordinate with. Just here, or do we have to coordinate with SVG? 16:46:32 <TabAtkins> anne: Officially SVG has to coordinate with us, but I've reserved some space for [something SVG-specific]. 16:46:42 <TabAtkins> [talk about different impls stomping on numbers] 16:46:42 <alexmog> alexmog has left #css 16:46:49 <alexmog> alexmog has joined #css 16:46:56 <fantasai> make the constant point to a UUID? :) 16:46:58 <TabAtkins> ChrisL: We need an easily referencable page where we can refer to this and stop conflicts. 16:47:10 <TabAtkins> [discussion on using a wiki for coordination] 16:47:19 <TabAtkins> anne: There is a way with WebIDL that you can extend an interface. 16:47:42 <TabAtkins> Bert: You can reference a wiki as an informative reference, but not a normative one. 16:47:53 <TabAtkins> anne: Yeah, sure, it can be informative. That's fine. 16:48:23 <TabAtkins> fantasai: So these numbers are all named constants, and people are supposed to use the names? 16:48:29 <TabAtkins> anne: Theoretically. 16:48:41 <TabAtkins> fantasai: Can we have the named constant return something other than a number? 16:48:46 <TabAtkins> anne: No, the type is a short. 16:49:34 <TabAtkins> anne: Same thing is done with, say, Nodes, but that doesn't change very often. CSS adds new things somewhat more often. 16:50:27 <TabAtkins> plinss: If you're implemeneting something early, like Paged Media in webkit, should prefixed versions use the same final number? 16:50:38 <TabAtkins> anne: No, it says right now that the CSSWG reserves the first 1000 values. 16:51:28 <TabAtkins> plinss: So proprietary versions should use a number above 1000. 16:52:08 <TabAtkins> ChrisL: Will implementations switch from >1000 to <1000 when they get standardized? 16:52:20 <TabAtkins> anne: When they drop the prefix should be fine. 16:52:37 <TabAtkins> plinss: Should we try to reserve blocks for individual browsers? 16:53:22 <TabAtkins> fantasai: Authors should just use the named constants. 16:53:29 <TabAtkins> smfr: Should the named constants be prefixed? 16:53:33 <howcome> howcome has joined #css 16:53:58 <TabAtkins> anne: Good question. If you don't prefix, there's a chance that code would still work when it moved to standardization. But if we changed anything, then it could break. 16:54:07 <TabAtkins> anne: Ideally we'd iterate fast enough that we don't run into that situation. 16:54:43 <TabAtkins> anne: If people want to write their thoughts to the list, it would be fine. 16:55:11 <TabAtkins> ACTION: anne to set up wiki page to list CSSOM constants for coordination 16:55:12 <trackbot> Created ACTION-219 - Set up wiki page to list CSSOM constants for coordination [on Anne van Kesteren - due 2010-04-07]. 16:55:28 <TabAtkins> plinss: Did we come up with a decision for how to do OM sections for new modules? 16:55:57 <TabAtkins> anne: I think for specs in WD, it would make sense to have them in the spec. But perhaps we should defer that a little and discuss the value APIs first. 16:56:20 <TabAtkins> anne: So currently for the value apis you get a CSSStyleDeclaration object, with a long list of attributes that represent CSS properties. 16:56:23 <TabAtkins> anne: And they all return a string. 16:56:26 <smfr> http://dev.w3.org/csswg/cssom/#the-cssstyledeclaration-interface 16:56:46 <TabAtkins> anne: The initial idea we had was that instead of a string it would return something special, that would act like a string but would allow extensions. 16:57:02 <TabAtkins> anne: I brought it up on public-script-coord, where ecmascript guys hang out, but they didn't think it was a good idea. 16:57:09 <TabAtkins> anne: [some examples of breakage] 16:57:31 <TabAtkins> anne: Based on that we have a new idea. The CSSStyleDeclaration object would have a new property called values, which would return a CSSStyleVales object. 16:57:54 <TabAtkins> anne: It would act like StyleDeclaration, but when you access a property, it would return a CSSValue object rather than a string. 16:58:18 <TabAtkins> anne: The object would have a cssText attribute that lets you set a string or get a serialization, which is equivalent to the existing API. 16:58:29 <TabAtkins> anne: So then the question is how to define the new value APIs on top of that. 16:58:41 <TabAtkins> anne: I think we want interfaces for the components. 16:58:49 <TabAtkins> anne: So an interface for %, for lengths, for color values 16:58:52 <fantasai> anne, http://wiki.csswg.org/spec/cssom-constants 16:59:06 <TabAtkins> anne: And if you have a width property, that supports both lengths and %, the object returned would implement both. 16:59:21 <smfr> http://dev.w3.org/csswg/cssom/#the-cssvalue-interface 16:59:23 <TabAtkins> anne: It would have an .px and .em accessor, but also a percentage accessor so you could set and get %. 16:59:39 <TabAtkins> anne: So how far do we want to go? Each and every property, or start out witha limited subset? 16:59:53 <TabAtkins> anne: And do we need a "type" like CSSRule so you can figure out what kind of value was set? 17:01:01 <TabAtkins> anne: Like, ComponentValue would return a type of lengthEm, lengthPx, etc. Would that be a short, like the other types? Or a string that could be interned, which could be more extensible. 17:01:41 <TabAtkins> anne: If we did numbers, then if we start filling in spots, say if we added a new length, it could be very separated from the other lengths. px could be 12, and rem could be 100. 17:01:57 <TabAtkins> plinss: As long as people use names, the numbers wouldn't matter much anyway. 17:02:03 <TabAtkins> plinss: We could also reserve blocks. 17:02:15 <TabAtkins> szilles: So what's the downside on strings? 17:02:19 <TabAtkins> plinss: Pereformance. 17:02:33 <TabAtkins> anne: If they're interned, it would just be pointer comparisons. 17:03:04 <TabAtkins> plinss: I'm concerned more with author script stuff. Will I be doing a thousand string comparisons, or a thousand short comparisons? 17:03:18 <Bert> s/Pereformance/Performance/ 17:03:21 <TabAtkins> smfr: Potentially, we could have them do atomic string comparisons. 17:03:30 <fantasai> You might also want to answer things like "is this a length (any kind)" or "is this a percentage" 17:03:57 <fantasai> ?: Can we define constants that are strings? 17:04:17 <plinss_> s/?/anne/ 17:04:30 <TabAtkins> ?: Nothing theoretically wrong with it. The strings are essentially immutable. 17:04:53 <TabAtkins> s/?/Sam Weinig/ 17:05:13 <weinig> weinig has joined #css 17:05:28 <TabAtkins> anne: How do we, at the object level, distinguish between value components and things that are separated lists of value components. 17:05:42 <TabAtkins> anne: Like, background-position takes two values. 17:05:59 <TabAtkins> anne: So how do we represent that? 17:06:10 <TabAtkins> plinss: I think it should return a backgroundPosition object that has two values. 17:06:58 <TabAtkins> glazou: We could return an array with the components in the order they appear. 17:07:16 <TabAtkins> plinss: Or an object with queryable values, so it's more extensible. 17:07:51 <TabAtkins> anne: Also, do we want a special interface for shorthands? Like margin, should we implement a margin property or only margin-left, margin-right, etc? 17:08:10 <TabAtkins> dbaron: Also there are some non-shorthand values that are rather complex, like shadows or border-image. 17:09:03 <TabAtkins> plinss: We could pretend they are shorthands and expose them as such in the object model. 17:09:13 <TabAtkins> anne: But then we're stuck if a property later becomes a shorthand. 17:09:27 <TabAtkins> fantasai: Like we're going to do with whitespace. 17:09:40 <TabAtkins> smfr: I think the hash-table approach would work for shorthands. 17:10:57 <fantasai> fantasai: So, for the 'margin' shorthand you'd be able to look up the 'margin-left' value and 'margin-right' value? 17:10:57 <dbaron> A bunch of the complex-valued properties are arbitrary-length lists, which are hard to represent as shorthands. 17:11:02 <TabAtkins> glazou: If possible, harmonize things across properties, so "x" is the same for all the values. 17:11:46 <TabAtkins> sam: In that case you wouldn't have named components, but rather numbered components. 17:11:57 <fantasai> fantasai: You could have named components that are lists 17:12:14 <TabAtkins> plinss: We've already had things that take a single value and turned them into lists of that value. 17:13:26 <TabAtkins> anne: A simple example would be background-image, which would return a css url, but also have a way of getting a list of css urls. 17:13:44 <TabAtkins> dbaron: I think the single-value thing should only return the single value if there *is* a single value, and otherwise complain about being a wrong tpe. 17:13:59 <dbaron> s/complain about/do whatever happens when it is/ 17:14:15 <dbaron> s/being a wrong tye/the wrong type/ 17:15:12 <TabAtkins> glazou: Recursively nested values. 17:15:21 <dbaron> What's interesting with url() values is often an absolute URL rather than a relative URL relative to the style sheet. 17:15:38 <TabAtkins> glazou: In the case of color, rgb returns a single color value, which also has .r, .g, .b. 17:15:43 <TabAtkins> glazou: etc. 17:17:38 <TabAtkins> glazou: Editors will *massively* use CSSOM if it is easier to use, but not if they have to reparse/rebuild values into a useful form every time. 17:18:19 <TabAtkins> anne: I think you want interfaces for this. 17:19:06 <TabAtkins> glazou: Another thing I want to see in the CSSOM, some things just for editors. 17:19:20 <TabAtkins> glazou: Like not just the reserialized text, but the original parsed text. 17:20:00 <TabAtkins> glazou: Like if the @style attribute has something wrong, browsers currently throw it away and it's hard to get at that. 17:20:24 <TabAtkins> glazou: Browsers don't need that, so they can just return null or whatever, but editors are allowed to return the full thing. 17:20:56 <TabAtkins> sam: Is that confusing for authors? 17:21:07 <TabAtkins> anne: If it's not for browsers, do we need it in the spec? 17:21:14 <TabAtkins> glazou: Yes, if you have multiple editors you want interop. 17:22:03 <TabAtkins> smfr: So what if someone wants to write a javascript editor tool in a normal browser? 17:22:18 <TabAtkins> TabAtkins: Like FireBug would love this. 17:22:26 <TabAtkins> smfr: Isn't this what UnknownRule is for? 17:22:37 <TabAtkins> dbaron: UnknownRule was designed by someone who doesn't understand CSS parsing. 17:22:49 <TabAtkins> plinss: We could just tell browsers to *not* throw away these things. 17:23:06 <TabAtkins> sam: For Firebug and Web Inspector we use internal hooks, and don't need the specced thing. 17:23:28 <TabAtkins> arronei: What if I'm a brand new editor for HTML and CSS? This is where having a spec would be great. 17:24:01 <TabAtkins> sam: The issue is that it would slow down browsers. We can either decide that we have it anyway, or not. 17:24:12 <TabAtkins> smfr: We could have a runtime switch controlled by the OM. It's weird, but shrug. 17:25:02 <TabAtkins> [discussion about editors and browsers throwing things away] 17:25:16 <TabAtkins> glazou: A live editing tool for HTML and CSS right now is impossible because of this limitation. 17:25:38 <fantasai> I don't think UnknownRule or UnknownAnything is necessarily the way to go. You should have a unified API insofar as possible. You can have MalformedRule or something for things that can't be parsed... 17:25:46 <TabAtkins> anne: We've had this discussion before. I thinkwe might want some editing features already, and we might want to move those upward. 17:26:01 <TabAtkins> anne: But I think we need a more concrete proposal for how to modify the OM for editors. 17:26:05 <fantasai> But if it's clearly propertyname : valueIcan'tUnderstand, you should get an api that works the same as for color: blue; 17:26:23 <fantasai> and returns the propertyname and the string representation of the value 17:26:36 <TabAtkins> glazou: concrete example: firebug, dragonfly, etc, from a given element, you can climb up the cascade to find which element triggered the current rule. But it's not standard! 17:26:45 <TabAtkins> glazou: We all use proprietary interfaces to do it. 17:26:52 <TabAtkins> anne: That's something we can definitely standardize. 17:27:08 <TabAtkins> anne: For changing the parsing engine we need more detailed proposals. 17:27:30 <TabAtkins> dbaron: CSS is harder to get right because you've got comments anywhere. 17:28:06 <TabAtkins> glazou: My own impl preserves comments between rules and between declarations. But that's a big bloat for browsers. 17:28:47 <TabAtkins> plinss: in the early days of gecko I made something that preserved all the information, and if it found a comment somewhere odd, it would shove it forward to the next 'normal' point for comments. 17:28:55 <TabAtkins> glazou: That's not perfect, but yeah it works. 17:29:07 <TabAtkins> glazou: I perfectly understand the browser's concerns wrt bloat and footprint. 17:29:23 <TabAtkins> glazou: But adding nothing at all shuts the door to a whole class of live applications on the web that are everywhere these days. 17:29:36 <TabAtkins> glazou: Wikis are everywhere, styles are everywhere, and we still can't edit styles. 17:30:05 <TabAtkins> anne: We can largely edit it. Not every property, but most of them. 17:30:16 <TabAtkins> anne: I think most editors let you edit the text file. 17:30:25 <TabAtkins> ChrisL: Because the OM isn't up to the task yet. 17:30:33 <TabAtkins> howcome: That's what the spec is trying to fix, right? 17:31:00 <TabAtkins> anne: For WYSIWYG you don't need comments, so I see some conflicts. 17:31:32 <TabAtkins> howcome: I think Anne is trying to get this done, and you're being aggressive to him. 17:31:44 <TabAtkins> glazou: I'm not aggressive, I love what you've done, I just want to see more. 17:32:30 <TabAtkins> smfr: You should both be able to edit the text directly, and move to doing sliders and such, and go back. We need that for our editor. 17:32:54 <TabAtkins> plinss: The Web has a legacy of documents being editted by hand, and we can't just throw that away into a non-hand-editable spec as soon as machines touch it. 17:33:12 <TabAtkins> sam: I think that Anne's work doesn't impede any of this. 17:33:39 <TabAtkins> glazou: I think that when OM was first created, editors weren't in anyone's mind. 17:34:30 <TabAtkins> plinss: Gecko actually got built to be an editor. The fact that it turned into a browser is happenstance. 17:34:58 <TabAtkins> plinss: While we were designing that stuff, we saw the convergence of editors and browsers as the web develops. 17:35:20 <TabAtkins> plinss: We eventually realized that the only difference between gecko being a browser and being an editor was a stylesheet. 17:36:29 <TabAtkins> anne: We just need to find what the cost for benefit is. If browsers already preserve comments, we can look into that, but we can't put comments everywhere. 17:36:34 <TabAtkins> anne: And what about whitespace? 17:37:10 <TabAtkins> glazou: What's important is maintaining what was entered. Like for border-radius, you can't just have everything but the -moz-border-radius thrown away just because that's the only one that was recognized. 17:37:37 <TabAtkins> anne: If someone can define what sort of string would be produced, and browsers are okay with the footprint, we'd be okay. 17:38:13 <TabAtkins> fantasai: I think you would start parsing, and get the property name as an ident. 17:38:25 <TabAtkins> plinss: ident, colon, stuff, semicolon. 17:38:49 <TabAtkins> sam: So basically we'd have something more than unknown rules, for unknown declarations too, and a browser mode that would change that. 17:38:57 <TabAtkins> fantasai: For all rules too. 17:39:32 <TabAtkins> alexmog: Let's have a CSS editing requirement TF and come up with a list of requirements for object model, for editors, and other features, so we can figure out what the goals we're trying to achieve are. 17:40:29 <TabAtkins> alexmog: Right now we're designing a partial object model. We can possible change the OM into something that does what we need, or something completely different for editors. 17:40:50 <TabAtkins> alexmog: [he talks to VS people twice a year about this, various requests] 17:41:27 <TabAtkins> RESOLVED: Alex and Daniel will start a CSS Editing TF. 17:41:51 <TabAtkins> anne: I think if you want it to end up in browsers you want it to reconcile with the OM. 17:42:02 <TabAtkins> glazou: Yes. 17:42:43 <TabAtkins> alexmog: I'm not quite convinced if a high-powered editor needs to be built on the object model. 17:43:26 <TabAtkins> alexmog: Like if there are only a small number of companies building major editors, they may not need a full OM in favor of just a more editing-friendly interface. 17:44:34 <TabAtkins> plinss: The same thing happened with HTML. First browsers didn't remember anything about the HTML, and the object model got thrown away as it was parsed. But we gradually kept around more of the model. 17:44:50 <TabAtkins> plinss: So we need to extend this over CSS. 17:45:05 <TabAtkins> plinss: We didn't build the DOM to build an editor, it just happens to also be useful for this. 17:45:22 <TabAtkins> glazou: We know there are some things that we always can't do, like preserving comments everywhere. 17:47:49 <bradk> It would be nice if the various developer tools (FireBug, etc.) preserved (and flagged somehow) properties and values that had typos or spelling mistakes, so that they can be edited and fix in-browser. 17:53:55 <dbaron> glazou, http://dbaron.org/css/timing-function-graphs 17:55:10 <bradk> bradk has joined #css 18:04:24 <alexmog> alexmog has joined #css 18:10:25 <TabAtkins> anne: We need to have the hash-table concept for values that are space-separated, and a list concept for values that are comma separated? 18:11:41 <TabAtkins> anne: for margin, you'd return a hashtable-like interface with each property 18:12:00 <TabAtkins> TabAtkins: We just need to make sure that properties that later turn into shorthands still work by themselves. 18:12:56 <TabAtkins> sam: My suggestion to anne was to take some of the more complex examples of syntax, break it down into concrete proposals, and put that on the list. 18:13:09 <TabAtkins> fantasai: I suggest border image. 18:13:15 <TabAtkins> glazou: Font stuff too. 18:13:25 <TabAtkins> sam: Whatever is *as hard* for anne as possible. 18:13:35 <TabAtkins> fantasai: shadows and the content property. 18:14:07 <TabAtkins> ACTION: anne to produce concrete examples of complex properties and put it on the list 18:14:07 <trackbot> Created ACTION-220 - Produce concrete examples of complex properties and put it on the list [on Anne van Kesteren - due 2010-04-07]. 18:14:56 <TabAtkins> smfr: We also need to define if every property has a canonical form. If someone specifies 'ease' in a timing function, do they get 'ease' back or a bezier function? 18:15:16 <TabAtkins> plinss: As much as possible we should return what the author specified. 18:15:56 <TabAtkins> anne: We could have a .keyword value that would return a keyword if the value corresponds to a keyword. 18:16:23 <TabAtkins> glazou: Same with color - if the author says "red", do we do 'red', '#f00', rgba(255,0,0,1), or what? 18:16:44 <TabAtkins> anne: Browsers try to store as little as possible right now. 18:17:52 <TabAtkins> plinss: For a browser, no matter what gets specified it'll be stored as a [r,g,b] or whatnot, and I'd want back what the author actually said sometimes if possible. 18:18:22 <TabAtkins> anne: We might have a bit that says if the color was originally a keyword or whatnot. 18:18:33 <TabAtkins> anne: Currently there are a number of normalization rules for various things. 18:18:41 <TabAtkins> plinss: I'm concerned that some of them go too far. 18:19:35 <TabAtkins> plinss: If you have multiple ways to pull a value back out of the OM, that's fine, but when serialized to text it should be as close to what the author said as possible. We can change "Red" to "red", don't need bit-for-bit, but the spirit should be the same. 18:19:51 <TabAtkins> smfr: One problem I have with gradients is that there's no canonicalization. 18:19:56 <TabAtkins> TabAtkins: Agreed, I need to add that. 18:20:14 <TabAtkins> plinss: CSS3 Color Issues 18:20:22 <dbaron> http://wiki.csswg.org/spec/css3-color 18:20:25 <szilles> szilles has joined #css 18:21:13 <TabAtkins> Currently the editors draft addresses most of these issues, but I haven't yet replied to the emails with these comments. 18:21:15 <TabAtkins> First is issue 5. 18:21:49 <TabAtkins> dbaron: At first I thought it was someone who didn't understand the spec, but I realize now that there isn't a good description of what rgba means. 18:22:01 <TabAtkins> ChrisL: And I think it should explain how it interacts with opacity (multiplied together). 18:22:18 <TabAtkins> dbaron: A repeated comment we got was the gamma correction section being out of date; I think I've addressed that. 18:22:23 <TabAtkins> ChrisL: Yeah, looks like it. 18:22:28 <smfr> editor's draft: http://dev.w3.org/csswg/css3-color/ 18:22:43 <TabAtkins> ChrisL: Beth will send me an email that gamma has changed between Leopard and Snow Leopard. 18:23:10 <TabAtkins> dbaron: The wording of the spec in general isn't great about what conformance requirements are, so there are some issues where I think I can improve that relatively easily. 18:23:24 <TabAtkins> dbaron: Frex, it says "here is how to convert hsl to rgb", but it doesn't say you *have* to do that. 18:23:32 <TabAtkins> ChrisL: yeah, that should be normative. 18:23:52 <TabAtkins> ChrisL: Also there was an issue about color spaces and color width and such. All colors should be sRGB, and 0-255. 18:24:05 <TabAtkins> dbaron: Issue 13 18:24:55 <TabAtkins> dbaron: Someone suggested we remove the statement about clipping values outside the device gamut, which makes me wonder what to replace it with. 18:25:24 <TabAtkins> ChrisL: I don't think they understood the issue. Do we have a conformance reuqirement to display colors you can't physically display? 18:25:41 <TabAtkins> dbaron: I think that we might not quite want to clip, but might do some special mapping near the edge. 18:25:57 <TabAtkins> ChrisL: [example with differing gamuts] 18:26:27 <TabAtkins> ChrisL: After doing gamut mapping, if I still end up with values outside the displayable colors, it must be clipped. 18:26:44 <TabAtkins> dsinger: Are you modifying what you remember the user asked for, or what you are trying to display? 18:27:01 <TabAtkins> ChrisL: If it's implying that what is specified goes 1-1 with device gamut, that needs to be changed. 18:27:11 <TabAtkins> dbaron: Right, that's why I want to change "clipped" to "clipped or mapped". 18:27:45 <TabAtkins> ChrisL: "clipped or mapped" isn't fine. 18:28:05 <TabAtkins> ChrisL: You need to say "values outside source gamut should be mapped to device gamut, values outside device gamut must be clipped". 18:28:10 <TabAtkins> dbaron: What's the source gamut? 18:28:16 <TabAtkins> ChrisL: The color space you're coming from, sRGB. 18:28:30 <TabAtkins> dbaron: CSS allows values outside of sRGB. 18:28:50 <TabAtkins> ChrisL: Yes, that's fine. If you have a printer that can do blues outside of sRGB, that's fine, CSS lets you express that. 18:29:19 <szilles> szilles has joined #css 18:29:30 <TabAtkins> ChrisL: But if you're showing on a screen, you can clip to the device's gamut. 18:29:40 <TabAtkins> dbaron: How is the source gamut related to things here? 18:30:27 <TabAtkins> ChrisL: I should have flagged 'device gamut' more. Once you've mapped to the device gamut, *then* you need to clip anything outside of it. 18:30:47 <TabAtkins> Bert: The device clips them for you, right? 18:30:53 <TabAtkins> ChrisL: Typically the driver clips them for you. 18:31:08 <TabAtkins> ChrisL: You need to introduce the term source gamut and device gamut, and use them separately. 18:31:15 <TabAtkins> dbaron: What is the source gamut? 18:31:30 <TabAtkins> ChrisL: In here, sRGB, or any other color space if we allow more later. 18:32:04 <TabAtkins> dbaron: But we allow things outside of sRGB. 18:32:16 <TabAtkins> ChrisL: Right, nobody is talking about clipping source gamut. 18:32:50 <TabAtkins> ChrisL: I can take an action to give a better description here. 18:33:01 <TabAtkins> szilles: [suggestion for communicating this without using the term gamut] 18:35:10 <TabAtkins> ACTION: clilley to rewrite the paragraph in CSS color concerning gamuts and clipping 18:35:10 <trackbot> Created ACTION-221 - Rewrite the paragraph in CSS color concerning gamuts and clipping [on Chris Lilley - due 2010-04-07]. 18:35:29 <TabAtkins> dbaron: issue 18, from xsl-fo. 18:35:41 <smfr> http://wiki.csswg.org/spec/css3-color#issue-18 18:36:53 <smfr> http://lists.w3.org/Archives/Public/www-style/2008Sep/0006.html 18:37:27 <TabAtkins> dbaron: It's one of the later messages in the thread. 18:38:04 <TabAtkins> ChrisL: Marbux is a troll. 18:38:14 <TabAtkins> glazou: We still need to respond to trolls. 18:38:23 <TabAtkins> glazou: Talked to AC people, they said it was no problem. 18:38:58 <TabAtkins> glazou: So we have an answer. It's member-only, but it's not a technical issue, only a legal one. It probably deserves a member-only answer. 18:39:19 <TabAtkins> ChrisL: So resolution is no change? 18:39:28 <TabAtkins> szilles: The "be" change should happen, though, right? 18:39:32 <TabAtkins> dbaron: That's editorial, yeah. 18:40:01 <TabAtkins> ChrisL: So we can say "We agree with the editorial comments from the XSL-FO working group". It makes it clear who we're agreeing with. 18:40:27 <TabAtkins> dbaron: There's a note at the bottom of the system colors section that I think is wrong. 18:40:46 <TabAtkins> dbaron: It says the computed value of a system color is the keyword itself. 18:40:57 <TabAtkins> dbaron: First it's weird that a normative requirement is a note, and I think it's wrong anyway. 18:41:06 <TabAtkins> dbaron: So system colors should compute to a color. 18:41:09 <TabAtkins> ChrisL: Sounds good. 18:41:47 <TabAtkins> ChrisL: I've seen Issue 20 come up in hypertext coordination group before, and so we need to say what we mean by 'deprecated'. 18:42:04 <TabAtkins> dbaron: We mean that impls should still implement it, but new content shouldn't use it. 18:42:36 <TabAtkins> ChrisL: Issue 27, we should discuss it. 18:42:50 <TabAtkins> ChrisL: I assume it's because we can get it out this decade? 18:43:13 <TabAtkins> dbaron: It doesn't have real dependencies; it can go to 2.1 just fine. 18:43:55 <dbaron> Sounds like people are all happy with depending on CSS 2.1 18:44:00 <TabAtkins> plinss: Next topic is animation of gradients. 18:44:16 <TabAtkins> smfr: I think this came up because the Transitions spec said gradients were animatable. 18:44:32 <alexmog> alexmog has joined #css 18:44:45 <TabAtkins> smfr: I think this is a mistake because gradients aren't a property, but rather a type of image, and we don't know how to transition images yet. 18:45:09 <TabAtkins> smfr: Also I think this might be someething for the public-fx group to input into as well. 18:45:57 <TabAtkins> ChrisL: Could you send a mail to the list about that? 18:46:07 <TabAtkins> ChrisL: [talks about how animating gradients in SVG is easy] 18:46:48 <TabAtkins> TabAtkins: I've got a goal with shepazu to unify some underlying concepts in CSS and SVG, to make those things easier. 18:46:55 <TabAtkins> plinss: Next topic is image-fit and image-position 18:47:05 <TabAtkins> fantasai: We can't do much, since that was supposed to be for SVG coord. 18:47:17 <TabAtkins> fantasai: But one thing we can talk about is naming. SVG wanted new names for things. 18:47:25 <TabAtkins> fantasai: We might be able to discuss that. 18:47:43 <fantasai> http://lists.w3.org/Archives/Public/www-style/2009Sep/0304.html 18:48:49 <anne> btw, http://blog.mozilla.com/security/2010/03/31/plugging-the-css-history-leak/ 18:49:53 <TabAtkins> howcome: image-* isn't perfect for video either 18:50:18 <TabAtkins> fantasai: fit-aspect-ratio says that you're fitting the aspect ratio to the box. 18:50:35 <TabAtkins> fantasai: As far as the most useful information you can stuff into the property, that's fine. 18:50:56 <TabAtkins> ChrisL: So fit-aspect-ratio and fit-position are good? 18:51:07 <TabAtkins> howcome: No. What if you put it on a <p>? 18:51:22 <TabAtkins> fantasai: No aspect ratio, so it's no good. 18:52:01 <TabAtkins> howcome: Are there other suggestions? 18:52:22 <TabAtkins> Bert: Without something pointing to images or replaced content, this sounds too general. 18:52:29 <fantasai> s/it's no good/it doesn't apply/ 18:52:46 <TabAtkins> dbaron: What's the list of values for this? 18:53:06 <TabAtkins> TabAtkins: For aspect ratio: fill, cover, and contain. For position, a bg-position. 18:53:27 <TabAtkins> howcome: Why isn't image good enough for SVG? 18:54:10 <TabAtkins> dbaron: If I hear "aspect-ratio", I expect something that looks like a ratio. 18:54:59 <TabAtkins> fantasai: Maybe aspect-ratio-fit, but then it's weird to combinee them into a shorthand. 18:55:48 <TabAtkins> smfr: content-fit, or just fit? 18:55:52 <TabAtkins> Bert: We had that. 18:55:52 <dsinger> here http://dev.w3.org/csswg/css3-page/ 18:56:12 <TabAtkins> TabAtkins: We had content-fit, said it was too general, and changed it to image-fit. 18:56:15 <smfr> http://dev.w3.org/csswg/css3-page/#img-fit 18:57:46 <TabAtkins> TabAtkins: This specifically says "replaced elements", which isn't great for SVG. 18:57:56 <TabAtkins> fantasai: When SVG imports it, they can clarify wording for their own purposes. 18:58:12 <TabAtkins> fantasai: In CSS, all values have no effect on non-replaced content. 18:58:41 <TabAtkins> Bert: content-* has another advantage, in that it refers back to the content property, which can produce a replaced element. 18:59:28 <Bert> 'content-fit' not 'fit-content' 19:00:03 <TabAtkins> [naming discussions] 19:00:20 <bradk> 'scale-how' and 'position-how' 19:00:28 <Bert> (I still prefer 'image-fit', though) 19:00:56 <fantasai> 'aspect-ratio-fit' 19:01:00 <fantasai> 'fit-aspect-ratio' 19:01:02 <fantasai> 'content-fit' 19:01:03 <fantasai> 'fit-content' 19:01:09 <fantasai> 'fit-scaling' 19:01:13 <fantasai> 'scaling-fit' 19:01:44 <dsinger> fitting? 19:02:11 <dsinger> 'replaced-element-fit-behavior'? 19:02:15 <bradk> fitting:have(1) 19:02:46 <fantasai> q+ for motion to switch topics until Molly can join the discussion 19:03:40 <TabAtkins> <br type=lunch> 19:04:02 <sylvaing> image-spread 19:04:22 <smfr> smfr has joined #css 19:40:57 <Lachy> Lachy has joined #css 20:01:37 <smfr> smfr has joined #css 20:02:05 <sylvaing> sylvaing has joined #css 20:02:27 <mjs> mjs has joined #css 20:03:33 <dethbakin> dethbakin has joined #css 20:05:42 <Arron> Arron has joined #css 20:07:46 <bradk> bradk has joined #css 20:09:53 <plinss_> plinss_ has joined #css 20:10:06 <mjs> mjs has joined #css 20:10:14 <mollydotcom> mollydotcom has joined #css 20:10:53 <mollydotcom> Hi all - guessing you're off for lunch? 20:11:07 <TabAtkins> just getting back, actually 20:11:17 <mollydotcom> hi Tab, how's it been going? 20:11:23 <TabAtkins> Excellent! 20:11:31 <mollydotcom> great to hear 20:11:49 <TabAtkins> Sad I didn't get to meet you this time. ;_; 20:12:01 <mjs> did you guys solve all problems with CSS yet? 20:12:19 <anne> we added some problems 20:12:20 <mollydotcom> I know, I was looking forward to it, but boy did I catch some kind of crud. 20:12:30 <mollydotcom> Ah, Anne, ever the optimist. 20:12:31 <mjs> anne: dammit! 20:14:03 <glazou> glazou has joined #css 20:17:22 <bradk> bradk has joined #css 20:18:01 <alexmog> alexmog has joined #css 20:18:02 <glazou> hi mollydotcom 20:18:20 <mollydotcom> Hi Daniel! 20:19:10 <TabAtkins> [continuing discussion about combining animations and gradients] 20:19:38 <TabAtkins> [specifically, maybe attaching animations to transitions, rather than states?] 20:19:54 <fantasai> RRSAgent: pointer 20:19:54 <RRSAgent> See http://www.w3.org/2010/03/29-CSS-irc#T20-19-54 20:20:47 <TabAtkins> [dean talking about animations with implicit start and end, like transitions do] 20:21:03 <TabAtkins> [if, say, you animate left when you transition a color, what's the final value of left?] 20:21:25 <Bert> (If 'transition-properties' has a value foo, then foo animates, even if the start and end values are the same.) 20:22:28 <TabAtkins> [discussion about new selectors to address the hover/unhover animations] 20:22:42 <TabAtkins> [something more analogous to mouseenter/mouseleave, rather than mouseover like :hover is] 20:23:08 <TabAtkins> [or something that explicitly captures a state transition, like :transition(:hover,:not(:hover))] 20:23:36 <TabAtkins> [combinatorial number of state transitions] 20:31:28 <TabAtkins> [event-based CSS property] 20:32:21 <TabAtkins> [back to keyframes for transitions?] 20:33:39 <jdaggett> jdaggett has joined #css 20:34:13 <anne> you could have something like :leave(:hover) or :leave(.test) for when something stops applying... 20:34:28 <anne> but keyframes for transitions is prolly an easier solution 20:35:02 <TabAtkins> plinss: Back to naming of image-fit and image-position, sincy mollydotcom is here. 20:35:02 <glazou> mollydotcom, we need your expertise finding names... 20:35:04 <fantasai> Topic: image-fit 20:35:12 <mollydotcom> I'm here to talk about that 20:35:25 <TabAtkins> smfr: dsinger had a suggestion that he put into irc earlier 20:35:39 <TabAtkins> smfr: viewing-scale : letterbox | crop | fill; viewing-position : ... 20:36:02 <plinss_> zakim, make room for 3 20:36:19 <Zakim> Zakim has joined #CSS 20:36:26 <plinss_> zakim, make room for 3 20:36:26 <Zakim> I don't understand 'make room for 3', plinss_ 20:36:46 <plinss_> zakim, room for 3 20:36:46 <Zakim> I don't understand 'room for 3', plinss_ 20:36:59 <plinss_> zakim, room for 3? 20:37:01 <Zakim> ok, plinss_; conference Team_(css)20:36Z scheduled with code 26632 (CONF2) for 60 minutes until 2136Z 20:37:05 <mollydotcom> do you want me to call in or shall I just type? Both hurt, typing less so as my throat is so swollen. 20:37:19 <glazou> mollydotcom: see conf call data just above 20:37:23 <fantasai> how about we call in, and you type? 20:37:34 <fantasai> that way you can hear everything 20:37:35 <glazou> Zakim, code? 20:37:35 <Zakim> the conference code is 26632 (tel:+1.617.761.6200 tel:+33.4.89.06.34.99 tel:+44.117.370.6152), glazou 20:37:49 <mollydotcom> ok, I'll call in and say hi and then type 20:37:51 <mollydotcom> thanks 20:37:53 <fantasai> :) 20:38:01 <plinss_> (or not quite hear as the case may be...) 20:38:06 <Zakim> Team_(css)20:36Z has now started 20:38:13 <Zakim> +[Apple] 20:38:23 <TabAtkins> mollydotcom: You can call in now. 20:38:47 <Zakim> +Molly_Holzschlag 20:38:48 <fantasai> http://lists.w3.org/Archives/Public/www-style/2009Sep/0304.html 20:40:03 <TabAtkins> mollydotcom: Elika has caught me up a little bit on the issue. 20:40:10 <TabAtkins> mollydotcom: We've been talking about this for a long time. 20:40:25 <TabAtkins> mollydotcom: If someone can pinpoint the terminology that we're struggling with, I can help out. 20:40:35 <TabAtkins> fantasai: We got a message from SVGWG, prompting the discussion. 20:41:16 <TabAtkins> mollydotcom: Main concern with image-fit and content-fit is that we're really not talking about images or content. 20:41:29 <TabAtkins> mollydotcom: It *may* be an image, but it's not traditionally what we call 'content'. 20:41:42 <TabAtkins> mollydotcom: I suggest, for semantic rationale, 'object-fit'. 20:41:54 <TabAtkins> howcome: Steve suggested that over lunch as well. I think it covers the things we're talking about here. 20:42:13 <TabAtkins> mollydotcom: Right, whether it's a video or some SVG or an image or an applet, we can call all those 'object'. 20:42:18 <mjs> does 'object-fit' really add any meaning to 'fit'? 20:42:34 <mjs> pretty much anything can be arguably an 'object' 20:42:41 <TabAtkins> mollydotcom: I have a problem from an educational perspective with using 'image'. 20:42:49 <TabAtkins> mollydotcom: I think 'object' does add meaning to 'fit'. 20:43:11 <TabAtkins> mollydotcom: I don't think it's true that *anything* can be an object. In the markup world, that always refers to a replaced element or similar. 20:43:14 <TabAtkins> fantasai: Agreed. 20:43:36 <mjs> in HTML there is specifically the <object> element, and people would think the property is referring to that 20:43:36 <TabAtkins> smfr: That could also bring up the reference to <object>, which would suggest an exclusion of <video> and similar. 20:43:42 <fantasai> fantasai: I don't think anyone thinks of a paragraph as an object 20:43:51 <TabAtkins> mollydotcom: Yeah, that's possible confusion. 20:43:53 <bradk> object has another meaning in JavaScript too. 20:44:03 <mjs> as a browser implementor, I certainly think of a paragraph as an object 20:44:12 <mjs> HTMLParagraphElement to be specific 20:44:16 <TabAtkins> As an author, do you think of it that way? 20:44:34 <mjs> no idea if authors think of it that way; I would imagine authors would do a lot of scripting would think of every element as an object 20:44:36 <TabAtkins> mollydotcom: To designers, 'image-fit' would say to them that we can't put a java applet in there. 20:44:46 <TabAtkins> mollydotcom: They come at us from a different perspective. 20:44:49 <mjs> if the intent is to capture all replaced elements, then maybe it should be replaced-fit 20:44:53 <TabAtkins> smfr: What's the objection to content-fit? 20:44:59 <TabAtkins> mollydotcom: Too broad. 20:45:05 <bradk> sometimes, when I'm dealing with an element in JS 20:45:37 <TabAtkins> mollydotcom: It seems to me that 'object' is a happier medium. 20:45:38 <fantasai> mollydotcom: And for content authors, content refers to the text content of the document 20:45:55 <mjs> TabAtkins, what does SVG intend to apply it to? everything? 20:45:58 <TabAtkins> object-fit: fill | contain | cover 20:45:58 <fantasai> object-fit: fill | contain | cover 20:46:09 <fantasai> object-position: <bg-pos> 20:46:10 <fantasai> ? 20:46:40 <fantasai> mollydotcom: To me it looks good, and I think I can have that make sense to people 20:46:49 <fantasai> mollydotcom: I think it's much harder to convey this than image-* 20:46:56 <fantasai> howcome: I can live with image-* too, but this is better 20:47:01 <mjs> I really doubt that "object" adequately distinguishes the set of SVG, CSS and HTML constructs it applies to, from the set of things it doesn't apply to 20:47:35 <mjs> TabAtkins, why not just name the property "fit"? does it need a noun? 20:47:38 <fantasai> mollydotcom: We were also talking about scaling 20:47:55 <TabAtkins> howcome: I think 'fit' is just too generic. 20:48:06 <Bert> (We had 'fit' at one point, and decided to change it.) 20:48:24 <TabAtkins> fantasai: It seems like it could be a shorthand for fit-position and something else. 20:48:24 <fantasai> it seems like it would be a shorthand for fit-position and something else 20:48:42 <TabAtkins> mollydotcom: Let's throw it in front of the SVGWG and see what they have to say. 20:49:05 <fantasai> mollydotcom: We talked about fit-scaling 20:49:06 <bradk> I still prefer 'scaling-fit' 20:49:08 <mjs> random proposal: fit-rule: fill | contain | cover, fit as a shorthand for fit-rule and fit-position 20:49:35 <TabAtkins> mollydotcom: Problem with me is the active word of scaling. It's not quite actively scaling. 20:49:43 <ChrisL> rrsagent, here 20:49:43 <RRSAgent> See http://www.w3.org/2010/03/29-CSS-irc#T20-49-43 20:49:53 <TabAtkins> mollydotcom: fit-scale, alone, makes sense to designers and similar people. 20:50:09 <TabAtkins> mollydotcom: if I say you ahve to scale this particular object, that makes more sense to me than saying 'fit-scaling'. 20:50:42 <TabAtkins> mollydotcom: In PS and you want to keep the aspect ratio, you just click "keep aspect ratio" and just change one value, or do it in %s. 20:50:48 <TabAtkins> mollydotcom: And that's a very familiar paradigm. 20:51:00 <TabAtkins> mollydotcom: So I think the word 'scale' is better, but there's vaguery in all of this. 20:51:11 <TabAtkins> mollydotcom: We just have to pick the one that is closest and most understandable to the most people. 20:51:12 <fantasai> fit-scale: fill | cover | contain 20:51:18 <fantasai> fit-position: <bg-pos> 20:51:19 <TabAtkins> howcome: So should we just list the alternatives? 20:51:26 <fantasai> could append <percentage> to fit-scale 20:51:33 <bradk> On a fit-scale of 1-10, I'm about a 5 maybe. 20:51:37 <fantasai> 100% would replace none 20:51:45 <fantasai> fit-scale: fill | cover | contain | <percentage> 20:52:16 <fantasai> mollydotcom: just giving one would preserve aspect ratio 20:52:32 <fantasai> mollydotcom: fit-scale: 100% would be the image its actual size 20:52:39 <fantasai> mollydotcom: fit-scale: 50% scales it down by 1/2 20:53:02 <fantasai> mollydotcom: Could allow 2 values would allow different scaling for different dimensions 20:53:07 <fantasai> howcome writes on the board 20:53:09 <fantasai> fit-scale 20:53:10 <fantasai> fit-position 20:53:10 <TabAtkins> howcome: Are these the two proposals we have? 20:53:13 <fantasai> --- 20:53:15 <fantasai> object-fit 20:53:17 <fantasai> object-position 20:53:20 <fantasai> --- 20:53:22 <fantasai> iage-fit 20:53:24 <fantasai> image-position 20:53:27 <fantasai> s/iage/image/ 20:53:31 <fantasai> --- 20:53:33 <fantasai> aspect-ratio-fit 20:53:37 <fantasai> fit-position 20:53:39 <fantasai> --- 20:53:42 <fantasai> scaling-fit 20:53:44 <fantasai> fit-position 20:54:02 <fantasai> --- 20:54:13 <fantasai> and either of last two with 'fit' in the front 20:55:06 <fantasai> howcome adds numbers 20:55:12 <fantasai> 1. fit-scale / fit-position 20:55:17 <fantasai> 2. object-fit / object-position 20:55:21 <fantasai> 3. image-fit / image-position 20:55:40 <fantasai> 4. aspect-ratio-fit (or fit-aspect-ratio) / fit-position 20:56:24 <mollydotcom> 2 from me 20:56:28 <fantasai> smfr: prefer 3, but 2 is ok 20:56:31 <fantasai> anne: same 20:56:38 <fantasai> steve: 1 or 2, not 3 20:56:59 <fantasai> beth: 2, fallback to 3 if it has to 20:57:02 <fantasai> sylvain: 3, then 2 20:57:12 <fantasai> alex: 3, then 2 20:57:24 <fantasai> alex: for the same reason I prefer mouse over pointer 20:57:26 <fantasai> bert: 2, 3 20:57:32 <fantasai> arron: 2, then 3 20:57:39 <fantasai> fantasai: 1, then 2 20:57:44 <fantasai> dbaron: 2 then 3 20:57:52 <fantasai> tantek: abstain 20:58:05 <fantasai> brad: 2 then 1 20:58:08 <fantasai> tab: 1 then 2 20:58:15 <fantasai> chris: 1 then 2 20:58:19 <fantasai> daniel: 2 then 1 20:58:26 <fantasai> peter: 1 then 2 20:58:33 <fantasai> dsinger: 1 then 2 20:58:48 <fantasai> howcome: 2 then 3 20:59:21 <fantasai> dbaron: 2 was first or second choice from everybody 21:01:07 <fantasai> fantasai: my one concern with 1 is that if you want to ad percentage scaling, it doesn't work with the object-fit name 21:01:20 <fantasai> anne points out that if you made a shorthand with these, the shorthand would be called object 21:01:27 <TabAtkins> s/anne/smfr/ 21:01:34 <mollydotcom> my cat apparently has some opinions about all this, but darned if I can understand her ;) 21:01:42 <TabAtkins> s/s\/anne\/smfr\/// 21:01:55 <bradk> meow-fit 21:02:05 <mollydotcom> She keeps saying it 21:02:19 <ChrisL> but its merely anecdotal 21:02:30 <mollydotcom> We are now the Cat Style Sheet Working Group, apparently 21:02:39 <mollydotcom> haha 21:02:42 <mollydotcom> short paw 21:02:50 <mollydotcom> Anne: you do make a good point 21:02:58 <mollydotcom> no shorthand should be called object IMO 21:03:13 <mollydotcom> is there going to be a real need to do that? 21:03:42 <TabAtkins> smfr: object-fit-scale, object-fit-position 21:03:43 <fantasai> smfr: Could combine them and have object-fit-scale and object-fit-position 21:04:35 <Zakim> -Molly_Holzschlag 21:04:37 <Zakim> -[Apple] 21:04:37 <Zakim> Team_(css)20:36Z has ended 21:04:38 <Zakim> Attendees were [Apple], Molly_Holzschlag 21:04:44 <glazou> mollydotcom: I'll cough for you in the meantime 21:04:54 <mollydotcom> bye folks! 21:05:15 <mollydotcom> @glazou, I hear wine relaxes the bronchial tubes :p 21:05:22 <TabAtkins> fantasai: smfr's suggestion would address the shorthand and make more sense with %s. 21:05:39 <glazou> mollydotcom: I'm not able to have a glass of wine at this time, trust me 21:07:32 <fantasai> TabAtkins: percentages would make a shorthand impossible to parse 21:08:01 <TabAtkins> RESOLVED: use object-fit and object-position for the properties 21:08:26 <fantasai> Topic: Advanced Layout Modules 21:08:31 <dbaron> ScribeNick: fantasai 21:08:42 <fantasai> TabAtkins: So, this is going to be less direct suggestions and more mjy plan of action in the future about what to do 21:09:00 <fantasai> TabAtkins: I'm a Google employee now, and will soon be chrome liaison 21:09:19 <fantasai> TabAtkins: I want to take the layout drafts and turn them into something we wnat to implement and use soon 21:09:29 <fantasai> TabAtkins: Specifically, Template, Flex, Grid, and a few others maybe 21:09:46 <fantasai> TabAtkins: I've been thinking for a while what the underlying abstractions are in the different layout drafts 21:09:55 <fantasai> TabAtkins: and also in the different layout modesl I as an authro want to do 21:10:07 <fantasai> TabAtkins: I would like to combine into one model, but don't think I can quite do that 21:10:16 <fantasai> alexmog: Why do you want to do this? 21:10:29 <fantasai> TabAtkins: Because I as an author want to use them. Because laying out in CSS sucks 21:10:47 <fantasai> alexmog: But you also want one or more browsers to implement 21:10:58 <fantasai> TabAtkins: I'd also hope to implement some of this myself 21:11:17 <fantasai> TabAtkins: So, the first model that layout things will be built on is table layout 21:11:30 <fantasai> TabAtkins: turns out talbe layout is super useful for layouts I've done, for doing things I didn't expect before I started playing with it 21:11:40 <fantasai> TabAtkins: Talbe alyout by itself is good, I like the way it lays out as a grid 21:11:54 <fantasai> TabAtkins: the problem is that it restricts your site markup: you need to put in containers and order things so that it lays out 21:11:59 <fantasai> TabAtkins: which can be bad for accessibility 21:12:02 <fantasai> TabAtkins: Template layout fixes this 21:12:11 <Bert> s/ talbe / table /g 21:12:11 <fantasai> TabAtkins: Once you look into it, it looks just like magic on top of table layout 21:12:24 <fantasai> TabAtkins: So I want to take Template Layout, slightly change it so that it is magic on top of table layout 21:12:41 <fantasai> TabAtkins: That would basically entail setting up the properties so set up a table grid out of pseudo eleents 21:12:55 <fantasai> TabAtkins: and hopefully discussing how content is flowed into the pseudo elements 21:13:04 <fantasai> TabAtkins: hopefully not a significant change in the draft, just conceptual 21:13:14 <fantasai> TabAtkins: Another thing to add would be another table layout model that's sane 21:13:29 <fantasai> TabAtkins: fixed table layout is sane 21:13:41 <fantasai> dbaron: no it's not, it's just nobody uses it so nobody knows how messed up it is 21:14:05 <fantasai> alexmog: Even if I don't understand table layout, I can ...? 21:14:24 <fantasai> dbaron: Another problem with table layout is that putting large things into small cells often doesn't do what you want 21:14:31 <fantasai> dbaron: eg. have one thing wider than viewport 21:14:40 <fantasai> dbaron: makes the whole table wider than the viewport 21:14:49 <fantasai> TabAtkins: might be an artifact of auto layout righ now 21:15:09 <fantasai> TabAtkins: Could consider putting out a new table layout model along with the mathching template model 21:15:28 <fantasai> TabAtkins: ... 21:15:42 <fantasai> dbaron: I removed support for * widths from Gecko because the implementation didnt do much 21:16:07 <fantasai> dbaron: And the HTML4 description of * widths said do what browsers do for percentage widths, and the spec for percentage widths said something else 21:16:26 <fantasai> alexmog: WPF does use table layout internally, and it implements * widths 21:16:55 <fantasai> alexmog: The advantage is that you can put content into any slot into the table 21:17:07 <fantasai> Bert: We could add a third algorithm to table-layout property 21:17:22 <fantasai> TabAtkins: Building off of table then lets you use auto or fixed layout if that happens to be what you want 21:17:35 <fantasai> Bert: That new algorithm would also allow the flex property in that case 21:17:51 <fantasai> Brad: Would you bring that into the table display types, too? 21:18:01 <fantasai> TabAtkins: Yes, if we add it to table-layout 21:18:23 <fantasai> TabAtkins: the only magic in Template would be to create pseudo elements that represent talbe parts and putting the content in there 21:18:31 <fantasai> TabAtkins: I'm going to start working on the drafts for these 21:18:36 <Bert> s/talbe/table/ 21:18:42 <fantasai> TabAtkins: Just wanted to give everyone a heads up 21:19:02 <fantasai> howcome: You have an implementation as template layout, right? 21:19:10 <fantasai> Bert: Yes, 3 impls. One uses same syntax as the draft 21:19:18 <TabAtkins> from alexis deveria 21:19:27 <fantasai> Bert: The other impls are the ones from Cesar, which uses an older syntax 21:19:36 <fantasai> Bert: And there's an impl from Andrew F. which uses another variant syntax 21:19:42 <fantasai> Bert: I like the idea 21:19:51 <fantasai> howcome: We need something like this, we haven't talked aobut htis for years 21:20:12 <fantasai> howcome: what about multicol? 21:20:20 <fantasai> TabAtkins: interact the same way as multicol and tables do now 21:21:01 <fantasai> alexmog: If you are creating a new kind of a grid, that grid could supercede grid positioning 21:21:18 <fantasai> alexmog: you could use that grid to position floats and have them interact with other content 21:21:36 <fantasai> Bert: My template draft has that, the grid is defined by the template grid 21:22:03 <fantasai> howcome confirms that grid units are defined in various drafts 21:22:13 <fantasai> Tantek: what's the general class of use cases that you're going for? 21:22:19 <fantasai> TabAtkins: Overall site layout 21:22:43 <fantasai> TabAtkins: I want to make sure that either htis directly or this plus other stuff is also useful for applications 21:22:51 <fantasai> TabAtkins: e.g. replace Gmail's hacky stuff 21:23:22 <fantasai> Tantek: Traditionally, grid-based layouts are really useful for application UI 21:23:46 <glazou> http://glazman.org/howcome-cupertino/ 21:24:01 <fantasai> Tantek: There are a whole class of applications that are doing ridiculous backflips to do UI 21:24:26 <fantasai> Tantek: Having a model that solves those use cases could cause a renaissance of web applications 21:24:50 <fantasai> TabAtkins: If we can come up with necessary flexibility with grid then building them together would be great .. (?) 21:25:06 <fantasai> Tantek: Consider the use cases together, and consider also the implementors 21:25:16 <fantasai> alexmog: I'm not against unifying the grid 21:25:37 <fantasai> alexmog: but I don't want to have super-complicated interactions across multiple models 21:25:42 <fantasai> dbaron: I don't think gmail is that gridlike 21:26:07 <fantasai> dbaron: The layouts tend to be more about taking one piece of UI and pushing it against the edge of the space, and then having the rest of the area taken up by the rest of the app 21:26:22 <fantasai> dbaron: You have menus and toolbars and sidebars 21:26:28 <fantasai> dbaron: In all these cases you're taking the rectangle 21:26:50 <fantasai> dbaron: taking up one part of it with a UI element, and then filling the remaining space 21:27:24 <fantasai> Tantek: Check out iPhone apps, they have very different UI models 21:27:50 <fantasai> howcome: We havent' really been able to exploit our table model because it hasn't been widely implemented 21:28:18 <fantasai> ... 21:28:43 <fantasai> discussion of WebKit-specific apps and table layout 21:29:14 <fantasai> Tantek: Interface builders have lots of interesting ways of laying out UI elements. It makes sense 21:29:22 <fantasai> snap-to-grid 21:29:25 <fantasai> pin one object to anther object 21:29:32 <fantasai> Tantek: just spend 15 min with interface-builder 21:30:10 <fantasai> howcome: Do we consider apps to be the driving force or documents? 21:30:17 <fantasai> fantasai: Both. We need to handle both. 21:30:55 <fantasai> Tab talks about grids defined by templates and tables and grids defined by content 21:31:37 <fantasai> alexmog: The grid I imagine is independent of content. You either place stuff on the gridlines, or snap to them 21:31:46 <fantasai> alexmog: The only thing you need to add is size to fit 21:31:56 <fantasai> alexmog: perhaps horizontal lines should fit to content 21:32:03 <fantasai> alexmog: that switches grid from trivial to complicated 21:32:13 <fantasai> Tantek: grids aren't just for UIs either 21:32:32 <fantasai> Tantek: Things like baseline-alignment across the page is super-hard to do today 21:32:42 <fantasai> Tantek: Grid would presumably solve that 21:32:47 <fantasai> TabAtkins: You could set up a grid with those line 21:32:56 <fantasai> TabAtkins: and then with some other mechanism tell text to line up to that 21:33:11 <fantasai> TabAtkins: You would need separate grids 21:33:58 <fantasai> TabAtkins: Whether layout grid + baseline grid is sufficient or we need author-named grids, not sure 21:34:04 <fantasai> fantasai thinks we should have named grids 21:34:31 <fantasai> Bert: Anne ask on IRC, so do you have to write the table module first if you are going to do this? 21:34:34 <tantek> tantek has joined #css 21:34:45 <szilles> szilles has joined #css 21:35:09 <fantasai> Anne: What does 'width' mean, what does 'height' mean 21:35:29 <fantasai> TabAtkins: Don't have to define that, can just say "do what you do currently" 21:36:09 <fantasai> TabAtkins: and build a new sane table model 21:36:14 <fantasai> alexmog would like a sane table model 21:36:50 <fantasai> Anne: I think we might get a bid of redundancy because only a few people know what the current one covers and what algorithms are defined that we might want to reuse 21:37:20 <fantasai> Steve: One requirement that I have is that I be able to describe the area into which thigns flow separately from the stuff that's flowing into it. 21:37:53 <fantasai> Steve: Right now table is entirely wound around the content that's in the table. I don't want that 21:38:12 <fantasai> Steve: I want to describe whatever it is without having the content 21:38:19 <fantasai> several, supported by Template module 21:38:29 <fantasai> smfr: Can you split content up between boxes? 21:38:41 <fantasai> TabAtkins: Not currently. No non-rectangular regions and no disconnectd regions 21:38:51 <fantasai> TabAtkins: would like to add later 21:39:17 <fantasai> howcome: Did you see the very first draft from 1997? 21:39:28 <fantasai> TabAtkins: No, just seen since Advanced Layout just before it got split into Template 21:39:31 <Bert> http://www.w3.org/TR/NOTE-layout 21:40:00 <dbaron> As far as defining table layout, http://dbaron.org/css/intrinsic/ and a spec that Markus was working on both define significant pieces of the width calculation 21:40:17 <dbaron> I actually think I like the height calculation that IE6 does more than what Gecko does. 21:40:53 <fantasai> TabAtkins: I'm not doing box-to-box flow in order to be conservative in level 3 21:41:11 <fantasai> TabAtkins: I think it would still be useful 21:41:17 <fantasai> ... printing ... 21:41:41 <fantasai> TabAtkins: Printing does bring up other issues. It does matter. 21:42:40 <fantasai> non-rectangular layout is difficult if multiple parts have flexible height 21:42:56 <fantasai> TabAtkins: Next layout topic 21:42:59 <fantasai> TabAtkins: Also related to table layout 21:43:11 <fantasai> TabAtkins: In my current use of tables, I often want to set up a ton of things in a grid 21:43:18 <fantasai> TabAtkins: but in my markup they're just a linear progression 21:43:32 <fantasai> TabAtkins: and I want them to fill through and automatically find the right number of rows 21:43:45 <fantasai> TabAtkins: so like normal table layout except without set rows 21:43:55 <fantasai> TabAtkins: either by filling the width of a space, or specifying a number of columns 21:44:03 <fantasai> howcome: Another idea is columns first 21:44:18 <fantasai> TabAtkins: also want to determine direction of cell flow 21:45:11 <fantasai> TabAtkins: When you loosen constraints on tables, then tend to become more similar to flexbox 21:45:27 <fantasai> TabAtkins: So does anyone theoretically object to these additions to table stuff? 21:45:44 <bradk> block-progression-direction to flow vertically, possibly 21:45:45 <fantasai> * flowing cells into rows without row containers 21:45:56 <fantasai> * cell progression direction: changin direction, changing itnto columns-first 21:46:39 <fantasai> dbaron: If you switching block-progression direction, you'll also switch the width and height algorithms 21:47:02 <fantasai> dbaron: Do you mean cell-progression-direction as a subfeature of the cell flow idea? 21:47:05 <fantasai> TabAtkins doesn't knowe 21:47:14 <fantasai> howcome complains about being forced to change markup to do layouts 21:47:52 <fantasai> howcome wants a property for det whether talbe is column-primary or row-primary 21:48:11 <fantasai> dbaron: One thing I liked about table height algorithms in IE6 is that they were much more similar to the width algorithms 21:48:59 <fantasai> howcome: You also had an idea about saying which cells you want to start a new row 21:49:15 <fantasai> TabAtkins: If you just want to fill to a specific width, then that doesn't work 21:49:20 <fantasai> TabAtkins: but for other cases it works 21:49:28 <fantasai> TabAtkins: you can use :nth-child to do a specific number of rows 21:50:27 <fantasai> fantasai: A problem with fill to a width is that you layou out your table, splitting into say 4 cols 21:50:38 <fantasai> fantasai: but then you find a really big cell and find you can only fit 2 cols 21:50:45 <fantasai> fantasai: then you have to go back and relayout the whole table 21:50:53 <fantasai> fantasai: (which is already a 2-3 pass algorithm) 21:51:01 <fantasai> TabAtkins: Ok, maybe that's not a good idea then. Dont' like iterative layouts 21:51:31 <bradk> container has 'table-flow: rows(4)' to auto flow table-cells vertically into 4 rows, with as many columns as it takes. 21:51:44 <fantasai> TabAtkins: you might also want to flow into multiple rows, but not line up column-wise 21:51:54 <fantasai> TabAtkins: They flow and wrap around, and each row is height-equalized 21:52:05 <fantasai> TabAtkins: can fake it with inline-block, but doesn't handle all cases 21:52:16 <fantasai> TabAtkins: Can't justify to exactly fit the row 21:52:28 <Bert> (We did have a tabulation proposal some time ago. It was dropped when leaders() could do 80% of that.) 21:52:35 <fantasai> ... 21:52:41 <fantasai> alexmog: That's a multi-line flexbox 21:52:48 <fantasai> http://fantasai.inkedblade.net/style/specs/tabs/ 21:53:23 <fantasai> TabAtkins: Almost 21:53:37 <fantasai> TabAtkins: box-pack-justify and a flexbox automatically sets all margins to be equivalent 21:53:46 <fantasai> TabAtkins: but if you want finer control voer that, you can't express it in those terms 21:53:51 <fantasai> TabAtkins: you can't set flex on margins 21:53:54 <Bert> (Different kind of "tabs" :-) ) 21:54:19 <fantasai> TabAtkins: I think that's only place where flexbox is lacking.. it lays out from the container's perspective but not the childrens 21:54:22 <fantasai> alexmog: that's the point 21:54:45 <fantasai> alexmog: Everywhere else in CSS every element has its own opinion on how it wants to be laid out 21:55:10 <fantasai> alexmog: Flexbox allows introducing simple or different layout algorithms because it doesn't interfere with anything else in the system 21:55:24 <fantasai> alexmog: The layout is totally governed by the container 21:55:34 <fantasai> alexmog: that's why it's a clean, easy-to-implement, easy-to-use spec 21:55:47 <fantasai> alexmog: If you let it allows margin collapsing and everything else that happens in CSS, then you create a monster 21:56:05 <fantasai> TabAtkins: I would like to dive down and try to design with flexbox, and then bring back anything I find that's insufficient 21:56:15 <fantasai> TabAtkins: But I'm willing to put htat off and do experimentation 21:56:23 <fantasai> dbaron: I think box-pack is pretty rarely used 21:56:25 <fantasai> in xul 21:56:32 <fantasai> dbaron: What's used instead is having more nested boxes 21:56:40 <fantasai> TabAtkins: I do something imilar to flexbox using table layout 21:57:00 <fantasai> TabAtkins: For a horizontal nav, I'll use auto or fixed table layout on a <ul> 21:57:13 <fantasai> TabAtkins: to either space out the links, or the space between the links 21:57:30 <fantasai> TabAtkins: in the first case, the white space between them changes, but their centers are spaced evenly 21:57:43 <fantasai> TabAtkins: auto layout almnost equalizes the spaces in between 21:59:01 <fantasai> Steve: You might want to wrap borders around that white space 21:59:14 <fantasai> fantasai: You might want to flex the borders, or you might want to flex the padding 21:59:29 <fantasai> TabAtkins: I handle that by either styling the <li> or the <a> inside it 22:00:04 <fantasai> Steve: There's another piece of this. If had a set of inline-blocks and turned jsutification on 22:00:14 <fantasai> Steve: The only place it could put space would be in between the inline-blocks 22:00:28 <fantasai> Steve: The catch is, you really want some space on the ends to make it look right 22:01:37 <fantasai> Steve: I'm asking you to think about it as justification 22:02:01 <fantasai> Steve: There may be other places you'd like justification 22:03:20 <fantasai> fantasai describes a catalog use case 22:03:35 <fantasai> TabAtkins: One thing I want to do that I don't have much experience with is what web apps need 22:03:44 <fantasai> TabAtkins: Because I'm experienced with web sites, but not web apps 22:04:10 <Bert> (There are also Media Queries to deal with different numbers of columns.) 22:04:32 <fantasai> Tab shows an example of a site he designed 22:04:39 <fantasai> TabAtkins: Here's a bunch of questions. 22:04:44 <fantasai> TabAtkins: I'm flowing this into three rows 22:05:02 <fantasai> TabAtkins: Right now I can only do with inline-blocks, but that means I can't equalize their heights 22:05:36 <fantasai> Steve: What's the difference between flexbox and flowing tables? 22:05:44 <fantasai> TabAtkins: Not having a grid in both directions 22:05:57 <fantasai> Steve: If I had something I could do this flowing in, having properties that could turn it into the grid... 22:06:15 <fantasai> Steve: I guess what I'm trying to say is that I see less similarity to tables for flowing tables than to flexbox 22:06:22 <fantasai> Steve: I would expect the flowing cells more in the flexbox world 22:06:27 <fantasai> Steve: with additional constraints 22:06:43 <fantasai> TabAtkins: That's why I said there seems to be a point where tables and flexbox come to gether 22:06:59 <fantasai> TabAtkins: As you add more constraints to flexbox and reduce constraints in tables they get more similar 22:07:18 <fantasai> TabAtkins: We could maybe add more possible constraints to flexbox, and have it look more like a table 22:07:45 <fantasai> TabAtkins: instead of going from tables towards flexbox 22:07:57 <fantasai> Bert: Question about your grid of questions 22:08:34 <fantasai> Bert: I would bet that most people fill top-to-bottom, whereas you fill horizontally first 22:08:54 <fantasai> Tab explains this is because that was the only way he could hack it up into a grid using existing features 22:10:20 <sylvaing> sylvaing has joined #css 22:10:24 <anne> btw, live style sheet editing: http://annevankesteren.nl/test/contenteditable-style.htm 22:11:16 <fantasai> Tab explains also why multicol + snap-to-grid wouldn't work: a large item would throw off the alignment 22:12:20 <fantasai> Steve: I have a similar use case of parallel translations 22:12:32 <fantasai> howcome: That's another good use case for column-major instead of column-major 22:12:39 <fantasai> s/column/row/ 22:13:34 <fantasai> TabAtkins: You'd run into the iterative layout problem fantasai pointed out 22:13:46 <fantasai> howcome: Have you looked at line-stacking-strategy? 22:13:54 <howcome> http://www.w3.org/TR/css3-linebox/#LineStacking 22:13:55 <fantasai> TabAtkins: Not recently 22:14:06 <fantasai> TabAtkins: One criticism is that it doesn't apply across blocks 22:15:13 <fantasai> ... 22:15:23 <fantasai> TabAtkins: Can you set line-stacking-strategy on boxy and have it apply to everything? 22:15:32 <fantasai> ?: It's never been implemented 22:15:40 <fantasai> Steve: InDesign in Japan does that 22:15:44 <fantasai> (just not in CSS) 22:16:01 <fantasai> howcome: It may not be the solution, but is something you should take into account 22:16:17 <fantasai> TabAtkins: I think there's an interesting intersection of table, multicol, flexbox, etc 22:16:36 <fantasai> howcome: I think it's great. Come with your youthful energy and work on this. 22:16:50 <fantasai> Steve: Something to be said for people solving problems by not being aware they're unsolveable 22:32:58 <smfr> smfr has joined #css 22:36:06 <bradk> bradk has joined #css 22:36:20 <mjs> mjs has joined #css 22:37:46 <Zakim> Zakim has left #CSS 22:38:20 <plinss_> plinss_ has joined #css 22:44:53 <alexmog> alexmog has joined #css 22:45:36 <TabAtkins_> TabAtkins_ has joined #css 22:54:42 <szilles> szilles has joined #css 22:54:44 <fantasai> dbaron: So the way widths work, you have some container 22:55:14 <fantasai> dbaron: THen you have something inside that has margin border padding, then something inside that 22:55:21 <fantasai> dbaron: You have computation going in from the edge 22:55:36 <fantasai> dbaron: What we've said in the past is that percentage heights are just auto if the container is auto 22:55:47 <fantasai> dbaron: But people want percentage heights to just work 22:55:55 <fantasai> dbaron: There are several places where this woudl be more useful 22:56:01 <fantasai> dbaron: One is multicol 22:56:12 <fantasai> dbaron: You usually want to scroll horizontally off the screen instead of vertically 22:56:27 <fantasai> dbaron: My idea is that, as we're doing layout, we keep an idea of what the available width is 22:57:00 <fantasai> dbaron: You start with the width of the viewport, subtract out borderpadding, and just keep subtracting in, possibly replacing with a fixed width 22:57:25 <fantasai> dbaron: If we did this for height as well, percentages could be useful 22:58:10 <fantasai> dbaron: It's not perfect, but it gives you a default in cases where you need a good default 22:58:25 <fantasai> alexmog: another use case is block progression direction changes 22:58:32 <fantasai> dbaron: And there might be some usec ases for doing this with flexbox 22:58:43 <TabAtkins> also text direction changes (vertical text vs horiz text) 22:58:54 <fantasai> dbaron: I'm not sure what we're doing with this, but I might try adding it under a vendor prefix in Mozilla. 22:59:15 <fantasai> TabAtkins: Would it be possible to implement this as how actual percentages work? 22:59:23 <fantasai> dbaron: Probably too late 22:59:31 <fantasai> TabAtkins: as a different unit or something? 22:59:54 <fantasai> dbaron: maybe 23:00:00 <fantasai> dbaron: We could use this for height: fill 23:00:04 <fantasai> dbaron: and maybe even height: content-fit 23:01:05 <fantasai> dbaron: This woudl only get you the effect of 100% 23:01:27 <fantasai> TabAtkins: you could expose fill through calc() and then you can get precentages that way 23:03:20 <fantasai> dbaron: A good use case would be max-height: fill 23:03:24 <fantasai> dbaron: for columns 23:03:32 <fantasai> dbaron: So you fill the screen, and then start growing out 23:04:18 <fantasai> TabAtkins: max-height: 100vh would also solve that case, right? 23:04:31 <fantasai> dbaron: Assuming your columns are not in something overflow: scroll 23:05:27 <fantasai> people seem to like this for height: fill 23:05:45 <fantasai> Topic: jd's followup to issue-156 23:06:22 <plinss_> http://lists.w3.org/Archives/Public/www-style/2010Mar/0538.html 23:09:19 <plh-dinner> plh-dinner has joined #css 23:09:43 <fantasai> discussion about the proposal 23:10:14 <fantasai> fantasai: "Once the font family's weights are mapped onto the CSS scale, missing weights are selected as follows:" 23:11:54 <fantasai> use that to replace the introductory sentence, then add jd's bulletted list 23:12:32 <fantasai> RESOLUTION: jdaggett + fantasai proposal above accepted 23:12:47 <howcome> http://dev.w3.org/csswg/css3-gcpm/#setting-named-strings-the-string-set-pro 23:12:51 <fantasai> Topic: GCPM 23:13:01 <fantasai> howcome: I'd like to publish another a WD 23:13:18 <fantasai> howcome: wrt env() function 23:13:32 <fantasai> howcome: There was a question of how to get the date and time in the locale of the user 23:13:44 <fantasai> howcome: There seems to be a widely-available strftime function 23:14:21 <fantasai> dbaron: There's also JavaScript functions that have this functionality 23:14:28 <fantasai> dbaron: I'm not sure if it's exactly compatible 23:15:22 <dbaron> https://developer.mozilla.org/en/Core_JavaScript_1.5_Reference/Global_Objects/Date/toLocaleFormat is a Gecko extension, not part of ECMA 23:16:01 <fantasai> glazou: fwiw, toLocalString uses the language of the browser, not the language of the system 23:16:12 <fantasai> dbaron disagrees 23:17:51 <fantasai> Tantek and Steve want to format date and time 23:17:59 <fantasai> howcome tries to explain that it's not the point of the feature 23:18:11 <fantasai> dbaron: Some strftime things are local-sensitive and some are not 23:18:27 <fantasai> Tantek: Your only choice in howcome's draft is to use the locale-specific version 23:18:47 <fantasai> Tantek: I prefer if the env() would return in ISO values 23:18:55 <fantasai> Steve: I would too, but i"m not sure it's as useful 23:18:59 <fantasai> Tantek: with hyphens 23:19:18 <fantasai> howcome: So 2010-03-30 23:20:09 <fantasai> bradk: Wasn't the point to do what the browser does now, but be able to style it further? 23:21:52 <fantasai> Steve: I don't mind publishing as long as this is marked as an issue 23:21:59 <fantasai> Tantek: You should start with something universal and expand from there 23:23:04 <fantasai> bradk: I don't think it's bad. There's a reason why browsers print the local-specific version. It's not our job to educate the world on universal time formats 23:23:27 <fantasai> fantasai: You could call it localtime so that you can add other things later 23:23:36 <fantasai> howcome: So local-time and local-date 23:24:40 <fantasai> howcome: what if I want both? 23:25:32 <fantasai> Tantek: local-date-time 23:25:52 <ChrisL> rrsagent, here 23:25:52 <RRSAgent> See http://www.w3.org/2010/03/29-CSS-irc#T23-25-52 23:26:08 <fantasai> howcome: Simon proposed to say that border-clip* should go into borders and backgrounds 23:26:18 <tantek> my personal preference would be for ordinal-date (YYYY-DDD) http://en.wikipedia.org/wiki/ISO_8601#Ordinal_dates 23:26:30 <tantek> and on that note - I have to depart. thanks everyone! 23:26:57 <fantasai> fantasai: We agreed to add this for CSS4 Backgrounds and Borders 23:28:36 <fantasai> discussion of where these features belong 23:28:48 <fantasai> fantasai volunteers to pull this into css4-backgrounds 23:30:07 <fantasai> ACTION: fantasai put border-clip into css4-backgrounds 23:30:07 <trackbot> Created ACTION-222 - Put border-clip into css4-backgrounds [on Elika Etemad - due 2010-04-07]. 23:30:50 <fantasai> howcome: Can we agree in principle in publishing GCPM as WD? 23:30:53 <fantasai> no objections 23:31:07 <fantasai> TabAtkins suggests removing repeat 23:31:18 <szilles> szilles has joined #css 23:31:28 <smfr> i also think that hyphenation should move 23:31:30 <fantasai> I suggested it originally, and I think it isn't needed 23:31:32 <fantasai> er 23:31:34 <fantasai> that was Tab 23:31:57 <fantasai> TabAtkins: Also, percentages should refer to the height for vertical borders 23:33:02 <fantasai> Peter: ok, I think we're done 23:33:26 <fantasai> http://lists.w3.org/Archives/Public/www-style/2010Mar/0551.html 23:33:51 <fantasai> Issue 107 - anonymous table boxes proposal is done, bzbarsky has approved this proposal, and it's ready for wg discussion 23:33:57 <fantasai> please review so we can discuss it 23:34:34 <fantasai> the wrapping on that sucks 23:34:41 <fantasai> I will resend from a real email client when I get home 23:36:57 <fantasai> Meeting closed. 23:37:02 <smfr> smfr has joined #css 23:41:33 <arronei> arronei has joined #CSS 23:41:46 <smfr> smfr has joined #css 00:10:38 <glazou> glazou has joined #css 00:25:33 <anne> anne has joined #CSS 00:27:11 <dino_> dino_ has joined #css 00:29:38 <dino> dino has joined #css 00:37:44 <smfr> smfr has left #css 00:39:32 <dethbakin> dethbakin has joined #css 00:58:55 <TabAtkins> TabAtkins has joined #css 01:02:36 <TabAtkins> TabAtkins has joined #css 01:04:59 <dbaron> dbaron has joined #css 01:10:55 <karl> karl has joined #CSS 01:16:21 <tantek> tantek has joined #css 01:16:57 <dino> dino has joined #css 01:20:09 <tantek> hey dino - good to see you yesterday 02:20:53 <miketaylr> miketaylr has joined #css 03:41:50 <Lachy> Lachy has joined #css 03:49:18 <mollydotcom> mollydotcom has left #css 04:08:32 <dino> dino has joined #css 04:09:16 <miketaylr> miketaylr has joined #css 04:29:44 <dbaron> RRSAgent, bye 04:29:44 <RRSAgent> I see 14 open action items saved in http://www.w3.org/2010/03/29-CSS-actions.rdf : 04:29:44 <RRSAgent> ACTION: dbaron write proposal for IE-Opera behavior for issue 26 [1] 04:29:44 <RRSAgent> recorded in http://www.w3.org/2010/03/29-CSS-irc#T21-30-31 04:29:44 <RRSAgent> ACTION: Chris Find tests for media queries and check into test repository [2] 04:29:44 <RRSAgent> recorded in http://www.w3.org/2010/03/29-CSS-irc#T23-05-59 04:29:44 <RRSAgent> ACTION: clilley Find tests for media queries and check into test repository [3] 04:29:44 <RRSAgent> recorded in http://www.w3.org/2010/03/29-CSS-irc#T23-06-28 04:29:44 <RRSAgent> ACTION: glazou make namespaces implementation reports [4] 04:29:44 <RRSAgent> recorded in http://www.w3.org/2010/03/29-CSS-irc#T23-12-52 04:29:44 <RRSAgent> ACTION: howcome to produce alternate proposal for handling animation and transition together [5] 04:29:44 <RRSAgent> recorded in http://www.w3.org/2010/03/29-CSS-irc#T18-40-40 04:29:44 <RRSAgent> ACTION: dean and smfr to produce issues list for Transitions and Animations, including comments from dbaron and howcome. [6] 04:29:44 <RRSAgent> recorded in http://www.w3.org/2010/03/29-CSS-irc#T18-44-50 04:29:44 <RRSAgent> ACTION: SteveZ Propose changes to character-transform to address above concerns [7] 04:29:44 <RRSAgent> recorded in http://www.w3.org/2010/03/29-CSS-irc#T21-06-10 04:29:44 <RRSAgent> ACTION: clilley Discuss font-family syntax with SVGWG [8] 04:29:44 <RRSAgent> recorded in http://www.w3.org/2010/03/29-CSS-irc#T23-06-45 04:29:44 <RRSAgent> ACTION: fantasai move issue to css3-lists [9] 04:29:44 <RRSAgent> recorded in http://www.w3.org/2010/03/29-CSS-irc#T23-33-27 04:29:44 <RRSAgent> ACTION: Tab Rewrite proposal for Issue 161 [10] 04:29:44 <RRSAgent> recorded in http://www.w3.org/2010/03/29-CSS-irc#T23-48-04 04:29:44 <RRSAgent> ACTION: anne to set up wiki page to list CSSOM constants for coordination [11] 04:29:44 <RRSAgent> recorded in http://www.w3.org/2010/03/29-CSS-irc#T16-55-11 04:29:44 <RRSAgent> ACTION: anne to produce concrete examples of complex properties and put it on the list [12] 04:29:44 <RRSAgent> recorded in http://www.w3.org/2010/03/29-CSS-irc#T18-14-07 04:29:44 <RRSAgent> ACTION: clilley to rewrite the paragraph in CSS color concerning gamuts and clipping [13] 04:29:44 <RRSAgent> recorded in http://www.w3.org/2010/03/29-CSS-irc#T18-35-10 04:29:44 <RRSAgent> ACTION: fantasai put border-clip into css4-backgrounds [14] 04:29:44 <RRSAgent> recorded in http://www.w3.org/2010/03/29-CSS-irc#T23-30-07