- From: Cameron McCormack <cam@mcc.id.au>
- Date: Fri, 28 Nov 2008 08:08:51 +1100
- To: public-svg-wg@w3.org
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 UTC