19:30:24 <RRSAgent> RRSAgent has joined #svg
19:30:24 <RRSAgent> logging to http://www.w3.org/2008/12/08-svg-irc
19:30:26 <trackbot> RRSAgent, make logs public
19:30:28 <trackbot> Zakim, this will be GA_SVGWG
19:30:28 <Zakim> ok, trackbot; I see GA_SVGWG()2:30PM scheduled to start now
19:30:29 <trackbot> Meeting: SVG Working Group Teleconference
19:30:29 <trackbot> Date: 08 December 2008
19:31:07 <Zakim> GA_SVGWG()2:30PM has now started
19:31:33 <heycam> Zakim, who is on the call?
19:31:33 <Zakim> On the phone I see no one
19:31:48 <heycam> but Zakim i should be on the call...
19:32:21 <heycam> Zakim, who is here?
19:32:21 <Zakim> On the phone I see no one
19:32:22 <Zakim> On IRC I see RRSAgent, Zakim, NH, ed, ChrisL, trackbot, heycam, shepazu, anthony, ed_work
19:32:35 <shepazu> Zakim, who's here?
19:32:35 <Zakim> On the phone I see no one
19:32:36 <Zakim> On IRC I see RRSAgent, Zakim, NH, ed, ChrisL, trackbot, heycam, shepazu, anthony, ed_work
19:34:13 <ed> Present: ED, DS, CM, AG
19:35:20 <anthony> Chair: Erik
19:35:26 <anthony> Scribe: anthony
19:35:49 <anthony> Topic: Selectors API Review
19:35:51 <ed> http://lists.w3.org/Archives/Public/public-webapps/2008OctDec/0450.html
19:36:26 <anthony> ED: We got responses from Lachlan
19:36:55 <anthony> ... The first high level comment he disagrees with is about NSRelovers
19:37:06 <anthony> ... and adding wording to say it will be in a future version
19:37:15 <anthony> DS: His rational is that other features are left out
19:37:27 <anthony> ... why does it need to be added in the future
19:37:46 <anthony> ... It's because it was the in the draft originally
19:37:53 <anthony> ... and was only recently removed
19:38:08 <anthony> ... it's also a critical piece of functionality for certain things
19:38:18 <anthony> ... that's just my opinion anyway
19:39:09 <heycam> Zakim, what conference is this?
19:39:09 <Zakim> this is GA_SVGWG()2:30PM conference code 7841
19:39:15 <anthony> ... We have no objections with a list of things that will be added in the next version
19:39:30 <anthony> ... if they want to add other things back into the spec
19:40:04 <anthony> ED: The second comment he agrees with
19:40:16 <anthony> ... I would be fine with saying we are satisfied with that
19:40:23 <anthony> ... unless someone disagrees
19:40:25 <anthony> DS: Nope
19:40:34 <anthony> ED: The next comment is Section 6
19:40:35 <ed> http://lists.w3.org/Archives/Public/public-webapps/2008OctDec/0453.html.
19:41:09 <anthony> ... I tried to explain the reasoning for not mentioning authoring requirements
19:41:45 <anthony> DS: The tests should be for the implementation not the user
19:42:48 <anthony> ED: I think it's probably more tricky to check scripts than markup
19:43:11 <anthony> ED: The next comment is about the Selectors Group Production
19:43:13 <ed> present+ CL
19:43:17 <ChrisL> zakim, who is here?
19:43:17 <Zakim> On the phone I see no one
19:43:18 <Zakim> On IRC I see RRSAgent, Zakim, NH, ed, ChrisL, trackbot, heycam, shepazu, anthony, ed_work
19:44:03 <anthony> ED: The comment we are discussing now he agrees with and changed the text a bit
19:44:10 <anthony> ... He added an extra sentence
19:44:26 <ed> This group of selectors must not use namespace prefixes
19:44:27 <ed>     that need to be resolved.
19:44:44 <anthony> ED: I think that is fine, probably
19:44:59 <anthony> ... it is allowed in the Selectors Group to have namespace selector
19:45:25 <anthony> ... but since the spec in general doesn't allow it I think it's fine
19:45:51 <anthony> CL: If they are saying it's not ready now but saying it's going to be ready later is different
19:46:12 <anthony> ... to it not ever going to be put in
19:46:37 <anthony> ED: Do we agree or disagree with it
19:46:46 <anthony> ... and what should our response be?
19:47:19 <ChrisL> s/now/in this version/
19:47:29 <ChrisL> s/later/in the next version/
19:48:27 <anthony> ED: We can connect this one to the response of our first comment
19:48:37 <anthony> ... which was about mentioning NSResolvers
19:48:45 <anthony> ... and saying what features will be in the next version
19:49:25 <anthony> ... The next comment was I think Lachlan misunderstanding the comment
19:49:34 <anthony> ... the only thing missing was the "of" in that sentence
19:49:56 <anthony> ... The next comment is about when the selection isn't done
19:50:14 <anthony> ... I thought the wording in the spec was a bit unclear about evaluating the selector
19:50:33 <anthony> ... he suggests waiting to hear back from some implementers before evaluating the text
19:50:38 <ed> s/selection isn't done/selection is done in the document/
19:51:13 <anthony> ED: Depending on how you read this you might get different results
19:51:28 <anthony> ... depending on their interpretation
19:51:42 <anthony> ... it is possible that they have different strategies for the selectors
19:51:56 <anthony> CM: Does it not say anywhere in the document about creating a list?
19:52:13 <anthony> ED: I didn't see anything when reading the spec
19:52:41 <anthony> ... although personally I'd be ok with letting that one go as is
19:52:48 <anthony> ... probably not as bigger issue
19:53:16 <anthony> ... The next one is about adding hardcoded namespaces for SVG and XHTML
19:53:42 <anthony> ... and he disagrees with that and mentions his previous comment on NSResolvers
19:53:54 <anthony> CM: They are automatically declared in XML
19:53:59 <anthony> CL: So it's not the same thing at all
19:54:21 <anthony> CM: In fact I think one of them you can't declare
19:54:40 <anthony> CL: That's right you can't declare the XML prefix
19:54:53 <anthony> ED: Oh you can't
19:54:54 <ChrisL> xml prefix is predeclared and cannot be redeclared
19:54:57 <anthony> CL: I think so
19:55:11 <anthony> ED: [Reads out spec]
19:55:24 <anthony> ... it must not be declared according to the sepc
19:55:31 <ed> http://www.w3.org/TR/REC-xml-names/#ns-decl
19:55:37 <ChrisL> you can't say xmlns:xml="http://example.com/foo"
19:56:19 <anthony> CM: And at least for matching xml:lang you can match on the node name because you know that prefix
19:56:36 <anthony> ... so in selectors if you don't put in the prefix is that matching on local name or node name?
19:56:44 <anthony> ED: I think it's local name
19:57:14 <ChrisL> could select on xml\:lang which is kinda gross
19:57:50 <anthony> CM: So selectors he says match the local part of the qualified name
19:58:01 <anthony> ... oh wait it says in the [namespace client...]
19:58:19 <anthony> CL: There is a separate attribute called lang, which should have the same value but who knows
19:58:34 <anthony> CM: Maybe sometimes you can do it sometimes you can't
19:58:43 <heycam> http://www.w3.org/TR/css3-selectors/#downlevel
19:59:52 <anthony> ED: He goes on to say that it would have adverse effects on future plans when introducing namespace resolution
20:00:16 <anthony> CM: Perhaps you can ask him if it's a downlevel client
20:01:33 <anthony> ED: My feeling that is we shouldn't push for the hardcoded prefixes
20:01:43 <anthony> ... we should push for future plans of namespaced elements
20:01:58 <anthony> CL: I guess it's fine for not having hardcoded prefixes for SVG and so on
20:02:04 <anthony> ... I think the XML is a different issue
20:02:39 <anthony> ED: So the next one is a link to DOM3 XPath to cover all the cases where selectors falls short
20:02:45 <anthony> ... and he doesn't see the benefit
20:03:01 <anthony> ... and two people have already responded saying it would useful
20:05:03 <anthony> ... The next response is he doesn't understand the comment I made
20:05:24 <anthony> ... which was to clarify the term NULL Namespace and Default Namespace
20:05:43 <anthony> ... and further down he disagrees with adding CSS Namespace
20:07:28 <anthony> ... so in this spec there is talk about Namespaces in CSS so at the minimum an informative reference
20:07:46 <anthony> CM: That syntax still has to be supported, so things that do prefix is resolution
20:07:49 <anthony> ED: Oh right
20:08:00 <anthony> ... so a normative reference is what is needed
20:08:14 <anthony> ... it's CSS 3 selectors they have there
20:08:56 <anthony> CM: So CSS Namespaces spec, is that only for use on top of CSS 2?
20:10:12 <anthony> CL: The selects module tells you how to use namespaces in the selector and the namespaces spec tells you how to declare them
20:10:19 <anthony> ... you need both together
20:10:54 <anthony> s/selects/selectors/
20:11:22 <ChrisL> you need both together to use the ns parts of selectors. if you are usig a non-ns subset of selectors then you don't need to declare a ns so you don't need css3 namespcaes,  just selectors
20:11:48 <anthony> ED: So on the grounds it doesn't use any namespace resolution, let's just ask for an informative reference
20:12:28 <anthony> ... it does mention the namespace syntax so it does make sense to at least give a mention
20:12:50 <anthony> ... and I'm not sure if the terms are slightly different
20:13:27 <anthony> ... The next comment is about the Example I proposed
20:13:36 <anthony> ... he points to Boris without giving a link
20:13:51 <ed> http://lists.w3.org/Archives/Public/www-svg/2008Dec/0022.html
20:14:14 <anthony> ED: So Boris says it can't be done at the moemnt
20:14:26 <anthony> ... but I disagree. There are work arounds at the moment
20:14:45 <anthony> ... I think the spec should acknowledge this at least
20:14:52 <anthony> s/moemnt/moment/
20:15:18 <anthony> ED: One way would be use class, so that you can identify elements
20:15:40 <anthony> ... it is difficult to identify different font elements here
20:16:21 <anthony> ... I did some of these work around and of course I ran into some bugs
20:16:34 <ChrisL> if you don't have namespaces, sure its going to be an issue (d'oh!)
20:17:29 <anthony> DS: The people who are going to be using SVG fonts in their name spaces are not going to be the same people that use the font element in HTML
20:17:50 <anthony> ED: So he doesn't want to include the example in the spec
20:17:58 <anthony> ... and doesn't want to write up on the problem
20:18:34 <anthony> DS: I think we should push back on that
20:18:52 <anthony> ED: It's strange to read his argument on that, he doesn't want to demonstrate the impossible
20:19:26 <anthony> CM: It seems like he's interpreting your request as "add an example of how you do this without namespaces"
20:20:07 <anthony> ED: The last one is the reference to CSS Namespaces as a normative reference
20:20:18 <anthony> CL: We should agree with that and ask it be a normative reference
20:20:38 <anthony> ED: Now the last one is it was changed normative reference and it's clearer now
20:21:01 <ed> s/ changed normative reference/ changed to informative references/
20:22:03 <anthony> ACTION: Erik to Collect all the discussed responses for the selectors API and send them in
20:22:03 <trackbot> Created ACTION-2376 - Collect all the discussed responses for the selectors API and send them in [on Erik Dahlström - due 2008-12-15].
20:22:47 <anthony> Topic: Clip Path
20:22:51 <shepazu> http://lists.w3.org/Archives/Public/public-svg-wg/2008OctDec/0418.html
20:23:05 <shepazu> s/Clip Path/Clip Path and masking/
20:23:31 <anthony> CL: Is this the same bug as the ellipses being clipped in Firefox
20:23:39 <anthony> DS: We should actually talk about that as well
20:24:13 <anthony> ... Cameron and I figured out that our resolution last week conflicted with an earlier resolution
20:24:35 <anthony> ... on how pointer events effect things outside the clipping area
20:25:31 <anthony> ... after discussion we can credibly put this wording in resolves the need to add extra values
20:26:18 <anthony> ... I used some of Chris's wording to make a new note for the errata that talks about pointer events
20:27:12 <anthony> ... so, if guys can look at that wording we can talk about Thomas Deweese's email
20:28:20 <shepazu> "must affect" -> "must register on"
20:28:29 <anthony> CM: So this is in addition to the other change?
20:28:40 <anthony> DS: The earlier changes were for the clippath section
20:28:50 <anthony> ... this is the changes for the pointer events section
20:29:19 <anthony> CM: I thought that he meant the description of the different values
20:29:28 <anthony> ... to clarify what visible paint actually means
20:29:41 <anthony> DS: Is that what you meant ED?
20:29:56 <anthony> ED: Let me just take a quick look at the spec
20:30:08 <anthony> DS: We could put in a high level note
20:30:17 <anthony> ED: The Pointer Events section is a bit hard to read
20:30:46 <anthony> ... there are special notes for a number of different things
20:31:24 <anthony> ... well it would prefer to have it mentioned somewhere
20:31:40 <anthony> DS: This is a general rule about pointer events
20:31:46 <anthony> ... about the whole visible thing
20:32:18 <anthony> ... the combination of this section plus the part in the clip path section conveys the information
20:32:26 <anthony> ... we can fix how it is presented in 2.0
20:32:40 <anthony> ED: What was Thomas's comment?
20:32:51 <shepazu> http://lists.w3.org/Archives/Public/www-svg/2008Dec/0015.html
20:33:05 <anthony> DS: He thinks that this is short term hack rather than a study
20:33:21 <anthony> ... he sees a closer relation to masks and clippaths
20:33:46 <anthony> ... [quote parts of email about pixel values]\
20:34:10 <anthony> CL: A clipping path is very geometric
20:34:28 <anthony> ... it is clear the path outside the clipping path is clear that it's outside
20:35:40 <anthony> ED: In some cases you can think of mask as a clippath
20:35:47 <anthony> DS: That's more of a highlevel comment
20:36:00 <anthony> ... that conceptulises it
20:36:03 <ed> s/mask as a clippath/clippath as a mask/
20:36:19 <anthony> ... my question is do implementers see them in the same way
20:36:22 <ChrisL> finess the comparison, say "in some ways" its like a mask (because inother ways they are different)
20:36:36 <anthony> ... do you use alot of the same code for clips and masks?
20:36:36 <ChrisL> s/finess/finesse/
20:36:53 <anthony> ... if yes then we need to pay more attention to this comment
20:37:15 <anthony> CL: One is doing hit testing and the other is doing a look up through a grid
20:37:50 <anthony> CM: Clipping does some geometry stuff and masking does a raster operation
20:37:59 <ChrisL> Thomas makes a good point here: Aside from all the above I have an actual question on implementation
20:37:59 <ChrisL> of the proposed errata.  The errata talks a lot like the element with
20:37:59 <ChrisL> the clip-path and the event target must be the same element.  In practice
20:37:59 <ChrisL> the clip is often on a higher level 'g' element.  So the question I
20:37:59 <ChrisL> have is do I take the errata literally and stop event propagation if
20:38:01 <ChrisL> the 'g' element has pointer-events="visible" and the event is outside
20:38:01 <ChrisL> of the clip the event will not propagate to the children of the 'g'
20:38:04 <ChrisL> even though some of the children may have their pointer-events set to
20:38:06 <ChrisL> 'all' (and hence should not be effected by clipping).
20:38:20 <anthony> DS: He says that a more robust model is to add event modifier attributes
20:38:28 <anthony> CL: He says don't do that now do it later
20:39:03 <anthony> DS: We already said the we would do things for other operations such as filters
20:39:10 <ChrisL> so the question is whether the current erratum precludes doing it later
20:39:26 <anthony> ... I suggest we respond to him
20:40:13 <anthony> ... and say the suggestion is good but clipping and masking are two different things and the interpretation we come to
20:40:56 <anthony> CL: He makes a good point at the end we need to consider
20:41:08 <anthony> ... the point he makes is the current errata is all on the same element
20:41:13 <anthony> ... and it could be on a group
20:41:27 <anthony> ... so we need to make sure that it is covered
20:41:42 <anthony> DS: Maybe the wording implies that, not sure if that changes our assumptions in anyway
20:42:12 <anthony> CL: You can have multiple clippaths and you can do additive things with clippaths
20:42:38 <ChrisL> if the clip path itself is filtering the events, then uniuoning the clippaths becomes problematic
20:43:00 <anthony> ED: You can "or" clippaths, you can't cut a hole in a clippath but you can union them together
20:43:20 <anthony> CL: Suppose you had 3 clippaths all circles with different radius
20:43:44 <anthony> ... the clip path is the biggest radius
20:44:11 <anthony> ... but if one of them doesn't accept pointer events then you have a section of the cutout that doesn't accept pointer events
20:44:47 <anthony> DS: It's not pointer events on the clippath it's pointer events on the target element
20:45:33 <anthony> ... doesn't necessarily mean we discounted his argument, does his argument still hold?
20:46:02 <anthony> CM: Is that the only point he made about the details of our suggestion?
20:46:24 <anthony> DS: I think that was his main point, I'm not sure if that is his only point
20:47:12 <anthony> ... I guess he's saying that the two features are combined in the one specification
20:48:26 <anthony> ... I don't really follow his argument though
20:50:00 <anthony> ... we should address his issue about the errata and that's the part we need to make sure we are correct on
20:50:28 <anthony> ... I Cameron came up with the response that it shouldn't have any undue affects on it
20:50:49 <anthony> ... it's the one where Chris comes up with the bullseye example
20:51:55 <anthony> ... we don't have to have an official response we can have a dialog with Thomas
20:52:17 <anthony> ... so Chris I welcome you chiming in on the thread
20:53:07 <shepazu> http://dev.w3.org/SVG/profiles/1.1F2/errata/errata.xml#capturing-pointer-events-zero-opacity
20:55:30 <anthony> ED: The wording that there is ok
20:56:16 <anthony> DS: Cameron do you have any suggestions for wording?
20:56:37 <anthony> CM: Not off the top of my head I'd have to have a think about it
21:49:01 <heycam`> heycam` has joined #svg
21:50:07 <Zakim> GA_SVGWG()2:30PM has ended
21:50:08 <Zakim> Attendees were 
22:19:31 <Zakim> Zakim has left #svg
22:35:26 <anthony> RRSAgent, make minutes
22:35:26 <RRSAgent> I have made the request to generate http://www.w3.org/2008/12/08-svg-minutes.html anthony