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