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