IRC log of css on 2012-09-12

Timestamps are in UTC.

15:35:20 [RRSAgent]
RRSAgent has joined #css
15:35:20 [RRSAgent]
logging to
15:35:25 [glazou]
Zakim, this will be Style
15:35:25 [Zakim]
ok, glazou; I see Style_CSS FP()12:00PM scheduled to start in 25 minutes
15:35:30 [glazou]
RRSAgent, make logs public
15:36:42 [dbaron]
dbaron has joined #css
15:51:14 [jdaggett]
jdaggett has joined #css
15:51:21 [lstorset]
lstorset has joined #css
15:52:18 [jdaggett]
jdaggett has joined #css
15:55:44 [cabanier]
cabanier has joined #css
15:56:08 [antonp]
antonp has joined #css
15:56:34 [rhauck]
rhauck has joined #css
15:57:13 [Zakim]
Style_CSS FP()12:00PM has now started
15:57:19 [Zakim]
+ +1.415.615.aaaa
15:57:29 [Zakim]
- +1.415.615.aaaa
15:57:30 [Zakim]
Style_CSS FP()12:00PM has ended
15:57:30 [Zakim]
Attendees were +1.415.615.aaaa
15:58:12 [Zakim]
Style_CSS FP()12:00PM has now started
15:58:16 [oyvind]
oyvind has joined #css
15:58:20 [Zakim]
+ +1.415.615.aaaa
15:58:32 [Zakim]
15:58:58 [Zakim]
15:58:59 [Zakim]
15:59:13 [jdaggett]
zakim, ??p33 is me
15:59:13 [Zakim]
+jdaggett; got it
15:59:14 [Zakim]
15:59:42 [Zakim]
15:59:46 [glazou]
Zakim, ??P41 is me
15:59:47 [Zakim]
+ +1.206.324.aabb
15:59:49 [Zakim]
+glazou; got it
15:59:56 [glazou]
Zakim, who is here ?
16:00:06 [jdaggett]
16:00:13 [Zakim]
On the phone I see +1.415.615.aaaa, Lea, jdaggett, plinss, stearns, glazou, +1.206.324.aabb
16:00:34 [Zakim]
On IRC I see oyvind, rhauck, antonp, cabanier, jdaggett, lstorset, dbaron, RRSAgent, Zakim, glazou, koji, miketaylr, SteveZ, macpherson__, SimonSapin, drublic, victor, vhardy_, ed,
16:00:38 [Zakim]
... plinss, Bert, paul___irish, hober, decadance, fantasai, Hixie, TabAtkins_, gsnedders, jwir3, Liam, stearns, isherman, krijnhuman, logbot, leaverou, arronei, trackbot, alexmog,
16:00:40 [Zakim]
... vhardy, sylvaing, shans, CSSWG_LogBot, heycam|away
16:00:55 [Zakim]
+ +1.619.846.aacc
16:01:26 [glazou]
Regrets: szilles (AB meeting), brad, smfr (Apple event), florian, rbetts
16:01:34 [Zakim]
+ +93192aadd
16:01:40 [antonp]
Zakim, aadd is me
16:01:44 [Zakim]
16:02:17 [JohnJansen]
JohnJansen has joined #css
16:02:18 [Zakim]
16:02:20 [Zakim]
+antonp; got it
16:02:29 [jarek]
jarek has joined #css
16:02:29 [rhauck]
rhauck has left #css
16:02:38 [hober]
Zakim, aacc is me
16:02:41 [leaverou]
Zakim, Lea is me
16:02:46 [Zakim]
16:03:00 [Zakim]
+hober; got it
16:03:04 [Zakim]
+leaverou; got it
16:03:08 [Zakim]
16:03:20 [PhilCupp]
PhilCupp has joined #css
16:03:21 [Zakim]
16:03:33 [Zakim]
16:03:33 [arronei]
zakim, microsoft has me
16:03:33 [JohnJansen]
Zakim, Microsoft has JohnJansen
16:03:46 [Zakim]
16:03:50 [Zakim]
+arronei; got it
16:03:52 [Zakim]
+JohnJansen; got it
16:03:59 [Zakim]
16:04:15 [fantasai]
Zakim, P78 is me
16:04:21 [fantasai]
ScribeNick: fantasai
16:04:28 [Zakim]
sorry, fantasai, I do not recognize a party named 'P78'
16:04:36 [fantasai]
glazou: any additions to agenda?
16:04:39 [glazou]
Zakim, ??P78 is fantasai
16:04:53 [rhauck]
rhauck has joined #css
16:05:15 [Zakim]
16:05:19 [Zakim]
16:05:23 [Zakim]
+fantasai; got it
16:05:35 [fantasai]
glazou: First topic is Sunday of TPAC, but we don't have any news unless Bert joins
16:06:00 [fantasai]
glazou: Any info on TTWF location in Paris?
16:06:05 [Zakim]
16:06:13 [Zakim]
16:06:17 [fantasai]
rhauck: We're working on it,
16:06:27 [fantasai]
rhauck: if anyone has suggestions, let us know
16:06:35 [fantasai]
rhauck: we'll email the list when we know
16:06:57 [fantasai]
rhauck: hoping by end of week
16:07:33 [fantasai]
Bert: We reserved the room for Sunday, will be in the Hotel de la Cité Concorde, in the conference center
16:07:59 [Zakim]
16:08:28 [fantasai]
glazou: Marie-Claire is planning a W3C meetup on Monday evening at the city hall of Lyon
16:08:39 [fantasai]
glazou: Will be general meetup aobut W3C and our specs and tools built on our specs
16:08:52 [fantasai]
glazou: Will collect items, if you want to speak, ping Marie-Claire
16:09:02 [fantasai]
16:09:35 [fantasai]
16:09:55 [fantasai]
glazou: maybe defer this until Florian can attend
16:10:01 [fantasai]
Topic: Font Load Events
16:10:08 [glazou]
16:10:09 [jdaggett]
16:10:21 [fantasai]
jdaggett: started out as proposal from Florian (?)
16:10:37 [fantasai]
jdaggett: topic brought up a number of times, need for events that indicate when fonts have been loaded
16:10:57 [fantasai]
jdaggett: reason for this is that there could be content on the page need to be measured, can't happen until fonts are loaded
16:11:04 [Zakim]
16:11:11 [koji]
zakim, ??p19 is me
16:11:11 [Zakim]
+koji; got it
16:11:29 [fantasai]
jdaggett: we've had several rounds of posts about font events from a couple years ago
16:11:36 [fantasai]
jdaggett: Tab recently proposed something
16:11:48 [fantasai]
jdaggett: I didn't like it, so I posted another proposal, in the spec now
16:12:01 [fantasai]
jdaggett: we need events for @font-face fonts b/c used lazily; not loaded until they're used
16:12:34 [fantasai]
jdaggett: Wanted to get from this call whether ppl happy with this proposal, flush out any possible objections
16:12:55 [fantasai]
jdaggett: Interface is still in flux; several ppl sent me private emails discussing certain parts of interface, things they find confusing, etc.
16:12:59 [fantasai]
jdaggett: Basically 2 types of events
16:13:08 [fantasai]
jdaggett: 1 gives you a way of identifying when all fonts are ready
16:13:16 [fantasai]
jdaggett: page could include multiple fonts, e.g. a bold and an italic
16:13:28 [fantasai]
jdaggett: It's hard for an author to track
16:13:34 [fantasai]
jdaggett: Also events that fire per font
16:13:45 [fantasai]
jdaggett: An app that wants to manage fonts very carefully would use those
16:13:54 [fantasai]
jdaggett: The existing WebLoader interface put together by Google is supported
16:14:17 [fantasai]
jdaggett: by several type [...] is more like per font detail
16:14:42 [fantasai]
Bert: I have no problem with the technology, just wondering what it does to the schedule of the draft
16:14:53 [fantasai]
Bert: Will it push back LC, or so easy will go ahead without loss of speed?
16:14:59 [glazou]
glazou: I read it and have no general comment; like it
16:15:00 [antonp]
[...] = online type services, I think
16:15:12 [fantasai]
jdaggett: Think it can go ahead without loss of speed, b/c ppl are very interested and sending lots of feedback
16:15:23 [fantasai]
jdaggett: caveat is that the OM for CSS font face rule, leftover from CSS2
16:15:30 [fantasai]
jdaggett: it uses CSSStyleDeclaration, which is odd
16:15:43 [fantasai]
jdaggett: I'm starting to hear rumblings of ppl that this isn't a good idea, switch to something else
16:15:48 [fantasai]
jdaggett: others are ambivalent
16:15:56 [fantasai]
jdaggett: Would influence this to a certain degree
16:16:19 [fantasai]
glazou: Could you use a CSS Rule instead?
16:16:31 [fantasai]
jdaggett: You need some place to define something like GetPropertyValue so you can get value of descriptors
16:16:37 [fantasai]
jdaggett: don't think need a setter for that...
16:16:51 [fantasai]
glazou: To avoid putting null CSSFontFaceRule in document, use a CSSRule
16:16:55 [fantasai]
jdaggett: What does that get you?
16:17:11 [fantasai]
glazou: In the future if we change CSSFontFaceRule [..] you will get it through CSSRule
16:17:25 [fantasai]
glazou: The result would be CSSRule, but you say in prose it is a CSSFontFaceRule
16:17:36 [fantasai]
several ppl confused
16:17:53 [fantasai]
glazou: You said that CSSFontFaceRule is subject to changes, b/c ppl don't like how it is right now.
16:18:01 [fantasai]
glazou: Suppose it becomes CSSFontFaceRule2 in the future
16:18:15 [fantasai]
glazou: That will still query interface to CSSRule, and you can use that as a reply to font-face attribute
16:18:33 [fantasai]
jdaggett: Don't think on CSSRule there's any way to access info currently contained in CSSStyleDeclaration
16:18:51 [fantasai]
glazou: No, not saying that. Saying that giving reply as CSSRule lets you have another interface in the future
16:19:03 [fantasai]
dbaron: Not a question of which interface, question of what we want on that interface
16:19:14 [fantasai]
jdaggett: Existing implementations implement the old interface, so have to consider that carefully.
16:19:20 [fantasai]
jdaggett: I think I need to do more research on this.
16:19:30 [fantasai]
jdaggett: Direct answer to Bert, but other OM issue could influence the schedule.
16:19:57 [fantasai]
jdaggett: If no one has other comments, then will continue to work through details on the list
16:20:10 [fantasai]
jdaggett: Since this is relatively major piece, once syntax worked out on the list, would like to publish another WD
16:20:13 [fantasai]
jdaggett: Sound reasonable?
16:20:13 [fantasai]
16:20:35 [fantasai]
jdaggett: Ok, I'll work on this another week, then ask WG for publish
16:20:48 [glazou]
16:20:54 [fantasai]
topic: CSs2.1
16:21:06 [fantasai]
anton: First is table box vs wrapper box and 'overflow'
16:21:17 [fantasai]
anton: Observed that it's implemented on table box, but only some values are supported
16:21:27 [fantasai]
anton: others are handled as visible
16:21:33 [antonp]
16:21:37 [fantasai]
anton: I proposed some wording, hope everyone's happy with it.
16:22:05 [fantasai]
works for me
16:22:20 [Zakim]
16:22:34 [fantasai]
Bert: Looks fine to me too
16:22:43 [fantasai]
glazou: no objection, no other comments?
16:22:49 [fantasai]
RESOLVED: Accepted
16:23:05 [fantasai]
anton: Second issue is an idea to help the wording in various places
16:23:22 [fantasai]
anton: going down a path we're going down a lot: defining terms we can reuse
16:23:23 [jarek]
jarek has joined #css
16:23:28 [fantasai]
anton: Want to define the term "block container element"
16:23:36 [fantasai]
anton: "block container box" was introduced in CSS2.1
16:23:43 [glazou]
slow down antonp please
16:23:50 [fantasai]
anton: A "block container element" is an element that generates a "block container box"
16:24:03 [fantasai]
anton: Don't have this wording in CSS2.1 yet, but would make fixing various issues much easier
16:24:18 [fantasai]
anton: I proposed this on the list, talked with fantasai, but no one else involved in conversation.
16:24:21 [antonp]
16:24:24 [fantasai]
anton: Looking what other ppl think
16:24:39 [fantasai]
anton: It's a long email, starts with motiviation
16:24:45 [fantasai]
anton: follows with prposal
16:25:35 [fantasai]
Rossen: Can I give you feedback a little bit later?
16:26:05 [fantasai]
glazou: Ok, let's take a week to review this proposal and discuss it next week.
16:26:22 [glazou]
16:26:23 [fantasai]
Topic: Consuming height at breaks
16:26:36 [TabAtkins_]
ScribeNick: TabAtkins_
16:27:03 [TabAtkins_]
fantasai: I've been going back and forth on this.
16:27:14 [TabAtkins_]
fantasai: Rossena nd I were talking last week about edits from the San Diego f2f.
16:27:20 [TabAtkins_]
fantasai: one of the issues taht came up was...
16:27:35 [TabAtkins_]
fantasai: If you have specified height on a box, that'll terminate *above* the bottom of the page, and continue on the next page.
16:27:42 [Zakim]
16:27:44 [TabAtkins_]
fantasai: You wont' consume height between the cut and the next page, and won't draw there either.
16:27:49 [TabAtkins_]
fantasai: That seems weird when you consider floats.
16:28:01 [TabAtkins_]
fantasai: Normally you ahve text wrapping around floats, and eventually wrapping under it.
16:28:09 [TabAtkins_]
fantasai: But here, there's space you can't wrap text around it.
16:28:17 [TabAtkins_]
fantasai: Because the element isn't visibly taking up space there.
16:28:28 [TabAtkins_]
fantasai: So we were discussing whether you can flow content under a broken float.
16:28:30 [Zakim]
16:28:31 [TabAtkins_]
fantasai: And the answer is no.
16:28:53 [TabAtkins_]
fantasai: And so - should you draw backgrounds, if you're taking up space (for the float)? If you're not drawing backgrounds, what are you doing with floats?
16:29:11 [TabAtkins_]
fantasai: So we're considering reversing, and just making everything draw to the bottom of the page and consume height. Thoughts?
16:29:31 [TabAtkins_]
antonp: I think it should draw to the bottom of the page. It's confusing as a reader to see something appear to terminate, but then it's there again at the next page.
16:30:22 [TabAtkins_]
antonp: I think I don't want it to consume height, though. Just calculate the extra space and add it on afterwards.
16:30:50 [TabAtkins_]
rossen: In essense, what Anton is asking for is to have a fairly tight coupling of content and containers, which is not present anywhere else in layout.
16:31:06 [TabAtkins_]
rossen: You have content, which draws independently of its container (to some degree).
16:31:23 [TabAtkins_]
rossen: The content is free to extend to whatever extent it needs.
16:31:31 [TabAtkins_]
rossen: The container may or may not take a dependency on that content.
16:31:59 [TabAtkins_]
rossen: If your height is auto, you stretch to the height; if it's specified, you just stick with that regardless of content.
16:32:13 [TabAtkins_]
rossen: Let's take as an example a block container with something with clearance on it.
16:32:28 [TabAtkins_]
rossen: If it's height auto, the clearance int he presence of a float will extend the height of the container.
16:32:37 [TabAtkins_]
rossen: Back to fragmentation, we're asking the same question.
16:32:49 [TabAtkins_]
rossen: I have something inside which needs to be longer than it was originally (extending to the next page).
16:33:03 [TabAtkins_]
rossen: The container may or may not take a dependency on that content, and stretch to the content's height.
16:33:11 [TabAtkins_]
rossen: But if it's fixed, it's just fixed.
16:33:30 [TabAtkins_]
rossen: So if, in this specific case, we don't consume from the specified height, now we're coupling content and containers.
16:33:41 [TabAtkins_]
rossen: And then my question is, why don't we do the same thing for 'clear' or similar mechanics?
16:33:52 [TabAtkins_]
rossen: That's why specified height is specified - if it's exhausted, it's exhausted.
16:34:22 [TabAtkins_]
antonp: That makes sense to me. You're right to bring up that there's two ways to look at it.
16:34:33 [TabAtkins_]
antonp: The question "why is height specified?"
16:34:47 [TabAtkins_]
antonp: It could be because of the relationship between the box and its surroundings, or between the box and its contents.
16:35:09 [TabAtkins_]
antonp: If you're specifying a height because you're going to specify properties on it that rely on that height, my answer won't be good - backgrounds won't look nice.
16:35:27 [TabAtkins_]
antonp: But equally, if you *don't* consume height, you might get the same visual problem as before.
16:35:42 [TabAtkins_]
antonp: I can imagine a situation where content is fragmented onto the next page.
16:35:56 [TabAtkins_]
antonp: There's a gap, but it's only partially filled now by the content.
16:36:10 [TabAtkins_]
antonp: You lose the visual indication that there can't be any more content.
16:36:37 [TabAtkins_]
TabAtkins_: In that case, it's kinda like overflow:visible, which does look horrible sometimes.
16:36:52 [TabAtkins_]
fantasai: Yes, you might have a background positioned relative to the top of the box, so it looks bad if it continues.
16:37:44 [TabAtkins_]
fantasai: On the other hand, you may have two boxes that have a specified height, because you want them to be the same specific size (maybe they're side-by-side). If they break at different points, they'll end at different points, when the layout of the rest of the box depends on them being the same height.
16:38:01 [TabAtkins_]
fantasai: There's no answer that'll give us the right behavior in all cases.
16:38:47 [TabAtkins_]
rossen: You can also usually address this by specifying min-height instead. In the non-fragmented case, they're the same height; if height extends to higher than expected during fragmentation, it's auto height and the container will stretch as necessary.
16:39:31 [TabAtkins_]
fantasai: One data point is that existing impls draw to the bottom fo the page and consume height.
16:39:55 [TabAtkins_]
fantasai: At least in Moz's codebase, it requires an extra level of bookkeeping if we want to draw to the bottom of the page but not consume height. You either do both or do neither.
16:40:31 [TabAtkins_]
fantasai: We're getting to the point of having more layout algorithms with boxes side-by-side, which should be the same height, and it makes sense for block flow to have the same behavior, so you're consistent.
16:40:46 [fantasai]
s/should be the same height/should draw to the bottom of the page/
16:41:15 [TabAtkins_]
antonp: I wouldnt' object to taht status quo.
16:41:26 [TabAtkins_]
antonp: I think it should draw to the bottom. If it's easier, let's have it consume height.
16:41:39 [TabAtkins_]
rossen: Again, I don't think anyone is suggesting the opposite.
16:41:39 [glazou]
ok bye hober
16:41:41 [Zakim]
16:42:03 [TabAtkins_]
rossen: The visual should be consistent with the layout.
16:43:03 [fantasai]
TabAtkins: [...]
16:43:23 [TabAtkins_]
TabAtkins_: Agreed. I liked the ability to sometimes do good, but you've convinced me that we cant' do good sufficiently often, so let's just do the simple thing that's usually good enough.
16:43:36 [TabAtkins_]
plinss: My only concern is having a box accidentally overflow when it wasn't intended to.
16:44:02 [TabAtkins_]
TabAtkins_: Right, that's the time when it turns bad. But as Rossen points out, there are ways around that (use min-height), and we can always expose an explicit swtich afterwards if we want.
16:44:29 [TabAtkins_]
rossen: Reiterating, looking at different impls, that's the beahvior you have today with pagination. So the spec will be fairly consistent with that.
16:44:43 [TabAtkins_]
rossen: So if we do introduce a smarter behavior, we may be looking at compat problems.
16:45:11 [TabAtkins_]
plinss: I'll point out that the "impls already do this" is usually a good argument, but most impls do such a bad job at pagination, it's not really a very strong argument here.
16:45:16 [TabAtkins_]
fantasai: I'd agree with that.
16:46:04 [TabAtkins_]
fantasai: But there are cases where consuming the specified height will cause overflow, and other cases where it will prevent overflow - by not consuming the remaining space on the page, the container may be longer than expected, and *it's* parent now overflows.
16:46:25 [TabAtkins_]
fantasai: Two boxes that are 100% tall in a fixed-height box, side by side.
16:46:37 [TabAtkins_]
fantasai: I break the page, one consumes height, the other doesn't, one of the boxes will overflow its parent.
16:46:57 [TabAtkins_]
fantasai: So neither behavior works in all cases. It depends on the layout, and depends on the content.
16:47:12 [TabAtkins_]
fantasai: Both answers are 50% good and 50% bad. So, the argument to be consistent seems to win otu.
16:48:13 [TabAtkins_]
Bert: I think it's fine, but could you summarize the conclusion again?
16:48:37 [TabAtkins_]
fantasai: The conclusion is that all boxes draw and consume height as normal in the presence of breaks, to the bottom of the page past the break.
16:48:47 [TabAtkins_]
Bert: Okay, I can agree with that.
16:49:02 [Zakim]
16:49:24 [TabAtkins_]
TabAtkins_: The point is that a break just does the equivalent of putting a big spacer element in there.
16:49:36 [TabAtkins_]
antonp: If you glue the boxes back together, it's the total height.
16:49:42 [Bert]
(The key is "consumes height", the border may indeed not even reach the bottom of the page.)
16:49:58 [TabAtkins_]
glazou: Objections?
16:50:17 [TabAtkins_]
RESOLVED: Conclusion by fantasai about breaking, above, accepted.
16:51:09 [Zakim]
16:51:26 [TabAtkins_]
Topic: Counter Styles
16:51:27 [glazou]
16:51:33 [glazou]
sylvaing: lol
16:51:40 [TabAtkins_]
fantasai: I think florian's issue is that he'd like the counter styles that weren't in 2.1 to be marked as at-risk.
16:52:33 [TabAtkins_]
TabAtkins_: I'm fine with marking all the non-2.1 styles (the 2.0 styles, and the replacement CJK styles) as at-risk.
16:52:37 [Zakim]
16:52:43 [TabAtkins_]
RESOLVED: Mark the non-2.1 Counter Styles as at-risk.
16:53:18 [Zakim]
16:53:19 [TabAtkins_]
glazou: I have one additional thing.
16:53:26 [fantasai]
Zakim, ??P33 is fantasai
16:53:26 [Zakim]
+fantasai; got it
16:53:30 [TabAtkins_]
glazou: Koji, you're right that I missed CSS Ruby in the list of documents int he prioritization email.
16:53:38 [TabAtkins_]
glazou: So please consider it included. I missed it by accident.
16:53:44 [TabAtkins_]
arronei: I ahve another comment on that list.
16:54:02 [TabAtkins_]
arronei: Did you send that list to some influentials, like Molly or Designers?
16:54:09 [TabAtkins_]
glazou: The Invited Experts in the WG got it.
16:54:21 [TabAtkins_]
glazou: I didn't ping anyone outside the WG.
16:54:52 [TabAtkins_]
TabAtkins_: I think between our IEs we ahve enough "designer voice" to be useful - Molly, Lea, etc.
16:55:02 [glazou]
you heard well
16:56:41 [TabAtkins_]
sylvaing: I don't see anything in there that says "you ahve to be an implementor to answer this", but if Anton thought he shouldn't answer it...
16:56:49 [TabAtkins_]
glazou: Be sure that the entire WG's answer will be valued.
16:57:34 [TabAtkins_]
glazou: Lea, you have two faces in this group - on the one hand, you're W3C staff, on the other hand, you're an influential member of the design community. So we'd probably be interested in your more personal opinions.
16:57:42 [TabAtkins_]
leaverou: Like what devs would like the most? Sure.
16:58:00 [TabAtkins_]
glazou: So, everyone, ping your AC reps so we can get the surveys back in two weeks time.
16:58:16 [Zakim]
16:58:16 [Zakim]
16:58:17 [Zakim]
16:58:19 [Zakim]
16:58:20 [Zakim]
16:58:21 [Zakim]
16:58:28 [Zakim]
16:58:30 [Zakim]
- +1.206.324.aabb
16:58:32 [Zakim]
16:58:33 [Zakim]
16:58:36 [Zakim]
- +1.415.615.aaaa
16:58:40 [Zakim]
16:58:41 [Zakim]
16:58:48 [Zakim]
16:59:11 [Zakim]
16:59:12 [Zakim]
Style_CSS FP()12:00PM has ended
16:59:12 [Zakim]
Attendees were +1.415.615.aaaa, plinss, jdaggett, stearns, +1.206.324.aabb, glazou, +1.619.846.aacc, +93192aadd, lstorset, antonp, hober, leaverou, arronei, JohnJansen,
16:59:12 [Zakim]
... [Microsoft], fantasai, Bert, dbaron, koji, TabAtkins_
17:02:04 [rhauck]
rhauck has joined #css
17:04:34 [rhauck1]
rhauck1 has joined #css
17:11:18 [leaverou]
glazou: what's the best way to reply? Copy the table in the email client and fill it in? Is there something better?
17:11:20 [SteveZ]
SteveZ has joined #css
17:11:28 [leaverou]
e.g. a wiki
17:11:41 [glazou]
leaverou: no, copy/paste + email please
17:11:49 [TabAtkins_]
I was going to just make a list with headings for the priority categories.
17:12:01 [leaverou]
TabAtkins_: ah, that sounds better!
17:12:07 [glazou]
guys, NO
17:12:12 [leaverou]
17:12:18 [glazou]
some membres may request confidentiality
17:12:24 [glazou]
let Peter and I handle this
17:12:29 [TabAtkins_]
Yeah, I was saying for *my* response.
17:12:31 [glazou]
members even
17:12:32 [glazou]
17:12:33 [TabAtkins_]
That is, Google's.
17:12:36 [glazou]
ok then
17:13:07 [leaverou]
yes, i was talking about my response too
17:13:38 [leaverou]
ah, nevermind, I found a good way to do it with Apple’s Mail. I'll send the table
17:13:51 [leaverou]
for anyone interested: Right click the email, choose "Redirect"
17:13:59 [leaverou]
then you get the table without any quotation
17:15:26 [TabAtkins_]
In most clients, you can just select "forward" and then remove the additional headers it puts in. No additional quotation added.
17:16:36 [leaverou]
TabAtkins_: when you forward, the original message is usually in a quote
17:16:44 [TabAtkins_]
Not in Gmail, at least.
17:16:51 [leaverou]
I guess Gmail is an exception then
17:17:00 [leaverou]
Thunderbird and Apple’s Mail put it in a quote
17:18:38 [leaverou]
dbaron: you there?
17:18:54 [dbaron]
leaverou, yes
17:19:04 [leaverou]
dbaron: I had never seen color correction before
17:19:13 [leaverou]
may I ask
17:19:31 [leaverou]
Why is there only default and sRGB? What about specifying a custom color profile?
17:21:58 [dbaron]
leaverou, because the spec is trying to solve the problem that it describes in the abstract & introduction
17:22:28 [dbaron]
leaverou, which is finding a path through which we can migrate to actually being in a defined color space at all
17:22:48 [leaverou]
dbaron: so there are thoughts about extending it in the future to allow custom color profiles, right?
17:23:12 [dbaron]
leaverou, I'm not sure; images can, of course, have custom color profiles
17:23:19 [dbaron]
leaverou, but I'm not sure it's really that valuable for CSS colors
17:23:29 [drublic]
drublic has joined #css
17:23:45 [leaverou]
dbaron: It certainly would be valuable if cmyk() colors were allowed outside of paged media
17:23:52 [dbaron]
leaverou, cmyk() is a mess
17:24:01 [dbaron]
leaverou, there's no standard for what it means
17:24:20 [leaverou]
there are multiple color profiles that define how it converts to sRGB, non?
17:24:53 [dbaron]
leaverou, I've really got to run now, though
17:25:17 [dbaron]
leaverou, can talk more another time
17:25:29 [leaverou]
dbaron: sure, lets pick this up later
17:25:38 [leaverou]
I'm very interested in the topic
17:40:52 [leaverou]
glazou: the FXTF specs are missing, is that intentional?
17:43:45 [fantasai]
leaverou: I'm guessing css3-background is LI because it's implemented already?
17:43:54 [leaverou]
fantasai: exactly
17:43:57 [fantasai]
17:44:31 [leaverou]
once something is implemented in the big four, the community's interest shifts
17:44:42 [leaverou]
they don't really care much about the edge cases
17:44:45 [leaverou]
in my experience
17:47:14 [leaverou]
for example, background-clip is still not implemented correctly by WebKit, but nobody seems to care
17:50:21 [drublic]
drublic has joined #css
17:56:53 [dbaron]
dbaron has joined #css
18:02:26 [leaverou]
TabAtkins_: you there?
18:02:34 [arno1]
arno1 has joined #css
18:07:24 [TabAtkins_]
leaverou: pong
18:07:37 [arno1]
arno1 has joined #css
18:07:41 [leaverou]
TabAtkins_: I think I remember a discussion about this, but I can't find it
18:07:46 [leaverou]
in CSS hierarchies
18:07:57 [leaverou]
can you do things like .foo > & > .bar ?
18:08:39 [TabAtkins_]
The current state of the spec, no. Just this morning I sent an email to Shane arguing that we should bite the bullet and allow it.
18:08:58 [leaverou]
TabAtkins_: ha, nice coincidence. Was that email to a list?
18:09:10 [leaverou]
TabAtkins_: I've recently started using LESS to experiment a bit with these concepts
18:09:13 [TabAtkins_]
Nah, private.
18:09:15 [leaverou]
and even though LESS doesn't allow it
18:09:20 [leaverou]
I think it would be immensely useful
18:09:26 [TabAtkins_]
LESS doesn't allow it? Sass does.
18:09:29 [leaverou]
e..g. When using .foo as a "conditional" type of thing
18:10:10 [leaverou]
e.g. I want the h1 to be styled this way, but when inside section#foo I want it to be styled a bit differently, but I still want to have everything in one place
18:10:20 [TabAtkins_]
Yeah, definitely. Clear and obvious use-cases.
18:10:32 [TabAtkins_]
I'm surprised that LESS doesnt' support it, but that's why Sass is better.
18:11:39 [leaverou]
TabAtkins_: also, does it allow @media rules to be nested inside it?
18:11:58 [leaverou]
e.g. I want this heading to be styled this way, but another way in print
18:11:59 [TabAtkins_]
Not yet. That's another, separate thing I'd like to make happen.
18:12:09 [leaverou]
18:12:13 [TabAtkins_]
Unrelated to Hierarchies - that should be part of Conditional.
18:14:27 [leaverou]
TabAtkins_: I'm not sure about that. I'm not talking about nesting @rules inside @rules, I'm talking about nesting @rules in CSS rules
18:14:35 [TabAtkins_]
18:14:53 [TabAtkins_]
The problems that make Hierarchies somewhat difficult are non-existent for nesting at-rules.
18:15:03 [leaverou]
and still be able to use & inside the @rule
18:18:55 [leaverou]
TabAtkins_: also, is & still necessary in the beginning? I remember there was a parsing issue?
18:19:17 [TabAtkins_]
That's the issue I was talking about up above.
18:19:36 [leaverou]
is it that you have to lookahead to more tokens to realize it's a nested rule?
18:19:51 [TabAtkins_]
Theoretically, it requires infinite lookahead to disambiguate, yeah.
18:20:07 [leaverou]
due to pseudo classes, I guess?
18:20:10 [TabAtkins_]
In practice, it requires 1-token lookahead for anything in HTML, and three-token for virtually anything in arbitrary XML.
18:20:27 [TabAtkins_]
Yeah, "a:hover" looks like a property named "a" with a value starting with the keyword "hover".
18:20:54 [leaverou]
oh, why is it different for XML? I'd guess due to namespaces, but I don't see the collision
18:21:18 [TabAtkins_]
HTML has a limited set of tagnames. XML has infinite.
18:21:32 [TabAtkins_]
There are no collisions between html tagnames and CSS properties so far. (SVG has 5.)
18:21:38 [leaverou]
authors can still use invalid arbitary tag names in HTML
18:21:45 [leaverou]
and CSS is still supposed to style them
18:21:51 [leaverou]
though I'm not sure that's specced
18:22:10 [TabAtkins_]
Sure, but that's okay.
18:22:38 [leaverou]
also, CSS has to remain forwards compatible, we can't restrict the tag selector to only known tag names, right?
18:22:51 [TabAtkins_]
Just check the first three tokens. If they look like "ident colon ident", interpret as a selector. Otherwise, interpret as a property.
18:23:06 [TabAtkins_]
This effectively means we're requiring a space on at least one side fo the colon in properties.
18:23:54 [leaverou]
TabAtkins_: could they still look like ident colon ident and look as a declaration?
18:24:22 [leaverou]
for example, border-style:solid
18:24:37 [TabAtkins_]
No, because of forward-compat. We don't want legacy browsers to break when we add new tagnames or pseudoclasses.
18:24:38 [leaverou]
18:24:59 [leaverou]
that's exactly what I'm saying
18:25:33 [leaverou]
my IRC client isn't helping much, it has this weird bug where I have to type /reload style to get new messages sometimes
18:26:07 [leaverou]
my IRC client (Colloquy) isn't helping much, it has this weird bug where I have to type / reload style to get new messages sometimes
18:26:21 [jet]
jet has joined #CSS
18:26:38 [leaverou]
including my messages, e.g. it seemed I didn't send this until I did that, which is why I sent it twice :(
18:27:07 [TabAtkins_]
18:27:24 [leaverou]
it only does it on W3C rooms for some reason, both private and public
18:31:03 [leaverou]
TabAtkins_: anyway, what I was saying is that many CSS files don't use a space after the colon for declarations. Especially minified CSS. We can't require that.
18:34:16 [TabAtkins_]
Then we're stuck. Shrug.
18:34:48 [leaverou]
18:38:19 [leaverou]
TabAtkins_: is there a mailing list discussion about this problem? Perhaps someone else has an idea of how to solve it
18:48:57 [dbaron]
dbaron has joined #css
19:13:31 [Zakim]
Zakim has left #css
19:53:52 [arno]
arno has joined #css
20:00:45 [drublic]
drublic has joined #css
21:06:42 [dbaron]
dbaron has joined #css
21:33:29 [arno]
arno has joined #css
21:59:56 [shepazu]
shepazu has joined #css
22:02:08 [cabanier]
cabanier has joined #css
23:26:21 [dbaron]
Hmmm, so, when I'm leaving Lyon after TPAC... would I rather leave at 5:50am from the train station or 7:35am from the airport? I think that's pretty close to a wash in terms of when I need to wake up, and it's also basically a wash in terms of price...
23:27:32 [isherman]
isherman has joined #css
23:33:19 [isherman]
isherman has joined #css
23:35:23 [stearns]
dbaron: the train ride might have better scenery once the sun came up