IRC log of CSS on 2010-03-29

Timestamps are in UTC.

18:15:52 [RRSAgent]
RRSAgent has joined #CSS
18:15:52 [RRSAgent]
logging to http://www.w3.org/2010/03/29-CSS-irc
18:16:37 [TabAtkins]
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 [ChrisL]
rrsagent, this meeting spans midnight
18:17:00 [TabAtkins]
Bert: I proposed some time ago to create a 3rd type of block that would allow @page.
18:17:03 [dbaron]
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 [TabAtkins]
Bert: But I think people wouldn't want that.
18:17:15 [dbaron]
(that was the list of who was present earlier; Dean Jackson and David Singer are not currently present)
18:18:01 [TabAtkins]
anne: That wouldn't solve the earlier problem, the background wouldn't be green.
18:18:08 [TabAtkins]
Bert: Right, but it would let you do what @page wants.
18:18:29 [TabAtkins]
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 [TabAtkins]
Bert: But that's inconsistent. Any other unknown token would throw away until the next semicolon.
18:19:19 [TabAtkins]
szilles: @ already has the role of being special.
18:19:52 [TabAtkins]
glazou: I think we agree that if an @ occurs inside a value isn't an @ rule.
18:20:08 [TabAtkins]
glazou: Frex, if the first token inside the brace is an @ token, we'd like it to be an @ rule.
18:20:23 [TabAtkins]
Bert: If that's a change, we can't do it.
18:20:33 [TabAtkins]
glazou: It's something new that wouldn't break anything.
18:20:36 [dbaron]
dbaron has joined #css
18:20:38 [TabAtkins]
Bert: It's in the spec.
18:20:58 [TabAtkins]
howcome: This is a change in the eternal grammar.
18:21:12 [TabAtkins]
anne: It doesn't change valid stylesheets. I think it's fine.
18:21:37 [TabAtkins]
Bert: We have the error-recovery rules for consistency; you're changing the rules, so you're losing consistency.
18:22:08 [TabAtkins]
glazou: We are fighting about extensibility all the time.
18:22:25 [TabAtkins]
Bert: Things like adding to a shorthand is different, it fits in the grammar.
18:22:48 [TabAtkins]
Bert: Show me a place in CSS3 that is incompatible with the forward-compatible rules.
18:22:52 [TabAtkins]
plinss: @page
18:23:22 [TabAtkins]
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 [TabAtkins]
howcome: This is a change in the eternal grammar, but we don't really have a great use-case.
18:24:01 [TabAtkins]
howcome: A green background isn't a good use-case.
18:24:18 [TabAtkins]
howcome: It's interoperable today, I'm not sure we should change it.
18:24:47 [TabAtkins]
howcome: We're suggesting this change to get a generic extension mechanism.
18:24:58 [TabAtkins]
plinss: We have @page, which allows intermingling of @ rules in a declaration block.
18:25:12 [TabAtkins]
plinss: If it's *only* valid here, with special rules and special error recovery, that's very surprising.
18:25:31 [TabAtkins]
howcome: Do we allow @page at the place where we're talking about?
18:25:45 [alexmog]
adding a semicolon to the use case makes it green, interoparably: body { @foo {}; background: green; }
18:25:48 [TabAtkins]
plinss: No, not right now. But @page acts like a declaration block, and allows more @ rules in it.
18:26:33 [TabAtkins]
glazou: [gives an example showing @page]
18:26:36 [fantasai]
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 [TabAtkins]
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]
szilles has joined #css
18:27:42 [TabAtkins]
glazou: But if you have @page{ @foo {} background: green; }, the background is thrown away. That's very surprising.
18:28:34 [TabAtkins]
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 [TabAtkins]
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 [dbaron]
... never mind what I said
18:29:29 [TabAtkins]
szilles: What anne just pointed out, if we have a single recovery mechanism, CSSOM can have a generic recovery mechanism.
18:29:46 [TabAtkins]
glazou: Non-generic means one parsing impl for @page, and another for other @ rules.
18:29:50 [fantasai]
We have different parsing of @keywords in different parts of the style sheet with or without the change we're proposing.
18:29:50 [TabAtkins]
glazou: That's ugly.
18:30:03 [fantasai]
For example, @keyword inside a declaration is still ignored as an invalid token
18:30:17 [fantasai]
However, having different parsing rules within a declaration block
18:30:26 [fantasai]
depending on whether the declaraiton block is inside @page or elsewhere,
18:30:28 [fantasai]
that is confusing
18:30:34 [TabAtkins]
alexmog: I'm agreeing with what Bert is saying. I'm not seeing use-cases, but we have interop against it.
18:30:37 [fantasai]
and it is a burden on implementors to implement two different types of error-recovery
18:30:49 [anne]
advantages: 1) consistent rules for authors 2) one code path for implementors
18:30:55 [TabAtkins]
alexmog: We'll have syntax that is ignored in older browsers but paid attention to in newer browsers.
18:31:15 [TabAtkins]
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 [TabAtkins]
anne: Advantages is consistent rules for authors, and implementors.
18:32:26 [TabAtkins]
alexmog: How much time until browsers have changed sufficiently to allow it?
18:32:48 [TabAtkins]
TabAtkins: No more time than it would take for any new @ rule to be usable.
18:33:25 [TabAtkins]
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 [TabAtkins]
anne: But can't it sometimes be a start of a selector then?
18:33:43 [TabAtkins]
fantasai: No.
18:34:33 [TabAtkins]
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 [TabAtkins]
anne: IE "@foo {}; body { background: green; }" kills the body block.
18:35:02 [TabAtkins]
Bert: Oh, no, not ; after everything.
18:35:16 [alexmog]
alexmog has joined #css
18:35:41 [TabAtkins]
anne: I think we can just recommend that authors put the @ blocks at the end of the declaration block.
18:36:17 [TabAtkins]
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 [TabAtkins]
Bert: I think we made a mistake on @page, not in the grammar.
18:36:51 [TabAtkins]
plinss: I think we made a mistake in the grammar, instead.
18:37:29 [TabAtkins]
fantasai: I think you can't stick an @ rule without braces is invalid inside a declaration block in the core grammar.
18:37:45 [TabAtkins]
fantasai: We have some options. We could do nothing, which means no @ rules inside declaration blocks ever.
18:37:58 [TabAtkins]
fantasai: And then just have Paged Media declare that @ rules have to be at the end.
18:38:22 [TabAtkins]
plinss: The problem is that the longer we put it out, the more entrenched we'll get.
18:38:41 [TabAtkins]
Bert: Not expensive? It's been in the spec for years!
18:38:56 [TabAtkins]
anne: What kind of implementations are you thinking of?
18:39:05 [TabAtkins]
Bert: TVs, etc.
18:39:28 [TabAtkins]
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 [TabAtkins]
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 [TabAtkins]
anne: In a few years we'll have an upgraded set of browsers.
18:41:04 [TabAtkins]
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 [TabAtkins]
Bert: So let's just put them at the end.
18:41:14 [TabAtkins]
fantasai: It's still invalid by the grammar.
18:41:51 [TabAtkins]
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 [TabAtkins]
howcome: We should have a very good reason to do it, and I haven't seen that reason.
18:42:42 [TabAtkins]
szilles: It simplifies the CSSOM model, for one. It simplifies parsing for CSS. It simplifies parsing for authors.
18:43:04 [alexmog]
alexmog has joined #css
18:43:48 [TabAtkins]
@mixin(border-rules)(n) { -moz-border-radius: n; -webkit-border-radius: n; border-radius: n; } div{ @mixin(border-rule, 8px) }
18:44:24 [TabAtkins]
Bert: Why do you need an @rule in the one place where it's not allowed?
18:44:45 [TabAtkins]
plinss: Because @rule already has rules for swallowing things to the end of a block.
18:44:58 [TabAtkins]
glazou: If you remember the time before CSS2, we didn't have @page.
18:45:24 [TabAtkins]
glazou: Declaration were *only* for style rules. When we came up for @page, we suddenly had a new place for declarations.
18:45:38 [TabAtkins]
glazou: We want to be able to reuse an existing construct in the same way.
18:46:01 [TabAtkins]
glazou: It would open up a new type of contributions for authors that we can't usually do.
18:46:47 [TabAtkins]
Bert: Imagine changing XML.
18:46:56 [TabAtkins]
glazou: We did that when we added @media.
18:46:59 [TabAtkins]
Bert: That in 1998.
18:48:08 [TabAtkins]
szilles: I recommend the chairs take a straw poll.
18:48:52 [TabAtkins]
anne: And the options are 1) special handling of @page, or 2) generic handling?
18:50:22 [anne]
... and 3) require at-rules at the end for @page
18:50:24 [TabAtkins]
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 [TabAtkins]
Bert: 3rd proposal, which has no chance, is to change Paged Media.
18:51:44 [TabAtkins]
s/3rd/4th/
18:51:57 [TabAtkins]
Bert: And pull out @margin rules from the @page blocks.
18:52:15 [TabAtkins]
fantasai: They should have probably been outside from the beginning, but right now we might as well remove them.
18:52:21 [TabAtkins]
howcome: Where would you put them if they were outside?
18:52:26 [ChrisL]
ChrisL has joined #css
18:52:48 [ChrisL]
CSS the Eternal Temple http://i40.tinypic.com/2nlwrjn.jpg
18:52:59 [TabAtkins]
howcome: [illustrates the change]
18:53:05 [Bert]
(One proposed change is in 13.2 say:... followed by a block of declarations <ins>and at-rules</ins>.)
18:53:15 [TabAtkins]
fantasai: Yeah, but we've got multiple implementations in printers, and so it can't be changed now.
18:55:01 [TabAtkins]
plinss: What's the point of putting @ at the end? It seems like an arbitrary place.
18:55:15 [TabAtkins]
fantasai: It makes it clearer how inheritance works.
18:56:00 [TabAtkins]
howcome: So how do we deal with @page containing @top-left and such?
18:56:10 [TabAtkins]
Bert: Right now, we don't. It's just invalid.
18:56:23 [TabAtkins]
Bert: We could create a special thing, not a declaration block, that would allow it.
18:57:00 [TabAtkins]
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 [TabAtkins]
plinss: It doesn't say we only do this based on where it was.
18:57:25 [TabAtkins]
Bert: Right, but we discussed that it should behave that way.
18:57:39 [TabAtkins]
plinss: Please show me in the spec where it says it should behave the way you say it shoudl behave.
18:57:44 [TabAtkins]
Bert: The two points above that.
18:57:58 [TabAtkins]
Bert: The question is only if there is an exception if the @ keyword appears right after a semicolon.
18:58:11 [TabAtkins]
dbaron: We don't specify what happens when the formal grammar disagrees with the prose.
18:58:27 [TabAtkins]
plinss: But the formal grammar doesn't define the recovery rules, only the prose does.
18:59:26 [dbaron]
dbaron: we usually go with whatever's more specific
18:59:32 [TabAtkins]
howcome: What if we used ::top-left or something?
18:59:44 [TabAtkins]
fantasai: Still invalid in a declaration block. Should have been @page::top-left, but shrug.
19:00:03 [TabAtkins]
Straw Poll:
19:00:07 [TabAtkins]
1) Generic Handling
19:00:17 [TabAtkins]
2) Special handling for @page in any order (current spec)
19:00:23 [TabAtkins]
3) Special handling, but @rules at the end.
19:00:54 [TabAtkins]
4) Change Paged Media to nuke margin boxes and rewrite @page.
19:01:18 [TabAtkins]
smfr: 1
19:01:20 [TabAtkins]
anne: 1
19:01:25 [TabAtkins]
szilles: 1
19:01:27 [bradk]
1 generic
19:01:27 [TabAtkins]
dbaron: 1
19:01:38 [TabAtkins]
s/dbaron/dethbakin/
19:04:06 [dbaron]
dbaron has joined #css
19:05:30 [TabAtkins]
sylvaing: abstain
19:05:41 [TabAtkins]
alexmog: 3 or 4, whatever doesnt' change CSS 2.1
19:05:49 [TabAtkins]
ChrisL: 1
19:06:06 [TabAtkins]
Bert: Prefer 4, second is 3. could also live with 2. Can't live with 1
19:06:11 [TabAtkins]
arronei: 1
19:06:25 [sylvaing]
sylvaing abstains in the absence of a use-case
19:06:28 [TabAtkins]
fantasai: anything but 4, defer to dbaron
19:06:31 [TabAtkins]
dbaron: 4
19:06:53 [TabAtkins]
bradk: 1
19:06:56 [TabAtkins]
TabAtkins: 1
19:06:59 [TabAtkins]
glazou: 1
19:07:01 [TabAtkins]
plinss: 1
19:07:14 [TabAtkins]
howcome: 3
19:07:23 [TabAtkins]
dsinger: 1
19:08:09 [fantasai]
I think HP would raise a formal objection for 4
19:08:24 [TabAtkins]
glazou: Twelve for #1, three or four for 3 and 4.
19:09:49 [TabAtkins]
dsinger: We have agreement on *not* 2.
19:10:00 [TabAtkins]
plinss: And we cant' do 4 because of existing impls.
19:10:13 [TabAtkins]
glazou: Existing impls do 2, so we're rejecting the current impls!
19:10:56 [TabAtkins]
fantasai: Not sure if existing impls do 2, maybe they do 1?
19:11:02 [TabAtkins]
ChrisL: How would you tell the difference?
19:11:33 [TabAtkins]
fantasai: Just pop my testcase into a supporting impl.
19:11:41 [anne]
<!DOCTYPE html><style> body { @foo {} background: green; } </style>
19:12:03 [ChrisL]
it would be good to gather that implementation experience for printers that currently handle @page
19:12:33 [TabAtkins]
body {
19:12:35 [TabAtkins]
@foo {
19:12:37 [TabAtkins]
}
19:12:39 [TabAtkins]
background: green;
19:12:41 [TabAtkins]
}
19:13:08 [TabAtkins]
glazou: People will write it like Tab has, what will they expect?
19:13:26 [TabAtkins]
howcome: Prince considers this an error, and doesn't show a green background.
19:13:33 [TabAtkins]
fantasai: So it implements 2?
19:14:23 [TabAtkins]
anne: Or 3, we can't tell.
19:14:36 [TabAtkins]
plinss: Elika, can you test with your printers and get back to us?
19:14:47 [TabAtkins]
fantasai: Would be good to get AH. Can we ping Murakami-san?
19:15:18 [TabAtkins]
fantasai: 3 would just mean normal 2.1 error-recovery mode.
19:15:39 [TabAtkins]
plinss: We'll come back when we get more implementations.
19:17:00 [dbaron]
dbaron has joined #css
19:17:00 [TabAtkins]
howcome: Is there anyone that can't live with 3?
19:17:10 [TabAtkins]
anne: #3 is actually pretty weird.
19:17:45 [TabAtkins]
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 [TabAtkins]
howcome: I think we can live with #3 now, and then make #1 valid later.
19:18:47 [TabAtkins]
dsinger: Can we write that we can possibly allow #1 later? Warn people about it?
19:19:11 [TabAtkins]
plinss: I don't think there's any point to saying "Sometime in the future, we might add future-proofing."
19:19:18 [ChrisL]
:)
19:19:33 [TabAtkins]
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_]
dbaron_ has joined #css
19:20:46 [TabAtkins]
howcome: There is no hole right now. You're creating a hole and then insisting it needs to be filled.
19:21:01 [TabAtkins]
anne: Paged Media doesnt' actually require them to be at the end.
19:21:24 [TabAtkins]
plinss: In my perspective, it's a bug in 2.1.
19:21:45 [TabAtkins]
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 [TabAtkins]
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 [TabAtkins]
howcome: We have impl issues with that.
19:23:09 [TabAtkins]
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 [TabAtkins]
Bert: But no one implements it like that anyway.
19:23:41 [TabAtkins]
plinss: Right. But my reading of CSS is that you throw away an invalid @ rule as a unit.
19:23:47 [TabAtkins]
Bert: Only at the toplevel.
19:23:59 [TabAtkins]
plinss: But CSS doesn't say that.
19:24:30 [TabAtkins]
howcome: This is a new situation. Bert is arguing *for* the browsers, Peter is arguing against?
19:24:59 [TabAtkins]
plinss: This isn't progressing. We'll get more examples. Until then we're not convincing anyone.
19:25:21 [TabAtkins]
szilles: Can we set a time for jdaggett's call? By my calc, 6am in Tokyo is 2pm here.
19:25:32 [TabAtkins]
szilles: Is 3pm okay for us (7am for him)?
19:25:46 [TabAtkins]
plinss: We have a lot of things for him to weigh in on.
19:26:02 [TabAtkins]
plinss: I'd like him as early as possible. I suggest we ask him when he's comfortable.
19:26:12 [dino]
dino has joined #css
19:26:17 [TabAtkins]
szilles: And then I"ll ask another Adobe employee to attend.
19:26:33 [TabAtkins]
<br type=lunch duration=1h>
20:00:52 [dethbakin]
dethbakin has joined #css
20:35:22 [Lachy]
Lachy has joined #css
20:40:50 [bradk]
bradk has joined #css
20:40:56 [sylvaing]
sylvaing has joined #css
20:41:21 [dbaron]
dbaron has joined #css
20:42:04 [glazou]
glazou has joined #css
20:42:23 [plinss__]
plinss__ has joined #css
20:43:10 [smfr]
smfr has joined #css
20:43:16 [Arron]
Arron has joined #css
20:45:23 [alexmog]
alexmog has joined #css
20:45:39 [glazou]
glazou has joined #css
20:45:44 [ChrisL]
ChrisL has joined #css
20:46:49 [fantasai]
http://wiki.csswg.org/spec/css2.1#issue-114
20:47:03 [fantasai]
http://wiki.csswg.org/spec/css2.1#issue-109
20:47:17 [fantasai]
http://wiki.csswg.org/spec/css2.1#issue-26
20:48:10 [fantasai]
dbaron: The way the spec currently says that vertical-align in table cells works is
20:48:14 [fantasai]
ScribeNick: fantasai
20:48:17 [fantasai]
dbaron: You have a table
20:48:38 [fantasai]
dbaron: like this
20:48:51 [fantasai]
dbaron draws a table with 2 rows 2 cols
20:49:09 [fantasai]
dbaron: And you have a table cell likes this
20:49:17 [fantasai]
dbaron draws a cell box in the upper half of the first cell
20:49:35 [fantasai]
dbaron: The spec says ... and it says that the 'height' property sets the height of a cell box
20:50:05 [fantasai]
dbaron: Suppose it says the cell height is 200px
20:50:10 [fantasai]
dbaron: The cell box will be 200px
20:50:17 [fantasai]
dbaron: and if the row is 200px high
20:50:38 [fantasai]
dbaron: the cell box stays put, and its contents are clearly not vertical-align: bottom
20:50:49 [fantasai]
dbaron: Nobody does this, everybody aligns the contents to the bottom
20:51:17 [jer]
jer has joined #css
20:51:27 [fantasai]
s/.../vertical-align aligns the cell box inside the cell/
20:51:47 [jer]
jer has left #css
20:52:09 [fantasai]
dbaron: There are 2 possible solutions here, with different implications, and different browsers pick different ones
20:52:30 [fantasai]
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 [fantasai]
dbaron: The other solution is to say that you have two boxes
20:53:10 [fantasai]
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 [fantasai]
dbaron: The tricky cases are where you have baseline alignment
20:53:59 [fantasai]
dbaron: You can get a case where baseline alignment requires more space than either cell would require alone
20:54:41 [fantasai]
dbaron: e.g. if you have a large-text box of auto height
20:54:54 [fantasai]
dbaron: and a small-text cell of large height
20:54:58 [fantasai]
dbaron: the baselines align
20:55:12 [fantasai]
dbaron: but the second box extends way below the bottom of the first
20:55:18 [fantasai]
dbaron draws this on the board
20:56:04 [css_projector]
http://dbaron.org/css/test/2010/css21-issue-26
20:56:47 [fantasai]
dbaron shows http://www.brunildo.org/test/td_height1.html
20:58:24 [fantasai]
fantasai: I would not expect vertical-align to increase the size of the cell there
21:03:53 [fantasai]
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 [smfr]
http://www.w3.org/TR/CSS21/tables.html#height-layout
21:08:12 [fantasai]
fantasai: Does height include the padding?
21:08:31 [fantasai]
fantasai: border-widths?
21:09:55 [fantasai]
Looks like height in Mozilla is a border-box height
21:11:54 [ChrisL]
ChrisL has joined #css
21:12:26 [fantasai]
fantasai thinks we should say that the height sets the border-box height of the cell box
21:12:38 [fantasai]
The contents of the cell are wrapped in an anonymous box, and that is aligned inside the cell
21:13:18 [fantasai]
Alex: What do Mozilla and WebKit do for flexbox?
21:13:22 [fantasai]
dbaron: I'm not so concerned with that
21:14:49 [fantasai]
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 [fantasai]
Steve: The first box has border, padding, etc.
21:16:54 [fantasai]
dbaron: We should figure out what we want so that someone can write a proposal
21:17:04 [fantasai]
dsinger asks a question
21:17:35 [fantasai]
dbaron: baseline alignment is a relative thing. You take all the cells in the row and baseline-align their contents.
21:17:58 [fantasai]
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 [fantasai]
Steve: So your question is that ... can we give names to these things?
21:19:33 [fantasai]
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 [fantasai]
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 [anne]
http://dev.w3.org/csswg/css3-tables-algorithms/Overview.src.htm
21:26:16 [fantasai]
howcome talks about making a bar chart
21:26:46 [fantasai]
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 [fantasai]
dbaron: Everything's like minimum heights in tables
21:27:29 [fantasai]
Alex agrees with Opera's interepretation
21:28:28 [fantasai]
Steve: If you want the other behavior, you can put a fixed height on a <div> inside
21:28:42 [fantasai]
plinss: Shouldn't require markup changes for layout
21:28:51 [fantasai]
fantasai: This is the most intuitive interpretation.
21:29:45 [fantasai]
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 [fantasai]
ACTION: dbaron write proposal for IE-Opera behavior for issue 26
21:30:31 [trackbot]
Created ACTION-210 - Write proposal for IE-Opera behavior for issue 26 [on David Baron - due 2010-04-05].
21:30:41 [fantasai]
Simon: Hyatt doesn't really care which way this goes
21:31:02 [fantasai]
http://wiki.csswg.org/spec/css2.1#issue-114
21:33:29 [szilles]
szilles has joined #css
21:34:39 [fantasai]
fantasai explains that the spec is unclear about what is allowed and what is invalid
21:35:41 [fantasai]
Arron has a bunch of testcases showing that results are very different across browsers
21:35:47 [fantasai]
There are two proposals for clarifying the spec
21:35:57 [fantasai]
one would make unquoted font names a series of identifier tokens
21:36:06 [fantasai]
the other would make them a series of nmchars tokens
21:36:14 [fantasai]
Chris suggests recommending quotes
21:36:20 [fantasai]
The spec already recommends quotes
21:38:15 [dethbakin]
dethbakin has joined #css
21:38:42 [dethbakin]
dethbakin has joined #css
21:39:29 [fantasai]
dbaron: right now in Gecko you have to escape or quote numbers
21:41:07 [jer]
jer has joined #css
21:41:45 [fantasai]
several: Let's allow everything
21:42:05 [ChrisL]
everything but comma
21:42:11 [fantasai]
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 [fantasai]
http://lists.w3.org/Archives/Public/www-style/2010Mar/0395.html
21:43:31 [fantasai]
http://www.w3.org/TR/CSS21/fonts.html#font-family-prop
21:44:35 [fantasai]
Chris: How about making a grammar for what the prose already says
21:45:24 [alexmog]
alexmog has joined #css
21:47:47 [fantasai]
discussion of what mistakes web authors are likely to make
21:47:56 [ChrisL]
some font families that might be useful for tests - "101 Dalmations" "3.14 Pi" "Twenty 4px"
21:49:11 [fantasai]
dbaron: right now the spec has document conformance reqs but no ua conformance reqs
21:51:09 [fantasai]
arron: If you run the testcases, you'll see a lot of constency except for numbers and brackets
21:51:56 [fantasai]
<br type=cookies>
21:55:24 [fantasai]
Topic: CSS2.1 Test Suite
21:55:39 [fantasai]
glazou: First issue is about inode strain on the server
21:57:00 [fantasai]
bert: it's not about space, it's our mirroring system
21:57:19 [fantasai]
Alex: Would adding another 15000 tests facilitate upgrading the system? :)
21:57:43 [fantasai]
Chris: It's generating emails to the mirrors for each file
21:58:13 [fantasai]
glazou: If solving this for w3.org involves more work for us on the test suite, let's just move.
21:58:26 [fantasai]
glazou: I suggest we do nothing and wait
21:59:21 [fantasai]
bert: I also have an action to get the issues list onto w3c servers
22:00:09 [dbaron]
dbaron has joined #css
22:00:41 [fantasai]
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]
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]
fantasai: We could create tarballs for the snapshots, just publish the latest expanded out
22:02:49 [fantasai]
Topic: Reviewing testcases
22:02:59 [fantasai]
Arron: We're not getting a lot of traction on review of testcases
22:03:10 [fantasai]
Arron: It's something that needs to happen
22:03:56 [fantasai]
Plinss: We decided we'd drive reviews by people generating implementation reports
22:04:32 [fantasai]
plinss: And then people can object if they find test is wrong
22:05:52 [fantasai]
glazou: When will the test suite be complete?
22:07:02 [fantasai]
discussion between glazou and fantasai about scheduling test suite work
22:08:09 [fantasai]
fantasai aims to publish ts beta 1 in mid-April
22:08:36 [fantasai]
Arron: It should take each browser vendors 2 days of 8 hours each to run an implementation report
22:08:59 [fantasai]
Glazou: We must be in PR by September, keep that in mind
22:09:10 [fantasai]
Topic: Vendor prefixes
22:09:12 [fantasai]
Bert: Why?
22:09:23 [fantasai]
glazou: There's been a bunch of discussion on www-style
22:09:32 [fantasai]
glazou: I don't think the current situation is satisfactory from the web authors pov
22:10:13 [fantasai]
glazou: On filters and web-authoring tools side it's hell
22:10:30 [fantasai]
Alex: Shouldn't be using experimental stuff until it's stable
22:11:09 [fantasai]
dbaron: I think we should be able to find a way to declare things stable until CR
22:11:25 [fantasai]
Steve: There is a way. It's called CR. It hasn't received enough review until then
22:11:44 [fantasai]
It hasn't gone to last call
22:11:52 [TabAtkins]
@mixin border-radius(radius: 8px) {
22:11:54 [TabAtkins]
-moz-border-radius: var(radius);
22:11:56 [TabAtkins]
-webkit-border-radius: var(radius);
22:11:58 [TabAtkins]
border-radius: var(radius);
22:11:58 [fantasai]
Steve: If you need to, make smaller modules.
22:11:59 [TabAtkins]
}
22:12:01 [TabAtkins]
.box-with-corners {
22:12:03 [TabAtkins]
@mixin border-radius(12px);
22:12:04 [TabAtkins]
border: 2px solid black;
22:12:06 [TabAtkins]
}
22:12:10 [TabAtkins]
^^^ make an end-run around the issue with additions to syntax
22:12:34 [fantasai]
glazou: I think we should have a frozen status for features
22:12:48 [fantasai]
Steve: ... W3C process
22:13:04 [fantasai]
dbaron: The versioning process of CSS isnt' a W3C process issue
22:13:16 [fantasai]
anne: What impl do or not doesn't have anything to do with process
22:14:37 [fantasai]
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]
dbaron has joined #css
22:15:01 [fantasai]
Steve: We have good examples where removing the prefix would have been a mistake
22:15:29 [fantasai]
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 [fantasai]
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 [fantasai]
Tab: I agree with Steve. I think we should stick with this model.
22:16:39 [fantasai]
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 [fantasai]
Tab: We could make vendor-prefixes less painful for authors we could use a mixins syntax
22:17:08 [glazou]
glazou has joined #css
22:17:40 [fantasai]
Tab: This example is simple one, for border-radius.
22:17:58 [fantasai]
Tab: If one implementation had a slightly different syntax, you could just change it in the mixin definition
22:18:03 [fantasai]
Tab: And you only need to write it once
22:18:23 [fantasai]
Tab: every time you need border-radius
22:18:36 [fantasai]
glazou talks about HTML5's versioning model
22:18:42 [fantasai]
Tab: I don't like HTML5's model. It's much nicer in JavaScript
22:18:55 [fantasai]
s/HTML5/HTML
22:18:57 [fantasai]
/
22:19:20 [fantasai]
Tab: JavaScript can afford to be ugly because you can layer a nice api over it
22:19:46 [fantasai]
dbaron: I think the big problem is not the model, but the timing of how we've been advancing properties
22:19:49 [alexmog]
alexmog has joined #css
22:20:06 [fantasai]
?: It's been a problem only for a few, more than one but only a few
22:20:26 [fantasai]
s/?/howcome/
22:20:50 [fantasai]
glazou: Whether it's a problem for a property depends a lot on how popular it is
22:21:41 [fantasai]
...
22:21:57 [fantasai]
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 [fantasai]
dbaron: We haven't changed our border-radius prefix because we don't yet match the current spec
22:22:39 [fantasai]
dbaron: Most of those issues are not even syntactic
22:22:47 [fantasai]
dbaron: There are a lot of requirements in the current spec that we don't implement
22:22:59 [fantasai]
dbaron: I had questioned at the time whether the spec needed to require things in that much detail
22:23:46 [fantasai]
howcome: I think you should drop the prefix anyway. Even if you have some bugs left. THey're just bugs
22:24:13 [fantasai]
Brad: If we had dropped the prefix for border-image earlier, we'd be stuck with that
22:25:14 [fantasai]
Brad: We wouldn't be able to make the changes I proposed.
22:25:17 [fantasai]
Brad: We thought it was stable.
22:25:36 [fantasai]
dbaron: I've heard comments from people who were unhappy that the prefixed versions didn't match the spec
22:25:39 [fantasai]
...
22:25:47 [fantasai]
Steve: Why isn't macros, by any other name, a good solution to this?
22:26:43 [fantasai]
glazou asks questions that were answered previously
22:26:57 [fantasai]
the minute-taker will not repeat the answers
22:27:15 [fantasai]
plinss: If they have different behavior?
22:27:20 [Bert]
(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 [fantasai]
Tab: If it's just syntactic, you can work around it. If you can't, then you're screwed anyway
22:27:49 [Bert]
Wrong paste, I meant http://sass-lang.com/ )
22:27:51 [fantasai]
Steve: If they don't do what you want, dropping the prefix isn't helpful anyway
22:28:18 [fantasai]
Plinss: The problem with this is, what if I change something via JavaScript?
22:28:27 [fantasai]
Anne: Maybe you don't see it in JavaScript
22:28:31 [fantasai]
...
22:28:41 [fantasai]
howcome: This saves people 30 seconds of copy-pasting. It's not really a problem
22:30:14 [fantasai]
howcome: I think this problem is over-rated
22:30:29 [anne]
I agree with howcome
22:30:56 [fantasai]
Tab: If we want to drop prefixes on something not in CR, we should pull it out into another module
22:30:58 [alexmog]
alexmog has joined #css
22:31:12 [fantasai]
Bert: We did that with css3-backgrounds, we dropped box-shadow so we could move everything else forward
22:31:24 [fantasai]
Tab: Yes. That would solve this while giving us all the benefits of CR.
22:32:15 [fantasai]
Steve: We can solve this problem by focusing on what's important and pushing that forward
22:33:39 [fantasai]
glazou: You don't know whether something's going to be succesful when you design it
22:33:53 [fantasai]
some arguments that it doesn't matter, you'll find out quickly
22:34:02 [fantasai]
others that you can predict it for some things anyway
22:34:12 [fantasai]
Steve: Once you find out something is popular, then you progress it faster.
22:34:17 [dbaron]
dbaron has joined #css
22:36:16 [fantasai]
glazou: If we accept the extra work to extract properties and push it forward, then it's not a problem
22:37:13 [fantasai]
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 [fantasai]
Chris: If it's mostly unstable, extract the stable parts and push that forward.
22:38:57 [fantasai]
Anne: Other WG's have pseudo-stable drafts that are implemented and shipped, and only take small changes
22:39:03 [fantasai]
Anne: It seems to work relatively well
22:39:05 [fantasai]
Steve: Yes and no
22:39:11 [fantasai]
-> offline
22:39:33 [fantasai]
glazou: If we have a high-priority set of properties, let's try to extract them to move faster
22:54:10 [fantasai]
Topic: Status-type Stuff
22:54:19 [fantasai]
Topic: Style-attr spec
22:54:32 [fantasai]
glazou: Last Call period ended. Need to check comments and write disposition of comments
22:54:55 [fantasai]
fantasai: I'm waiting for a response from SVGWG, other than that it's pretty much done
22:55:38 [fantasai]
http://dev.w3.org/csswg/css-style-attr/issues-lc-2009
22:57:40 [dbaron]
dbaron has joined #css
22:57:56 [fantasai]
dbaron: Should include tests for common problems
22:58:02 [fantasai]
dbaron: like braces around the declaration block
22:58:12 [fantasai]
Topic: Media Queries
22:58:19 [fantasai]
glazou: CR period ended a few months ago
22:58:25 [fantasai]
glazou: We dont' have a test suite, I think
22:58:34 [fantasai]
Anne: a lot of tests submitted, but no suite
22:58:39 [fantasai]
glazou: So, what do we do?
22:58:47 [fantasai]
Anne: We find someone to go through the tests and make a test suite
22:58:54 [fantasai]
howcome: We already found him
22:59:03 [fantasai]
howcome: Can't you do that?
22:59:09 [fantasai]
anne: I'm not sure I want to
22:59:15 [fantasai]
howcome: That wasn't my question :)
22:59:44 [fantasai]
anne: We have a lot of different tests, they're not all in the same format
23:00:47 [fantasai]
Anne explains some of the types of tests that were submitted
23:01:59 [fantasai]
discussion of how to test the 'grid' feature
23:04:52 [fantasai]
glazou: Are you able to handle the media queries test suite, or not?
23:05:01 [fantasai]
anne: I would rather not. I haven't done any work on it
23:05:12 [fantasai]
anne: the tests are posted to various mailing lists
23:05:59 [fantasai]
ACTION: Chris Find tests for media queries and check into test repository
23:05:59 [trackbot]
Sorry, amibiguous username (more than one match) - Chris
23:05:59 [trackbot]
Try using a different identifier, such as family name or username (eg. ChrisWilson, clilley)
23:06:11 [fantasai]
Anne: I'm sort of swamped with editing
23:06:28 [fantasai]
ACTION: clilley Find tests for media queries and check into test repository
23:06:29 [trackbot]
Created ACTION-211 - Find tests for media queries and check into test repository [on Chris Lilley - due 2010-04-05].
23:06:39 [fantasai]
Topic: Namespaces
23:06:46 [fantasai]
glazou: We're in CR, it is implemented
23:07:03 [fantasai]
dbaron: I think we fixed the one parsing bug we had
23:07:37 [fantasai]
glazou: We need implementation reports
23:09:36 [fantasai]
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 [dbaron]
Implementation report Firefox 3.6.2 Linux: all tests pass
23:12:40 [fantasai]
dbaron: All tests pass on FF3.7 Linux
23:12:45 [dbaron]
http://www.w3.org/Style/CSS/Test/CSS3/Namespace/current/
23:12:52 [fantasai]
ACTION: glazou make namespaces implementation reports
23:12:52 [trackbot]
Created ACTION-212 - Make namespaces implementation reports [on Daniel Glazman - due 2010-04-05].
23:13:32 [fantasai]
Topic: CSS3 Page
23:14:36 [fantasai]
fantasai: It needs a lot more work before another Last Call
23:14:46 [fantasai]
Topic: CSS3 Backgrounds and Borders
23:16:17 [fantasai]
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 [fantasai]
Topic: CSS3 Color
23:16:37 [fantasai]
dbaron: Some LC comments are non-trivial. We should go through the comments some time this meeting
23:17:09 [fantasai]
dbaron: The current editor's draft addresses most, but not all, issues. Haven't sent responses yet.
23:17:24 [dbaron]
http://wiki.csswg.org/spec/css3-color is the issues list
23:17:57 [fantasai]
Topic: Background Shorthand Syntax, to slash or not to slash
23:22:05 [TabAtkins]
fantasai: 4 issues, somewhat related.
23:22:12 [TabAtkins]
fantasai: All effect the shorthand.
23:22:22 [TabAtkins]
fantasai: sylvain's issue was background-clip.
23:23:10 [arronei]
arronei has joined #CSS
23:24:21 [TabAtkins]
fantasai: Start with background-clip, do we allow content-box?
23:25:15 [TabAtkins]
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 [TabAtkins]
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__]
plinss__ has joined #css
23:27:23 [TabAtkins]
bradk: [on board] Right now you've got like "/ <bg-size>".
23:28:23 [TabAtkins]
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]
TabAtkins: I want to avoid / whenever possible, though.
23:30:51 [TabAtkins]
bradk: We're already using /s in various properties, border-radius, font, border-image.
23:31:27 [TabAtkins]
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 [TabAtkins]
anne: Other places with keywords, like overflow, don't need a /.
23:32:01 [TabAtkins]
anne: And background-repeat.
23:32:36 [TabAtkins]
bradk: You need *something* to separate bg-position and bg-size.
23:32:40 [TabAtkins]
anne: Yeah.
23:33:21 [TabAtkins]
bradk: You get some freedom with how you write things with the /
23:33:27 [TabAtkins]
anne: Is that freedom actually needed, though?
23:34:32 [TabAtkins]
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 [TabAtkins]
fantasai: I think separating them would make things more difficult.
23:34:54 [TabAtkins]
fantasai: When you're parsing, you can just shove stuff into data structures directly.
23:35:08 [TabAtkins]
fantasai: You don't have to remember what has come before.
23:35:57 [TabAtkins]
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 [TabAtkins]
fantasai: position is always a position. If size is completely absent, it's a position.
23:36:38 [TabAtkins]
bradk: Don't you have to read ahead to see if there's a size?
23:37:07 [TabAtkins]
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 [TabAtkins]
Bert: I think the main issue is just one of readability.
23:39:35 [TabAtkins]
[discussion about human/machine parsability with a / anywhere in the rule versus / immediately before a size]
23:43:11 [TabAtkins]
TabAtkins: So can we add content-box to bg-clip, and accept the shorthand?
23:44:38 [TabAtkins]
strawpoll: Add content-box to background-clip?
23:45:03 [TabAtkins]
Abstain? 6
23:45:10 [TabAtkins]
Objections? 0
23:45:18 [TabAtkins]
RESOLVED: Add content-box to bg-clip
23:45:36 [TabAtkins]
RESOLVED: Allow setting bg-origin and clip in shorthand
23:48:55 [TabAtkins]
fantasai: Disallow "/size position", definitely.
23:49:23 [dsinger__]
dsinger__ has joined #css
23:49:45 [TabAtkins]
fantasai: Allow "position url /size" and "/size url position"?
23:50:29 [TabAtkins]
fantasai: Or restrict it to *only* "position/size"?
23:51:54 [TabAtkins]
RESOLVED: Change background shorthand to have "<bg-position> [/ <bg-size>]". (Position is required if you specify size.)
23:52:13 [fantasai]
http://lists.w3.org/Archives/Public/www-style/2010Feb/0238.html
23:52:15 [TabAtkins]
fantasai: Small one about border-radius.
23:52:41 [TabAtkins]
fantasai: 1) Define gradient stops in more detail. 2) Dont' define color-transitions at all.
23:53:05 [TabAtkins]
howcome: So what was the problem before?
23:53:23 [dsinger__]
dsinger__ has joined #css
23:53:34 [TabAtkins]
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 [TabAtkins]
ChrisL: Currently the spec tells you where on the curve the midpoint is.
23:54:02 [TabAtkins]
ChrisL: I think we should still be able to get that, and I think that's enough to get a gradient.
23:55:45 [TabAtkins]
ChrisL: [describes a linear-gradient based one]
23:56:01 [TabAtkins]
sylvaing: Could we get it back through CR quickly with that?
23:57:11 [ChrisL]
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 [TabAtkins]
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 [TabAtkins]
fantasai: I think making it undefined is fine, and then we have an informative appendix.
23:59:28 [TabAtkins]
szilles: The experience of leaving things undefined is that someone ends up defining them.
00:00:31 [TabAtkins]
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 [TabAtkins]
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 [TabAtkins]
sylvaing: If we later do 45deg corners, you'll need a linear gradient, etc.
00:02:37 [TabAtkins]
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 [TabAtkins]
szilles: But we won't have that freedom after a little bit.
00:04:00 [TabAtkins]
dbaron: I think I'm okay with that lack of freedom.
00:04:08 [jer]
jer has joined #css
00:07:29 [TabAtkins]
fantasai: If our browsers do something right now that authors don't like, we'll change.
00:07:59 [fantasai]
dbaron: sometimes it's best to let the market decide
00:10:04 [TabAtkins]
sylvaing: I'm fine with specifying sharp transitions, and I'm fine with undefined.
00:10:06 [fantasai]
"It is not defined what these transitions look like."
00:11:01 [fantasai]
Tab: I'm fine with explicitly undefined, being defined later possibly constrained by market forces
00:11:29 [fantasai]
Chris: I would prefer it to be dfined, but I can live with the other options
00:11:41 [TabAtkins]
arronei: From a testing perspective, I prefer defined.
00:13:18 [TabAtkins]
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 [TabAtkins]
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 [fantasai]
RESOLVED: proposal 3 accepted
00:14:52 [TabAtkins]
szilles: So all existing hard-edged impls match that proposal?
00:14:55 [TabAtkins]
glazou: yes.
00:15:07 [TabAtkins]
glazou: howcome, you have the floor for box-shadow
00:15:17 [TabAtkins]
howcome: box-shadow was removed to gain speed for the spec.
00:15:35 [TabAtkins]
howcome: We now have 4 interoperable impls of box-shadow, so I think we should put it back in.
00:16:06 [TabAtkins]
howcome: Or else put it in it's own spec.
00:16:37 [TabAtkins]
glazou: I have some tests, and it looks interoperable.
00:16:56 [TabAtkins]
howcome: [looking at MS people] I suspect they have something up their sleeve.
00:17:00 [TabAtkins]
sylvaing: We'd like to see it back in.
00:19:25 [TabAtkins]
howcome: So we have interop, why was it removed?
00:19:34 [dbaron]
dbaron has joined #css
00:19:56 [TabAtkins]
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 [TabAtkins]
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 [TabAtkins]
RESOLVED: Put the simple version of box-shadow back into B&B.
00:22:07 [TabAtkins]
Topic: GCPM - env() function
00:22:15 [plinss__]
http://dev.w3.org/csswg/css3-gcpm/
00:22:28 [howcome]
howcome has joined #css
00:22:31 [miketaylr]
miketaylr has joined #css
00:22:38 [plinss__]
http://dev.w3.org/csswg/css3-gcpm/#string-set
00:23:01 [TabAtkins]
howcome: If you print in most browsers, the browser will put the time of printing in the margin box.
00:23:12 [TabAtkins]
howcome: The idea is to make it possible to get that info in CSS.
00:23:25 [ChrisL]
env(location.lattitude)
00:24:16 [dbaron]
Is this going to gradually turn into strftime?
00:24:24 [TabAtkins]
dbaron, yes.
00:25:21 [dbaron]
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 [TabAtkins]
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 [glazou]
s/Michelle/Mischa
00:26:25 [dbaron]
s/Michelle Wolfe/Misha Wolf/
00:26:36 [dbaron]
s/Mischa Wolfe/Misha Wolf/
00:26:49 [TabAtkins]
szilles: How does the system know what to output the date as?
00:27:19 [TabAtkins]
glazou: From the system locale.
00:27:51 [TabAtkins]
szilles: That assumes the locale it is printed in is the same as the locale it is read for.
00:28:17 [TabAtkins]
glazou: That's the same problem that you *already have* with dates on printouts, you're just styling them now.
00:29:39 [TabAtkins]
[discussion of how Word does stuff/locale bindings]
00:30:12 [TabAtkins]
howcome: There is a way to just ask the system for the date, and env(date) would just give that.
00:30:43 [TabAtkins]
szilles: What's the use-case for this?
00:31:04 [TabAtkins]
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 [TabAtkins]
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 [TabAtkins]
howcome: By adding this feature, we allow ourselves to turn it off as well.
00:34:43 [TabAtkins]
szilles: I could potentially turn it off with just a little checkbox in some preferences.
00:35:07 [TabAtkins]
TabAtkins: No browser lets you do that right now. We can solve it through CSS.
00:36:18 [TabAtkins]
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 [TabAtkins]
glazou: You already have (new Date()).toLocaleString().
00:37:40 [TabAtkins]
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 [TabAtkins]
szilles: I don't think there's a such thing as the "date".
00:38:47 [TabAtkins]
TabAtkins: You're trying to add things to what we just want to simply cssify.
00:38:50 [anne]
javascript:(new Date).toLocaleString()
00:38:59 [anne]
Monday March 29, 17:38:45 GMT-0700 2010
00:39:55 [TabAtkins]
smfr: Is the intent to limit it to Paged Media?
00:40:11 [TabAtkins]
howcome: No, it can go in content property, so it can go anywhere potentially.
00:40:48 [anne]
anne has joined #CSS
00:40:54 [TabAtkins]
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 [TabAtkins]
glazou: More detail is needed there.
00:41:19 [anne]
anne has joined #CSS
00:41:22 [TabAtkins]
glazou: Sometimes when printing, the *username* is displayed on the printout. We shouldn't give access to that.
00:41:59 [TabAtkins]
howcome: So it seems like this is potentially a useful thing, but there are security and i18n concerns.
00:42:03 [TabAtkins]
bradk: Date, or date and time?
00:42:25 [TabAtkins]
howcome: We can do env(date) and env(time).
00:43:04 [TabAtkins]
plinss: Some printouts have the document title.
00:43:12 [TabAtkins]
howcome: You can already pull that from <title> 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