W3C home > Mailing lists > Public > public-svg-wg@w3.org > January to March 2009

Minutes January 26, 2009 telcon

From: Anthony Grasso <anthony.grasso@cisra.canon.com.au>
Date: Tue, 27 Jan 2009 10:26:23 +1100
Message-ID: <497E469F.1050207@cisra.canon.com.au>
To: public-svg-wg@w3.org




       [1] http://www.w3.org/

                                - DRAFT -

                    SVG Working Group Teleconference

26 Jan 2009


       [2] http://lists.w3.org/Archives/Public/public-svg-wg/2009JanMar/0059.html

    See also: [3]IRC log

       [3] http://www.w3.org/2009/01/26-svg-irc


           Shepazu, [IPcaller], heycam, ChrisL, jwatt, ed, anthony




      * [4]Topics
          1. [5]Errata
          2. [6]XLink attribute definitions have mismatching quotes
          3. [7]Focus behavior when focussed element hidden
          4. [8]filter primitive subregions
          5. [9]Focus behavior when focussed element hidden Again
          6. [10]Filter Primitive Subregions Again
          7. [11]Selection of Thursday telcon topic
          8. [12], selectors-api
          9. [13]selectors-api mail
         10. [14]ISSUE-2037
         11. [15]Core
         12. [16]BoundingBox Thing
      * [17]Summary of Action Items

    <trackbot> Date: 26 January 2009

    <shepazu> [18]http://www.w3.org/Graphics/SVG/WG/track/agenda

      [18] http://www.w3.org/Graphics/SVG/WG/track/agenda

    <ChrisL> trackbot, start engines

    <trackbot> Sorry, ChrisL, I don't understand 'trackbot, start
    engines'. Please refer to [19]http://www.w3.org/2005/06/tracker/irc
    for help

      [19] http://www.w3.org/2005/06/tracker/irc

    <jwatt> Zakim: ??P1 is jwatt

    <jwatt> Zakim: ??P1 is me

    <jwatt> of course, we couldn't possibly accept a colon instead of a
    comma, could we?

    <scribe> Scribe: anthony



    <trackbot> ISSUE-2001 -- Prose describing <font> content model does
    not match DTD -- OPEN

    <trackbot> [20]http://www.w3.org/Graphics/SVG/WG/track/issues/2001

      [20] http://www.w3.org/Graphics/SVG/WG/track/issues/2001



    ED: Finished one of my actions
    ... have two more for Errata of 1.1
    ... one of which was for list separators
    ... not sure if we've addressed it
    ... but I have an action for it

    <heycam> ACTION-2163?

    <trackbot> ACTION-2163 -- Erik Dahlström to add 1.1 errata for
    stroke-dasharray to align 1.1 with SVGT1.2 (to allow
    whitespace-separated values) -- due 2008-08-30 -- OPEN

    <trackbot> [22]http://www.w3.org/Graphics/SVG/WG/track/actions/2163

      [22] http://www.w3.org/Graphics/SVG/WG/track/actions/2163

    ED: Stroke Dash-array is the action
    ... I remember discussing it
    ... doesn't seem to be very recent

    <heycam> ACTION-2165?

    <trackbot> ACTION-2165 -- Erik Dahlström to add a 1.1 errata item
    for having xml:space on tspan elements to align with 1.2T (split out
    from ACTION-2048) -- due 2008-08-30 -- OPEN

    <trackbot> [23]http://www.w3.org/Graphics/SVG/WG/track/actions/2165

      [23] http://www.w3.org/Graphics/SVG/WG/track/actions/2165

    CMC: For the first one, since I'm meant to be looking at list
    separators in general
    ... you can hold off on that one
    ... and the second one I assume we all agreed with it
    ... just wondering what things in SVG Tiny 1.2 that relate to this

    ED: For the ISSUE-2001

    CMC: That looks good for me

    ED: Not a major change
    ... just aligning the spec with the DTD

    CMC: Does the DTD itself does it have fontFace?

    ED: Yes
    ... not sure if you want to mention it somewhere in the text

    CMC: A lot of that chapter you'd have to recreate

    CL: You shouldn't have to reverse engineer from examples to figure
    out what's needed

    CMC: I wonder if Tiny has enough stuff to figure out what is needed
    for that chapter

    <scribe> ACTION: Chris to Check the Tiny 1.2 Chapter to see if there
    is any text in there that can be used for ISSUE-2001 [recorded in

    <trackbot> Created ACTION-2415 - Check the Tiny 1.2 Chapter to see
    if there is any text in there that can be used for ISSUE-2001 [on
    Chris Lilley - due 2009-02-02].

    CMC: Do we want to move this to proposed?

    ED: I put it as category 2
    ... since I didn't think of it as a major change

    CL: It's a clarification and not a new feature
    ... it's not a conformance change as such

    ED: We pretty much already rely on particular behaviour
    ... I've moved it to proposed

XLink attribute definitions have mismatching quotes


      [25] http://dev.w3.org/SVG/profiles/1.2T/errata/errata.xml#xlink-attr-quotes

    CMC: Just wanted to get agreement to move to proposed
    ... I typed "news" instead of "new"

    ED: It looks funny
    ... because of the quote marks in the changed text

    AG: Looks like "news" | 'replace" | 'embed" | 'other" | 'none"

    CMC: Just making a fix for that
    ... check the update now

    AG: Looks good to me

    CMC: I guess we can move that to proposed

    AG: Yes

    ED: Looks fine to me

    <ChrisL> Yes, straightforward

Focus behavior when focussed element hidden



    CMC: Mail is from Ian
    ... we asked HTML if they had any definition for this
    ... seems like they are looking at it at the moment

    DS: We did kind of define it
    ... we just picked what was most intuitive

    CMC: I guess that's the information that he's after
    ... Doug did you want to reply to that

    DS: That's fine
    ... I should confirm this in our spec
    ... as I recall that's what we had decided as the default

    CMC: What was decided?

    DS: Hang let me see
    ... if an element has focus and it is removed from the DOM or set to
    display none
    ... it should lose focus
    ... and document should get focus
    ... it should also throw a focus out event
    ... if the element has display none taken off it doesn't gain focus
    ... I'll confirm the spec and replay to Ian

    <scribe> ACTION: Doug to Check the specification to verify the focus
    behaviour of an element that loses focus then reply to Ian's email
    about it [recorded in

    <trackbot> Created ACTION-2416 - Check the specification to verify
    the focus behaviour of an element that loses focus then reply to
    Ian's email about it [on Doug Schepers - due 2009-02-02].

    DS: Under the most intuitive place under element focus I don't see

filter primitive subregions

      [28] http://www.w3.org/TR/SVG/filters.html#FilterPrimitiveSubRegion

    JW: I'll paste something in first

    <jwatt> <svg xmlns="[29]http://www.w3.org/2000/svg"

      [29] http://www.w3.org/2000/svg
      [30] http://www.w3.org/1999/xlink

    <jwatt> <filter id="filter">

    <jwatt> <feImage x="50" xlink:href="green.png"/> <!-- native size
    {100,100} -->

    <jwatt> <feOffset x="-50"/>

    <jwatt> </filter>

    <jwatt> <rect width="100" height="100" fill="red"/>

    I'm wondering what that should do

    <jwatt> <rect width="100" height="100" fill="red"

    <jwatt> </svg>

    JW: It all comes down to Filter Primitive Subregion

    ED: Currently opera isn't handling anything that is outside of the
    Root Filter region

    JW: The Mozilla code seems to be mixed up about it
    ... this should give a green rect that covers the red rect
    ... correct?

    ED: The default subregion is the root filter region

    JW: Imagine that on the filter element I set x,y=0 and

    <ChrisL> "All intermediate offscreens are defined to not exceed the
    intersection of the filter primitive subregion with the filter

    CL: [Reads spec out]
    ... so if you have something completely outside of it then the
    intersection is 0

    <ChrisL> so the intersection is zero

    JW: Wasn't really sure if that was just intended as the end result
    or if that was instructions for intermediate steps
    ... at the beginning when it says what the filter subregion says it
    could say that
    ... it could say explicitly when it's talking about x,y width,height
    it says that the filter subregion about x,y,width,height
    ... Chris is right it does say something about exceeding the filter
    ... but it didn't say that at the start
    ... it might be helpful to add something like that at the start in
    one of the first paragraphs
    ... but I'm not sure if it's useful to have filters behave that way
    ... when you have feOffset
    ... it's useful to have a filter subregion to have something outside
    of the main region

    ED: You can still do that using filterUnits="UserSpaceOnUse"

    JW: I'm not sure
    ... you could actually make filter region bigger by doing that
    ... but you could still potentially have feImage that has part of it
    outside the filter region

    ED: Can you give an example
    ... so you have an image feImage
    ... that part of is outside the entire canvas?

    JW: let's just say my element is 100 x 100 and I have an feImage
    ... that is outside side the 100 x 100 area
    ... I want to use feOffset to translate it to the correct area

    ED: Could you use x,y to move it there?

    JW: I guess you probably could

    ED: You could specify x,y on it
    ... I think you might be able to put transform on it, I'm not 100%
    sure on that though


      [31] http://dev.w3.org/SVG/modules/filters/publish/SVGFilter.html

    JW: I was hoping this would be more simple

    CL: I doped a link in
    ... to the chapter

    ED: I have a huge backlog of actions on Filters
    ... I'm hoping to have a bunch of them figure for the SVG f2f
    ... it is possible that I have one on filters subregion


      [32] http://dev.w3.org/SVG/modules/filters/publish/SVGFilter.html

    ED: but I do remember defining something in the Filters 1.2

    CMC: So should we take this one to email then?

    CL: I suspect that might be best

    ED: I wouldn't mind seeing use cases that couldn't be handled
    ... for filter subregions bigger than the main region

Focus behavior when focussed element hidden Again

    DS: Looks like we deferred it to SVG 2.0
    ... I do recall making a test for it
    ... well testing for it
    ... and there was no conforming behaviour
    ... we don't have any normative language in the spec about it
    ... there was no one set behaviour in HTML
    ... I think it comes down to us just deciding something

    CMC: I don't particularly mind what we choose to suggest to the HTML
    ... and wait to hear back from them
    ... I'd be fine with what you were suggesting before

    DS: Ok I'll correspond with them
    ... does anyone else have a strong feeling on the subject?

    ED: I'm just wondering there are things that could be more useful
    ... when the element loses focus
    ... the focus could go up the chain

    CL: Next focusable parent
    ... which could be the document

    <ChrisL> closest focussable parent

    DS: I'm thinking of forms
    ... if there is a focus ring defined in SVG
    ... it might make sense to go to the previous focus item
    ... failing that go to the parent

    CL: Going to the previous one makes more sense
    ... so the parent is fallback
    ... I agree with you

    DS: To me that would be the more requested behaviour because it
    doesn't take you out of the context

    CL: If the author is concerned they could explicitly move the focus
    to an element before removing
    ... we are trying to make a reasonable fallback case
    ... for when authors don't do anything

    DS: We should explicitly say this is going to be the behaviour so
    consider changing the focus manually
    ... I'll go to them with the above proposal and with any tests I can
    ... and see if they want to align
    ... I think the good thing is we haven't specified it
    ... so we can have unified behaviour

Filter Primitive Subregions Again

    JW: So basically my question is what seems to be underspecified
    ... say I have filter region 200x200
    ... this is only a problem sorry
    ... scrap this
    ... it's only a problem if you allow filter primitive subregions to
    extend beyond the filter region

Selection of Thursday telcon topic

    CMC: Not sure we worked a procedure to figuring out how to pick
    topics for Thursday's telcon

    ED: agenda requests are always welcome

    DS: We normally select things Adhoc
    ... so I don't see anything wrong with picking topics now
    ... Chris how's your progress on your module
    ... it would be nice to have a prepared list of topics

    ED: Maybe on the wiki page

    DS: Cameron's got the Use Case and requirements for the layout

    CMC: I'll probably want to flesh that out a bit more before
    discussion anything on a telcon
    ... but if people want to suggest requirements that would be great
    as well

    DS: What about filters? Could we talk about filters?

    ED: I believe we covered part of that on Thursday
    ... I'm hoping to go over some of the actions I have and I'm hoping
    to push out a publication around the F2F

    DS: And Anthony you said something about the compositing module

    AG: Yes, Erik and discussed the enable-background property
    ... so I'm pretty much going to use what's in Filters

    DS: And we can get Print on the agenda at some point

    CL: That would be good

    ED: Someone should take an action to update the wiki table using the
    minutes from the previous telcon

    CL: I can update it
    ... do you have an existing action you can allocate to me?

    DS: I'd have to look through

    CMC: I noticed there were a number of issues posted on Core for new
    ... I'm not sure what context they belong in
    ... they don't really correspond to any of the modules
    ... it sounds like a good Thursday thing

, selectors-api

      [33] http://lists.w3.org/Archives/Public/www-svg/2009Jan/0035.html

selectors-api mail

    ED: Selectors API

    <ed> [34]http://dev.w3.org/2006/webapi/selectors-api/#examples0

      [34] http://dev.w3.org/2006/webapi/selectors-api/#examples0

    ED: Noticed we got an email
    ... scroll down at the bottom of the section and there's an example
    that shows how to selects API and scripting to select elements based
    on namespaces
    ... you have to filter results from selects API since it doesn't
    have name spaces

    <ChrisL> instead of filtering the selector results, it would be so
    much simpler if it just supported namespaces, like selectors itself

    ED: This particular is sort of a compromise he doesn't really
    mention DOM3 Xpath but he does give the example

    CMC: So the suggestion before was in DOM3 Xpath
    ... if you need namespaces

    ED: right
    ... are we fine with this?
    ... it looks fine to me
    ... doesn't look like it will have Xpath in it anyway

    CL: Yes, that's fine

    ED: So unless I find any other unaddressed issues
    ... can I respond to the list saying we are fine with the changes?

    DS: Yes, that should be alright


    <heycam> ISSUE-2037?

    <trackbot> ISSUE-2037 -- Define how focusHighlight is applied when
    put on a container element -- RAISED

    <trackbot> [35]http://www.w3.org/Graphics/SVG/WG/track/issues/2037

      [35] http://www.w3.org/Graphics/SVG/WG/track/issues/2037

    CMC: Erik I think you raised this issue
    ... it looks like something we should of looked at before
    ... is this the issue Chris P raised?

    ED: I could be related to this I guess
    ... although I'm not sure it's really defined in 1.2 Tiny what
    happens for this particular case
    ... you have <g> which is focusable, then you have a child that has
    focus auto
    ... the question is what happens

    CMC: I suppose it would be preferable if it was defined
    ... what does Opera do in this case?

    ED: I think but not 100% the element does have the focus
    ... well, the current value of focusHighlight would be used

    CMC: You mean it would be overridden

    ED: It should probably be tested though

    <scribe> ACTION: Erik to Test the focus highlight problem is SVG
    Tiny 1.2 relating to ISSUE-2037 [recorded in

    <trackbot> Created ACTION-2417 - Test the focus highlight problem is
    SVG Tiny 1.2 relating to ISSUE-2037 [on Erik Dahlström - due


      [37] http://lists.w3.org/Archives/Public/public-svg-wg/2009JanMar/0061.html


    DS: I could be the editor of the integration spec
    ... for the modules
    ... I guess what I'm saying is I'm offering to work on the
    integrating spec
    ... whatever that might be
    ... SVG 1.2 Full - but I'd rather not use that
    ... but I'll pull together some spec that addresses things in a
    larger way that references some specs
    ... and we'll call it whatever we want to call it

BoundingBox Thing


      [38] http://lists.w3.org/Archives/Public/public-svg-wg/2009JanMar/0061.html

    CMC: Niklas sent this email

    DS: I don't know if we put this in the spec
    ... but we did decide what the behaviour was
    ... it's essentially if you have just a text element
    ... so it's just a line

    CMC: I think I remember you discussing this
    ... if width OR height is auto
    ... so he's asking for that auto dimension
    ... should it be infinite or just the space it consumed

    DS: Oh I see
    ... It should be space
    ... [Reads spec out]

    <shepazu> [[

    <shepazu> If both 'width' and 'height' have the value 'auto', the
    text will be rendered in a single line along the direction of the
    text progression until all the text is rendered, or until a
    line-breaking element such as 'tbreak' is encountered, in which case
    the remaining text is rendered on a new line.

    <shepazu> ]]

    DS: We don't explicitly say what the BBox is

    <ed> [39]http://www.w3.org/TR/SVGMobile12/coords.html#BoundingBox

      [39] http://www.w3.org/TR/SVGMobile12/coords.html#BoundingBox

    CL: Right we don't say explicitly

    ED: We do say in general terms
    ... I guess you could auto does mean enclosed

    DS: It wouldn't hurt to define it

    CMC: If the width=100 and longest line is 95 then the BBox is 100x95

    DS: Correct
    ... No wait
    ... that's an interesting point
    ... the width of the textArea is not the size of the content

    <ed> [[ For text content elements, for the purposes of the bounding
    box calculation, each glyph must be treated as a separate graphics
    element. The calculations must assume that all glyphs occupy the
    full glyph cell. For example, for horizontal text, the calculations
    must assume that each glyph extends vertically to the full ascent
    and descent values for the font. An exception to this is the
    'textArea', which uses that element's geometry for the bounding box

    DS: we do mention BBox textArea

    <shepazu> [[ An exception to this is the 'textArea', which uses that
    element's geometry for the bounding box calculation. ]]

    DS: That's not actually quite true
    ... unless width and height are auto

    CMC: If any of the two dimensions set to auto
    ... it's going to be the longest line of text or the height of the
    ... is that correct?

    ED: I think that's what we want

    <shepazu> , unless width and height are auto, in which case it is
    the geometry of the rendered text, as with the 'text' element

    CMC: For the case of height of being auto do we want to care about
    lines of text or just the actual shapes that go in there?

    DS: that's an interesting point the line height

    CMC: I can't remember what the line height thing was

    DS: I know it's aligned with XSL-FO

    [as corrected by Chris]

    DS: That line height is an interesting point we don't actually say
    what should happen there
    ... if width and height are auto
    ... we don't explicitly say what happens

    <scribe> ACTION: Doug to Investigate what the BBox size is when
    textArea width and height are auto and respond to Niklas's email
    [recorded in

    <trackbot> Created ACTION-2418 - Investigate what the BBox size is
    when textArea width and height are auto and respond to Niklas's
    email [on Doug Schepers - due 2009-02-02].

    <ed> nope

Summary of Action Items

    [NEW] ACTION: Chris to Check the Tiny 1.2 Chapter to see if there is
    any text in there that can be used for ISSUE-2001 [recorded in
    [NEW] ACTION: Doug to Check the specification to verify the focus
    behaviour of an element that loses focus then reply to Ian's email
    about it [recorded in
    [NEW] ACTION: Doug to Investigate what the BBox size is when
    textArea width and height are auto and respond to Niklas's email
    [recorded in
    [NEW] ACTION: Erik to Test the focus highlight problem is SVG Tiny
    1.2 relating to ISSUE-2037 [recorded in

    [End of minutes]

     Minutes formatted by David Booth's [45]scribe.perl version 1.133
     ([46]CVS log)
     $Date: 2009/01/26 22:14:48 $

      [45] http://dev.w3.org/cvsweb/~checkout~/2002/scribe/scribedoc.htm
      [46] 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 [47]http://dev.w3.org/cvsweb/~checkout~/2002

      [47] http://dev.w3.org/cvsweb/~checkout~/2002/scribe/

Guessing input format: RRSAgent_Text_Format (score 1.00)

Succeeded: s/root/document/
Succeeded: s/it goes/it doesn't/
Succeeded: s/Primative/Primitive/
Succeeded: s/Suggestions/agenda requests are/
Succeeded: s/it/in/
Succeeded: s/fine any other undressed/find any other unaddressed/
Succeeded: s/don't say/don't say explicitly/
Succeeded: s/ED/DS/
Found Scribe: anthony
Inferring ScribeNick: anthony
Default Present: Shepazu, [IPcaller], heycam, ChrisL, jwatt, ed, anthon
Present: Shepazu [IPcaller] heycam ChrisL jwatt ed anthony
Agenda: [48]http://lists.w3.org/Archives/Public/public-svg-wg/2009JanMa
Found Date: 26 Jan 2009
Guessing minutes URL: [49]http://www.w3.org/2009/01/26-svg-minutes.html
People with action items: chris doug erik

      [48] http://lists.w3.org/Archives/Public/public-svg-wg/2009JanMar/0059.html
      [49] http://www.w3.org/2009/01/26-svg-minutes.html

    End of [50]scribe.perl diagnostic output]

      [50] http://dev.w3.org/cvsweb/~checkout~/2002/scribe/scribedoc.htm
Received on Monday, 26 January 2009 23:27:08 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 17:29:41 UTC