See also: IRC log
<ed> trackbot, start telcon
<trackbot> Date: 27 September 2010
<ed> Zakim: room for 8?
Zakim: Apple is smfr and dino
i confused it
<dbaron> I'm getting "this passcode is not valid"
<dbaron> then again, I think Zakim doesn't like the tone dialing from either my cellphone or office phone anymore
<plinss> sorry, not available, having to step away from the phone due to personal issues going on...
<scribe> scribenick: smfr
<ed> Agenda: http://lists.w3.org/Archives/Public/public-fx/2010JulSep/0089.html
smfr: we support the element
proposal, in general
... we don't like the fact that the element has to be visible,
forcing overflow:hidden hacks
ed: opera is also interested
dbaron: you really want a url reference
<dbaron> ... for some things
smfr: we see this as a way to get away from our -webkit-box-reflect property
<dbaron> but element() can be useful for things like reflectiions of content in the document
smfr: tabatkins posted the message (url above), but I haven't seen a spec
doug: what is the next step? what spec would this go into?
smfr: one issue is that it has a
CSS property and some API
... i don't really like the API
doug: maybe use a selector rather than an ID?
dino: what's the use case for the API?
smfr: i think we need roc on a call to delve into this
doug: should someone take an action to work on the spec for this, and gather feedback
dbaron: i can ask roc (he's away right now)
<scribe> ACTION: dbaron to get roc onto the next call [recorded in http://www.w3.org/2010/09/27-fx-minutes.html#action01]
<trackbot> Sorry, couldn't find user - dbaron
<scribe> ACTION: david baron to get roc onto the next call [recorded in http://www.w3.org/2010/09/27-fx-minutes.html#action02]
<trackbot> Created ACTION-14 - Baron to get roc onto the next call [on David Singer - due 2010-10-04].
arg
next topic
SVG/CSS unitless values
http://lists.w3.org/Archives/Public/public-fx/2010JulSep/0005.html
doug: css is going to defining
more in user units (like svg uses px, but they are really just
user units)
... not necessarily counter-intuitive to user if the values are
unitless
dbaron: there are existing ares
in css where parsing disambiguation requires the ability to
distinguish lengths and numbers
... that's a big motivation in css to not change this
... gecko requires units according to css; it only allows
unitless numbers for longhand properties in quirks mode
<ed> a good summary in this thread by chris lilley: http://lists.w3.org/Archives/Public/public-fx/2010JulSep/0011.html
dbaron: the other motivation in
css is that in many areas pixel units are frowned upon
... so making them the default would encourage bad practice
plinss: css wg has been talking about dropping the requirements for units this back in 1998
doug: when is it the wrong thing
to do? browsers now do scaling/magnify etc
... are the old assumptions still valid?
plinss: i don't see any reason
why they don't hold
... css-wg has even been talking about what pixel units are
ed: esp with css transforms etc.
doug: pixel is no longer what css
intended
... less to do with pixels on a device, but it has more general
applicability than before
plinss: we're trying to make it a normal length unit, since it has less association with device pixels than in the past
doug: it should be divorced from the device pixel (esp with transforms), but that makes it more realistic
plinss: but then px has no more significance than inch etc
doug: lots of people think in px
[doug drops out]
dino: we can't make a decision here: css-wg owns the decision
ed: still need to get feedback from public-fx to css-wg
<ed> http://lists.w3.org/Archives/Public/public-fx/2010JulSep/0053.html
<ed> the svg wg discussed it at the f2f,minutes here: http://www.w3.org/2010/09/07-svg-minutes.html#item04
doug: svg-wg looked into it,
discussed at the F2F
... border adds geometry, so svg-wg thought it was not
applicable
... allowing background to apply to root svg should may be a
special case
dbaron: boundary between the formatting models should be at the...
?
dbaron: border could change how much space you have available, but so do other things
doug: that's not true now: rectangle around the SVG would not add to the size of the SVG
dbaron: the case here is svg in some other content
<dbaron> (I thought)
doug: we have to define it for
all the cases, including standalone svg
... no problem with border and background on inline svg
dbaron: an inline svg to the CSS model is a replaced element
<dbaron> s/at the .../at the content box/
<dbaron> http://schepers.cc/css-in-svg
doug: most important is that they
are defined, not necessarily how they are defined
... other people felt that other non-root svg elements should
not have these properties apply
... in svg content, if you want to highlight something, you may
want to change the background or make an outline
you currently have do this through script by DOM manipulation
it would be a lot nicer by applying css properties
ed: you could some of that by CSS hover and more SVG content e.g another shape
dbaron: I think you can have the SVG content in the tree the whole time, and change the fill
doug: but then you're cluttering
the DOM
... we see how easy this in with CSS in HTML; it's much harder
in SVG
... would like a grand unification of SVG and CSS
smfr: that's a larger topic than the one on the agenda, but could be useful
doug: i'd be fine with the svg being a special case, and defining it as has been proposed
ed: is that for the SVG integration spec, or something in this group?
doug: if things overlap with
other specs, then they go into the SVG Integration Spec
... maybe the SVG Integration Spec should be a product of
public-fx
... SVG Integration Spec intends to fill the gaps between
specs
ed: does CSS define how borders are applied to replaced elements like the SVG root element?
doug: the implementations are
fairly consistent, but the behavior (for reference content) is
not the one most people expect
... inline SVG behavior is fine
... opened an issue for SVG2 to make it easier to make
autoscaling content
... rather than width/height 100%, you could say that the
document uses autoscaling
dougt to bring up in 2 weeks
ed: is doug going to put something in the integration spec
doug: css folks should email public-fx
<scribe> ACTION: doug to summarize the options for CSS applying to the SVG root before the next telecon [recorded in http://www.w3.org/2010/09/27-fx-minutes.html#action03]
<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].
http://www.w3.org/2010/09/07-svg-minutes.html#item05
ed: some differences between
implementations in how pointer-events: auto behaves
... conclusion from SVG F2F: if you have inline SVG, clicks in
transparent areas go through to the underlying content as the
default behavior
... most implementations do this
... Firefox was the notable exception
dbaron: we're treating the root svg element like a replaced element
<ed> Example: http://www.schepers.cc/svg/blendups/overlay/test/overlap.xhtml
doug: most authors would expect
events to go through to the html
... it should go into the integration spec
dbaron: is the intent that SVG behaves differently that the SVG root element is different?
doug: yes
ed: is pointer-events in HTML part of any spec?
what-wg discussion is here: http://www.mail-archive.com/whatwg@lists.whatwg.org/msg22699.html
doug: i don't think it belongs in
the SVG Integration spec. it belongs somewhere else
... i'm interested in speccing this out
<scribe> ACTION: doug to draw up a pointer-events spec [recorded in http://www.w3.org/2010/09/27-fx-minutes.html#action04]
<trackbot> Created ACTION-16 - Draw up a pointer-events spec [on Doug Schepers - due 2010-10-04].
ed: anything else for today?
[no response]
dino drew up this: http://webkit.org/specs/PointerEventsProperty.html
adjourned
ed: do you take care of posting the minutes?
<ed> smfr: sure
thanks
<ed> trackbot, end telcon
This is scribe.perl Revision: 1.135 of Date: 2009/03/02 03:52:20 Check for newer version at http://dev.w3.org/cvsweb/~checkout~/2002/scribe/ Guessing input format: RRSAgent_Text_Format (score 1.00) FAILED: s/at the .../at the content box/ Succeeded: s/more CSS/more SVG content e.g another shape/ Succeeded: s/exect/expect/ Found ScribeNick: smfr Inferring Scribes: smfr Default Present: ed, +1.858.655.aaaa, plinss, smfr, dino, +1.919.824.aabb, dbaron, shepazu Present: ed +1.858.655.aaaa plinss smfr dino +1.919.824.aabb dbaron shepazu Agenda: http://lists.w3.org/Archives/Public/public-fx/2010JulSep/0089.html WARNING: No meeting chair found! You should specify the meeting chair like this: <dbooth> Chair: dbooth Found Date: 27 Sep 2010 Guessing minutes URL: http://www.w3.org/2010/09/27-fx-minutes.html People with action items: baron david dbaron doug WARNING: Input appears to use implicit continuation lines. You may need the "-implicitContinuations" option.[End of scribe.perl diagnostic output]