IRC log of svg on 2008-12-08

Timestamps are in UTC.

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