W3C home > Mailing lists > Public > public-svg-wg@w3.org > October to December 2008

Minutes, SVG telcon Monday 8 December 2008

From: Anthony Grasso <anthony.grasso@cisra.canon.com.au>
Date: Tue, 09 Dec 2008 09:45:42 +1100
Message-ID: <493DA396.6090209@cisra.canon.com.au>
To: W3C SVG Public Working Group <public-svg-wg@w3.org>




       [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


           ED, DS, CM, AG, CL




      * [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


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


       [8] http://lists.w3.org/Archives/Public/public-webapps/2008OctDec/0453.html.

    ED: I tried to explain the reasoning for not mentioning authoring

    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
    ... the only thing missing was the "of" in that sentence
    ... The next comment is about when the selection is done in the
    ... 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

    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
    ... and he disagrees with that and mentions his previous comment on

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


      [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

    <ChrisL> if you don't have namespaces, sure its going to be an issue

    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

    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

    <trackbot> Created ACTION-2376 - Collect all the discussed responses
    for the selectors API and send them in [on Erik Dahlström - due

Clip Path and masking


      [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?


      [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

    <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

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

    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



    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

    [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

      [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
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

This archive was generated by hypermail 2.3.1 : Tuesday, 6 January 2015 21:20:10 UTC