15:19:16 <RRSAgent> RRSAgent has joined #css
15:19:16 <RRSAgent> logging to http://www.w3.org/2014/04/16-css-irc
15:19:20 <glazou> RRSAgent, make logs public
15:19:48 <glazou> glazou has changed the topic to: http://lists.w3.org/Archives/Public/www-style/2014Apr/0171.html
15:24:40 <krit> TabAtkins: Scientific notations are not allowed in V&U while they are in CSS 2.2. Should that be fixed in V&U? http://www.w3.org/TR/2013/CR-css3-values-20130730/#numbers
15:27:39 <TabAtkins> Yeah.
15:27:47 <SimonSapin> http://dev.w3.org/csswg/css-values/#numbers refers to Syntax which does have scinot
15:28:04 <SimonSapin> but also defines "zero or more decimal digits ..."
15:28:06 <TabAtkins> Yeah, but the informal definition doesn't mention that.
15:33:04 <antonp> antonp has joined #css
15:34:22 <Ms2ger> Ms2ger has joined #css
15:45:55 <gregwhitworth> gregwhitworth has joined #css
15:50:41 <dauwhe> dauwhe has joined #css
15:51:04 <glenn> glenn has joined #css
15:55:41 <dael> dael has joined #css
15:56:51 <Zakim> Style_CSS FP()12:00PM has now started
15:56:58 <Zakim> +dael
15:57:07 <dael> ScibeNick: dael
15:57:29 <Zakim> +??P3
15:57:33 <glazou> Zakim, ??P3 is me
15:57:33 <Zakim> +glazou; got it
15:57:42 <Zakim> + +1.720.897.aaaa
15:57:49 <glenn> zakim, aaaa is me
15:57:49 <Zakim> +glenn; got it
15:57:55 <ChrisL> ChrisL has joined #css
15:58:07 <Zakim> +dauwhe
15:58:17 <Zakim> +Stearns
15:58:58 <Zakim> +[IPcaller]
15:59:09 <Zakim> +SGalineau
15:59:32 <dauwhe> Zakim, IPcaller is AH_Miller
15:59:32 <Zakim> +AH_Miller; got it
16:00:12 <Zakim> + +1.281.305.aabb
16:00:20 <TabAtkins> zakim, aabb is me
16:00:20 <Zakim> +TabAtkins; got it
16:01:13 <Zakim> +??P5
16:01:21 <Zakim> +Bert
16:01:21 <Zakim> +fantasai
16:01:22 <SimonSapin> Zakim, ??P5 is me
16:01:23 <Zakim> +SimonSapin; got it
16:01:28 <SimonSapin> probably
16:02:12 <Zakim> +??P31
16:02:35 <gregwhitworth> Zakim ??P31 is me
16:02:44 <glazou> Zakim, ??P31 is gregwhitworth
16:02:44 <Zakim> +gregwhitworth; got it
16:02:55 <Zakim> +ChrisL
16:02:56 <bkardell_> bkardell_ has joined #css
16:03:19 <lmclister> lmclister has joined #css
16:03:54 <Zakim> +Plh
16:04:20 <dael> glazou:let's get started.
16:04:32 <dael> glazou: plinss isn't going to be here today.  Any extras? I saw TabAtkins's
16:04:43 <dael> Topic: Tab's Extra Item
16:04:46 <Zakim> +dbaron
16:04:58 <Zakim> +??P39
16:05:03 <dael> TabAtkins: The X unit says that if font metrics are impossible you can use a fallback, but ch doesn't have similar wording
16:05:14 <SimonSapin> s/X unit/ex unit/
16:05:20 <dael> ...: I jsut suggest we have similar wording that allows the fallback in the exact same cases
16:05:24 <dael> TabAtkins: Any obj?
16:05:28 <SimonSapin> s/fallback/fallback of 0.5em/
16:05:32 <dael> glazou: I saw ChrisL say he's okay
16:05:40 <MaRakow> MaRakow has joined #CSS
16:05:41 <dael> glazou: Any other opinoins? Objections?
16:05:45 <dael> glazou: No one cares?
16:05:46 <fantasai> seems fine to me
16:05:56 <dael> glazou: No obj?
16:05:58 <koji> koji has joined #css
16:06:01 <dbaron> I wouldn't want this fallback to happen too often, but it sounds ok
16:06:18 <dael> plh: There was an IRC comment that said it would be easier to just register ???
16:06:26 <dael> TabAtkins: That seems inconcistant with the X unit
16:06:31 <glazou> s/plh/SimonSapin
16:06:35 <dael> plh: I don't really have an opinion
16:06:37 <glazou> s/register/not support the ch unit
16:06:38 <Zakim> + +1.206.992.aacc
16:06:52 <MaRakow> zakim, aacc is me
16:06:53 <SteveZ> SteveZ has joined #css
16:06:53 <Zakim> +MaRakow; got it
16:07:03 <dael> TabAtkins: If it means syntax error you won't know it's font sruff after parsing time.  If it's something else you'll fail wierd so it may as well be as cose as possible
16:07:06 <dael> SimonSapin: Okay
16:07:09 <Zakim> +krit
16:07:09 <dael> glazou: Any obj?
16:07:16 <dbaron> s/X unit/ex unit/
16:07:20 <dael> RESOLVED: Default for CH unit is 0.5EM
16:07:30 <Zakim> +SteveZ
16:07:34 <dael> Topic:  Add -x/-y longhands to background-* properties
16:07:37 <glazou> http://lists.w3.org/Archives/Public/www-style/2014Apr/0085.html
16:08:00 <dael> TabAtkins: So several browsers, webkit blink have suppored backgroud-position x/y
16:08:27 <dael> TabAtkins: There's been some debate on this but I believe the plano n record is that we're going to add both varients of names and have a mechanisim to decide whigh
16:08:43 <dael> TabAtkins: That allows us to add both background-position and background-repeat x/y
16:08:53 <dael> TabAtkins: So I thinkw e should add because authors rely on it
16:09:14 <dael> TabAtkins: I think it gets odd with size, but we can make it work.  I'm not sure if there are others that need to be split, position, size and repeat
16:09:16 <Zakim> -glazou
16:09:20 <lmclister> lmclister has joined #css
16:09:35 <dael> dbaron: I'm definitly in favor of it for background-position, but I'd like to see data on who supports the others, esp. size
16:09:37 <Zakim> + +1.415.231.aadd
16:09:46 <dbaron> dbaron: ... b/c of the difficulties with cover and contain
16:09:50 <Zakim> +??P53
16:09:58 <dael> TabAtkins: I don't know if anyone does size, but webkit for repeat with some odd work arounds.  I'm not sure if anyone else does, though.
16:10:00 <glazou> Zakim, ??P53 is me
16:10:00 <Zakim> +glazou; got it
16:10:01 <plh> q+
16:10:03 <koji> zakim, +1.415.231.aadd is me
16:10:04 <Zakim> +koji; got it
16:10:09 <dael> ???: For IE we support it witht he value of repeat x and repeat y
16:10:18 <dael> TabAtkins: They background repeat prop with those keywords?
16:10:22 <gregwhitworth> Yeah I'm testing background-position-x and that doesn't work in IE
16:10:22 <dael> ???: Right
16:10:31 <gregwhitworth> So webkit only
16:10:33 <plh> q-
16:10:36 <dael> ???: We don't support individual prop, just the one property with those values
16:10:45 <Zakim> +BrianKardell
16:10:46 <MaRakow> s/???/MaRakow
16:10:52 <Bert> q+ to say the reason for bg-x/bg--y was sprites, but that reason no longer exists.
16:11:13 <dael> koji: I think that esp. fantasai or someone from Mozilla was opposed in the past.
16:11:14 <sylvaing_> Bert, why does it no longer exist?
16:11:18 <glazou> Zakim, code?
16:11:18 <Zakim> the conference code is 78953 (tel:+1.617.761.6200 sip:zakim@voip.w3.org), glazou
16:11:38 <dael> fantasai: It was largely b/c concern about interact with logical version of prop and if that's sorted, and I think it might be, than there's not reason not to
16:11:47 <Zakim> + +33.1.34.51.aaee
16:11:47 <Zakim> -glazou
16:11:51 <dael> fantasai: It's a question of if this is compart with start and end keywords
16:11:54 <glazou> Zakim, aaee is me
16:11:54 <Zakim> +glazou; got it
16:12:06 <dael> TabAtkins: Plan is to support background position block and other features.
16:12:19 <dael> koji: We had to use adjust position?
16:12:30 <dael> TabAtkins: Right now position and repeat.  Those are the two I'd like resolution on today
16:12:36 <dael> fantasai: I think we want more data on repeat
16:12:42 <dael> ...: Let's just position now
16:12:43 <TabAtkins> background-position-block/background-position-inline
16:12:54 <dael> TabAtkins: He asked who supported.
16:13:03 <dael> dbaron: So what are the values of repeat x/y?
16:13:10 <dael> TabAtkins: yes/no?
16:13:18 <dael> dbaron: I'm okay with position and repeat
16:13:25 <TabAtkins> s/yes\/no/repeat and no-repeat/
16:13:27 <dael> SimonSapin: I'd liek aproposal on how we'll do logical directions
16:13:38 <dael> fantasai: I think this should be B&B 4 along with the logical keyowrds
16:13:56 <dael> TabAtkins: I don't want to delay to 4 since it's not real yet and both these prop have been supported for a long time
16:14:10 <dael> ...: position can get into 3's CR and repeat could likely too
16:14:20 <dael> dbaron: I'd rather not add to 3.  We've done it too much.
16:14:35 <dael> koji: So if we do 4 it should be in version 1
16:14:46 <dael> fantasai: I think we should do this in 4 and people can support earlier.
16:14:48 <koji> s/koji/???/
16:14:49 <astearns> s/koji/krit/
16:15:01 <dael> fantasai: x and y have been around for a long time.
16:15:08 <dael> fantasai: We have a legacy prefix and clause
16:15:23 <dael> TabAtkins: So add background position and background repleat x/y?
16:15:48 <dael> plh: The reason to have these in the past was to quickly switch BG but now that we're using media segments, do we still need it?
16:16:07 <plh> s/plh/Bert/
16:16:08 <dael> s/plh/simonsapin
16:16:09 <Zakim> +??P2
16:16:12 <fantasai> s/segments/fragments/
16:16:18 <krit> s/o if we do 4 it should be in version 1/o if we do it in 3 it should be in version CSS Masking 1 as well?/
16:16:22 <dael> TabAtkins: No one supports media fragments yet
16:16:27 <fantasai> dbaron: Gecko supports it
16:16:37 <dael> TabAtkins: They're used commonly
16:16:45 <dael> glazou: dbaron did you say gecko supports?
16:16:46 <dbaron> ... or we're very close to it
16:16:50 <dael> dbaron: I'm not sure we're close
16:16:58 <Zakim> +??P4
16:17:00 <Zakim> -??P39
16:17:01 <dael> MaRakow: It'll be a while before people can depend on it
16:17:07 <glazou> q?
16:17:12 <Bert> q-
16:17:15 <sylvaing_> s/MaRakow/sgalineau
16:17:16 <Rossen_> Rossen_ has joined #css
16:17:30 <dael> fantasai: So one of the...this is different but in the images 4 draft we have a function that takes comma seperated list, but no one supports it
16:17:39 <kawabata> kawabata has joined #css
16:17:52 <dael> ...: But there were various reasons to support.  We marked comma seperated as at-risk and I think we should drop that.
16:18:07 <dael> ??: Webkit it is mostly the test suite that's missing.
16:18:13 <glazou> s/??/krit
16:18:15 <dael> TabAtkins: I can work on that now that I know it's a thing
16:18:21 <dael> fantasai: The test suite for what?
16:18:24 <dael> TabAtkins: Image function
16:18:38 <dael> fantasai: I still think we should push comma to level 4 and figure out how it can interact
16:18:44 <dael> TabAtkins: Can we defer since that's tangential?
16:18:47 <dael> fantasai: yes.
16:19:04 <dael> TabAtkins: So from before, are the obj to background position and background repeat x/y in Levl 4?
16:19:11 <dael> fantasai: I'm okay if we add logical keywords
16:19:13 <dael> TabAtkins: Sure.
16:19:19 <dael> glazou: Sounds like a compromise
16:19:26 <fantasai> s/keywords/keywords at the same time so we can make sure they work out correctly/
16:19:36 <dael> bert: I would like to have a follow-up resolution
16:19:39 <dael> glazou: Okay
16:20:00 <dael> glazou: Any obj to setting -x/-y to background-position?
16:20:01 <fantasai> s/bert/krit/
16:20:25 <dael> bert: I don't think we should add prop that make things confusiong for authors.  They asked for position that's great, but if they don't want something else we shouldn't
16:20:33 <dael> glazou: I think browsers are impl the longhands
16:20:59 <dael> ???: For the background repeat we support repeat-x repeat-y because we thought of those as mutually exclusing.  What would the both specify to repeat
16:21:11 <astearns> s/???/rossen/
16:21:15 <dael> TabAtkins: That's a longstanding part of BG.  Those values for position translate into longhand values.
16:21:32 <dael> ...: Balckgroun-repeat-x becomes background-repeat-x-repeat
16:21:50 <dael> rossen: So when I spec that they both repeat, are you saying only one repeats?
16:21:55 <jet> jet has joined #css
16:22:02 <dael> TabAtkins: That'st he repeat value.  it has four values, repeat on either end
16:22:06 <Bert> s/ They asked for position that's great, but if they don't want something else we shouldn't/They can use position already, so unless there is a really strong use case, don't add more redundant properties/
16:22:10 <dael> Rossen_: Okay, than it's fine.
16:22:15 <dael> glazou: So any objection?
16:22:16 <florian> florian has joined #css
16:22:39 <Zakim> -??P2
16:22:48 <dael> RESOLVED: background-position-x/y background-repeat-x/y approved
16:23:00 <Zakim> +??P2
16:23:02 <florian> florian has joined #css
16:23:07 <dael> krit: Should we also do this for ???
16:23:13 <dael> TabAtkins: I'm fine either way
16:23:14 <astearns> s/???/masking/
16:23:16 <ChrisL> s/???/masking
16:23:17 <dael> glazou: Is there a use case?
16:23:20 <dael> TabAtkins: I don't know
16:23:21 <kawabata> zakim, ??P2 is kawabata
16:23:21 <Zakim> +kawabata; got it
16:23:31 <Bert> (Resolved to put a proposal in level 4, not to put it in the existing level 3, as far as I understood.)
16:23:38 <Zakim> + +44.203.575.aaff
16:23:40 <krit> s/???/masking level 1/
16:23:40 <dael> krit: There's prefixing so perhaps we need it for alignment
16:23:46 <glazou> Bert, correct /cc dael
16:23:46 <dael> krit: It can wait for masking 2
16:23:46 <florian> Zakim, I am aaff
16:23:48 <Zakim> +florian; got it
16:23:57 <dael> bert, thanks
16:24:09 <dael> Topic: Image Orientation for Backgrounds
16:24:11 <glazou> http://lists.w3.org/Archives/Public/www-style/2014Apr/0149.html
16:24:17 <dael> glazou: This is something Boris posted
16:24:32 <dael> TabAtkins: I'd prefer for that to stay on list. Well, not syntax, but we can discuss idea
16:24:33 <SimonSapin> background-repeat/position: also, resolved to add logical directions at the same time
16:24:45 <dael> TabAtkins: Does anyone need refreser on idea?
16:24:48 <gregwhitworth> yes it would
16:24:49 <adenilson> adenilson has joined #css
16:25:01 <glazou> ChrisL, yes
16:25:05 <dael> TabAtkins: If you're familial with excess metadata, orientation can be whatever and some camera will record that.
16:25:06 <ChrisL> zakim, unmute me
16:25:06 <Zakim> ChrisL should no longer be muted
16:25:16 <dael> TabAtkins: So later it can be displayed however you held your camera
16:25:23 <sylvaing_> s/excess/EXIF
16:25:37 <dael> TabAtkins: The web doesn't normally care, it jsut displays the same as in image.  This would allow you to display how you took it.
16:26:12 <dael> TabAtkins: Boris brought up where people were asking to auto-apply the rotation in the background.  So the suggestion was to add this ti image function either as auto or as a keyword you can opt into
16:26:34 <BradK> BradK has joined #CSS
16:26:42 <dael> ChrisL: I think option 2 is better, first b/c some cameras get it wrong and sbecause some camera don't do it so people manually rotate.
16:26:53 <gregwhitworth> Not to mention it's possibly creates a huge compat issue
16:26:58 <dael> dbaron: I actually disagree b/c vast majority of cases, they want axis to be honored
16:27:09 <ChrisL> s/camera don/viewers don/
16:27:18 <dael> ...: If image always honors axis people will see it's wronga nd fix first so when we build new things we should honor
16:27:23 <dbaron> s/axis/exif/
16:27:27 <BradK> BradK has joined #CSS
16:27:27 <dael> TabAtkins: IF we by default, should there be a way to turn it off?
16:27:46 <dael> ChrisL: There's lots of content such as JPEG where it's not honored.  So we'd change exisiting webpages.
16:28:00 <dael> dbaron: We're not changing existing because it's only if people use this new feature
16:28:06 <dael> ChrisL: That's what I mean by opt-in
16:28:20 <dael> dbaron: We want to say all the features of this new thing rotate.
16:28:31 <Bert> (url() contiunues to ignore EXIF, but image() honors it. Subtle, but might just work...)
16:28:35 <dael> glazou: So the conclusion is this is a feature we want and want to continue tech on ML
16:28:51 <dael> TabAtkins: We may have resolved.  I'm okay if image() shoudl always respect axis metadata
16:28:55 <dael> dbaron: That's fine
16:29:04 <dbaron> that wasn't actually me, but I'm also fine with it
16:29:04 <dael> Bert: I think that's okay
16:29:13 <dael> florian: As long as it's contatined to image() it's fine
16:29:23 <ChrisL> \o/
16:29:26 <Bert> s/okay/okay, given that we don't have tests for it yet, anyway./
16:29:40 <TabAtkins> RESOLVED: Make the image() function always respect EXIF orientation metadata
16:30:02 <Zakim> +BradK
16:30:02 <sylvaing_> always or will we ever want an override in image()
16:30:04 <dael> fantasai: On that topic can we have the image() function drop comma seperation and decide if we want that level 4?
16:30:16 <dael> TabAtkins: I'm cool with that.  I'd like fallback to interop better so let's do that
16:30:37 <dael> bert: Wait, then youc an't extend image later and attach mediaquery liek features like adding images.
16:30:43 <astearns> s/bert/krit/
16:30:44 <dael> ...: Youc an't do that later w/o commas
16:30:53 <BradK> Zakim, who is here?
16:30:53 <Zakim> On the phone I see dael, glenn, dauwhe, Stearns, AH_Miller, SGalineau, TabAtkins, SimonSapin, Bert, fantasai, gregwhitworth, ChrisL, Plh, dbaron, MaRakow, krit, SteveZ, koji,
16:30:56 <Zakim> ... BrianKardell, glazou, ??P4, kawabata, florian, BradK
16:30:56 <Zakim> On IRC I see BradK, adenilson, florian, jet, kawabata, Rossen_, lmclister, SteveZ, koji, MaRakow, bkardell_, ChrisL, dael, glenn, dauwhe, gregwhitworth, Ms2ger, antonp, RRSAgent,
16:30:56 <Zakim> ... Zakim, glazou, AH_Miller, gsnedders, dbaron, plh, rodneyrehm, abucur, Garbee, arronei, renoirb, Teoli_, krit, mvujovic__, jacobg__, lmclister___, achicu___, TabAtkins,
16:30:58 <Zakim> ... cbiesinger_, dfreedm_, shepazu, liam, trackbot, Bert, ed, CSSWG_LogBot, Hixie, logbot, amtiskaw__, mihnea__, sylvaing_, heycam|away, decadance, SimonSapin, hober, cabanier__,
16:30:58 <Zakim> ... slightlyoff
16:31:02 <dael> TabAtkins: We're not removing commas, just the list feature.  We're recasting image() as petter url for images
16:31:03 <fantasai> http://www.w3.org/TR/2012/CR-css3-images-20120417/#image-fallbacks
16:31:17 <dael> fantasai: We're dropping this featuer, but keeping image framents and solid color images
16:31:30 <dael> krit: But not comma sep. values, just one value, one string
16:31:43 <dael> ...: That's a big step.  Wasn't iamge supposed to allow fallback features.
16:31:53 <dael> fantasai: That'st he internt, but we want to address in level 4.
16:32:15 <dael> ...: You may want to change which image due to supported, size of screen, and viasbility and there's no coherent solution.
16:32:38 <dael> fantasai: Since we have those requirements when we designed fallback, we want to come up with a soluttion that makes it work together.
16:32:58 <dael> fantasai: For now we know for sure we want axis metadata and solid color images to work as well as mediaqueries
16:33:08 <dael> fantasai: That's all straightforward and should stay in CR
16:33:19 <dael> krit: Do we need to rush or can we stay on ML
16:33:33 <dael> krit: You can get feedback so people that are interested can speak
16:33:37 <dael> TabAtkins: Are you impl?
16:33:44 <dael> krit: No, I know there's a patch.
16:33:58 <dael> krit: In general I don't feel confident resolving.  Can we talk next week?
16:34:12 <ChrisL> zakim, mute me
16:34:12 <Zakim> ChrisL should now be muted
16:34:20 <dael> ???: Quick question, if you want to override you'd have to do it manually or is there override?
16:34:27 <glazou> s//??/sgalineau
16:34:31 <dael> TabAtkins: Right now you'd have to do URL, but I'm fine with a keyword
16:34:49 <glazou> http://lists.w3.org/Archives/Public/www-style/2014Mar/0603.html
16:34:54 <SimonSapin> fantasai, EXIF orientation
16:34:58 <dael> Topic: Changing MediaQueryList to use events
16:35:21 <dael> TabAtkins: The thing returned by the match function has a custom fallback for when they stop matching.
16:35:41 <dael> ...: The suggestion is to switch to using the event listener.
16:36:04 <dael> TabAtkins: This is a very minor behaviour change if you're depending on specifics on how events vs callbacks are registered.
16:36:08 <dael> ...: I suspect that's rare
16:36:23 <dael> TabAtkins: The benefit is this makes us more standard event style and reduces special case code.
16:36:44 <dael> TabAtkins: Boris said there's no code, but Elliott from Blink said there's a lot of extra code to do this in Firefox, Webkit and Blink
16:36:53 <dael> ...: We'd liket o drop and use standard event proess
16:37:04 <dael> SimonSapin: If we're starting from scratch, sure, but this has been out
16:37:13 <SimonSapin> s/SimonSapin/florian/
16:37:15 <dbaron> I don't know where this extra code in Firefox is.
16:37:24 <dael> TabAtkins: You can move cleanly to the event-base except for a few edge cases that are difficult anyway
16:37:41 <dael> ...: Only change is timing and if you register the same function multiple times if it gets called once or twice
16:37:57 <dael> florian: If it's that tiny, why is it so much code?
16:38:11 <dael> TabAtkins: B/c it's re-impl a protion of what we do for events
16:38:23 <Zakim> -kawabata
16:38:28 <dael> TabAtkins: With events we do a few lines of hookup code which works.
16:38:54 <dael> TabAtkins: From the thread I don't believe there were strong obj. Boris had minor obj b/c he said it was easy in code, but Elliott pointed out it wasn't.
16:38:59 <dael> TabAtkins: Are there obj nw?
16:39:01 <BradK> sylvaing: I also question the use case for angle (something like [vertical | horizontal] seems better to me), but that's a separate topic.
16:39:07 <dael> dbaron: What are the rules?
16:39:17 <dael> TabAtkins: I don't know if current spec defines, but event spec does
16:39:18 <Zakim> +??P2
16:39:24 <dael> dbaron: What does event spec define as?
16:39:28 <dael> TabAtkins: I don't know
16:39:34 <dael> dbaron: I'd like to know before I agree.
16:39:48 <sylvaing_> BradK: yes. my understanding is that there is at most 4 angles here so <angle> seems odd
16:39:50 <kawabata> zakim, ??P2 is kawabata
16:39:50 <Zakim> +kawabata; got it
16:39:54 <dael> dbaron: I want any added lsiteners to not effect...Like if you add a new listener in the middle I want the event not to fire.
16:40:04 <dael> TabAtkins: Is that spec to mediaquery, or is this in general?
16:40:08 <dael> dbaron: I don't know.
16:40:39 <dael> dbaron: Part of the problem is you can fire the event on multiple lsiteners so multiple MQ change as a result of same thing.  Event spec will define a single event, but not multiple
16:40:47 <dael> TabAtkins: That's b/c it would be multiple callbacks
16:41:18 <dael> dbaron: What we have to define is a simgle thing causes multiple thigns to change.  The MQ change adds and event to another event that changed and does that event happen if it's fired later.
16:41:33 <dael> TabAtkins: It seems like you just want this to be well defined in general, not just in this case
16:41:36 <BradK> sylvaing: Spec has it rounding up to 90deg increments, but even so, seems to rely on knowledge of content of whatever page and image it is used on.
16:42:01 <dael> dbaron: I think the problem is if we make the change we'd have to define order.  IF you can define lsiteners that fire within eachother it matters what order they happen
16:42:10 <dael> TabAtkins: And I think the callbacks don't handle order
16:42:23 <dael> dbaron: Byt the callbacks don't effect eachother, at least not in Gecko
16:42:43 <dael> ???: Is that gecko specific?  B/c unless it's in spec we have the same problem
16:42:48 <dael> dbaron: So I guess I'm okay with it
16:42:49 <glazou> s/??/florian
16:43:01 <dael> TabAtkins: I'll post to the thread to make sure we get some discussion about that.
16:43:09 <sylvaing_> MaRakow: my initial suggestion was to have a flag that says 'behave like url()'. Specifying an orientation is something else...
16:43:14 <dael> glazou: Okay.  So discussion continues on ML
16:43:17 <glazou> http://lists.w3.org/Archives/Public/www-style/2014Apr/0112.html
16:43:22 <dael> Topic: Scrollbar Tracking Control
16:43:34 <dael> TabAtkins: This is an issue that i've been trying to bring up for a year.
16:43:35 <Zakim> -??P4
16:43:56 <dael> TabAtkins: It would be conventiant if CSS could declare a scrollbar in an element once it's close to the bottom attaches to the bottom
16:44:14 <dael> TabAtkins: This is common in chat windows and things were you continually add content to the bottomo f the list.
16:44:17 <sylvaing_> MaRakow: yeah, the idea was there is a feature of image() you want to use but you want the EXIF metadata ignored. not sure it matters. we'll see...
16:44:21 <Zakim> +[Microsoft]
16:44:33 <Rossen_> zakim, microsoft has me
16:44:33 <Zakim> +Rossen_; got it
16:44:44 <dael> TabAtkins: It's quite had to get this to work well.  Gmail has a constant fight witht he chat windows getting them to stick when the height can change unpredictably
16:44:59 <dael> TabAtkins: So have something where if a user scrolls a certain distance from the bottom it stays?
16:45:12 <dael> ???: Do we need a distance or can we say distance zero?
16:45:19 <florian> s/???/florian
16:45:29 <dael> dbaron: I was trying to find my objections and I think I've found them
16:45:45 <dael> dbaron: I think my biggest is that I think it's not particularly related to distance form edge
16:46:01 <dael> ...: it's more to which end the content shoulds tck to no matter where you are relative to the edge
16:46:14 <Zakim> -BrianKardell
16:46:21 <dael> dbaron: There's cases wehre people will add to top and you want to maintain scroll relative to top IE twitter
16:46:32 <dael> dbaron: So you want to hold scroll close to bottom
16:47:04 <dael> TabAtkins: Twitter adds content on both sides. So that would be if you're sufficently far from the content added so you adjust your scroll so the content doesn't move
16:47:04 <dbaron> http://lists.w3.org/Archives/Public/www-style/2012Dec/0077.html
16:47:26 <dael> ??: So you may not what to maintain because if you scroll up to read more, you want to stay there unless you're at the bottom.
16:47:34 <astearns> s/??/florian/
16:47:41 <dael> florian: I think I'm with TabAtkins, but with that user case
16:48:02 <dael> TabAtkins: I think that's interesting and useful, but different.  I'd be willing to look into it
16:48:16 <dael> dbaron: But I think what I'm objecting to is that it should be two prop, not one.
16:48:21 <dael> TabAtkins: Can you elaborate?
16:48:25 <dael> dbaron: It's too long ago
16:48:35 <dael> TabAtkins: Maybe it was semantic where it should be about any edge?
16:48:44 <BradK> When you are at the bottom of twitter, you do NOT want to stay at the bottom when new content is added to the bottom. You want to stay on the tweet you are on.
16:48:44 <dael> TabAtkins: That way you could add to either side and it would stick?
16:49:03 <dael> TabAtkins: Is this something you'd like to discuss on thread?
16:49:22 <dael> dbaron: One this was which end the content was coming from and the other was how different you are from the edge
16:49:33 <dael> florian: I'm not sure that would work in twitter.  Content can add from both sides
16:49:55 <dael> TabAtkins: If you're willing to discuss on list, that's okay. I've brought it up and got crickets and I want to make progress
16:50:01 <dael> dbaron: You should go ahead
16:50:08 <dbaron> ... I don't have time to discuss it
16:50:12 <dael> florian: If we get snapping is scroll would that fix it?
16:50:38 <dael> TabAtkins: Current proposal is that the user agent defines. There may be cases where youw ant to say exactly how far you are from edge
16:50:47 <dael> florian: Where would you want to not be at the edge?
16:51:08 <jcraig> jcraig has joined #css
16:51:19 <dael> TabAtkins: IRC cloud does only at edge and it messes up b/c you can't scroll through the edge. I'm not sure where the bug is, but you can be 2px from the edge and can't get all down
16:51:28 <dael> florian: But if you do scroll snapping, you can do it.
16:52:04 <dael> ???: I think if you have milt snap points and the content changes enough you may snap to a point that's futher away and snap to the middle.  But that would happen here too if you can define multiple
16:52:22 <glazou> not sure who is speaking
16:52:23 <dael> TabAtkins: This is justtop bottom left or right.  And if you define distance from edge you stay the same distance.
16:52:25 <sylvaing_> s/???/MaRakow
16:52:27 <glazou> ok
16:52:31 <dael> ???: So this is on the scroller?
16:52:41 <glazou> s/???/MaRakow
16:52:52 <dael> MaRakow: So when you're resizing and want to keep your content it would be off?
16:53:00 <adenilson> adenilson has joined #css
16:53:18 <dael> TabAtkins: That's part encoumpassed by twitter case, but it's beyond what I'm asking for.  It's interesting, but doens't tie in
16:53:29 <dael> ??: Your 2px thing sounds like a bug not a use case.
16:53:42 <glazou> s/??/florian
16:53:46 <dael> TabAtkins: Could be, but sometimes I don't scroll all the way down and it doesn't recover.
16:54:23 <sylvaing_> s/define/establish
16:54:30 <dael> florian: If you scroll clsoe the the edge but not quite with this new prop, the person that designed the thing with incorporate scroll snapping, take you to the edge, and have you stick there.
16:54:41 <Zakim> -kawabata
16:54:42 <MaRakow> MaRakow: Also, I feel like this is similar to the use case for keeping the same content in view while resizing responsive web pages
16:54:44 <dbaron> I think this design isn't great for extending to say whether it's distance-from-top or distance-from-bottom that you want to hold constant when the current scroll position is in the middle
16:54:51 <dael> TabAtkins: I don't think this links to snapping.  b/c having something that moves you allt he way is sometimes useful, sometimes annoying.
16:54:57 <adenilson> adenilson has joined #css
16:55:03 <dael> TabAtkins: They work well together, but shouldn't be tied together explicitly
16:55:20 <dael> glazou: So any obj to continue discussion in email and, once stable, TabAtkins requests and ED?
16:55:31 <dael> glazou: I think this is interesting and want to see a proposal
16:55:41 <dael> TabAtkins: The proposal is in the e-mails, but we can disucss.
16:55:53 <dael> glazou: I'm going to contibute too. Let me think about it
16:56:01 <dael> TabAtkins: Contibution is what I need
16:56:15 <dael> RESOLVED: Discussion continues over e-mail
16:56:24 <dael> glazou: Any remaning items that can be done in 4 minutes?
16:56:27 <dael> Topic: Subgird
16:56:32 <BradK> BradK has joined #CSS
16:56:35 <dael> fantasai: There was no discussion on ML
16:56:41 <dael> TabAtkins: Yeah, not in 4 minutes
16:56:45 <dael> glazou: Okay
16:56:59 <glazou> http://lists.w3.org/Archives/Public/www-style/2014Apr/0057.html
16:57:00 <dael> TabAtkins: I think the pow operator?
16:57:08 <dael> Topic: calc() pow operator
16:57:17 <Zakim> +??P10
16:57:35 <dael> TabAtkins: So it was suggested to add pow operator to calc.  There's a unit as the base on one side and the expoent ont he other.
16:57:44 <BradK> Argh. What is the URL for the IRC transcript? My IRC client just crashed.
16:57:52 <dael> TabAtkins: Seems reasonable and no odd problems as long as we keep the exponent non-negative
16:58:18 <dael> TabAtkins: Only issues is presidence.  You'd have to use parens for anything more than a single digit.
16:58:26 <fantasai> s/presidence/precedence/
16:58:28 <glazou> s/presidence/precedence
16:58:35 <fantasai> s/digit/number/
16:58:39 <dael> TabAtkins: Presumably this is only when both are unitless
16:59:04 <dael> TabAtkins: Given that we're not using unit alg. both things need to be a number, but you can multi by 1px to convert to px
16:59:09 <dael> fantasai: I missed the use case
16:59:12 <dael> glazou: me too.
16:59:33 <dael> glazou: I wonder if it's worth the impl.  Of course the browser vendors get final word
16:59:46 <dael> TabAtkins: The use case was in the link. It's for mathmatically pleasing things
16:59:58 <dael> glazou: I have no real opinion. I think we can, but don't see the interest
17:00:07 <dael> TabAtkins: It's low value, but simple and does have cases.
17:00:25 <dael> glazou: If we follow that path we'll need sin etc. because that's what we do with complex animations
17:00:35 <ChrisL> yay for sin/cos
17:00:38 <dael> glazou: I'm not sure if we want CSS to have a full calculator
17:00:51 <dael> florian: Could it be custom properties?
17:01:11 <dael> TabAtkins: I'm not sure it's slippery slope, but I can understand it's not important enough.
17:01:14 <TabAtkins> --pow(5, 2)
17:01:34 <dael> fantasai: I think we don't have to address this.  We can do vaiables so you can do variable constants.  This can be a preprocessor
17:01:44 <dael> SimonSapin: Did I miss the use case?
17:01:54 <dael> TabAtkins: It's the link in the agenda.
17:02:14 <dael> glazou: I'm not hearing consensus. I think we can do this in the future, but it's not high priority.
17:02:26 <dael> ChrisL: I think the common opinion is we're unsure what it's for
17:02:33 <sylvaing_> s/ChrisL/sgalineau
17:02:36 <dael> glazou: So I think we won't resolve for the time being.
17:02:48 <Zakim> -dbaron
17:02:50 <Zakim> -SGalineau
17:02:53 <Zakim> -TabAtkins
17:02:54 <Zakim> -SteveZ
17:02:54 <Zakim> -glenn
17:02:55 <Zakim> -dauwhe
17:02:55 <dael> glazou: So we're 2 minutes past the hour. The two remaing items for next week. Talk to you next week!
17:02:56 <Zakim> -krit
17:02:57 <Zakim> -MaRakow
17:02:57 <Zakim> -[Microsoft]
17:02:58 <Zakim> -fantasai
17:02:58 <Zakim> -glazou
17:02:58 <Zakim> -BradK
17:02:58 <Zakim> -gregwhitworth
17:02:58 <Zakim> -Bert
17:02:59 <kawabata> kawabata has left #css
17:02:59 <Zakim> -koji
17:02:59 <Zakim> -AH_Miller
17:03:01 <Zakim> -SimonSapin
17:03:01 <Zakim> -florian
17:03:01 <Zakim> -ChrisL
17:03:03 <Zakim> -dael
17:03:04 <Zakim> -Stearns
17:03:11 <Zakim> -Plh
17:03:25 <glazou> glazou has joined #css
17:03:42 <AH_Miller> AH_Miller has joined #CSS
17:07:37 <BradK> BradK has joined #CSS
17:08:12 <Zakim> disconnecting the lone participant, ??P10, in Style_CSS FP()12:00PM
17:08:13 <Zakim> Style_CSS FP()12:00PM has ended
17:08:13 <Zakim> Attendees were dael, glazou, +1.720.897.aaaa, glenn, dauwhe, Stearns, SGalineau, AH_Miller, +1.281.305.aabb, TabAtkins, Bert, fantasai, SimonSapin, gregwhitworth, ChrisL, Plh,
17:08:14 <Zakim> ... dbaron, +1.206.992.aacc, MaRakow, krit, SteveZ, koji, BrianKardell, +33.1.34.51.aaee, kawabata, +44.203.575.aaff, florian, BradK, Rossen_
17:21:50 <zcorpan> zcorpan has joined #css
17:22:13 <jcraig> jcraig has joined #css
17:40:40 <zcorpan> zcorpan has joined #css
17:46:44 <bradk> bradk has joined #css
18:28:58 <AH_Miller> AH_Miller has joined #CSS
18:36:41 <florian> florian has joined #css
18:36:44 <florian> florian has left #css
18:43:28 <fharper> fharper has joined #css
19:10:40 <Zakim> Zakim has left #css
19:22:34 <fharper> fharper has joined #css
19:22:37 <florian> florian has joined #css
19:31:15 <tobint> tobint has joined #css
19:36:02 <zcorpan> zcorpan has joined #css
19:46:15 <jcraig> jcraig has joined #css
19:50:58 <glenn> glenn has joined #css
20:01:19 <adenilson> adenilson has joined #css
20:04:54 <fharper> fharper has joined #css
20:31:46 <renoirb> renoirb has left #css
20:37:33 <krit> plinss: ping
20:38:18 <plinss> krit: pong
20:38:34 <krit> plinss: Hi. Does Shepherd parse WebIDL?
20:38:41 <plinss> yep
20:38:50 <krit> plinss: things like DOMString have no representation
20:38:57 <krit> plinss: but are defined by WebIDL
20:39:07 <krit> plinss: http://www.w3.org/TR/WebIDL/#idl-DOMString
20:40:12 <plinss> ah, you were asking if it’s parsing the WebIDL spec, as opposed to WebIDL in other specs…
20:40:16 <plinss> no, it’s not parsing that spec, but I can add it easily enough
20:40:28 <krit> plinss: hahah, yes
20:40:32 <krit> plinss: that is what I meant
20:40:39 <plinss> ok, give me a minute
20:41:06 <krit> plinss: it might be that it recognizes float, double and all these things as well, would it?
20:41:15 <krit> plinss: so might create a bit of noise
20:43:20 <plinss> Well, Shepherd would find all the anchors in the WebIDL spec, and classify the types of the <dfn> anchors, it depends on if there are <dfn>s for all the other types
20:43:42 <krit> plinss: ah right
20:43:59 <krit> plinss: even for IDLs in specs?
20:44:10 <krit> plinss: doesn't bikeshed use your IDL parser?
20:44:23 <plinss> yes, it does
20:44:41 <krit> plinss: so it might create a lot of links after adding the WebIDL spec.
20:44:45 <krit> plinss: Am I wrong?
20:45:01 <plinss> hang on, I have to look at the bikeshed code to remember what it does exactly
20:48:55 <plinss> I think it will only markup non-webidl native types, so we should be ok
20:49:47 <krit> cool
20:50:12 <plinss> I can always remove the spec if it causes a lot of noise
20:50:37 <plinss> though I’m not sure the WebIDL spec actually has a <dfn> for DOMString
20:50:55 <plinss> but I’ll add it to Shepherd anyway, and we can fix it if we need to
21:00:59 <plinss> ok, it’s added, but fwfw, the webidl parser treats DOMString as a webdil-native type so it doesn’t get markup in bikeshed anyway…
21:02:35 <krit> plinss: oh, ok
21:02:46 <krit> plinss: probably makes sense
21:02:53 <krit> plinss: thanks for adding
21:03:07 <plinss> are you trying to get all the DOMString types in other spec’s IDL to link to the WebIDL spec?
21:03:25 <krit> plinss: I think so
21:03:42 <krit> plinss: I just checked... so far I had to make bikeshed ignore DOMString
21:03:51 <krit> plinss: because it couldn't find a reference
21:04:19 <plinss> hmm, was bikeshed adding the link to DOMString itself?
21:08:45 <krit> plinss: I think it relied on the webidl output
21:08:53 <krit> plinss: but not entirely sure
21:09:10 <krit> plinss: maybe i have <a>DOMString</a> somewher
21:09:11 <krit> e
21:09:39 <krit> plinss: ok, <a interface>DOMString</a> is in the code, see it now
21:10:12 <plinss> maybe, because it doens’t seem to cause an issue in other specs
21:10:41 <plinss> ah, well in order to get _that_ to work, we have to update the WebIDL spec to actually include a <dfn> for DOMString with an ‘interface’ type, it doesn’t have that now...
21:11:16 <plinss> there doesn’t appear to ba a <dfn> for it at all at this point
21:11:57 <krit> plinss: We need to republish WebIDL anyway. Shall I ask Cameron to update the spec, or isn't it worth it?
21:12:24 <krit> heycam|away: --^
21:12:25 <plinss> yeah, it’s probably worth it
21:13:03 <krit> plinss: <dfn dfn-type=interface>DOMString</dfn> it would be?
21:13:12 <plinss> yes
21:13:21 <krit> plinss: cool, thanks!
21:13:49 <plinss> and it also needs an id or to be in an element with an anchor
21:14:30 <birtles_> birtles_ has joined #css
21:14:32 <plinss> e.g. the <dfn> could be in the section header
21:18:28 <krit> plinss: I hope heycam|away reads the comments :)
21:30:12 <plinss> krit: fwiw, it would be a fairly simple change to the WebIDL parser that bikeshed uses to make it turn DOMString in IDL uses to links
21:30:59 <krit> plinss: I think it would be useful... but WebIDL spec still needs to change
21:31:00 <plinss> but it would also want to turn ByteString, object, Date and RegExp into links too, so they’d all need the proper <dfn> markup in the WebIDL spec
21:31:19 <krit> plinss: ah understand...
21:31:36 <krit> plinss: thanks for your help again
21:31:38 <plinss> np
21:38:08 <zcorpan> zcorpan has joined #css
21:45:17 <jet> jet has joined #css
21:53:46 <florian> florian has joined #css
21:55:35 <florian1> florian1 has joined #css
22:15:46 <TabAtkins> plinss: The DOMString thing is troublesome in other specs - I've had to ignore the linking error elsewhere.
22:16:05 <TabAtkins> So it's nice to have WebIDL in Shepherd, especially once it actually contains the dfns. ^_^
22:16:18 <plinss> Yeah, it seemed like the right thing to do
22:16:34 <plinss> thoughts on having the uses of DOMString in IDL link to the WebIDL spec?
22:21:29 <TabAtkins> I'm fine with that.
22:21:41 <TabAtkins> The more links the better, honestly.
22:21:50 <TabAtkins> Link double/etc too.
22:22:10 <arronei> arronei has joined #css
22:22:34 <plinss> eeek, linking the primitive types would get a bit much, don’t you think?
22:28:40 <TabAtkins> Shrug, they have non-obvious definitions.
22:28:57 <TabAtkins> I suppose I can detect them and give them a class to receive even less obvious styling.
22:29:06 <TabAtkins> Like, be invisible except on :hover.
22:39:20 <zcorpan> zcorpan has joined #css
22:56:19 <florian> florian has joined #css
23:27:27 <heycam> yeah not sure linking DOMString etc. is worth it
23:27:54 <heycam> plinss, krit, but let me know what specific changes to make in the Web IDL spec you'd like
23:28:14 <heycam> (preferably by email)
23:38:39 <jdaggett> jdaggett has joined #css
23:40:02 <jcraig> jcraig has joined #css
23:40:08 <zcorpan> zcorpan has joined #css
23:46:40 <glenn> glenn has joined #css
23:47:54 <plinss> TabAtkins: so if we’re going to add/handle all these new <dfn>s in the WebIDL spec, what type of <dfn> are they going to be? I’m thinking we need to define a new type for them…
23:48:00 <TabAtkins> Do we?
23:48:06 <TabAtkins> They're basically interfaces, no?
23:48:54 <plinss> are they? maybe DOMString is an interface, but ‘boolean’?, ‘object’?
23:49:31 <TabAtkins> They're close enough, I'd think. Distinguishing between "primitive" and "interface" doesn't seem particularly useful.
23:50:49 <plinss> ok I suppose, just feels odd
23:51:41 <plinss> I think we maybe do need a new type for promises though?
23:51:59 <plinss> (and I need to update the widlparser to handle them)
23:52:17 <TabAtkins> Why do we need something new for promises?
23:52:40 <TabAtkins> It's a container type, sure, but so is "sequence".
23:57:03 <florian> florian has joined #css
23:57:18 <plinss> meh, ok
23:57:25 <plinss> I still need to add support in the parser though
23:58:54 <TabAtkins> I'm curious why you thought Promise needed something new, though.