SVG Working Group Teleconference -- 08 Dec 2008

<trackbot> Date: 08 December 2008

<heycam> but Zakim i should be on the call...

<scribe> Scribe: anthony

Selectors API Review

<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].

Clip Path and masking

<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

- DRAFT -

SVG Working Group Teleconference

08 Dec 2008

Attendees

Contents

Selectors API Review

Clip Path and masking

Summary of Action Items

Scribe.perl diagnostic output