IRC log of svg on 2008-11-27

Timestamps are in UTC.

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: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?