See also: IRC log
<trackbot> Date: 08 December 2008
<heycam> but Zakim i should be on the call...
<scribe> Scribe: anthony
<ed> 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> 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> http://www.w3.org/TR/REC-xml-names/#ns-decl
<ChrisL> you can't say xmlns:xml="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> 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> 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 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].
<shepazu> 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> 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> 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
This is scribe.perl Revision: 1.133 of Date: 2008/01/18 18:48:51 Check for newer version at 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 references/ 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: http://www.w3.org/2008/12/08-svg-minutes.html People with action items: erik[End of scribe.perl diagnostic output]