19:30:46 <RRSAgent> RRSAgent has joined #svg
19:30:46 <RRSAgent> logging to http://www.w3.org/2008/11/27-svg-irc
19:30:48 <trackbot> RRSAgent, make logs public
19:30:50 <trackbot> Zakim, this will be GA_SVGWG
19:30:50 <Zakim> ok, trackbot; I see GA_SVGWG()2:30PM scheduled to start now
19:30:51 <trackbot> Meeting: SVG Working Group Teleconference
19:30:51 <trackbot> Date: 27 November 2008
19:31:50 <Zakim> GA_SVGWG()2:30PM has now started
19:31:56 <Zakim> +??P0
19:32:05 <Zakim> +??P1
19:32:17 <ed> Zakim, +??P0 is me
19:32:17 <Zakim> sorry, ed, I do not recognize a party named '+??P0'
19:32:28 <ed> Zakim, ??P0 is me
19:32:28 <Zakim> +ed; got it
19:32:31 <anthony> Zakim, ??P1 is me
19:32:31 <Zakim> +anthony; got it
19:32:45 <Zakim> +??P2
19:32:51 <heycam> Zakim, ??P2 is me
19:32:51 <Zakim> +heycam; got it
19:33:07 <Zakim> +??P3
19:33:33 <shepazu> Zakim, ??P3 is me
19:33:33 <Zakim> +shepazu; got it
19:34:42 <heycam> Scribe: Cameron
19:34:44 <heycam> ScribeNick: heycam
19:34:52 <heycam> Chair: Erik
19:35:02 <heycam> Topic: SVG 1.1 errata
19:35:08 <shepazu> http://lists.w3.org/Archives/Public/public-svg-wg/2008OctDec/0403.html
19:35:12 <Zakim> +ChrisL
19:35:34 <shepazu> http://www.w3.org/Graphics/SVG/Group/repository/errata/errata.xml#clippath-pointer-events
19:36:01 <heycam> CM: This was mentioned on batik-users, which is why I mention it
19:36:17 <heycam> ED: there is no action on it?
19:36:18 <chris> chris has joined #svg
19:37:14 <heycam> DS: i don't know if there's an action or not, but i'll take one
19:37:32 <heycam> DS: i don't think i specified it well, but my email didn't say exactly what needs to be done
19:37:44 <heycam> DS: it just says that clip path does not affect pointer events
19:37:59 <shepazu> [[
19:38:00 <shepazu> clarify that clipPath does not affect 
19:38:01 <shepazu> pointer events.  This should note that since clipPath is not rendered, 
19:38:01 <shepazu> no pointer-event values on children of clipPath will affect the target.
19:38:02 <shepazu> [[
19:38:18 <heycam> DS: mozilla has this behaviour now
19:38:50 <heycam> CL: it could mean that clip path with two paths inside it, and you can't clip on them
19:38:51 <shepazu> https://bugzilla.mozilla.org/show_bug.cgi?id=376952
19:39:01 <shepazu> https://bugzilla.mozilla.org/attachment.cgi?id=261068
19:39:02 <heycam> CL: or the second one is whether you can click on clipped out parts of shapes
19:39:19 <ed> testcase: https://bugzilla.mozilla.org/attachment.cgi?id=261068 (yes, works the same in FF3.1b1 and Opera 9.62)
19:40:30 <heycam> CM: it's the second one, yes?
19:41:26 <heycam> DS: actually that bug is a different issue
19:41:46 <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)
19:42:26 <ed> confirmed that the testcase works the same in Safari 3.2.1 too
19:44:01 <heycam> CL: in the second case, you have a rendered shape with pointer-events and part of it is clipped
19:44:19 <heycam> CL: so 2a) is stuff inside the clipping path, which is rendered -- should it get pointer events (yes, it should)
19:44:36 <heycam> CL: 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)
19:44:56 <heycam> DS: i think everybody thinks the visible stuff should get pointer events
19:45:45 <shepazu> http://www.w3.org/TR/SVGTiny12/interact.html#PointerEventsProperty
19:45:55 <ed> http://www.w3.org/TR/SVG11/interact.html#PointerEventsProperty
19:46:45 <heycam> CL: in tiny 1.2, should pointer-events='bounding-box' be affected by clip?
19:47:14 <heycam> DS: in the example at the url above, it's easily adapted to a test for that
19:47:43 <heycam> DS: i would argue that the clip path is in effect occluding the rest of the element
19:47:55 <heycam> DS: as if i had a path with a shape cut out of it
19:48:04 <heycam> CL: but is it occluding it as in capturing the event?
19:48:14 <heycam> CL: i'd describe it as a hole (i.e., the opposite)
19:48:37 <heycam> DS: does it matter if the pointer-events is set on the target element or on the clipping element?
19:49:00 <heycam> CM: i would think that pointer-events on a clipPath doesn't do anything, since it is used only for geometry
19:49:14 <heycam> CL: it's not rendered, so it cannot by itself have pointer events
19:50:10 <heycam> DS: is the clipPath element necessary?
19:50:16 <heycam> CM: probably for @clipPathUnits
19:53:50 <heycam> ED: in firefox and opera the pointer events aren't delivered to clipped out regions, in safari they are
19:54:10 <ed> http://pastie.org/325527
19:57:45 <heycam> CL: if you get the bounding box of the clipped circle you get the whole circle?
19:57:46 <heycam> ED: yes
19:58:09 <heycam> ED: wonder what you get if you request the bounding box of a group that contains a clipped shape
19:58:45 <heycam> AG: i agree with CM [unscribed] who thinks of clipping as effectively changing the geometry
19:58:56 <heycam> AG: [and hence affecting pointer events, bounding box, etc.]
19:59:07 <heycam> DS: i'd argue for the opposite, the clipping path just affects the rendering
19:59:57 <heycam> ED: i agree with DS, and so do safari and opera (and ASV iirc)
20:00:05 <ed> ...and firefox
20:00:22 <heycam> CM: that's the current behaviour in batik
20:00:52 <heycam> DS: seems webkit ignores pointer-events and delivers them for all of the shape always
20:01:54 <heycam> DS: i can imagine a use case for pointer-events respecting the clipping path
20:02:20 <heycam> DS: boundingbox and all should, imo, apply just to the non-clipped content
20:03:41 <heycam> s/just to the non-clipped content/apply to all of the base geometry/
20:04:25 <heycam> AG: we should check our bounding box definition
20:04:42 <heycam> DS: i think the bbox definition is sufficient at the moment
20:04:55 <heycam> AG: we should ensure that pointer-events=boundingbox is aligned with what the bounding box definition is
20:05:24 <heycam> 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
20:05:53 <heycam> CL: i'm suggesting that the clip path doesn't affect pointer-events='all'
20:06:00 <heycam> CL: so that case would be still ok
20:07:14 <heycam> CM: should the visible* values be affected by clip path, and the other values not?
20:08:23 <heycam> DS: also change in the masking/compositing module
20:08:34 <heycam> DS: i'll put together wording for both the 1.1 erratum and the masking/compositing module change
20:09:50 <heycam> ACTION: Doug to propose wording for the clip path pointer-events erratum and masking/compositing module change
20:09:50 <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].
20:10:04 <shepazu> http://trac.webkit.org/export/38760/trunk/WebKitSite/specs/PointerEventsProperty.html
20:10:52 <heycam> CL: css has borders, it's not clear whether that's a stroke or not
20:11:06 <heycam> CL: e.g. a <div> with a border, does visibleStroke apply to that?
20:11:13 <heycam> DS: it's the first checkin, he's still working on it
20:15:34 <heycam> (discussion about having a general mapping of css painting to svg stroking/filling)
20:15:43 <heycam> (and concepts more broadly)
20:16:33 <heycam> CL: if border is defined as the stroke, then what about stroking text?  and things like that.
20:16:55 <heycam> DS: i heard that someone is interested in doing stroking of text with a different property name.  how would that affect svg?
20:17:20 <heycam> CL: sounds innocuous, but then what happens with SVG text that has this new text-stroke property?
20:18:25 <heycam> ACTION: Doug to start a conversation with the CSS WG about this
20:18:25 <trackbot> Created ACTION-2359 - Start a conversation with the CSS WG about this [on Doug Schepers - due 2008-12-04].
20:19:01 <heycam> ACTION-2359: Where "this" means this mapping of SVG concepts to CSS.
20:19:01 <trackbot> ACTION-2359 Start a conversation with the CSS WG about this notes added
20:19:10 <heycam> Topic: selectors-api review
20:19:14 <heycam> ED: anybody else reviewed?
20:19:18 <heycam> DS: it's not due for a while yet?
20:19:22 <heycam> ED: 12 december
20:19:36 <heycam> CL: i feel like we should push back more on the lack of namespace support
20:19:44 <heycam> CL: i.e., put back namespace support
20:20:45 <heycam> ED: postpone this discussion until next telcon?
20:21:20 <Zakim> -shepazu
20:21:44 <heycam> Topic: Errata
20:22:00 <heycam> AG: i've done my errata related actions
20:22:13 <heycam> AG: i've added the 1.1 full 2ed to cvs
20:22:16 <heycam> AG: with some of the changes
20:22:31 <anthony>  - Linking in a text environment
20:22:33 <anthony>  - feFlood in attribute
20:22:35 <anthony>  - Filter subregion
20:22:37 <anthony>  - Cleaning up the wording of the underlying value being the identity transform
20:22:39 <anthony>  - Start and end incorrectly described for text
20:22:40 <anthony>  - Typo 'effect' instead of 'affect'
20:22:42 <anthony>  - Incorrect reference to solidColor element
20:22:44 <anthony>  - Capturing pointer-events with a zero opacity mask
20:22:46 <ed> http://dev.w3.org/SVG/profiles/1.1F2/master/
20:22:58 <ed> http://dev.w3.org/SVG/profiles/1.1F2/errata/errata.xml
20:23:04 <heycam> AG: i stripped out the 1.1F errata from that errata.xml and added it to the public repository
20:23:25 <heycam> AG: i need to check in the tests that relate to the errata
20:23:44 <heycam> AG: i want to discuss where we should put the xslt that transforms the errata
20:23:50 <heycam> AG: in tools/errata/ ?
20:24:07 <heycam> AG: but there are two xslts, one that makes the xml readable in a browser, and another that makes a publishable version
20:24:17 <heycam> CL: for the first one we need that published so that they can view the xml easily
20:24:24 <heycam> CL: the second one can be in any convenient place
20:24:41 <heycam> AG: so first one in tools/ directory, other in the errata/ directory?
20:25:01 <heycam> AG: also, what are we going to do with the 1.1 tiny errata
20:25:16 <heycam> CL: are any of those not in 1.2T?
20:25:21 <heycam> AG: i'll go back and check
20:25:45 <ed> old errata file: http://www.w3.org/Graphics/SVG/Group/repository/errata/errata.xml
20:26:10 <heycam> CL: i ask because i saw a heise news item that said it replaced 1.1T, which i hadn't really though of before
20:26:25 <heycam> CL: but if it's important, we could publish errata and a 2ed of 1.1T
20:27:01 <heycam> CL: if the errata are already covered in 1.2T, i'd say leave them be
20:27:05 <ed> http://www.w3.org/Graphics/SVG/Group/repository/errata/errata.xml#version-m11
20:28:10 <heycam> ED: i'd say 1.2T is the new version to look at
20:28:29 <heycam> 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
20:29:37 <heycam> ED: my suggestion is to keep the 1.1F errata items in the new repo, leave the 1.1T ones in the old repo
20:30:03 <heycam> AG: i also moved the errata we discussed last time to proposed
20:30:16 <heycam> ED: will we have a diff marked 1.1 2ed spec?
20:30:36 <heycam> CL: yes that's a good idea
20:30:58 <heycam> ED: we should ensure the changes in the errata file get copied over to the spec
20:31:37 <heycam> ED: and mark the changes in the Changes appendix?
20:31:58 <heycam> 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
20:32:05 <heycam> CL: i have no preference either way
20:33:32 <heycam> CM: should be easy to generate the diffs
20:33:43 <heycam> Topic: StaticNodeList erratum
20:33:47 <ed> http://www.w3.org/Graphics/SVG/Group/repository/errata/errata.xml#liveness-getintersectionlist-getenclosurelist
20:34:06 <heycam> ED: this is for getIntersectionList and getEnclosureList
20:34:11 <heycam> ED: it's been changed to be a StaticNodeList
20:34:25 <heycam> ED: 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
20:34:29 <heycam> CL: why that way?
20:34:37 <heycam> ED: seems to be the way people are doing it in the Web Apps WG
20:34:44 <heycam> ED: so i'd prefer to align with that
20:34:51 <heycam> ED: it doesn't really affect us much, just a name
20:35:06 <heycam> ED: we're not alone in using non-live NodeLists
20:35:58 <anthony> http://dev.w3.org/SVG/profiles/1.1F2/errata/errata.xml
20:36:11 <heycam> ACTION: Erik to change the live node list erratum to revert the name to NodeList
20:36:11 <trackbot> Created ACTION-2360 - Change the live node list erratum to revert the name to NodeList [on Erik Dahlström - due 2008-12-04].
20:37:34 <heycam> Topic: language/switch processing erratum
20:37:41 <heycam> ED: i'd rather deal with this in Core 2.0
20:37:50 <heycam> CL: this was proposed to the symm wg originally, and they rejected it
20:37:58 <ed> http://dev.w3.org/SVG/profiles/1.1F2/errata/errata.xml#language-switch-processing
20:39:06 <ed> http://www.w3.org/Graphics/SVG/WG/track/products/9
20:40:07 <heycam> ED: so raise this for core 2.0, and remove the erratum
20:40:13 <heycam> ED: since it's a new feature
20:44:40 <shepazu> there is actually talk of doing this in a DOM spec
20:44:56 <shepazu> in WebApps WG
20:45:11 <ed> ISSUE-2189 raised for core 2
20:45:31 <shepazu> sorry, static nodelist
20:49:46 <ed> http://www.w3.org/Graphics/SVG/WG/track/issues/2186
20:51:30 <heycam> Topic: Undefined behavior with filters erratum
20:52:14 <heycam> We decide to remove it.
20:52:19 <heycam> ED: there is ISSUE-2186 already
20:52:22 <heycam> ISSUE-2186?
20:52:22 <trackbot> ISSUE-2186 -- Investigate undefined behaviour with filters? -- RAISED
20:52:22 <trackbot> http://www.w3.org/Graphics/SVG/WG/track/issues/2186
20:53:31 <heycam> ACTION: Anthony to make the appropriate changes to the text rotation erratum
20:53:31 <trackbot> Created ACTION-2361 - Make the appropriate changes to the text rotation erratum [on Anthony Grasso - due 2008-12-04].
20:55:22 <heycam> Topic: Reword F.5 Tangents erratum
20:55:25 <heycam> ED: i have an action on this
20:55:34 <heycam> CL: did we not have something on this in 1.2T from olaf?
20:55:49 <heycam> ED: tiny doesn't have markers, text path, arcs, so it wouldn't be complete for 1.1
20:56:10 <heycam> ED: but we could probably borrow some wording from tiny
20:56:52 <heycam> ED: i'd hope that zero length paths are defined in tiny
20:57:05 <heycam> CL: i thought this was one of the complex tests olaf added to the test suite
20:57:36 <heycam> ED: one of the at risk ones
20:58:01 <heycam> ED: we should backport the wording from 1.2T to this erratum
20:58:24 <heycam> ACTION: Erik to backport the zero length path wording from 1.2T to this "Reword F.5 Tangents" erratum
20:58:24 <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].
20:58:32 <chris> see http://www.w3.org/TR/SVGTiny12/implnote.html#PathElementImplementationNotes
20:59:10 <heycam> Topic: Case sensitivity rewording erratum
21:00:47 <heycam> ED: i don't think we have a test for this
21:01:02 <heycam> CL: the test would need @style or <style>, which isn't in 1.2T
21:01:05 <heycam> ED: but we could test it for full
21:01:13 <heycam> CL: it should be allowed in the css syntax
21:01:21 <heycam> CL: but it shouldn't be allowed in the attribute syntax
21:01:25 <heycam> CL: i agree it should be tested
21:01:33 <heycam> ED: but we should not errata it?
21:01:41 <heycam> CL: yes, i don't think there's anything to errata
21:01:54 <heycam> CL: if the presentation attribute uses a different case than the spec, then it's an invalid value
21:02:04 <heycam> CL: but in css you can case it however you want
21:02:09 <heycam> CL: but this doesn't require a change to the spec
21:02:18 <heycam> ED: reading the spec now i am not convinced there is an error to fix
21:02:20 <heycam> CL: i agree
21:03:21 <heycam> ACTION: Chris to write a test for case sensitivity in style sheets
21:03:21 <trackbot> Created ACTION-2363 - Write a test for case sensitivity in style sheets [on Chris Lilley - due 2008-12-04].
21:03:43 <heycam> ACTION-2363: Test for case INsensitivity
21:03:43 <trackbot> ACTION-2363 Write a test for case sensitivity in style sheets notes added
21:04:59 <ed> http://dev.w3.org/SVG/profiles/1.1F2/errata/errata.xml#case-sensitivity-rewording
21:05:19 <Zakim> -ed
21:05:20 <Zakim> -ChrisL
21:05:20 <Zakim> -heycam
21:05:22 <Zakim> -anthony
21:05:23 <Zakim> GA_SVGWG()2:30PM has ended
21:05:25 <Zakim> Attendees were ed, anthony, heycam, shepazu, ChrisL
21:05:32 <heycam> RRSAgent, make minutes
21:05:32 <RRSAgent> I have made the request to generate http://www.w3.org/2008/11/27-svg-minutes.html heycam
21:48:10 <shepazu> hmmm... I wonder how much value there is in insisting on case-sensitivity in attribute values, if we are going to allow error-correction in content in SVG-in-HTML?
21:48:51 <shepazu> heycam, ed_work, anthony... thoughts?
22:18:10 <Zakim> Zakim has left #svg
22:49:33 <anthony> shepazu, is there a technical reason for having case-sensitivity in attribute values?
22:50:17 <shepazu> well, it makes parsing easier
22:50:41 <shepazu> XML processors will expect it, still
22:51:02 <shepazu> XML is case-sensitive
22:51:13 <shepazu> so, I guess we need to keep that stricture
22:51:38 <shepazu> for all the places where SVG is treated as a simple XML format
22:52:35 <heycam> then again, having different case sensitivity rules between css and presentation attributes may be confusing
23:00:51 <shepazu> heycam: true
23:01:20 <shepazu> and, in fact, between standalone SVG content and SVG content in HTML...
23:01:43 <heycam> yeah...
23:03:48 <shepazu> this is what gives me pause
23:04:56 <shepazu> it's easy enough for an implementation to correct simple case mismatches (just convert to lower-case and compare that), and harder for authors to remember them
23:05:42 <shepazu> I admit that I curse viewBox regularly, both for myself, and because I've seen it so often as a cause of buggy content
23:06:10 <shepazu> not sure why that wasn't 'viewbox'
23:07:06 <heycam> and (as some people point out) the inconsistent capitalisation of elements
23:07:13 <heycam> e.g. <font-face-uri>
23:07:22 <heycam> vs camel case
23:13:42 <shepazu> yeah, it does seem clumsy... lower-case would have been more consistent and easier to remember...
23:13:55 <shepazu> but maybe they were not counting on so many hand-coders
23:14:12 <shepazu> figured that authoring tools would do the heavy lifting
23:19:38 <heycam> maybe
23:28:52 <shepazu> so, your assessment, heycam?
23:29:20 <shepazu> should we loosen up the case-sensitivity?  should we make it optional?  should we remain strict?
23:29:44 <heycam> i think in general i like case sensitivity
23:29:45 <shepazu> (for SVG 2.0, obviously)
23:29:56 <heycam> but i also dislike inconsistency ;)
23:30:07 <heycam> i wonder what implementations actually do
23:30:16 <shepazu> what do you like about case-sensitivity?
23:31:00 <heycam> it forces me to use a particular case (so i don't have to decide)
23:31:13 <heycam> and it also means that other peoples' code will have the same casing
23:33:19 <shepazu> so, if it weren't for legacy, I would not find that compelling enough a reason
23:41:31 <heycam> the reasons against would be author friendliness, and consistency with css?
23:47:19 <shepazu> and consistency with the pragmatics of how SVG in text/html will be parsed
23:48:08 <heycam> you think it's something we should consider then?