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