W3C home > Mailing lists > Public > public-svg-wg@w3.org > October to December 2008

Minutes, telcon 27 November 2008

From: Cameron McCormack <cam@mcc.id.au>
Date: Fri, 28 Nov 2008 08:08:51 +1100
To: public-svg-wg@w3.org
Message-ID: <20081127210850.GC23853@arc.mcc.id.au>

http://www.w3.org/2008/11/27-svg-minutes.html

   [1]W3C

      [1] http://www.w3.org/

                               - DRAFT -

                   SVG Working Group Teleconference

27 Nov 2008

   See also: [2]IRC log

      [2] http://www.w3.org/2008/11/27-svg-irc

Attendees

   Present
          ed, anthony, heycam, shepazu, ChrisL

   Regrets
   Chair
          Erik

   Scribe
          Cameron

Contents

     * [3]Topics
         1. [4]SVG 1.1 errata
         2. [5]selectors-api review
         3. [6]Errata
         4. [7]StaticNodeList erratum
         5. [8]language/switch processing erratum
         6. [9]Undefined behavior with filters erratum
         7. [10]Reword F.5 Tangents erratum
         8. [11]Case sensitivity rewording erratum
     * [12]Summary of Action Items
     _________________________________________________________



   <trackbot> Date: 27 November 2008

   <scribe> Scribe: Cameron

   <scribe> ScribeNick: heycam

SVG 1.1 errata

   <shepazu>
   [13]http://lists.w3.org/Archives/Public/public-svg-wg/2008OctDec/040
   3.html

     [13] http://lists.w3.org/Archives/Public/public-svg-wg/2008OctDec/0403.html

   <shepazu>
   [14]http://www.w3.org/Graphics/SVG/Group/repository/errata/errata.xm
   l#clippath-pointer-events

     [14] http://www.w3.org/Graphics/SVG/Group/repository/errata/errata.xml#clippath-pointer-events

   CM: This was mentioned on batik-users, which is why I mention it

   ED: there is no action on it?

   DS: i don't know if there's an action or not, but i'll take one
   ... i don't think i specified it well, but my email didn't say
   exactly what needs to be done
   ... it just says that clip path does not affect pointer events

   <shepazu> [[

   <shepazu> clarify that clipPath does not affect

   <shepazu> pointer events. This should note that since clipPath is
   not rendered,

   <shepazu> no pointer-event values on children of clipPath will
   affect the target.

   <shepazu> [[

   DS: mozilla has this behaviour now

   CL: it could mean that clip path with two paths inside it, and you
   can't clip on them

   <shepazu> [15]https://bugzilla.mozilla.org/show_bug.cgi?id=376952

     [15] https://bugzilla.mozilla.org/show_bug.cgi?id=376952

   <shepazu> [16]https://bugzilla.mozilla.org/attachment.cgi?id=261068

     [16] https://bugzilla.mozilla.org/attachment.cgi?id=261068

   CL: or the second one is whether you can click on clipped out parts
   of shapes

   <ed> testcase:
   [17]https://bugzilla.mozilla.org/attachment.cgi?id=261068 (yes,
   works the same in FF3.1b1 and Opera 9.62)

     [17] https://bugzilla.mozilla.org/attachment.cgi?id=261068

   CM: it's the second one, yes?

   DS: actually that bug is a different issue

   <chris> in the first case, you are putting pointer-events on the
   paths inside clip-path; on the second, you have pointer-events on a
   rendered shape (which is clipped)

   <ed> confirmed that the testcase works the same in Safari 3.2.1 too

   CL: in the second case, you have a rendered shape with
   pointer-events and part of it is clipped
   ... so 2a) is stuff inside the clipping path, which is rendered --
   should it get pointer events (yes, it should)
   ... so 2b) is stuff outside the clipping path, which isn't rendered
   -- should it get pointer events? (i think it depends on the value of
   pointer-events)

   DS: i think everybody thinks the visible stuff should get pointer
   events

   <shepazu>
   [18]http://www.w3.org/TR/SVGTiny12/interact.html#PointerEventsProper
   ty

     [18] http://www.w3.org/TR/SVGTiny12/interact.html#PointerEventsProperty

   <ed>
   [19]http://www.w3.org/TR/SVG11/interact.html#PointerEventsProperty

     [19] http://www.w3.org/TR/SVG11/interact.html#PointerEventsProperty

   CL: in tiny 1.2, should pointer-events='bounding-box' be affected by
   clip?

   DS: in the example at the url above, it's easily adapted to a test
   for that
   ... i would argue that the clip path is in effect occluding the rest
   of the element
   ... as if i had a path with a shape cut out of it

   CL: but is it occluding it as in capturing the event?
   ... i'd describe it as a hole (i.e., the opposite)

   DS: does it matter if the pointer-events is set on the target
   element or on the clipping element?

   CM: i would think that pointer-events on a clipPath doesn't do
   anything, since it is used only for geometry

   CL: it's not rendered, so it cannot by itself have pointer events

   DS: is the clipPath element necessary?

   CM: probably for @clipPathUnits

   ED: in firefox and opera the pointer events aren't delivered to
   clipped out regions, in safari they are

   <ed> [20]http://pastie.org/325527

     [20] http://pastie.org/325527

   CL: if you get the bounding box of the clipped circle you get the
   whole circle?

   ED: yes
   ... wonder what you get if you request the bounding box of a group
   that contains a clipped shape

   AG: i agree with CM [unscribed] who thinks of clipping as
   effectively changing the geometry
   ... [and hence affecting pointer events, bounding box, etc.]

   DS: i'd argue for the opposite, the clipping path just affects the
   rendering

   ED: i agree with DS, and so do safari and opera (and ASV iirc)

   <ed> ...and firefox

   CM: that's the current behaviour in batik

   DS: seems webkit ignores pointer-events and delivers them for all of
   the shape always
   ... i can imagine a use case for pointer-events respecting the
   clipping path
   ... boundingbox and all should, imo, apply apply to all of the base
   geometry

   AG: we should check our bounding box definition

   DS: i think the bbox definition is sufficient at the moment

   AG: we should ensure that pointer-events=boundingbox is aligned with
   what the bounding box definition is

   ED: i'd disagree with that for 'all', since it says for the fill or
   stroke of the element, regardless of the values for
   fill/stroke/visibility

   CL: i'm suggesting that the clip path doesn't affect
   pointer-events='all'
   ... so that case would be still ok

   CM: should the visible* values be affected by clip path, and the
   other values not?

   DS: also change in the masking/compositing module
   ... i'll put together wording for both the 1.1 erratum and the
   masking/compositing module change

   <scribe> ACTION: Doug to propose wording for the clip path
   pointer-events erratum and masking/compositing module change
   [recorded in
   [21]http://www.w3.org/2008/11/27-svg-minutes.html#action01]

   <trackbot> Created ACTION-2358 - Propose wording for the clip path
   pointer-events erratum and masking/compositing module change [on
   Doug Schepers - due 2008-12-04].

   <shepazu>
   [22]http://trac.webkit.org/export/38760/trunk/WebKitSite/specs/Point
   erEventsProperty.html

     [22] http://trac.webkit.org/export/38760/trunk/WebKitSite/specs/PointerEventsProperty.html

   CL: css has borders, it's not clear whether that's a stroke or not
   ... e.g. a <div> with a border, does visibleStroke apply to that?

   DS: it's the first checkin, he's still working on it

   (discussion about having a general mapping of css painting to svg
   stroking/filling)

   (and concepts more broadly)

   CL: if border is defined as the stroke, then what about stroking
   text? and things like that.

   DS: i heard that someone is interested in doing stroking of text
   with a different property name. how would that affect svg?

   CL: sounds innocuous, but then what happens with SVG text that has
   this new text-stroke property?

   <scribe> ACTION: Doug to start a conversation with the CSS WG about
   this [recorded in
   [23]http://www.w3.org/2008/11/27-svg-minutes.html#action02]

   <trackbot> Created ACTION-2359 - Start a conversation with the CSS
   WG about this [on Doug Schepers - due 2008-12-04].

   ACTION-2359: Where "this" means this mapping of SVG concepts to CSS.

   <trackbot> ACTION-2359 Start a conversation with the CSS WG about
   this notes added

selectors-api review

   ED: anybody else reviewed?

   DS: it's not due for a while yet?

   ED: 12 december

   CL: i feel like we should push back more on the lack of namespace
   support
   ... i.e., put back namespace support

   ED: postpone this discussion until next telcon?

Errata

   AG: i've done my errata related actions
   ... i've added the 1.1 full 2ed to cvs
   ... with some of the changes

   <anthony> - Linking in a text environment

   <anthony> - feFlood in attribute

   <anthony> - Filter subregion

   <anthony> - Cleaning up the wording of the underlying value being
   the identity transform

   <anthony> - Start and end incorrectly described for text

   <anthony> - Typo 'effect' instead of 'affect'

   <anthony> - Incorrect reference to solidColor element

   <anthony> - Capturing pointer-events with a zero opacity mask

   <ed> [24]http://dev.w3.org/SVG/profiles/1.1F2/master/

     [24] http://dev.w3.org/SVG/profiles/1.1F2/master/

   <ed> [25]http://dev.w3.org/SVG/profiles/1.1F2/errata/errata.xml

     [25] http://dev.w3.org/SVG/profiles/1.1F2/errata/errata.xml

   AG: i stripped out the 1.1F errata from that errata.xml and added it
   to the public repository
   ... i need to check in the tests that relate to the errata
   ... i want to discuss where we should put the xslt that transforms
   the errata
   ... in tools/errata/ ?
   ... but there are two xslts, one that makes the xml readable in a
   browser, and another that makes a publishable version

   CL: for the first one we need that published so that they can view
   the xml easily
   ... the second one can be in any convenient place

   AG: so first one in tools/ directory, other in the errata/
   directory?
   ... also, what are we going to do with the 1.1 tiny errata

   CL: are any of those not in 1.2T?

   AG: i'll go back and check

   <ed> old errata file:
   [26]http://www.w3.org/Graphics/SVG/Group/repository/errata/errata.xm
   l

     [26] http://www.w3.org/Graphics/SVG/Group/repository/errata/errata.xml

   CL: i ask because i saw a heise news item that said it replaced
   1.1T, which i hadn't really though of before
   ... but if it's important, we could publish errata and a 2ed of 1.1T
   ... if the errata are already covered in 1.2T, i'd say leave them be

   <ed>
   [27]http://www.w3.org/Graphics/SVG/Group/repository/errata/errata.xm
   l#version-m11

     [27] http://www.w3.org/Graphics/SVG/Group/repository/errata/errata.xml#version-m11

   ED: i'd say 1.2T is the new version to look at

   CL: there are various other things that could be backported to 1.1T,
   but i don't think that's a good use of our time

   ED: my suggestion is to keep the 1.1F errata items in the new repo,
   leave the 1.1T ones in the old repo

   AG: i also moved the errata we discussed last time to proposed

   ED: will we have a diff marked 1.1 2ed spec?

   CL: yes that's a good idea

   ED: we should ensure the changes in the errata file get copied over
   to the spec
   ... and mark the changes in the Changes appendix?

   CL: that, or we could have this/latest version uris at the top, and
   have another version which is the diff marked version of the spec
   ... i have no preference either way

   CM: should be easy to generate the diffs

StaticNodeList erratum

   <ed>
   [28]http://www.w3.org/Graphics/SVG/Group/repository/errata/errata.xm
   l#liveness-getintersectionlist-getenclosurelist

     [28] http://www.w3.org/Graphics/SVG/Group/repository/errata/errata.xml#liveness-getintersectionlist-getenclosurelist

   ED: this is for getIntersectionList and getEnclosureList
   ... it's been changed to be a StaticNodeList
   ... so instead of using the type StaticNodeList, i'd prefer to say
   that it's a NodeList with a comment saying it's not live

   CL: why that way?

   ED: seems to be the way people are doing it in the Web Apps WG
   ... so i'd prefer to align with that
   ... it doesn't really affect us much, just a name
   ... we're not alone in using non-live NodeLists

   <anthony> [29]http://dev.w3.org/SVG/profiles/1.1F2/errata/errata.xml

     [29] http://dev.w3.org/SVG/profiles/1.1F2/errata/errata.xml

   <scribe> ACTION: Erik to change the live node list erratum to revert
   the name to NodeList [recorded in
   [30]http://www.w3.org/2008/11/27-svg-minutes.html#action03]

   <trackbot> Created ACTION-2360 - Change the live node list erratum
   to revert the name to NodeList [on Erik Dahlström - due 2008-12-04].

language/switch processing erratum

   ED: i'd rather deal with this in Core 2.0

   CL: this was proposed to the symm wg originally, and they rejected
   it

   <ed>
   [31]http://dev.w3.org/SVG/profiles/1.1F2/errata/errata.xml#language-
   switch-processing

     [31] http://dev.w3.org/SVG/profiles/1.1F2/errata/errata.xml#language-switch-processing

   <ed> [32]http://www.w3.org/Graphics/SVG/WG/track/products/9

     [32] http://www.w3.org/Graphics/SVG/WG/track/products/9

   ED: so raise this for core 2.0, and remove the erratum
   ... since it's a new feature

   <shepazu> there is actually talk of doing this in a DOM spec

   <shepazu> in WebApps WG

   <ed> ISSUE-2189 raised for core 2

   <shepazu> sorry, static nodelist

   <ed> [33]http://www.w3.org/Graphics/SVG/WG/track/issues/2186

     [33] http://www.w3.org/Graphics/SVG/WG/track/issues/2186

Undefined behavior with filters erratum

   We decide to remove it.

   ED: there is ISSUE-2186 already

   ISSUE-2186?

   <trackbot> ISSUE-2186 -- Investigate undefined behaviour with
   filters? -- RAISED

   <trackbot> [34]http://www.w3.org/Graphics/SVG/WG/track/issues/2186

     [34] http://www.w3.org/Graphics/SVG/WG/track/issues/2186

   <scribe> ACTION: Anthony to make the appropriate changes to the text
   rotation erratum [recorded in
   [35]http://www.w3.org/2008/11/27-svg-minutes.html#action04]

   <trackbot> Created ACTION-2361 - Make the appropriate changes to the
   text rotation erratum [on Anthony Grasso - due 2008-12-04].

Reword F.5 Tangents erratum

   ED: i have an action on this

   CL: did we not have something on this in 1.2T from olaf?

   ED: tiny doesn't have markers, text path, arcs, so it wouldn't be
   complete for 1.1
   ... but we could probably borrow some wording from tiny
   ... i'd hope that zero length paths are defined in tiny

   CL: i thought this was one of the complex tests olaf added to the
   test suite

   ED: one of the at risk ones
   ... we should backport the wording from 1.2T to this erratum

   <scribe> ACTION: Erik to backport the zero length path wording from
   1.2T to this "Reword F.5 Tangents" erratum [recorded in
   [36]http://www.w3.org/2008/11/27-svg-minutes.html#action05]

   <trackbot> Created ACTION-2362 - Backport the zero length path
   wording from 1.2T to this \"Reword F.5 Tangents\" erratum [on Erik
   Dahlström - due 2008-12-04].

   <chris> see
   [37]http://www.w3.org/TR/SVGTiny12/implnote.html#PathElementImplemen
   tationNotes

     [37] http://www.w3.org/TR/SVGTiny12/implnote.html#PathElementImplementationNotes

Case sensitivity rewording erratum

   ED: i don't think we have a test for this

   CL: the test would need @style or <style>, which isn't in 1.2T

   ED: but we could test it for full

   CL: it should be allowed in the css syntax
   ... but it shouldn't be allowed in the attribute syntax
   ... i agree it should be tested

   ED: but we should not errata it?

   CL: yes, i don't think there's anything to errata
   ... if the presentation attribute uses a different case than the
   spec, then it's an invalid value
   ... but in css you can case it however you want
   ... but this doesn't require a change to the spec

   ED: reading the spec now i am not convinced there is an error to fix

   CL: i agree

   <scribe> ACTION: Chris to write a test for case sensitivity in style
   sheets [recorded in
   [38]http://www.w3.org/2008/11/27-svg-minutes.html#action06]

   <trackbot> Created ACTION-2363 - Write a test for case sensitivity
   in style sheets [on Chris Lilley - due 2008-12-04].

   ACTION-2363: Test for case INsensitivity

   <trackbot> ACTION-2363 Write a test for case sensitivity in style
   sheets notes added

   <ed>
   [39]http://dev.w3.org/SVG/profiles/1.1F2/errata/errata.xml#case-sens
   itivity-rewording

     [39] http://dev.w3.org/SVG/profiles/1.1F2/errata/errata.xml#case-sensitivity-rewording

Summary of Action Items

   [NEW] ACTION: Anthony to make the appropriate changes to the text
   rotation erratum [recorded in
   [40]http://www.w3.org/2008/11/27-svg-minutes.html#action04]
   [NEW] ACTION: Chris to write a test for case sensitivity in style
   sheets [recorded in
   [41]http://www.w3.org/2008/11/27-svg-minutes.html#action06]
   [NEW] ACTION: Doug to propose wording for the clip path
   pointer-events erratum and masking/compositing module change
   [recorded in
   [42]http://www.w3.org/2008/11/27-svg-minutes.html#action01]
   [NEW] ACTION: Doug to start a conversation with the CSS WG about
   this [recorded in
   [43]http://www.w3.org/2008/11/27-svg-minutes.html#action02]
   [NEW] ACTION: Erik to backport the zero length path wording from
   1.2T to this "Reword F.5 Tangents" erratum [recorded in
   [44]http://www.w3.org/2008/11/27-svg-minutes.html#action05]
   [NEW] ACTION: Erik to change the live node list erratum to revert
   the name to NodeList [recorded in
   [45]http://www.w3.org/2008/11/27-svg-minutes.html#action03]

   [End of minutes]
     _________________________________________________________


    Minutes formatted by David Booth's [46]scribe.perl version 1.133
    ([47]CVS log)
    $Date: 2008/11/27 21:05:37 $
     _________________________________________________________

     [46] http://dev.w3.org/cvsweb/~checkout~/2002/scribe/scribedoc.htm
     [47] http://dev.w3.org/cvsweb/2002/scribe/

Scribe.perl diagnostic output

   [Delete this section before finalizing the minutes.]
This is scribe.perl Revision: 1.133  of Date: 2008/01/18 18:48:51
Check for newer version at [48]http://dev.w3.org/cvsweb/~checkout~/2002
/scribe/

     [48] http://dev.w3.org/cvsweb/~checkout~/2002/scribe/

Guessing input format: RRSAgent_Text_Format (score 1.00)

Succeeded: s/just to the non-clipped content/apply to all of the base g
eometry/
Found Scribe: Cameron
Found ScribeNick: heycam
Default Present: ed, anthony, heycam, shepazu, ChrisL
Present: ed anthony heycam shepazu ChrisL
Found Date: 27 Nov 2008
Guessing minutes URL: [49]http://www.w3.org/2008/11/27-svg-minutes.html
People with action items: anthony chris doug erik

     [49] http://www.w3.org/2008/11/27-svg-minutes.html

WARNING: Input appears to use implicit continuation lines.
You may need the "-implicitContinuations" option.


   End of [50]scribe.perl diagnostic output]

     [50] http://dev.w3.org/cvsweb/~checkout~/2002/scribe/scribedoc.htm


-- 
Cameron McCormack ≝ http://mcc.id.au/
Received on Thursday, 27 November 2008 21:09:29 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Thursday, 27 November 2008 21:09:30 GMT