IRC log of CSS on 2010-04-28

Timestamps are in UTC.

15:41:57 [RRSAgent]: RRSAgent has joined #CSS
15:41:57 [RRSAgent]: logging to http://www.w3.org/2010/04/28-CSS-irc
15:42:05 [glazou]: Zakim, this will be Style
15:42:05 [Zakim]: ok, glazou; I see Style_CSS FP()12:00PM scheduled to start in 18 minutes
15:42:11 [glazou]: RRSAgent, make logs public
15:52:01 [glazou]: Zakim, code?
15:52:01 [Zakim]: the conference code is 78953 (tel:+1.617.761.6200 tel:+33.4.89.06.34.99 tel:+44.117.370.6152), glazou
15:53:11 [jdaggett]: jdaggett has joined #css
15:53:31 [Lachy]: Lachy has joined #css
15:53:37 [bradk]: bradk has joined #css
15:53:41 [glazou]: jdaggett: you're not attending the call, correct?
15:55:36 [Zakim]: Style_CSS FP()12:00PM has now started
15:55:44 [Zakim]: + +95089aaaa
15:55:51 [glazou]: Zakim, aaaa is me
15:55:51 [Zakim]: +glazou; got it
15:56:12 [szilles]: szilles has joined #css
15:56:22 [arronei]: arronei has joined #CSS
15:57:00 [oyvind]: oyvind has joined #css
15:58:06 [Zakim]: +plinss
15:58:41 [Zakim]: +SteveZ
15:59:12 [murakami]: murakami has joined #css
15:59:50 [Zakim]: + +1.650.275.aabb
16:00:11 [glazou]: Zakim, aabb is bradk
16:00:11 [Zakim]: +bradk; got it
16:00:14 [bradk]: Zakim aabb is me
16:00:53 [Zakim]: +Bert
16:01:38 [Zakim]: +[Microsoft]
16:01:55 [arronei]: zakim, Microsoft is me
16:01:55 [Zakim]: +arronei; got it
16:02:05 [smfr]: smfr has joined #css
16:02:08 [Zakim]: +[Microsoft]
16:02:16 [sylvaing]: sylvaing has joined #css
16:02:30 [glazou]: Zakim, [Microsoft] has sylvaing
16:02:30 [Zakim]: +sylvaing; got it
16:02:52 [Zakim]: +smfr
16:03:13 [smfr]: Zakim, [Apple] has smfr
16:03:13 [Zakim]: sorry, smfr, I do not recognize a party named '[Apple]'
16:04:00 [glazou]: regrets from molly, TabAtkins, dsinger
16:04:03 [Zakim]: + +34.60.940.aacc
16:04:16 [glazou]: Zakim, aacc is CesarAcebal
16:04:17 [Zakim]: +CesarAcebal; got it
16:05:31 [Zakim]: +??P16
16:05:39 [fantasai]: Zakim, P16 is me
16:05:40 [Zakim]: sorry, fantasai, I do not recognize a party named 'P16'
16:05:42 [Zakim]: + +47.21.65.aadd
16:05:44 [fantasai]: Zakim, ??P16 is me
16:05:44 [Zakim]: +fantasai; got it
16:05:59 [Zakim]: -glazou
16:06:07 [glazou]: called dropped hold on
16:06:09 [fantasai]: Zakim +47 is howcome
16:06:19 [Zakim]: +glazou
16:06:28 [fantasai]: Zakim, +47 is howcome
16:06:28 [Zakim]: +howcome; got it
16:06:36 [fantasai]: ScribeNick: fantasai
16:06:45 [glazou]: I have major phone issues apparently
16:07:30 [fantasai]: Topic: Test Suite
16:07:45 [fantasai]: Daniel: Peter and I would like to know where we are at this point
16:08:03 [fantasai]: arron: I started work on adding the metadata
16:08:14 [fantasai]: arron: I should have half done by the end of this week, hopefully all done by end of next week
16:08:40 [fantasai]: arron: That would mean that all the cases that have not been put in due to metadata will be ready to publish in the test suite
16:09:35 [fantasai]: fantasai: I haven't done anything, but I think two weeks time is reasonable for preparing a publication
16:09:40 [fantasai]: Topic: Template Layout
16:09:49 [fantasai]: Bert would like to publish a new working draft
16:10:03 [fantasai]: Bert: Mostly small changes, but would like to publish another draft to show it is still active
16:10:55 [Zakim]: +David_Baron
16:10:56 [fantasai]: Bert: Question of what properties should apply to ::slot()
16:11:05 [fantasai]: Bert: Tab favors all properties, I prefer limiting the properties
16:11:20 [ChrisL]: ChrisL has joined #css
16:11:27 [fantasai]: RESOLVED: Publish new WD of css3-layout
16:11:33 [fantasai]: Topic: Calc()
16:11:37 [dbaron]: dbaron has joined #css
16:11:42 [glazou]: http://lists.w3.org/Archives/Public/www-style/2010Apr/0184.html
16:12:05 [fantasai]: howcome: It's a good question, what should be inherited from calc()
16:12:08 [Zakim]: +ChrisL
16:12:12 [fantasai]: dbaron: I had a proposal in one of the responses
16:12:18 [glazou]: http://lists.w3.org/Archives/Public/www-style/2010Apr/0256.html
16:12:19 [dbaron]: http://lists.w3.org/Archives/Public/www-style/2010Apr/0258.html
16:13:05 [fantasai]: dbaron: Right now, calc() is only taking lengths or percentages. It doesn't take keywords of the properties
16:13:27 [fantasai]: dbaron: We haven't figured out what to do with things that are dimensionally invalid for the property
16:13:47 [fantasai]: dbaron: I suggest percentages transformed the same way they they're handled in the property
16:13:57 [fantasai]: dbaron: And all lengths converted to an absolute length
16:14:08 [fantasai]: dbaron: If we add keywords, they would be treated similar to percentages
16:14:24 [fantasai]: dbaron: So if you say calc(50% + 2em)
16:14:37 [fantasai]: dbaron: Then the em gets converted using the element's font size
16:15:09 [fantasai]: dbaron: The percentage gets calculated according to property rules
16:15:33 [ChrisL]: so the inherited value is the "most resolved" value which might be calc() ...
16:15:43 [fantasai]: dbaron: So font-size: calc(50% + 2em) is equivalent to 250%
16:16:17 [fantasai]: dbaron: But width: calc(50% + 2em) would inherit as calc(50% + Xabsoluteunits)
16:16:43 [fantasai]: ?: It makes sense for a value to inherit the same way when it's inside calc() as when it's outside it
16:16:59 [glazou]: s/?/glazou
16:17:07 [fantasai]: ...
16:17:18 [bradk]: calc(50%) === 50%
16:17:28 [fantasai]: dbaron: We do want calc() to inherit reasonable because people might want to use it for properties that inherit by default
16:17:56 [fantasai]: Sylvain: So, people would want the formula to inherit, not the result of the calculation?
16:19:00 [Zakim]: -howcome
16:19:01 [fantasai]: fantasai: You don't want to inherit the calculation, because that would require you to do layout before inheritance.
16:20:04 [fantasai]: glazou: I'm not sure I like inheriting the formula
16:20:24 [fantasai]: fantasai: If you have width: 50%, you want width: calc(50%) to inherit the same way
16:21:06 [Bert]: (Currently, 'width: 50%' ... 'width: inherit' also inherits the percentage, not the calculated width, so not too different from calc(50% + 1em).)
16:21:10 [fantasai]: fantasai: If you resolve the formula to an absolute length, then it won't inherit the same way
16:23:19 [fantasai]: sylvain: Why shouldn't it behave differently? It has a different syntax.
16:24:24 [glazou]: dbaron: with fantasai
16:24:44 [fantasai]: <div class="a"> <div class="b"></div> </div>
16:25:07 [glazou]: Zakim, who is noisy?
16:25:07 [fantasai]: .a { padding: really big; }
16:25:19 [Zakim]: glazou, listening for 10 seconds I heard sound from the following: [Microsoft] (51%)
16:25:26 [fantasai]: Say .a { width: 50% } resolves to 100px
16:25:41 [fantasai]: .b { width: 50%; } resolves to 25px
16:25:56 [fantasai]: .b { width: inherit; } currently also resolves to 25px
16:25:59 [fantasai]: You're suggesting that
16:26:21 [fantasai]: .a { width: calc(50% + 1px) } (resolves to 101px)
16:26:33 [fantasai]: .b { width: inherit; }
16:26:47 [fantasai]: You're saying b should resolve to 101px
16:27:01 [fantasai]: rather than 26px
16:27:05 [fantasai]: you == sylvain
16:27:57 [dbaron]: Zakim, [Microsoft] has Rossen_Atanassov
16:27:57 [Zakim]: +Rossen_Atanassov; got it
16:28:08 [fantasai]: Rossen: So, the response that David actually had, the latest one, saying that you basically inherit the calc and on the way down the inheritance you have two types of inheritance
16:28:19 [fantasai]: Rossen: So ems, you resolve the ems, and then inherit the value
16:28:29 [fantasai]: Rossen: Percentage values inherit all the way down as percentages
16:28:37 [fantasai]: Rossen; so percentages are resolved in your current space
16:28:42 [fantasai]: Rossen: That makes sense to me
16:28:51 [fantasai]: Rossen: If you have calc(50%) it inherits down as 50 percent
16:29:04 [fantasai]: Rossen: But calc(1em) inherits down as whatever 1em calculates tow here it's specified
16:29:22 [fantasai]: Rossen: That's what I see in dbaron's response, and that basically confirms my understanding of how it should work
16:29:44 [fantasai]: SteveZ: So if I have an expression, it will calculate itself out unless it uses a percentage that would not be calculated out at that point if it were freestanding
16:32:27 [fantasai]: Sylvain argues that the 'calc()' syntax requests a different behavior from a user perspective.
16:32:30 [fantasai]: dbaron disagrees
16:32:56 [fantasai]: Rossen: The interesting example here, suppose we had calc(50% + 1em)
16:32:57 [dbaron]: I think calc() is about combining existing values, and those values should behave just like they do without calc().
16:34:02 [fantasai]: SteveZ: The surprise doesn't come from calc, it comes from certain values not being calculated due to layout being required.
16:34:19 [fantasai]: SteveZ: This is already an issue. calc() makes it more complicated because some values computed and others don't
16:34:27 [fantasai]: SteveZ: so it emphasizes the problem
16:34:44 [fantasai]: SteveZ: To me, calc() of some value should be exactly the same as that value alone
16:35:17 [fantasai]: fantasai: Does anyone here disagree with SteveZ's last statement?
16:36:21 [fantasai]: Sylvain: I think some people will expect that calc() computes the value and then inherits down.
16:36:44 [fantasai]: Sylvain: I don't think it's crazy that an average web author considers calc(X) should behave differently than X alone
16:37:37 [fantasai]: glazou: We have two ways of saying how calc() is working.
16:37:54 [dbaron]: What's the difference between these proposals?
16:38:04 [fantasai]: glazou asserts that dbaron and fantasai and Rossen and sylvain have different proposals
16:38:11 [fantasai]: dbaron and fantasai don't understnad why
16:38:23 [fantasai]: Sylvain: I'm not proposing something different, I'm just saying it may be confusing.
16:39:11 [fantasai]: Rossen: calc() is just like parentheses. You can put parentheses around a single value in an expression; it doesn't do anything
16:39:21 [fantasai]: Rossen: I'm fine with writing up a paragraph on this
16:39:39 [fantasai]: SteveZ: I think that the teaching thing is no worse than teaching exponents, when any number to the first power is the same as that number
16:39:49 [fantasai]: Sylvain: The functional notation creates some expectations
16:40:35 [fantasai]: SteveZ: I found dbaron's description hard to read, so Rossen, if you write it up I would prefer a better explanation of why percentages behave the way they do
16:40:52 [dbaron]: I think the essence of my proposal is that each leaf value within the calc() expression gets computed as though it's a value of the property.
16:41:05 [dbaron]: Except I worded it to allow for values that aren't values of the property.
16:41:30 [fantasai]: Topic: Selectors Serialization
16:41:32 [bradk]: width: calc(100% - <padding-amount>) is something I could imagine using, and inheriting
16:41:34 [fantasai]: glazou: Is anne on the call?
16:41:55 [fantasai]: Topic: RFC on View Modes
16:42:05 [smfr]: url?
16:42:17 [Bert]: http://www.w3.org/TR/2010/WD-view-mode-20100420/
16:43:04 [fantasai]: SteveZ: Who wrote the comments?
16:43:14 [fantasai]: Bert: i think we developd the comments together
16:43:18 [fantasai]: Steve: But somebody sent them
16:43:46 [fantasai]: glazou: Peter and Bert and I will sort it out after the call
16:43:50 [fantasai]: Topic: Empty Media Queries
16:44:01 [glazou]: http://lists.w3.org/Archives/Public/www-style/2010Apr/0391.html
16:44:39 [fantasai]: Sylvain: The one thing was the definitions are in two different places
16:44:56 [fantasai]: Sylvain: I understand if we don't want to move backwards to fix that
16:45:32 [fantasai]: ChrisL: In the DOM, if you remove an attribute or if it has it's default value, you can tell the difference. Is that the same as here?
16:46:00 [fantasai]: Sylvain: The implementations of @media are inconsistent, and it is more inconsistent when you consider the markup side
16:46:40 [fantasai]: Sylvain: Right now we have the OM defined somewhere else, not fully defined
16:46:51 [fantasai]: Sylvain: And then we have the spec for the static definition of media queries
16:47:04 [fantasai]: Sylvain: And because we have different specs, we won't have a full set of testcases
16:47:14 [fantasai]: ChrisL: Sounds like you're arguing to merge the two specs
16:47:24 [fantasai]: Sylvain: ... interop
16:47:40 [fantasai]: ChrisL: There is a problem with testing things between the specs
16:47:57 [fantasai]: Sylvain: I think it's worth it, but I'd like to hear what others think. Because right now there is no interop
16:48:00 [ChrisL]: ... and thus these two should be combined
16:48:05 [fantasai]: Sylvain: The results at the edges are pretty strange
16:48:31 [fantasai]: dbaron: We discussed in the past what empty media queries should mean
16:48:55 [fantasai]: dbaron: We concluded that empty media queries are equivalent to all, but other specs might not allow empty media queries.
16:49:17 [fantasai]: dbaron: So you can't write @media { } and expect that to apply to all media
16:49:23 [ChrisL]: why does that spec dissalow an empty media query?
16:49:35 [fantasai]: because it wasn't allowed in 2.1
16:50:19 [fantasai]: dbaron: The spec has changed over time, and maybe some statements that would clarify have moved around or been lost
16:51:04 [fantasai]: Sylvain: For compat with legacy, you have media='' equivalent to all, and then @media { } is invalid, and then deleting mediums from the OM gives you 'not all'
16:51:43 [fantasai]: Sylvain: I think I understand what I'm supposed to do for a static style sheet, but I'm not so sure about the OM
16:52:07 [fantasai]: glazou: Does that mean we need an extra constraint on the OM saying that the empty media list is invalid for the OM?
16:52:40 [fantasai]: Sylvain: I don't think we'll get a perfect model for compat, but, even if the attribute, OM, and style sheet behave differently at least it should be defined somewhere
16:53:03 [fantasai]: ChrisL: Why can't @media { } mean all?
16:53:31 [fantasai]: dbaron: I think it's perfectly reasonable, but every time we discuss this issue we come to a different conclusion
16:53:53 [fantasai]: dbaron: We resolved last August that it should be invalid. I went and implemented that.
16:54:06 [ChrisL]: this is why we need to get specs to rec instead of being in permanent churn
16:54:08 [fantasai]: dbaron: It's gotten to the point that when the group discusses something and resolves it, I don't consider it permanent
16:54:48 [fantasai]: Sylvain: I'm not asking for consistency among OM, attr, and CSS, I just want it clearly defined
16:55:27 [fantasai]: glazou: If I have an @media string, and from the OM I want to remove the one media attached to it and replace it with anothe
16:55:55 [ChrisL]: i agree with daniel. the intermediate state is all
16:55:58 [fantasai]: glazou: It makes sense for the intermediate state to mean all
16:56:21 [ChrisL]: that isn't a contradiction. its ok to have something reachable by dom that is not reachable by syntax
16:56:26 [fantasai]: glazou: I see the parsing and the OM being independent
16:56:50 [fantasai]: dbaron: From an implementation perspective, there's a tricky issue here. Because the way the media query spec defines invalidity
16:57:13 [fantasai]: dbaron: An invalid query doesn't invalidate the list of queries, it only invalidates that particular query
16:57:20 [fantasai]: dbaron: And invalid queries are treated as false
16:57:58 [fantasai]: dbaron: You would need to record that there was some invalid thing that's false, so that when you remove the valid attributes you get false, not all
16:58:37 [fantasai]: glazou: If we say that an empty media list attached to the OM is equivalent to 'all' ...
16:58:51 [fantasai]: dbaron: The tricky thing is what is an empty media list
16:59:20 [fantasai]: dbaron: If you have an invalid media query as part of the media list, you have to keep track of that.
16:59:40 [fantasai]: dbaron: We implemented that the media query was not empty, and that's a permanent state: you can't remove everything through the OM
17:00:03 [fantasai]: dbaron thinks maybe he needs to write something up with examples
17:00:18 [fantasai]: glazou: Does this mean the error-handling rules of media queries make it impossible to handle a few cases
17:00:36 [ChrisL]: it sounds like the rules throw up an error state for no good reason
17:00:41 [fantasai]: glazou: It seems we may need to revisit the error-handling rules
17:01:12 [fantasai]: Sylvain: all is a sensical default for empty media lists
17:01:23 [fantasai]: peter: What happens if you then serialize the OM?
17:01:30 [fantasai]: Sylvain: Then you serialize as 'all'
17:01:46 [fantasai]: Sylvain: It's an edge case, but the spec should say something about it
17:02:00 [fantasai]: Sylvain: It would be nice to have it all in the sme place and have a suite of testcases
17:02:28 [fantasai]: dbaron: I think there's a relatively straightforward solution wrt error handling, and that's to replace any invalid queries with 'not all'.
17:02:40 [dbaron]: print, screen and (nonexistent-query), projection
17:02:42 [dbaron]: turns into
17:02:45 [dbaron]: print, not all, projection
17:02:51 [dbaron]: so that if somebody then does
17:02:59 [dbaron]: media.remove("print")
17:03:02 [dbaron]: media.remove("projection")
17:03:04 [dbaron]: you have 'not all'
17:03:11 [dbaron]: rather than an empty query that evaluates to 'all'
17:03:37 [fantasai]: Bert: Why wouldn't you just ignore it?
17:04:09 [fantasai]: fantasai and glazou try to explain
17:04:20 [fantasai]: ACTION: dbaron and glazou Write a proposal
17:04:21 [trackbot]: Created ACTION-226 - And glazou Write a proposal [on David Baron - due 2010-05-05].
17:04:53 [Zakim]: -ChrisL
17:04:57 [Zakim]: -David_Baron
17:04:58 [fantasai]: Meeting closed.
17:04:58 [Zakim]: -smfr
17:05:00 [Zakim]: -SteveZ
17:05:00 [Zakim]: -[Microsoft]
17:05:01 [Zakim]: -glazou
17:05:03 [Zakim]: -CesarAcebal
17:05:05 [Zakim]: -plinss
17:05:05 [Zakim]: -fantasai
17:05:09 [Zakim]: -arronei
17:05:20 [Zakim]: -Bert
17:06:38 [glazou]: szilles: still here ?
17:08:11 [glazou]: apparently not
17:10:20 [Zakim]: disconnecting the lone participant, bradk, in Style_CSS FP()12:00PM
17:10:23 [Zakim]: Style_CSS FP()12:00PM has ended
17:10:25 [Zakim]: Attendees were +95089aaaa, glazou, plinss, SteveZ, +1.650.275.aabb, bradk, Bert, arronei, sylvaing, smfr, +34.60.940.aacc, CesarAcebal, +47.21.65.aadd, fantasai, howcome,
17:10:28 [Zakim]: ... David_Baron, ChrisL, Rossen_Atanassov
17:22:14 [TabAtkins_]: TabAtkins_ has joined #css
17:31:57 [dbaron]: dbaron has joined #css
17:55:55 [shepazu]: shepazu has joined #css
17:59:44 [Bert]: rrsagent, draft minutes
17:59:44 [RRSAgent]: I have made the request to generate http://www.w3.org/2010/04/28-CSS-minutes.html Bert
18:00:11 [Bert]: rrsagent, make logs public
18:01:21 [divya]: divya has joined #css
18:28:51 [shepazu]: shepazu has joined #css
18:29:06 [shepazu]: shepazu has joined #css
18:29:44 [Zakim]: Zakim has left #CSS
18:46:48 [sylvaing]: sylvaing has joined #css
19:43:13 [sylvaing]: sylvaing has joined #css
20:17:56 [shepazu]: shepazu has joined #css
21:03:04 [divya]: divya has joined #css
21:18:41 [sylvaing]: sylvaing has joined #css
21:29:37 [divya]: Does anyone know how/why the CSS namespaced SVG selector seems to work on this example HTML page without specifying the namespace on the inline SVG itself? http://dl.dropbox.com/u/952/namespaces/index.html (needs minefield)
21:30:15 [divya]: (and html5.enabled = true on about:config)
22:23:04 [sylvaing]: sylvaing has joined #css
22:33:15 [shepazu]: shepazu has joined #css
23:17:51 [TabAtkins_]: TabAtkins_ has joined #css