15:20:54 <RRSAgent> RRSAgent has joined #css
15:20:54 <RRSAgent> logging to http://www.w3.org/2013/03/27-css-irc
15:20:58 <glazou> Zakim, this will be Style
15:20:59 <Zakim> ok, glazou; I see Style_CSS FP()12:00PM scheduled to start in 40 minutes
15:21:03 <glazou> RRSAgent, make logs public
15:23:29 <lmclister> lmclister has joined #css
15:26:18 <glazou> Regrets: hober, molly, TabAtkins_ , SimonPieters
15:28:00 <Ms2ger> Ms2ger has joined #css
15:28:50 <lmclister> lmclister has joined #css
15:32:37 <sgalineau> sgalineau has joined #css
15:38:26 <sgalineau> sgalineau has joined #css
15:47:44 <BradK> BradK has joined #CSS
15:53:59 <florian> florian has joined #css
15:56:06 <glazou> Zakim, code?
15:56:06 <Zakim> the conference code is 78953 (tel:+1.617.761.6200 sip:zakim@voip.w3.org), glazou
15:56:18 <Zakim> Style_CSS FP()12:00PM has now started
15:56:27 <SimonSapin> SimonSapin has joined #css
15:56:39 <dbaron> dbaron has joined #css
15:57:01 <Zakim> +??P31
15:57:01 <Zakim> +[IPcaller]
15:57:08 <glazou> Zakim, ??P31 is me
15:57:10 <Zakim> +glazou; got it
15:57:37 <plh> plh has joined #css
15:57:43 <florian> Zakim, [IPcaller] has me
15:57:44 <Zakim> +florian; got it
15:57:53 <Zakim> +BradK
15:57:55 <plh> regrets for the call. overloaded :(
15:57:58 <Dael> Dael has joined #css
15:58:19 <glazou> ok
15:58:26 <glazou> Regrets: +plh
15:58:33 <glazou> Regrets: hober, molly, TabAtkins_ , SimonPieters
15:59:10 <Zakim> +SimonSapin
15:59:23 <krit> krit has joined #css
15:59:26 <Zakim> +[IPcaller.a]
15:59:34 <Zakim> +plinss
15:59:46 <Zakim> +krit
15:59:47 <Dael> zakim, IPcaller.a is me
15:59:47 <Zakim> +Dael; got it
15:59:51 <rhauck> rhauck has joined #css
16:00:01 <Zakim> +glenn
16:00:06 <Zakim> -glazou
16:00:19 <Zakim> +??P49
16:00:22 <Zakim> +??P9
16:00:30 <glazou> Zakim, ??P9 is me
16:00:30 <Zakim> + +93192aaaa
16:00:30 <Zakim> +glazou; got it
16:00:43 <{Darktears}> Zakim, ??P49 is me
16:00:43 <Zakim> +{Darktears}; got it
16:00:46 <antonp> Zakim, aaaa is me
16:00:46 <Zakim> +antonp; got it
16:00:52 <Zakim> +[Microsoft]
16:01:05 <Zakim> +nvdbleek
16:01:18 <glazou> Zakim, who is noisy?
16:01:28 <Zakim> glazou, listening for 10 seconds I heard sound from the following: antonp (4%), [Microsoft] (50%)
16:01:53 <Zakim> -krit
16:01:55 <Zakim> + +1.206.675.aabb
16:01:56 <Zakim> +Bert
16:01:57 <Zakim> +dbaron
16:01:59 <glazou> Zakim, [Microsoft] has israel
16:01:59 <Zakim> +israel; got it
16:02:05 <smfr> smfr has joined #css
16:02:06 <sgalineau> Zakim, aabb is me
16:02:06 <Zakim> +sgalineau; got it
16:02:19 <Rossen> Rossen has joined #css
16:02:33 <Zakim> +[Microsoft.a]
16:02:35 <Zakim> +fantasai
16:02:37 <Zakim> +Krit
16:02:39 <Zakim> +krit.a
16:02:43 <Rossen> zakim, microsoft has me
16:02:43 <Zakim> +Rossen; got it
16:02:50 <Zakim> +smfr
16:03:00 <Zakim> +Stearns
16:03:03 <rhauck> zakim, krit.a is me
16:03:03 <Zakim> +rhauck; got it
16:03:12 <krit> rhauck: sure?
16:03:37 <glazou> Zakim, who is noisy?
16:03:42 <Zakim> -Krit
16:03:43 <Zakim> +Lea
16:03:50 <Zakim> glazou, listening for 10 seconds I heard sound from the following: sgalineau (27%)
16:03:53 <SimonSapin> SimonSapin has joined #css
16:03:55 <Zakim> +[Microsoft.aa]
16:03:58 <glazou> Zakim, mute sgalineau
16:03:58 <Zakim> sgalineau should now be muted
16:04:14 <JohnJansen> JohnJansen has joined #CSS
16:04:18 <glazou> Zakim, unmute sgalineau
16:04:20 <Zakim> sgalineau should no longer be muted
16:04:20 <Zakim> +Krit
16:04:34 <JohnJansen> Zakim, Microsoft has JohnJansen
16:04:35 <Zakim> +JohnJansen; got it
16:04:39 <Zakim> +ChrisL
16:04:39 <glazou> Zakim, who is on the phone?
16:04:39 <Zakim> On the phone I see [IPcaller], BradK, SimonSapin, Dael, plinss, glenn, {Darktears}, glazou, antonp, [Microsoft], nvdbleek, sgalineau, Bert, dbaron, fantasai, [Microsoft.a], rhauck,
16:04:43 <Zakim> ... smfr, Stearns, Lea, [Microsoft.aa], Krit, ChrisL
16:04:43 <Zakim> [IPcaller] has florian
16:04:43 <Zakim> [Microsoft] has JohnJansen
16:04:43 <Zakim> +SteveZ
16:05:03 <glazou> eheh
16:05:12 <Israelh_MS> Israelh_MS has joined #css
16:05:36 <antonp> ScribeNick: antonp
16:05:38 <SteveZ> SteveZ has joined #css
16:05:44 <Dael> yes
16:05:55 <marakow> marakow has joined #CSS
16:06:03 <Dael> having some audio problem so can't talk
16:06:13 <Dael> Okay, thank you
16:06:25 <antonp> TOPIC: extra items for agenda
16:06:29 <antonp> glazou: no
16:06:31 <antonp> TOPIC: Publications
16:06:34 <dbaron> http://lists.w3.org/Archives/Public/www-style/2013Mar/0600.html
16:06:49 <antonp> glazou: Request from dbaron to publish FPWD of css3-overflow
16:07:05 <antonp> dbaron: I added Section 2
16:07:21 <antonp> ... Would be great if others could read that
16:07:29 <shepazu> shepazu has joined #css
16:07:39 <jdovey> jdovey has joined #css
16:07:56 <antonp> florian: I like the draft but have issues with overflow-x/y and so I'd like to review that section to flag possible problems
16:08:17 <antonp> ?: has there been any implementation activity on this?
16:08:24 <Ms2ger> Ms2ger has joined #css
16:08:35 <antonp> ??: Where does this sit in the group's priority list, charter etc?
16:08:39 <Zakim> +jdovey
16:08:44 <stearns> s/??/stearns/
16:09:05 <antonp> florian: I wonder how much interest in Opera there is
16:09:18 <antonp> glazou: Old charter expires in Sept, and this isn't currently charter
16:09:33 <antonp> ...: We occassionally enforce the deliverables in the charter
16:09:43 <antonp> dbaron: This is mostly moving things from other docs into this one
16:09:50 <antonp> ...: which is not generally a charter problem
16:10:01 <antonp> ChrisL: That's correct
16:10:32 <antonp> dbaron: The new thing [fragment overflow?] is new but is an alternative to something that already exists in another doc
16:10:40 <antonp> glazou: Are you OK with a week for the WG to review?
16:10:42 <antonp> dbaron: yes
16:10:51 <antonp> glazou: What is the priority of this spec, to you?
16:11:09 <antonp> dbaron: I've heard implementers say that they are interested
16:11:20 <antonp> florian: I'd like this to make progress, though I'm not implementing anything
16:11:27 <stearns> whether overflow:fragments is an alternative is debatable - I consider it an addition
16:11:34 <antonp> Rossen: Is this targetting various layout models, not just block?
16:11:52 <antonp> ...: A lot of text is copied from css21 but it should be generalized
16:12:12 <antonp> dbaron: It applies to block and flex containers.  It's intentional that it doesn't apply to eg inline
16:12:23 <antonp> Rossen: Grid is a valid target spec
16:12:26 <nvdbleek2> zakim, mute me
16:12:26 <Zakim> nvdbleek should now be muted
16:12:28 <antonp> <speaking at once>
16:12:45 <antonp> fantasai: Grid containers are defined in the grid spec right now
16:12:47 <antonp> dbaron: OK
16:13:22 <antonp> florian: You specified overflow-x/y but don't carry over the definition of overflow-style - yet there is overlap.  Although I don't like overflow-style we should avoid overlap
16:13:27 <Zakim> +[Microsoft.aaa]
16:13:27 <arronei> zakim, microsoft has me
16:13:27 <Zakim> +arronei; got it
16:13:40 <antonp> dbaron: overflow-style is pretty much dead as far as I can tell
16:13:50 <antonp> florian: overflow-paged?
16:13:51 <antonp> dbaron: yes
16:14:05 <antonp> florian: <something about Opera>. Probably nobody
16:14:13 <antonp> Bert: overflow-style came from Marquee spec
16:14:24 <antonp> ChrisL: sounds fairly dead
16:14:54 <antonp> Bert: We introduced it to allow various different ways of overflowing, not just Opera's but things like marquees and thumbnails
16:15:06 <antonp> glazou: I don't think this discussion is relevant to the current topic
16:15:25 <antonp> florian: (It's a good discussion)
16:15:34 <antonp> ...: we should have it at some point.
16:15:53 <Zakim> -Lea
16:15:53 <fantasai> I think fragments should not be an overflow-style, but paged vs. scroll should be
16:16:06 <antonp> glazou: 1 week for WG to review, then decision next week?
16:16:08 <antonp> dbaron: OK
16:16:15 <antonp> ACTION on everyone: review doc
16:16:15 <trackbot> Error finding 'on'. You can review and register nicknames at <http://www.w3.org/Style/CSS/Tracker/users>.
16:16:32 <antonp> TOPIC: Grid Layout (followup from last week)
16:16:40 <antonp> glazou: Rossen wanted a week to review the doc
16:16:54 <antonp> Rossen: We're OK overall with going forward with a publishing a new WD
16:17:03 <antonp> ...: I have feedback, but can use mailing list for that
16:17:12 <antonp> ... No blockers for now
16:17:22 <antonp> glazou: Any objections to advancing the doc?
16:17:26 <Zakim> +Lea
16:17:31 <antonp> RESOLVED: Publish grid layout spec
16:17:44 <antonp> TOPIC: issue 6 for css3 text decoration
16:18:05 <antonp> dbaron: I have a better URL for Issue 6 other than the one in the Disposition of Comments from yesterday
16:18:07 <dbaron> http://lists.w3.org/Archives/Public/www-style/2013Mar/0529.html
16:18:18 <dbaron> http://lists.w3.org/Archives/Public/www-style/2013Mar/index.html#msg534
16:18:28 <koji> koji has joined #css
16:18:28 <antonp> dbaron: I also sent a bunch of other messages <see second URL>
16:18:41 <antonp> dbaron: I don't quite know how to proceed, given the other issues
16:19:13 <antonp> dbaron: I'd rather discuss on the mailing list; I haven't seen responses to them.  Don't know if fantasai agrees
16:19:35 <antonp> fantasai: I haven't seen all of these yet
16:19:40 <antonp> glazou: OK, let's move on
16:19:52 <antonp> TOPIC: vertical % margins and padding on flexbox
16:20:00 <glazou> http://lists.w3.org/Archives/Public/www-style/2013Mar/0143.html
16:20:02 <antonp> dbaron: Not necessarily /from/ me, but I wanted to poke the issue
16:20:07 <glazou> http://lists.w3.org/Archives/Public/www-style/2013Mar/0143.html
16:20:14 <glazou> http://lists.w3.org/Archives/Public/www-style/2013Mar/thread.html#msg143
16:20:18 <antonp> ... people are shipping implementations of flexbox and this is a change proposal
16:20:26 <antonp> ... I'm curious about the status
16:21:02 <antonp> fantasai: When you have margins on a block el, the vert margin (block direction margins) resolve against the size of the container in the inline dimension
16:21:43 <antonp> flexbox doesn't say anything about this being different for flex items, whereas grid does specify that % margins are relative to the same dimension
16:21:49 <antonp> ... so there's an inconsistency
16:22:12 <antonp> ...: for blocks, height of containing block isn't defined, so % margins relative to that wouldn't be defined commonly
16:22:29 <antonp> ...: for flexbox that reasoning doesn't apply so much (nor for grid)
16:22:50 <antonp> s/isn't defined/isn't defined commonly/
16:23:16 <antonp> <fantasai describes flexbox behaviour>
16:23:25 <antonp> glazou: Implementors?
16:23:55 <antonp> dbaron: I'm fine with switching, but it seems odd for different display types to behave differently.  I'd prefer to do it sooner rather than later though.
16:24:13 <antonp> Rossen: Matching flexbox behaviour to grid makes sense, will help app developers
16:24:19 <fantasai> fantasai: another issue is that the inconsistency in dimensions is particularly confusing for Flexbox: e.g. for row flexboxes percentage margins would work in the main axis, but for column flex boxes they wouldn't
16:24:30 <Ms2ger`> Ms2ger` has joined #css
16:24:47 <antonp> ... The inconsistency will be overcome by authors soon enough.
16:25:12 <antonp> RESOLVED: We copy the behaviour of % margins/paddings from grid to flexbox
16:25:24 <antonp> TOPIC: media queries and data transfer
16:25:24 <glazou> http://lists.w3.org/Archives/Public/www-style/2013Jan/0434.html
16:25:30 <glazou> http://lists.w3.org/Archives/Public/www-style/2013Jan/0522.html
16:25:52 <antonp> dbaron: ?? raised this is an issue initially.  I don't want to solve it today, but again I wanted to poke it.
16:26:03 <stearns> s/??/henri/
16:26:17 <glazou> s/henri/hsivonen
16:26:18 <antonp> dbaron: Lack of a CSS solution is pushing other groups to push HTTP solutions, which I and others don't think is ideal
16:26:42 <antonp> <dbaron explains the issue>
16:27:19 <Zakim> -[IPcaller]
16:27:25 <antonp> dbaron: The proposal is a proposal to add something to HTML, to the LINK element which links to the stylesheet, saying that the stylesheet shouldn't be retrieved [....]
16:27:52 <antonp> fantasai: can't we do that by default, that UI shouldn't fetch stylesheets if it thinks it's not used (matched)?
16:27:53 <Zakim> +[IPcaller]
16:28:05 <antonp> .... and not loaded into object model unless explicitly requested
16:28:32 <antonp> dbaron: Implementations would be unhappy about doing it for print
16:29:24 <antonp> fantasai: the UI wouldn't download SSs that it knows it's not going to use, but if it thinks it might use the SS then it would load it, at lower priority, but not into the object model until it matched
16:29:25 <antonp> dbaron: device width/height can change when you rotate a mobile device
16:29:33 <teoli> teoli has joined #css
16:30:19 <antonp> dbaron: Original design was to make it harder for authors to mess up accidentally
16:30:44 <antonp> dbaron: Consider the mail as authoritative
16:31:09 <antonp> ... about the summary/description of the topic
16:31:51 <antonp> dbaron: This is probably and HTML group topic
16:32:00 <antonp> .. but people here should be aware of it
16:32:35 <antonp> florian: Thought/Question: a stylesheet included from within a CSS conditional (supports) should also be deferred?
16:32:42 <fantasai> I'm worried we're going to get "async all the things!" from some authors and "what's an async? i don't know that feature, so my sites don't use it" from others
16:33:03 <fantasai> would be best if the default behavior was more optimal
16:33:32 <fantasai> then force loading or not loading if needed
16:33:35 <antonp> florian: If we allow 'defer' or whatever on the style element so that it applies to inline style, I'd like it to be compatible for @import inside @supports
16:33:50 <Bert> (I wonder what this does to phishing and privacy. One reason to favor MQ over CC/PP was that MQ can hide the UA's characteristics and user preferences.)
16:33:53 <antonp> florian: Can we put suggestions to the HTML group
16:33:58 <antonp> dbaron: I'll ask Henri to
16:34:06 <glazou> http://lists.w3.org/Archives/Public/www-style/2013Feb/thread.html#msg323
16:34:13 <antonp> TOPIC: CaretPosition.getClientRect() (new API)
16:34:29 <antonp> dbaron: I wanted to seek comments from non-Mozilla people
16:34:44 <fantasai> http://lists.w3.org/Archives/Public/www-style/2013Feb/0323.html
16:35:12 <antonp> dbaron: CaretPosition is interesting; it usually corresponds to a collapsed range, but allows to get caret position from inside input or text area
16:35:31 <antonp> glazou: makes sense
16:35:40 <antonp> smfr: Fine for me
16:35:56 <Zakim> -Lea
16:35:57 <antonp> Rossen: I'm still catching up on the topic, sorry
16:36:25 <antonp> Rossen: if this isn't urgent I'd like to involve someone else and get back to you
16:36:34 <antonp> dbaron: That's fine, but I wanted to poke it
16:36:50 <antonp> glazou: let's revisit later when we have Rossen's input
16:36:56 <glazou> http://lists.w3.org/Archives/Public/www-style/2013Mar/0573.html
16:37:01 <Zakim> +Lea
16:37:02 <stearns> http://lists.w3.org/Archives/Public/www-style/2013Mar/0414.html
16:37:06 <antonp> TOPIC: click events and ::hover styling in styleable fragment containers
16:37:18 <antonp> stearns: I have a long message on the list, with only one response
16:37:46 <antonp> ... main issue: DOM tree, visual box tree; click events and :hover styling propagate only from DOM tree, which leaves out fragment containers
16:37:58 <antonp> ... would be good to apply these to fragment containers
16:38:01 <antonp> ... 4 options
16:38:01 <zcorpan> zcorpan has joined #css
16:38:15 <antonp> ... 1. Interleave frag container into event propagation somehow
16:38:29 <antonp> 2. Fork the propagation to have two different propagation chains
16:38:42 <antonp> 3. (Only works for events)
16:39:06 <antonp> 4. Have a switch: either use the current DOM tree behaviour or with a switch allow you to move up the visual container hierarchy]
16:39:31 <antonp> glazou: I responded, saying I like the 4th solution, especially thinking about pointer events
16:40:07 <antonp> .... solves an old issue about hovering positioned elements too, which exists as a note in the selectors spec
16:40:31 <antonp> stearns: The solution that I put out would only deal with the frag containers, but I suppose it could be extended to this situation too
16:40:37 <antonp> glazou: it's a similar situation
16:40:39 <Zakim> -SimonSapin
16:40:51 <antonp> Rossen: Talking about containing block chain, instead of DOM structure, glazou?
16:40:53 <antonp> glazou: yes
16:41:07 <antonp> Rossen: I can see this potentially being extended to cover both
16:41:16 <antonp> glazou: yes, there's a possibility to extend it.
16:41:22 <Zakim> +SimonSapin
16:41:24 <antonp> ... overall, pointer events strategy seems good
16:41:43 <antonp> dbaron: I'm concerned about CSS properties being changed on event propagation
16:41:49 <antonp> BradK: I don't like switch
16:41:51 <dbaron> s/being changed/changing/
16:41:58 <dbaron> s/changing on/changing/
16:42:02 <sgalineau> baron, doesn't pointer-event do that to some extent already?
16:42:33 <antonp> <stearns refers to example in his mail, about pages>
16:42:46 <fantasai> sgalineau, not really. It changes the geometry of the target only, atm
16:43:08 <sgalineau> fantasai, you can use it to prevent an element from capturing events
16:43:17 <antonp> stearns: I'm happy to try out option 4, unless there's anyone who prefers any of the three previous options
16:43:32 <antonp> fantasai: I'm not DOM or events person but second one looks like it could be OK
16:43:45 <fantasai> I'm sympathetic to dbaron's concern about layering, but I'll also note that propagating through the region parenting is entirely controlled by CSS
16:43:48 <antonp> stearns: 2nd one is about duplicate event which goes up the visual hierarchy
16:44:00 <Zakim> -Lea
16:44:08 <Zakim> -Krit
16:44:16 <antonp> fantasai: concern with 4th one: pointer events changes the geometry with respect to pointer clicks, but doesn't change anything else
16:44:42 <fantasai> sgalineau, That's equivalent to making its geometry match the empty set of points
16:44:46 <antonp> sgalineau: You're changing which way it's routing
16:44:54 <antonp> fantasai: It's like making it hidden
16:45:24 <antonp> sgalineau: if a different node gets the event, you get a different route
16:45:26 <antonp> fantasai: no
16:45:29 <antonp> sgalineau: yes
16:45:33 <Zakim> +Lea
16:45:49 <fantasai> You're just changing what got hit, not what the routing is after the hit
16:46:07 <sgalineau> disagree; another node behind you gets the event and may not be your parent afaik.
16:46:21 <antonp> glazou: there are use cases for web designers
16:46:29 <antonp> glazou: we need a solution.
16:46:43 <fantasai> sgalineau, right, but you didn't hit that because it wasn't "visible". You didn't change the routing of the event bubble chain, you changed its target
16:46:49 <antonp> glazou: Is it OK if stearns starts proposing a solution of some kind, eg based on 4th option?
16:47:23 <antonp> stearns: I'll post to list saying we're going with option 4.  Some of the discussion we've just had should be replicated on the list please
16:47:28 <sgalineau> if a CSS property causes a different element from capture/bubbling then we already are doing this
16:47:48 <antonp> RESOLVED: stears to post to list with a solution based on option 4
16:47:54 <glazou> http://lists.w3.org/Archives/Public/www-style/2013Mar/0573.html
16:48:01 <antonp> TOPIC: Changes to offsetParent in styleable fragment containers
16:48:21 <antonp> stearns: Question for named flows and a bit for shadow DOM and its insertion points
16:48:34 <antonp> ...: What are the offset attributes for?
16:49:14 <antonp> Are they for getting some relative position to a box on the page, or is it meant to provide the offsets to the closest visual ancestor which has something to do with the box's position?
16:49:48 <antonp> stearns: DOM structure vs Visual box
16:50:08 <antonp> stearns: I wanted to poke this issue because I didn't get any response on the list
16:50:17 <antonp> smfr: Why do authors use the offset attrs?
16:50:40 <antonp> .. we've talked about adding API allowing point conversion between elements
16:50:49 <antonp> ... if we have that, we don't need offset-top stuff
16:51:01 <antonp> smfr: Maybe we should push for that API
16:51:25 <antonp> We'd have to do something sensible for offset-parent, but doesn't matter too much if implementations differ a bit
16:51:51 <antonp> stearns: I'm ok with the idea that if it's not interoperable anyway then let's not fix it
16:52:36 <antonp> TOPIC: Reissue css3-values CR?, followup from last week
16:52:36 <glenn> glenn: suggest discussing with roc and boris (zbasky)
16:52:38 <Zakim> -ChrisL
16:52:40 <glazou> https://lists.w3.org/Archives/Member/w3c-css-wg/2013JanMar/0349.html
16:52:59 <Ms2ger`> Public link?
16:53:09 <fantasai> Tab and I think it's time to reissue CR on css3-values, since
16:53:09 <fantasai> we've made a few clarifications. They're listed here: http://dev.w3.org/csswg/css3-values/#changes
16:53:12 <fantasai> Let us know if we missed any; I remember Alan mentioned something
16:53:14 <fantasai> and I can't remember if it was one of these or something else. :/
16:53:28 <Ms2ger`> Ta
16:53:33 <SimonSapin> http://www.w3.org/mid/514AD389.8060008@exyr.org
16:53:37 <Zakim> +ChrisL
16:54:19 <glenn> s/zbasky/zbarsky/
16:54:26 <antonp> fantasai: Any other issues to be handled before CR?
16:55:01 <antonp> dbaron: I wonder if viewport units should say that it counts the scrollbars when overflow is scroll, rather than the current cumbersome description
16:55:04 <fantasai> ACTION fantasai clarify interaction of viewport units and scroll
16:55:04 <trackbot> Created ACTION-551 - Clarify interaction of viewport units and scroll [on Elika Etemad - due 2013-04-03].
16:55:08 <stearns> I don't remember what my issue might have been
16:55:09 <fantasai> ACTION fantasai Edit in Simon's issue
16:55:09 <trackbot> Created ACTION-552 - Edit in Simon's issue [on Elika Etemad - due 2013-04-03].
16:55:28 <antonp> SimonSapin: I'm fine with resolving with last weeks resolution
16:55:35 <antonp> glazou: any objections?
16:55:47 <antonp> RESOLVED: publish new CR for css3-values
16:56:05 <antonp> fantasai: I'll prepare it for Tuesday (doing edits today) and I'll inform the mailing list
16:56:17 <antonp> ..: there'll be space to tweak it between now and next week
16:56:20 <glazou> http://lists.w3.org/Archives/Public/www-style/2013Mar/0275.html
16:56:32 <antonp> TOPIC: Renaming :matches(), followup from last week
16:56:49 <Bert> (I'm offline Monday, but Elika probably doesn't need my help wth the publication anyway :-) )
16:57:18 <antonp> fantasai: SimonSapin_ sent the e-mail that we said someone would send last week
16:57:30 <antonp> glazou: so no resolution right now?
16:57:56 <antonp> SimonSapin: feedback: currently does not allow combinators inside matches, so matches with only one argument isn't very useful
16:58:16 <antonp> selectors4 is concerned with performance, but we can remove that restriction
16:58:29 <antonp> ^ fantasai said the above
16:58:48 <antonp> fantasai: Tab and I discussed the idea of different levels of selector support for this featur
16:59:07 <antonp> glazou: let's defer to mailing list
16:59:15 <antonp> TOPIC: extra stuff
17:00:06 <antonp> glazou: 72 hours e-mail: in case of a decision which has to be made technically on the mailing list, there's a tag in the summary indicating 72 hours for providing objections
17:00:23 <antonp> ...: it's a clean way of making a decision to avoid topics dying off
17:00:38 <antonp> fantasai: Pretty good idea, but don't pull it up with no warning
17:01:01 <antonp> ChrisL: if it's kicked off by a telecon, then we should be ok
17:01:06 <antonp> <general agreement>
17:01:30 <Zakim> -nvdbleek
17:01:54 <antonp> antonp: if we do this, please mention it in the summary of the minutes of the telecon so that it's easy to see that it's happened
17:02:14 <antonp> <general agreement from various speakers>
17:02:29 <Zakim> -[Microsoft.aa]
17:02:30 <Zakim> -sgalineau
17:02:31 <Zakim> -SteveZ
17:02:33 <Zakim> -[Microsoft.aaa]
17:02:33 <Zakim> -BradK
17:02:34 <Zakim> -dbaron
17:02:35 <Zakim> -Stearns
17:02:36 <Zakim> -glazou
17:02:36 <Zakim> -ChrisL
17:02:36 <Zakim> -jdovey
17:02:36 <Zakim> -glenn
17:02:36 <Zakim> -[Microsoft.a]
17:02:38 <Zakim> -antonp
17:02:39 <Zakim> -Lea
17:02:40 <Zakim> -rhauck
17:02:41 <Zakim> -plinss
17:02:43 <Zakim> -{Darktears}
17:02:43 <Zakim> -Bert
17:02:45 <Zakim> -Dael
17:02:46 <Zakim> -smfr
17:02:57 <Zakim> -fantasai
17:02:58 <Zakim> -SimonSapin
17:02:58 <Zakim> -[IPcaller]
17:03:20 <fantasai> ok, so publish grid-layout and css3-values...
17:06:07 <marakow> marakow has left #css
17:07:58 <Zakim> disconnecting the lone participant, [Microsoft], in Style_CSS FP()12:00PM
17:08:01 <Zakim> Style_CSS FP()12:00PM has ended
17:08:01 <Zakim> Attendees were glazou, florian, BradK, SimonSapin, [IPcaller], plinss, krit, Dael, glenn, +93192aaaa, {Darktears}, antonp, nvdbleek, +1.206.675.aabb, Bert, dbaron, israel,
17:08:02 <Zakim> ... sgalineau, [Microsoft], fantasai, Rossen, smfr, Stearns, rhauck, Lea, JohnJansen, ChrisL, SteveZ, jdovey, arronei
17:12:15 <rhauck> rhauck has joined #css
17:24:12 <rhauck> rhauck has joined #css
17:29:52 <cabanier> cabanier has joined #css
17:40:51 <glazou> dbaron, will you attend the css3-conditional call?
17:54:33 <mihnea> mihnea has joined #css
17:56:55 <dbaron> glazou, yes
17:57:03 <glazou> ok thanks
18:00:59 <isherman-book> isherman-book has joined #css
18:02:09 <rhauck1> rhauck1 has joined #css
18:08:59 <logbot> logbot has joined #css
18:15:16 <Zakim> Zakim has left #css
18:33:45 <darktears> darktears has joined #css
18:54:08 <glenn> glenn has joined #css
19:29:38 <sgalineau> sgalineau has joined #css
19:31:25 <darktears> darktears has joined #css
19:31:38 <glenn> glenn has joined #css
19:43:47 <rhauck> rhauck has joined #css
19:47:41 <abucur> abucur has left #css
19:49:07 <krit1> krit1 has joined #css
19:52:06 <florian> florian has joined #css
20:10:15 <teoli> teoli has joined #css
20:30:56 <dbaron> dbaron has joined #css
21:04:52 <TabAtkins__> TabAtkins__ has joined #css
21:05:24 <TabAtkins__> Yo, fantasai, I think I've finished the first draft of Colors 4.
21:07:17 <stearns> TabAtkins_: fantasai: I'm confused by "A value of ‘auto’ for ‘align-self’ computes to the value of ‘align-items’ on the element's parent, or ‘stretch’ if the element has no parent." in flexbox - how can a flex item have no parent?
21:08:13 <TabAtkins__> If the element isn't part of a flexbox.  Setting align-self: auto; on <html> needs to be defined.
21:09:39 <stearns> seems like it only comes up for <html> - if an element has a non-flexbox parent, there's still a value of align-items to refer to
21:12:31 <abucur> abucur has joined #css
21:14:38 <TabAtkins__> TabAtkins__ has joined #css
21:15:31 <TabAtkins__> stearns: Yes, that's correct.  We just have to deal with the error case any time we talk about "the parent of an element".
21:18:19 <stearns> ok, thanks
21:27:26 <slightlyoff> slightlyoff has joined #css
21:29:01 <jarek> jarek has joined #css
21:36:28 <ojan> ojan has joined #css
21:40:09 <sgalineau> sgalineau has joined #css
21:42:30 <sawrubh> sawrubh has joined #css
21:50:57 <sgalineau> sgalineau has joined #css
21:56:29 <darktears> darktears has joined #css
22:04:11 <darktears> darktears has joined #css
22:04:28 <glenn> glenn has joined #css
22:33:16 <dbaron> dbaron has joined #css
22:40:55 <dbaron_> dbaron_ has joined #css
22:41:08 <plh> plh has joined #css
23:19:48 <glenn> glenn has joined #css
23:32:04 <glenn_> glenn_ has joined #css
23:45:21 <SimonSapin> SimonSapin has joined #css
23:50:44 <glenn> glenn has joined #css
23:51:49 <stearns> TabAtkins_: Is there a reason you went with order 2,1,3 in the holy grail flexbox example, instead of just order: -1; for nav?