15:23:27 <RRSAgent> RRSAgent has joined #css
15:23:27 <RRSAgent> logging to http://www.w3.org/2013/07/17-css-irc
15:23:34 <glazou> Zakim, this will be Style
15:23:34 <Zakim> ok, glazou; I see Style_CSS FP()12:00PM scheduled to start in 37 minutes
15:23:38 <glazou> RRSAgent, make logs public
15:23:46 <glazou> glazou has changed the topic to: http://lists.w3.org/Archives/Public/www-style/2013Jul/0425.html
15:30:18 <florian> florian has joined #css
15:36:43 <SimonSapin> do we have "fuzzy reftests" where up to some number of different pixels is acceptable?
15:37:56 <Ms2ger> Nope
15:38:25 <SimonSapin> :/
15:39:08 <SimonSapin> Should I add new tests in incoming or a submitted?
15:39:58 <SimonSapin> http://wiki.csswg.org/test/css2.1/contribute says submitted
15:40:17 <stearns> SimonSapin: incoming is your scratch space. submitted is for tests you think are ready
15:41:26 <SimonSapin> stearns: I have reftests passing in Gecko. I think they’re ready but I haven’t really been reviewed
15:41:39 <stearns> SimonSapin: submitted, then
15:43:47 <SimonSapin> they also test details that are not in the spec yet, some of of which don’t have a WG resolution yet
15:45:34 <dbaron> dbaron has joined #css
15:49:48 <antonp> antonp has joined #css
15:51:02 <fantasai> SimonSapin: submitted is probably fine. Put the issues on the WG agenda
15:51:29 <SimonSapin> "Painting area and 'background-attachment: local'" is already on the agenda for today
15:53:06 <fantasai> didn't we figure it out already?
15:54:05 <SimonSapin> fantasai: positioning yes
15:54:18 <SimonSapin> painting/clipping, there are two parts
15:54:46 <cabanier> cabanier has joined #css
15:55:12 <SimonSapin> I think we have consensus that values of background-clip should represent the same rectangles as background-origin, ie. scroll with the content. (No WG resolution yet)
15:56:14 <Zakim> Style_CSS FP()12:00PM has now started
15:56:21 <Zakim> +??P5
15:56:24 <glazou> Zakim, ??P5 is me
15:56:24 <Zakim> +glazou; got it
15:56:34 <fantasai> I'm happy to say it's implied from the previous resolution. Doesn't make sense otherwise...
15:56:38 <SimonSapin> But I also proposed that if a background layer is attached to the scrolled content, it should be clipped like the scrolled content because of 'overflow'
15:56:46 <Zakim> +plinss
15:57:11 <SimonSapin> … and thus not paint below the border
15:57:24 <Rossen> Rossen has joined #css
15:57:37 <SimonSapin> fantasai, see https://test.csswg.org/shepherd/testcase/attachment-local-clipping-color-6/spec/css-backgrounds-3/ and its ref
15:58:29 <Zakim> +??P19
15:58:34 <Zakim> +??P21
15:58:37 <glenn> zakim, ??p19 is me
15:58:37 <Zakim> +glenn; got it
15:58:41 <lmclister> lmclister has joined #css
15:58:47 <SimonSapin> Zakim, ??P21 is me
15:58:47 <Zakim> +SimonSapin; got it
15:59:05 <Zakim> +[IPcaller]
15:59:14 <florian> Zakim, [IPcaller] has me
15:59:14 <Zakim> +florian; got it
15:59:36 <Zakim> +[Microsoft]
15:59:45 <Rossen> zakim, microsoft has me
15:59:47 <Zakim> +Rossen; got it
16:00:03 <leif> leif has joined #css
16:00:14 <rhauck> rhauck has joined #css
16:00:17 <JohnJansen> JohnJansen has joined #CSS
16:00:46 <dael> dael has joined #css
16:00:49 <nvdbleek> zakim, code?
16:00:49 <Zakim> the conference code is 78953 (tel:+1.617.761.6200 sip:zakim@voip.w3.org), nvdbleek
16:01:06 <koji> koji has joined #css
16:01:07 <Zakim> + +34.93.192.aaaa
16:01:12 <Zakim> +??P33
16:01:13 <antonp> Zakim, aaaa is me
16:01:14 <Zakim> +antonp; got it
16:01:19 <leif> Zakim, I am ??P33
16:01:19 <Zakim> +leif; got it
16:01:26 <Zakim> + +1.610.324.aabb
16:01:30 <Zakim> +nvdbleek
16:01:31 <leif> Zakim, mute me
16:01:31 <Zakim> leif was already muted, leif
16:01:34 <dael> zakim, aabb is me
16:01:34 <Zakim> +dael; got it
16:01:36 <nvdbleek> zakim, mute me
16:01:36 <Zakim> nvdbleek should now be muted
16:01:47 <Zakim> +Bert
16:02:53 <ChrisL> ChrisL has joined #css
16:03:07 <smfr> smfr has joined #css
16:03:12 <Zakim> +fantasai
16:04:12 <Zakim> +smfr
16:04:37 <Zakim> +Lea
16:05:11 <Zakim> +dbaron
16:05:19 <antonp> ScribeNick: antonp
16:05:32 <antonp> TOPIC: extra items
16:05:50 <glazou> leaverou, will be hotter later in the week and next week ; already 35+ in the south
16:05:55 <antonp> Rossen: A css-shapes issue I wanted to add, medium priority
16:05:57 <Zakim> + +33.6.03.00.aacc
16:06:04 <glazou> leaverou, had 42 a while ago in south-west
16:06:12 <shezbaig_wk> shezbaig_wk has joined #css
16:06:31 <antonp> TOPIC: Invited expert
16:06:40 <ChrisL> +1
16:06:44 <Bert> +1
16:06:48 <Zakim> + +1.212.318.aadd
16:06:49 <smfr> +1
16:06:50 <antonp> plinss: Lea will be leaving W3C, want to bring her back into the WG as an Invited Expert
16:06:51 <dbaron> +1
16:06:52 <florian> Florian: +1
16:06:57 <leaverou> :D
16:06:58 <SimonSapin> +1
16:07:00 <fantasai> +1
16:07:00 <shezbaig_wk> zakim, aadd is me
16:07:00 <Zakim> +shezbaig_wk; got it
16:07:03 <ChrisL> wb lea
16:07:05 <leaverou> thank you all so much!!!
16:07:13 <Rossen> ++
16:07:14 <MaRakow> MaRakow has joined #CSS
16:07:18 <antonp> RESOLVED: Lea is back!!
16:07:37 <antonp> TOPIC: Paris F2F
16:07:47 <antonp> glazou: Dates etc?  Please could Mozilla comment
16:07:54 <antonp> dbaron: OK
16:08:08 <antonp> TOPIC: Positioned Layout Status
16:08:41 <antonp> arronei: I'm still around ;-)  Paying attention but also working on other things
16:09:20 <antonp> arronei: In a F2F about a year ago, we agreed to add Ted as an Editor, but I haven't seen any updates
16:09:29 <antonp> arronei: I'd prefer another editor to help me out
16:09:33 <Zakim> +[Microsoft.a]
16:09:37 <Zakim> -glenn
16:09:43 <antonp> .. This spec isn't going to be a priority for me
16:09:50 <MaRakow> Zakim, [Microsoft.a] is me
16:09:51 <Zakim> +MaRakow; got it
16:10:00 <antonp> Rossen: The spec only has a couple of issues; can't we try to push it out of the door
16:10:20 <antonp> .. It contains a load of css21 stuff, plus a couple of other things worth reviewing and possibly moving to LC
16:10:30 <Zakim> +??P19
16:10:39 <glenn> zakim, ??p19 is me
16:10:39 <Zakim> +glenn; got it
16:10:47 <antonp> Rossen: Are you guys (smfr) still gonna work on position:Sticky?
16:11:03 <antonp> smfr: Yeah we're interested in that area, but not sure we'll be involved in speccing
16:11:13 <antonp> smfr: ...
16:11:26 <antonp> dbaron: He's an intern, will be around for a couple of months
16:11:34 <Zakim> +SteveZ
16:11:42 <antonp> Rossen: Sounds like there's interest in Sticky, but not interest in the positioning spec!
16:11:59 <antonp> ...: if somebody provides content, we can get it into the positioning spec
16:12:12 <antonp> fantasai: propose that spec = css21 + sticky
16:12:19 <antonp> Rossen: That's pretty much what it already is
16:12:31 <antonp> fantasai: Tab and I could help out on the spec after the summer, maybe
16:12:48 <antonp> Rossen: Let's take up the Sticky conversation on the mailing list
16:12:52 <antonp> dbaron: sounds good
16:13:01 <antonp> TOPIC: Dropping default
16:13:08 <antonp> http://lists.w3.org/Archives/Public/www-style/2013Jul/0021.html
16:13:37 <antonp> fantasai: 'default' keyword doesn't have a good use case
16:13:49 <antonp> .. Places where it could help have other solutions possible
16:14:14 <glazou> +1 on the confusing name...
16:14:21 <antonp> .. Even if we go with the proposed "initial or inherit" definition of 'default', the word 'default' is a confusing name
16:14:41 <glenn> q+
16:14:53 <israelh> israelh has joined #css
16:15:01 <antonp> .. Default style in CSSOM doesn't refer to "initial or inherit", it refers to something else, so again confusing.
16:15:15 <antonp> So first proposal is drop 'default
16:15:32 <antonp> Second is have a value called 'initial-or-inherit'
16:15:43 <antonp> florian: let's wait for use case before creating the keyword!
16:15:58 <c_palmer> c_palmer has joined #css
16:15:59 <antonp> ChrisL: name sounds reasonable for what it is
16:16:06 <leaverou> florian++
16:16:26 <antonp> .. What authors really want is a way of saying "I wish I'd never set these rules" - and we don't havethat
16:16:43 <Zakim> +[IPcaller.a]
16:16:49 <koji> zakim, [ipcaller.a] is me
16:16:49 <Zakim> +koji; got it
16:17:01 <Zakim> +shezbaig_wk.a
16:17:03 <antonp> dbaron: the use case is a low-level thing.  Sometimes amount to explaining how existing things work
16:17:11 <antonp> .. authors like reset stylesheets
16:17:23 <antonp> .. We introduced 'all' property, which only makes sense with this value
16:17:42 <plinss> ack glenn
16:17:53 <antonp> Glenn: TGML[?] uses: default is a generic font family name, so uses it as a keyword effectively
16:18:13 <antonp> fantasai: CSS spec reserves 'default'.  In retrospect, maybe wasn't such a good idea
16:18:17 <plinss> s/TGML/TTML/
16:18:18 <ChrisL> s/TGML/TTML/
16:18:31 <antonp> florian: Calling it undeclared/reset avoids the issues we've been raising
16:18:40 <antonp> Rossen: "reset" is weird
16:18:51 <florian> s/undeclared/undeclare/
16:18:52 <Bert> q+ to say it seems 'all' is only useful with 'inherit-or-initial' and vice-versa. That suggests 'all' is maybe not a property at all.
16:18:58 <antonp> fantasai: Use case: the 'all' shorthand
16:19:08 <antonp> .. that's the use case that makes most sense
16:19:29 <antonp> Rossen: Sounds like an infrequent use case.  The longer "inherit-or-initial" is more descriptive
16:19:35 <antonp> florian: It's a little ambiguous to me
16:19:38 <dbaron> s/only makes sense with this value/only makes sense with this value.  I think if we drop this we should drop 'all'./
16:19:54 <antonp> florian: If you know cascade well, it might be obvious.  Otherwise, you don't know what it's going to do!
16:19:59 <antonp> .. Hence prefer undeclared
16:20:03 <plinss> ack next
16:20:05 <Zakim> Bert, you wanted to say it seems 'all' is only useful with 'inherit-or-initial' and vice-versa. That suggests 'all' is maybe not a property at all.
16:20:10 <plinss> ack next
16:20:17 <antonp> Bert: Agreed that use case is 'all' property
16:20:29 <glenn> btw, 'default' wasn't a reserved keyword in CSS2 (1998) which was what TTML originally referenced
16:20:33 <antonp> .. so maybe think of that case as something other than a property, eg an @-rule
16:20:42 <Rossen> width: reset; - this is a bit weird
16:20:46 <plinss> q?
16:20:49 <fantasai> I guess, 'reset' for 'initial-or-inherit' and 'unset' for 'default', both useful for 'all'
16:20:51 <Rossen> width: unset
16:20:52 <antonp> .. Only useful with !important added, else you don't reset everything??
16:21:16 <antonp> antonp: I quite like 'unset'
16:21:18 <antonp> Rossen: +1
16:21:35 <antonp> fantasai: 'reset' is good for 'initial-or-inherit' I guess
16:21:48 <ChrisL> ChrisL has joined #css
16:21:50 <antonp> Rossen: when you say "with reset" it sounds like a layout instruction rather than a cascaed instruction
16:21:53 <ChrisL> IS UNSET ALLOWED ON SHORTHANDS AND IF SO IS IT FULLY SPECIFIED?
16:21:56 <antonp> .. 'unset' doesn't suffer from that.
16:22:02 <ChrisL> oops caps
16:22:03 <leaverou> the good thing about all is that people already know it from transition-property
16:22:06 <fantasai> ChrisL, yes
16:22:06 <plinss> q=
16:22:13 <plinss> queue=
16:22:13 <antonp> florian: +1 for unset
16:22:15 <ChrisL> ChrisL has joined #css
16:22:37 <antonp> ChrisL: Is it allowed on shorthands, and is it fully specified
16:22:40 <fantasai> http://dev.w3.org/csswg/css-cascade/#inherit-initial
16:22:41 <antonp> fantasai: yes
16:23:10 <antonp> leaverou: Is 'unset' going to be a property?
16:23:16 <antonp> fantasai: no, a value
16:23:43 <antonp> fantasai: One concern: "all" shorthand, you might want the behaviour that's currently specified for 'default'
16:24:01 <antonp> .. you might want to say "Blow everything away but leave UA stylesheet intact"
16:24:12 <antonp> dbaron: That's sort of what you have with the new version of 'default'
16:24:15 <antonp> fantasai: yes, exactly
16:24:40 <antonp> fantasai: that's the only use case I can think of for 'default' that isn't handled well at the moment
16:25:06 <dbaron> original proposal: https://lists.w3.org/Archives/Member/w3c-css-wg/2002OctDec/0191.html
16:25:08 <antonp> florian: Does "default" only leave UA and User stylesheets, or does it remove either/or of those?
16:25:20 <antonp> fantasai: It removes whichever stylesheet (user/author) you're in#
16:25:41 <antonp> fantasai: Dunno, maybe it's not needed
16:25:54 <antonp> fantasai: I haven't quite fully thought through
16:26:15 <antonp> dbaron: Concern about fiddling with the name: we've had it on the table for over 10 years and made it a reserved keyword in lots of places#
16:26:27 <dbaron> s/lots of/a bunch of/
16:26:34 <antonp> florian: we wouldn't be the first group to do that ;-)
16:26:46 <antonp> glazou: nor the first time the group has spent 10 years not doing something ;-)
16:27:11 <antonp> florian: I think "unset" is clear; I don't expect many fonts to be called that
16:27:24 <dbaron> dbaron: Though if the name is obscure enough, we'd probably be oke.
16:27:40 <antonp> (switch order of dbaron and florian's comments)
16:27:55 <antonp> glazou: Will implementors implement it in the timeframe of PR?
16:28:05 <antonp> fantasai: initial-or-inherit behaviour will be very straightforward
16:28:11 <antonp> dbaron: +1; an hour's work
16:28:27 <antonp> Bert: I don't think that's the right argument. Rather, how useful is this?
16:28:43 <antonp> fantasai: "all" shorthand is the most important use case, which isn't particularly important
16:28:57 <dbaron> I would object to dropping this value without dropping the 'all' shorthand as well.
16:29:24 <antonp> The only value which makes sense for "all" is "initial" and this.  (inherit is useless)
16:29:37 <antonp> (fantasai said that ^^)
16:29:43 <antonp> (ie the above)
16:29:54 <dbaron> dbaron: I don't think 'all: inherit' is useless in the presence of things like 'display: contents'.
16:30:04 <antonp> fantasai: OK, /almost/ never useful ;-)
16:30:43 <antonp> dbaron: <explains>
16:31:30 <antonp> fantasai: as dbaron says, you need this value or something like it in order for "all" shorthand to be useful
16:31:45 <antonp> Bert: why does a property only have one useful value?
16:32:09 <antonp> fantasai: either don't set, or set it to initial which breaks everything, or you set it to this value which allows inherited properties to inherit
16:32:29 <antonp> Bert: dbaron's example: same as setting "all" to new keyword, it seems to me
16:32:46 <antonp> dbaron: That might be true if it has exactly one child, but a bit different if more than one
16:33:11 <antonp> Bert: Setting on element, 'display' value gets reset (becomes inline)
16:33:18 <fantasai> s/everything/inheritance/
16:33:22 <antonp> dbaron: I think that's not true in flexbox, grid
16:33:38 <antonp> Bert: should be in grid.  Flexbox might be strange
16:33:50 <antonp> florian: We seemed to like "unset"
16:34:14 <antonp> .. as a new name for "initial-or-inherit"
16:34:25 <antonp> Bert: I think the name is fine, but I question the need for that value
16:34:50 <antonp> plinss: Do we drop "default"?
16:35:21 <antonp> fantasai: Proposal is to remove "default" and change the name of "initial-or-inherit" to "unset"
16:35:50 <antonp> fantasai: Taking the proposal in full, for "all" you don't have the option of saying "blow away my styles but leave UA styles intact"
16:36:07 <antonp> florian: In any case, you still have the !important playing around, right?
16:36:28 <antonp> .. so using that property in an author stylesheet would still leave !important user styles in place
16:36:31 <antonp> fantasai: correct
16:36:43 <antonp> fantasai: I'd like another week to think about this
16:37:02 <antonp> plinss: so revisit next week?
16:37:12 <antonp> .. OK.
16:37:21 <antonp> TOPIC: Grid auto-flow followup
16:37:31 <antonp> plinss: we had a resolution, Tab had a follow-up comment
16:37:37 <antonp> <Tab is on holiday>
16:37:38 <plinss> http://lists.w3.org/Archives/Public/www-style/2013Jul/0223.html
16:37:52 <ChrisL> ChrisL has joined #css
16:38:03 <antonp> plinss: e-mail about switch for dense vs sparse packing
16:38:25 <fantasai> http://lists.w3.org/Archives/Public/www-style/2013Jul/0226.html
16:38:41 <fantasai> propose to use tight or dense keyword (optional) in grid-auto-flow, if we want this
16:38:48 <antonp> Rossen: Based on their implementation, they've implemented 'dense' or are going to?
16:39:02 <antonp> fantasai: They've implemented dense packing for grid-auto-flow
16:39:14 <antonp> Rossen: HAving a switch shouldn't be a problem if the default is sparse
16:39:17 <antonp> fantasai: yeah
16:39:26 <antonp> fantasai: We can mark it at risk
16:39:29 <antonp> Rossen: I agree
16:39:38 <antonp> dbaron: Do we actually want this switch?
16:40:00 <antonp> Rossen: I'm not sure /we/ do.  In fact we don't want to implement dense because we haven't heard any demand
16:40:13 <antonp> .. If chrome is implementing it I'm guessing they have use case
16:40:20 <antonp> .. Currently we're not interested in dense
16:40:56 <antonp> plinss: anybody else implementing this?
16:40:58 <antonp> <silence>
16:41:08 <antonp> plinss: OK so we add it at risk
16:41:18 <antonp> Rossen: Now, or we wait for Tab to make a case for it on the call?
16:41:42 <antonp> Rossen: I'm with dbaron: I want to hear a case, not introduce it and then remove it down the line
16:41:57 <antonp> plinss: OK, defer until Tab comes back
16:42:07 <antonp> fantasai: are people happy with proposed syntax if we /do/ add it?
16:42:19 <antonp> <various agreement>
16:42:30 <antonp> plinss: Noted that we like the syntax.
16:42:52 <antonp> TOPIC: css-backgrounds] Painting area and 'background-attachment: local'
16:43:02 <antonp> SimonSapin: Two parts in the proposal to discuss separately
16:43:36 <antonp> http://lists.w3.org/Archives/Public/www-style/2013Jun/0276.html
16:43:45 <antonp> .. <explains issue>
16:44:39 <antonp> Rossen: So is the summary, "scroll the clip the same way that you want to scroll the background, given that it's local"
16:44:41 <antonp> SimonSapin: yes
16:44:49 <SimonSapin> https://test.csswg.org/shepherd/testcase/attachment-local-clipping-color-6/spec/css-backgrounds-3/
16:44:49 <antonp> SimonSapin: I have some test cases
16:44:52 <fantasai> ACTION: fantasai add diagrams to this section
16:44:52 <trackbot> Created ACTION-568 - Add diagrams to this section [on Elika Etemad - due 2013-07-24].
16:44:54 <SimonSapin> https://test.csswg.org/shepherd/reference/attachment-local-clipping-color-6-ref/spec/css-backgrounds-3/
16:45:26 <antonp> .. <explains>
16:46:00 <antonp> .. It's the same argument as the recent change for background-origin, ie consistency
16:46:24 <antonp> Rossen: In your ref, the clip will /not/ apply in this case?
16:46:27 <antonp> SimonSapin: What do you mean?
16:46:28 <Rossen> https://test.csswg.org/shepherd/repository/49f0d56a1c4a98ee4fec497c29412d89179fc012/contributors/mozilla/submitted/css3-background/background-attachment-local/attachment-local-clipping-color-6.html
16:46:38 <antonp> Rossen: IS this the test case you were referring to?
16:46:40 <antonp> SimonSapin: yes
16:46:47 <antonp> Rossen: this one has a clipped circle
16:46:52 <antonp> SimonSapin: yes, there's overflow hidden
16:47:12 <antonp> .. Background-attachment: clip only has an impact when overflow is other that visible
16:47:47 <dbaron> SimonSapin: In this case when you scroll, the white part at the top scrolls away because it's part of the scrolled content.
16:47:50 <antonp> Rossen: You propose we scroll the clipped circle as well?
16:48:00 <antonp> SimonSapin: yes, that's the second part of my proposal
16:48:41 <antonp> fantasai: How about I make some spec edits for this, and then we review them and see if they make sense?
16:48:46 <antonp> SimonSapin: Works for me
16:48:55 <antonp> Rossen: So we're not accepting anything until we have the edit
16:49:29 <antonp> SimonSapin: Second part of proposal: overflow:hidden and attach background local, makes sense that background should be clipped
16:49:42 <antonp> <explains>
16:50:02 <antonp> SimonSapin: Should behave just like it was set on another element inside the overflow:hidden element, which is indeed how the ref was built
16:50:36 <antonp> smfr: I'm confused; we don't have any spec text which describes how rounded corners affect the appearance of backgrounds
16:50:38 <antonp> fantasai: yeah we do
16:50:49 <fantasai> http://www.w3.org/TR/css3-background/#corner-clipping
16:51:04 <antonp> SimonSapin: I used rounded corners to make the test more obvious, but they're not necessary.  If you have a border which isn't completely opaque
16:51:21 <antonp> dbaron: You seem to be asking to switch an option behaviour to a required behaviour
16:51:34 <antonp> SimonSapin: It should have something that implies the same but for a different reason
16:52:09 <dbaron> SimonSapin: It's more complicated with rounded corners; you really want two clips.
16:52:48 <antonp> fantasai: I'm gonna edit the spec, and your issue is whether or not hte background is allowed to paint into the border area or not. Spec currently allows it, some imps do it.  You're proposing it not be allowed
16:53:01 <antonp> fantasai: I don't really have an opinion
16:53:51 <antonp> fantasai: It's a bit odd to have things outside of the scrollbar but scroll with the scrollbar
16:54:03 <fantasai> but doable, has been done
16:54:13 <antonp> SimonSapin: What is attached to the contents should be clipped with the contents.  Everything is derived from that.
16:54:38 <antonp> Rossen: That will break a bunch of optimizations that people may have done for scrolling
16:54:45 <antonp> .. so it might not get much traction
16:55:10 <antonp> .. For clipping ,and layering, inside of the scrollbar, for example, there may be optimizations when repainting
16:55:19 <antonp> .. If you allow to scroll outside, the optimizations are no longer valid
16:55:22 <ChrisL> ChrisL has joined #css
16:55:34 <antonp> SimonSapin: don't you have the same problem with background-attachmnet:local, even without my proposal?
16:55:54 <antonp> fantasai: I think everyone is confused.  Let's wait for the spec edits and then open an issue about whether the behaviour should be optional or required
16:56:12 <antonp> Bert: shouldn't it be to make the optional behaviour forbidden?
16:56:24 <antonp> fantasai: You're allowed to do two things. Only one should be allowed
16:56:32 <SimonSapin> https://test.csswg.org/shepherd/search/testcase/spec/css-backgrounds-3/load/t120/ attachment-* test
16:56:32 <antonp> Bert: not sure
16:56:58 <antonp> SimonSapin: ^ more tests, may help
16:57:17 <SimonSapin> SimonSapin: reftests. These are what *I think* should happen
16:57:25 <antonp> plinss: ETA of edits, fantasai?
16:57:30 <ChrisL> ChrisL has joined #css
16:57:32 <antonp> fantasai: I'll ping you when ready
16:57:49 <antonp> TOPIC: Rossen's shapes topic
16:57:56 <antonp> Rossen: applicability of shapes
16:58:06 <Rossen> http://lists.w3.org/Archives/Public/www-style/2013Jul/0286.html
16:58:08 <antonp> .. Alan made a couple of edits in the last round of edits for css-shapes
16:58:19 <ChrisL> ChrisL has joined #css
16:58:21 <israelh> israelh has joined #css
16:58:34 <antonp> .. he restricted the applicability of what shape-outside is allowed to apply to, and he made it apply to floats only
16:58:47 <antonp> .. The restriction at hte moment looks very artificial
16:59:15 <antonp> .. He seems to agree with that, and said that he didn't want to take a normative reference to the exclusions spec.  He didn't want hte specs tied
16:59:31 <antonp> Rossen: But I don't see why the restriction should be to floats and not include block-level block
16:59:50 <antonp> Rossen: if it applied to block-level block and implemented exclusions, can benefit
16:59:58 <antonp> dbaron: Say in the shapes spec applies to float
17:00:15 <dbaron> dbaron: ... and then say in the exclusions spec that it applies to more things
17:00:15 <antonp> .. and then say in the exclusions spec that that spec makes shapes apply to more thing
17:00:34 <Zakim> -glazou
17:00:50 <antonp> dbaron: I think that's perfectly reasonable in this set.  Shapes without exclusions doesn't make sense for it to apply to anything other than floats
17:01:04 <antonp> Rossen: Sure, and visually there will be no effect
17:01:14 <antonp> .. If you apply a shape to a non-exclusion, nothing will be visually different
17:01:32 <antonp> .. IF you want to see the effect, you have to apply it to exclusions
17:01:47 <Bert> q+ to suggest a note in the shapes spec to say that in the future, shapes may apply to more than floats.
17:01:51 <antonp> Rossen: It applies to block-level blocks, and if it happens to be an exclusion you'll see an effect
17:02:08 <antonp> dbaron: But the thing only applies to floats or exclusions!
17:02:16 <Zakim> -smfr
17:02:24 <smfr> smfr has left #css
17:02:30 <antonp> szilles: are you arguing over the difference between "Applies to" and "affects"
17:02:44 <antonp> dbaron: we often try to write the "Applies to" line in that way
17:02:59 <plinss> ack next
17:02:59 <Zakim> Bert, you wanted to suggest a note in the shapes spec to say that in the future, shapes may apply to more than floats.
17:03:15 <antonp> Bert: Applies To line should only apply to things that actually exist.  A note could say that the applicability can be extended later
17:03:37 <antonp> .. It's common to comment that things are expected to have wider applicability in the future
17:04:11 <Zakim> -SteveZ
17:04:18 <antonp> s/Bert,/Bert:/
17:04:35 <antonp> Rossen: as long as we're not excluding exclusions from applicability, I can live with that
17:04:49 <Zakim> -nvdbleek
17:04:56 <antonp> dbaron: IIUC then I'm ok with that
17:05:04 <Zakim> - +33.6.03.00.aacc
17:05:06 <Zakim> -dael
17:05:07 <Zakim> -dbaron
17:05:09 <Zakim> -fantasai
17:05:12 <Zakim> -Lea
17:05:13 <Zakim> -SimonSapin
17:05:13 <Zakim> -[Microsoft]
17:05:13 <Zakim> -antonp
17:05:13 <Zakim> -plinss
17:05:15 <Zakim> -glenn
17:05:17 <Zakim> -koji
17:05:19 <Zakim> -Bert
17:05:43 <Zakim> -MaRakow
17:06:09 <stearns> (just got out of my other meeting) Bert: the shapes draft does have a note mentioning that shapes will be extended later to exclusions
17:06:23 <Zakim> -shezbaig_wk
17:06:58 <Zakim> -leif
17:07:13 <leif> leif has left #css
17:15:26 <rhauck> rhauck has joined #css
17:19:33 <dbaron> SimonSapin, btw, your audio quality wasn't very good during the telecon today, which I think contributed to the confusion
17:22:13 <leaverou> yup, what dbaron said. I wanted to participate in that discussion, but could barely understand what Simon was saying
17:23:26 <Zakim> -shezbaig_wk.a
17:24:07 <Zakim> -[IPcaller]
17:24:08 <Zakim> Style_CSS FP()12:00PM has ended
17:24:08 <Zakim> Attendees were glazou, plinss, glenn, SimonSapin, florian, Rossen, +34.93.192.aaaa, antonp, leif, +1.610.324.aabb, nvdbleek, dael, Bert, fantasai, smfr, Lea, dbaron,
17:24:08 <Zakim> ... +33.6.03.00.aacc, +1.212.318.aadd, shezbaig_wk, [Microsoft], MaRakow, SteveZ, [IPcaller], koji
18:20:00 <SimonSapin> dbaron, leaverou: weird I got one of those special purpose headsets
18:28:12 <nvdbleek> nvdbleek has joined #css
18:37:27 <dbaron> dbaron has joined #css
19:06:33 <Zakim> Zakim has left #css
19:19:06 <SimonSapin> SimonSapin has joined #css
19:39:49 <glenn> glenn has joined #css
21:02:26 <fantasai> Bert: is counter-styles set to publish on Thursday?
21:03:46 <Bert> Hi Fantasai, yes, everything is ready. The webmaster will do the rest tomorrow.
21:10:25 <fantasai> Bert: great, thanks!
21:23:16 <fantasai> oh, right, the DoC
21:23:19 <fantasai> that's where they're tracked
21:25:35 <fantasai> Bert: btw, can you update the erratum for bug 15392 as resolved in http://lists.w3.org/Archives/Public/www-style/2013May/0201.html ?
21:25:48 <fantasai> Bert: we have a dependency on that to close an issue in Flexbox...
21:38:55 <liam> liam has joined #css
22:03:35 <rhauck1> rhauck1 has joined #css
23:18:12 <cabanier> cabanier has joined #css