- From: Anthony Grasso <Anthony.Grasso@cisra.canon.com.au>
- Date: Mon, 27 Sep 2010 23:31:29 +0000
- To: "public-fx@w3.org" <public-fx@w3.org>
Hi everyone, Sorry I missed the call. I lost my voice over the weekend which isn't very helpful for a telcon. Should be fine to make the next call. Cheers, Anthony P.S. Still looking for my voice. > -----Original Message----- > From: public-fx-request@w3.org [mailto:public-fx-request@w3.org] On > Behalf Of Erik Dahlstrom > Sent: Tuesday, 28 September 2010 7:03 AM > To: public-fx@w3.org > Subject: Minutes September 27 2010 public-fx telcon > > As html: > > > http://www.w3.org/2010/09/27-fx-minutes.html > > > As text: > > > [1]W3C > > [1] http://www.w3.org/ > > - DRAFT - > > CSS-SVG Task Force Teleconference > > 27 Sep 2010 > > [2]Agenda > > [2] > http://lists.w3.org/Archives/Public/public-fx/2010JulSep/0089.html > > See also: [3]IRC log > > [3] http://www.w3.org/2010/09/27-fx-irc > > Attendees > > Present > ed, +1.858.655.aaaa, plinss, smfr, dino, +1.919.824.aabb, > dbaron, shepazu > > Regrets > Chair > SV_MEETING_CHAIR > > Scribe > smfr > > Contents > > * [4]Topics > 1. [5]SVG/CSS unitless values > 2. [6]CSS border and background-color on the <svg> element > 3. [7]'pointer-events' and (event) transparency > * [8]Summary of Action Items > _________________________________________________________ > > <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: > [9]http://lists.w3.org/Archives/Public/public-fx/2010JulSep/0089.htm > l > > [9] > 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 > [10]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 [11]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 > > [12]http://lists.w3.org/Archives/Public/public-fx/2010JulSep/0005.ht > ml > > [12] > http://lists.w3.org/Archives/Public/public-fx/2010JulSep/0005.html > > SVG/CSS unitless values > > 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: > [13]http://lists.w3.org/Archives/Public/public-fx/2010JulSep/0011.ht > ml > > [13] > 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 > > CSS border and background-color on the <svg> element > > <ed> > [14]http://lists.w3.org/Archives/Public/public-fx/2010JulSep/0053.ht > ml > > [14] > http://lists.w3.org/Archives/Public/public-fx/2010JulSep/0053.html > > <ed> the svg wg discussed it at the f2f,minutes here: > [15]http://www.w3.org/2010/09/07-svg-minutes.html#item04 > > [15] 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> > [16]http://software.hixie.ch/utilities/js/live-dom-viewer/?%3C!DOCTY > > PE%20html%3E%0A%3Cstyle%3E%0A%0Asvg%20%7B%20width%3A%20100p > x%3B%20he > > ight%3A%20100px%3B%20background%3A%20yellow%3B%20border%3A%2 > 0medium% > > 20solid%20fuchsia%20%7D%0A%0A%3C%2Fstyle%3E%0A%3Csvg%20viewBo > x%3D%22 > > 0%200%20100%20100%22%3E%0A%20%20%3Ccircle%20cx%3D%2250%22%2 > 0cy%3D%22 > > 50%22%20r%3D%2250%22%20fill%3D%22green%22%20%2F%3E%0A%3C%2F > svg%3E > > [16] > 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%20 > r%3D%2250%22%20fill%3D%22green%22%20%2F%3E%0A%3C%2Fsvg%3E > > 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> [17]http://schepers.cc/css-in-svg > > [17] 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 > [18]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]. > > 'pointer-events' and (event) transparency > > [19]http://www.w3.org/2010/09/07-svg-minutes.html#item05 > > [19] 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: > [20]http://www.schepers.cc/svg/blendups/overlay/test/overlap.xhtml > > [20] 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: > [21]http://www.mail- > archive.com/whatwg@lists.whatwg.org/msg22699.htm > l > > [21] 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 > [22]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: > [23]http://webkit.org/specs/PointerEventsProperty.html > > [23] http://webkit.org/specs/PointerEventsProperty.html > > adjourned > > ed: do you take care of posting the minutes? > > <ed> smfr: sure > > thanks > > <ed> trackbot, end telcon > > Summary of Action Items > > [NEW] ACTION: david baron to get roc onto the next call [recorded in > [24]http://www.w3.org/2010/09/27-fx-minutes.html#action02] > [NEW] ACTION: dbaron to get roc onto the next call [recorded in > [25]http://www.w3.org/2010/09/27-fx-minutes.html#action01] > [NEW] ACTION: doug to draw up a pointer-events spec [recorded in > [26]http://www.w3.org/2010/09/27-fx-minutes.html#action04] > [NEW] ACTION: doug to summarize the options for CSS applying to the > SVG root before the next telecon [recorded in > [27]http://www.w3.org/2010/09/27-fx-minutes.html#action03] > > [End of minutes] > _________________________________________________________ > > > Minutes formatted by David Booth's [28]scribe.perl version 1.135 > ([29]CVS log) > $Date: 2010/09/27 20:57:11 $ > _________________________________________________________ > > [28] http://dev.w3.org/cvsweb/~checkout~/2002/scribe/scribedoc.htm > [29] http://dev.w3.org/cvsweb/2002/scribe/ > > Scribe.perl diagnostic output > > [Delete this section before finalizing the minutes.] This is scribe.perl > Revision: 1.135 of Date: 2009/03/02 03:52:20 Check for newer version at > [30]http://dev.w3.org/cvsweb/~checkout~/2002 > /scribe/ > > [30] 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.aa bb, > dbaron, shepazu > Present: ed +1.858.655.aaaa plinss smfr dino +1.919.824.aabb dbaron she > pazu > Agenda: [31]http://lists.w3.org/Archives/Public/public-fx/2010JulSep/00 > 89.html > > [31] > 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: [32]http://www.w3.org/2010/09/27-fx-minutes.html > People with action items: baron david dbaron doug > > [32] http://www.w3.org/2010/09/27-fx-minutes.html > > WARNING: Input appears to use implicit continuation lines. > You may need the "-implicitContinuations" option. > > > End of [33]scribe.perl diagnostic output] > > [33] http://dev.w3.org/cvsweb/~checkout~/2002/scribe/scribedoc.htm > > > -- > Erik Dahlstrom, Core Technology Developer, Opera Software Co-Chair, W3C > SVG Working Group Personal blog: http://my.opera.com/macdev_ed The information contained in this email message and any attachments may be confidential and may also be the subject to legal professional privilege. If you are not the intended recipient, any use, interference with, disclosure or copying of this material is unauthorised and prohibited. If you have received this email in error, please immediately advise the sender by return email and delete the information from your system.
Received on Monday, 27 September 2010 23:33:50 UTC