SVG Working Group Teleconference -- 27 Nov 2008

<trackbot> Date: 27 November 2008

<scribe> Scribe: Cameron

<scribe> ScribeNick: heycam

SVG 1.1 errata

<shepazu> http://lists.w3.org/Archives/Public/public-svg-wg/2008OctDec/0403.html

<shepazu> 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> https://bugzilla.mozilla.org/show_bug.cgi?id=376952

<shepazu> 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: https://bugzilla.mozilla.org/attachment.cgi?id=261068 (yes, works the same in FF3.1b1 and Opera 9.62)

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> http://www.w3.org/TR/SVGTiny12/interact.html#PointerEventsProperty

<ed> 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> 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 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> 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 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> http://dev.w3.org/SVG/profiles/1.1F2/master/

<ed> 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: 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> 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> 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> 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 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> http://dev.w3.org/SVG/profiles/1.1F2/errata/errata.xml#language-switch-processing

<ed> 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> 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> 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 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 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 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 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> http://dev.w3.org/SVG/profiles/1.1F2/errata/errata.xml#case-sensitivity-rewording

- DRAFT -

SVG Working Group Teleconference

27 Nov 2008

Attendees

Contents