IRC log of fx on 2010-09-27

Timestamps are in UTC.

19:56:08 [RRSAgent]
RRSAgent has joined #fx
19:56:08 [RRSAgent]
logging to http://www.w3.org/2010/09/27-fx-irc
19:56:15 [plinss]
zakim, passcode?
19:56:15 [Zakim]
sorry, plinss, I don't know what conference this is
19:56:24 [plinss]
zakim, this will be fx
19:56:24 [Zakim]
I do not see a conference matching that name scheduled within the next hour, plinss
19:56:25 [ed]
trackbot, start telcon
19:56:27 [trackbot]
RRSAgent, make logs world
19:56:29 [trackbot]
Zakim, this will be 3983
19:56:29 [Zakim]
I do not see a conference matching that name scheduled within the next hour, trackbot
19:56:30 [trackbot]
Meeting: CSS-SVG Task Force Teleconference
19:56:30 [trackbot]
Date: 27 September 2010
19:56:58 [ed]
Zakim: room for 8?
19:57:39 [plinss]
zakim, room for 8?
19:57:41 [Zakim]
ok, plinss; conference Team_(fx)19:57Z scheduled with code 26631 (CONF1) for 60 minutes until 2057Z
19:58:43 [Zakim]
Team_(fx)19:57Z has now started
19:58:50 [Zakim]
+??P0
19:58:56 [ed]
Zakim, ??P0 is me
19:58:56 [Zakim]
+ed; got it
19:58:57 [Zakim]
+ +1.858.655.aaaa
19:59:01 [Zakim]
+smfr
19:59:05 [plinss]
zakim, aaaa is me
19:59:05 [Zakim]
+plinss; got it
19:59:20 [ed]
Agenda: http://lists.w3.org/Archives/Public/public-fx/2010JulSep/0089.html
20:02:43 [dbaron]
dbaron has joined #fx
20:02:51 [Zakim]
-smfr
20:03:02 [Zakim]
+[Apple]
20:03:20 [smfr]
Zakim: Apple is smfr and dino
20:03:37 [smfr]
Zakim, Apple is smfr and dino
20:03:37 [Zakim]
I don't understand 'Apple is smfr and dino', smfr
20:03:42 [smfr]
Zakim, Apple is smfr, dino
20:03:42 [Zakim]
I don't understand 'Apple is smfr, dino', smfr
20:03:46 [smfr]
Zakim, Apple is smfr
20:03:46 [Zakim]
+smfr; got it
20:03:51 [smfr]
Zakim, Apple is also dino
20:03:53 [Zakim]
I don't understand 'Apple is also dino', smfr
20:03:56 [smfr]
Zakim, Apple is dino
20:03:56 [Zakim]
sorry, smfr, I do not recognize a party named 'Apple'
20:03:59 [dbaron]
Zakim, Apple has smfr and dino
20:03:59 [Zakim]
sorry, dbaron, I do not recognize a party named 'Apple'
20:04:10 [smfr]
i confused it
20:04:15 [dbaron]
Zakim, smfr is [Apple]
20:04:15 [Zakim]
+[Apple]; got it
20:04:20 [dbaron]
Zakim, [Apple] has smfr and dino
20:04:20 [Zakim]
+smfr, dino; got it
20:04:35 [dbaron]
I'm getting "this passcode is not valid"
20:04:53 [dbaron]
then again, I think Zakim doesn't like the tone dialing from either my cellphone or office phone anymore
20:04:58 [Zakim]
+ +1.919.824.aabb
20:05:32 [Zakim]
+[Mozilla]
20:05:59 [ed]
Zakim, pick a victim?
20:05:59 [Zakim]
I don't understand your question, ed.
20:06:07 [ed]
Zakim, pick a victim
20:06:08 [Zakim]
Not knowing who is chairing or who scribed recently, I propose plinss
20:06:47 [plinss]
sorry, not available, having to step away from the phone due to personal issues going on...
20:06:51 [ed]
Zakim, pick a victim
20:06:51 [Zakim]
Not knowing who is chairing or who scribed recently, I propose smfr
20:06:57 [smfr]
scribenick: smfr
20:07:06 [ed]
Agenda: http://lists.w3.org/Archives/Public/public-fx/2010JulSep/0089.html
20:08:21 [smfr]
smfr: we support the element proposal, in general
20:08:40 [smfr]
smfr: we don't like the fact that the element has to be visible, forcing overflow:hidden hacks
20:09:40 [smfr]
ed: opera is also interested
20:09:54 [smfr]
dbaron: you really want a url reference
20:10:06 [dbaron]
... for some things
20:10:25 [smfr]
smfr: we see this as a way to get away from our -webkit-box-reflect property
20:10:38 [dbaron]
but element() can be useful for things like reflectiions of content in the document
20:11:00 [smfr]
smfr: tabatkins posted the message (url above), but I haven't seen a spec
20:11:21 [smfr]
doug: what is the next step? what spec would this go into?
20:12:45 [smfr]
smfr: one issue is that it has a CSS property and some API
20:13:00 [smfr]
smfr: i don't really like the API
20:13:10 [smfr]
doug: maybe use a selector rather than an ID?
20:14:08 [smfr]
dino: what's the use case for the API?
20:14:35 [smfr]
smfr: i think we need roc on a call to delve into this
20:15:16 [smfr]
doug: should someone take an action to work on the spec for this, and gather feedback
20:15:22 [smfr]
dbaron: i can ask roc (he's away right now)
20:15:45 [smfr]
ACTION: dbaron to get roc onto the next call
20:15:45 [trackbot]
Sorry, couldn't find user - dbaron
20:15:56 [smfr]
ACTION: david baron to get roc onto the next call
20:15:57 [trackbot]
Created ACTION-14 - Baron to get roc onto the next call [on David Singer - due 2010-10-04].
20:16:20 [smfr]
arg
20:16:49 [smfr]
next topic
20:17:02 [smfr]
SVG/CSS unitless values
20:17:03 [smfr]
http://lists.w3.org/Archives/Public/public-fx/2010JulSep/0005.html
20:17:16 [ed]
topic: SVG/CSS unitless values
20:17:43 [smfr]
doug: css is going to defining more in user units (like svg uses px, but they are really just user units)
20:18:09 [smfr]
doug: not necessarily counter-intuitive to user if the values are unitless
20:18:48 [smfr]
dbaron: there are existing ares in css where parsing disambiguation requires the ability to distinguish lengths and numbers
20:19:06 [smfr]
dbaron: that's a big motivation in css to not change this
20:19:49 [smfr]
dbaron: gecko requires units according to css; it only allows unitless numbers for longhand properties in quirks mode
20:20:31 [ed]
a good summary in this thread by chris lilley: http://lists.w3.org/Archives/Public/public-fx/2010JulSep/0011.html
20:20:35 [smfr]
dbaron: the other motivation in css is that in many areas pixel units are frowned upon
20:20:51 [smfr]
dbaron: so making them the default would encourage bad practice
20:21:41 [smfr]
plinss: css wg has been talking about dropping the requirements for units this back in 1998
20:22:32 [smfr]
doug: when is it the wrong thing to do? browsers now do scaling/magnify etc
20:22:40 [smfr]
doug: are the old assumptions still valid?
20:22:57 [smfr]
plinss: i don't see any reason why they don't hold
20:23:17 [smfr]
plinss: css-wg has even been talking about what pixel units are
20:23:45 [smfr]
ed: esp with css transforms etc.
20:23:53 [smfr]
doug: pixel is no longer what css intended
20:24:14 [smfr]
doug: less to do with pixels on a device, but it has more general applicability than before
20:24:38 [smfr]
plinss: we're trying to make it a normal length unit, since it has less association with device pixels than in the past
20:25:28 [smfr]
doug: it should be divorced from the device pixel (esp with transforms), but that makes it more realistic
20:25:40 [smfr]
plinss: but then px has no more significance than inch etc
20:25:59 [smfr]
doug: lots of people think in px
20:26:03 [smfr]
[doug drops out]
20:26:10 [Zakim]
-shepazu
20:26:22 [smfr]
dino: we can't make a decision here: css-wg owns the decision
20:26:48 [smfr]
ed: still need to get feedback from public-fx to css-wg
20:26:57 [smfr]
topic: CSS border and background-color on the <svg> element
20:26:59 [ed]
http://lists.w3.org/Archives/Public/public-fx/2010JulSep/0053.html
20:27:09 [Zakim]
+shepazu
20:29:25 [ed]
the svg wg discussed it at the f2f,minutes here: http://www.w3.org/2010/09/07-svg-minutes.html#item04
20:29:28 [smfr]
doug: svg-wg looked into it, discussed at the F2F
20:30:29 [smfr]
doug: border adds geometry, so svg-wg thought it was not applicable
20:30:51 [smfr]
doug: allowing background to apply to root svg should may be a special case
20:31:05 [dbaron]
http://software.hixie.ch/utilities/js/live-dom-viewer/?%3C!DOCTYPE%20html%3E%0A%3Cstyle%3E%0A%0Asvg%20%7B%20width%3A%20100px%3B%20height%3A%20100px%3B%20background%3A%20yellow%3B%20border%3A%20medium%20solid%20fuchsia%20%7D%0A%0A%3C%2Fstyle%3E%0A%3Csvg%20viewBox%3D%220%200%20100%20100%22%3E%0A%20%20%3Ccircle%20cx%3D%2250%22%20cy%3D%2250%22%20r%3D%2250%22%20fill%3D%22green%22%20%2F%3E%0A%3C%2Fsvg%3E
20:31:26 [smfr]
dbaron: boundary between the formatting models should be at the...
20:31:48 [smfr]
?
20:32:04 [smfr]
dbaron: border could change how much space you have available, but so do other things
20:32:20 [smfr]
doug: that's not true now: rectangle around the SVG would not add to the size of the SVG
20:32:37 [smfr]
dbaron: the case here is svg in some other content
20:32:42 [dbaron]
(I thought)
20:32:49 [smfr]
doug: we have to define it for all the cases, including standalone svg
20:33:03 [smfr]
doug: no problem with border and background on inline svg
20:33:24 [smfr]
dbaron: an inline svg to the CSS model is a replaced element
20:33:47 [dbaron]
s/at the .../at the content box/
20:34:16 [dbaron]
http://schepers.cc/css-in-svg
20:34:46 [smfr]
doug: most important is that they are defined, not necessarily how they are defined
20:35:22 [smfr]
doug: other people felt that other non-root svg elements should not have these properties apply
20:35:58 [smfr]
doug: in svg content, if you want to highlight something, you may want to change the background or make an outline
20:36:26 [smfr]
you currently have do this through script by DOM manipulation
20:36:43 [smfr]
it would be a lot nicer by applying css properties
20:37:11 [smfr]
ed: you could some of that by CSS hover and more CSS
20:37:32 [smfr]
dbaron: I think you can have the SVG content in the tree the whole time, and change the fill
20:37:33 [ed]
s/more CSS/more SVG content e.g another shape/
20:37:50 [smfr]
doug: but then you're cluttering the DOM
20:38:18 [smfr]
doug: we see how easy this in with CSS in HTML; it's much harder in SVG
20:39:08 [smfr]
doug: would like a grand unification of SVG and CSS
20:39:43 [smfr]
smfr: that's a larger topic than the one on the agenda, but could be useful
20:40:16 [smfr]
doug: i'd be fine with the svg being a special case, and defining it as has been proposed
20:40:28 [smfr]
ed: is that for the SVG integration spec, or something in this group?
20:41:00 [smfr]
doug: if things overlap with other specs, then they go into the SVG Integration Spec
20:41:08 [smfr]
doug: maybe the SVG Integration Spec should be a product of public-fx
20:41:52 [smfr]
doug: SVG Integration Spec intends to fill the gaps between specs
20:42:16 [smfr]
ed: does CSS define how borders are applied to replaced elements like the SVG root element?
20:42:56 [smfr]
doug: the implementations are fairly consistent, but the behavior (for reference content) is not the one most people exect
20:43:02 [smfr]
s/exect/expect
20:43:08 [smfr]
doug: inline SVG behavior is fine
20:43:45 [smfr]
doug: opened an issue for SVG2 to make it easier to make autoscaling content
20:44:05 [smfr]
doug: rather than width/height 100%, you could say that the document uses autoscaling
20:44:25 [smfr]
dougt to bring up in 2 weeks
20:44:56 [smfr]
ed: is doug going to put something in the integration spec
20:45:04 [smfr]
doug: css folks should email public-fx
20:46:30 [smfr]
action: doug to summarize the options for CSS applying to the SVG root before the next telecon
20:46:31 [trackbot]
Created ACTION-15 - Summarize the options for CSS applying to the SVG root before the next telecon [on Doug Schepers - due 2010-10-04].