Minutes Feb 12, 2009, telcon




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

                                - DRAFT -

                    SVG Working Group Teleconference

12 Feb 2009


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

    See also: [3]IRC log

       [3] http://www.w3.org/2009/02/12-svg-irc


           ed___, [IPcaller], heycam, shepazu, anthony, ChrisL




      * [4]Topics
          1. [5]Vector Effects
          2. [6]Sydney F2F action priorities
          3. [7]Issue 2002
          4. [8]ISSUE-2021
          5. [9]ISSUE-2182
          6. [10]CSS integration issues
          7. [11]ISSUE-2049
      * [12]Summary of Action Items

    <trackbot> Date: 12 February 2009

    <shepazu> sigh

    <shepazu> stupid bots

    <shepazu> \me ' flight leaves at 10:30 pm

    <shepazu> Thu 12 Feb, 2009

    <shepazu> Qantas

    <shepazu> Los Angeles to Sydney

    <shepazu> flight: QF12

    <shepazu> depart: 22:30

    <shepazu> arrive: 08:10, 14 Feb 09 (Sat)

    <scribe> Scribe: anthony

Vector Effects

    CL: Got it out just about 30 mins
    ... will give time to for people to look at it

Sydney F2F action priorities

    ED: I was wondering if there are some particular actions that should
    be looked at before the F2F
    ... I have about 30-40 actions
    ... I might do some while travelling
    ... currently I'm thinking I'll do a bit of HTML 5 reading and a few
    of the filter spec actions
    ... or if anyone else has any actions they want to priorities

    CL: They sound like good priorities

    ED: I just made a few minor updates to the F2F page

    <ed___> [13]http://www.w3.org/Graphics/SVG/WG/wiki/SydneyF2F2009

      [13] http://www.w3.org/Graphics/SVG/WG/wiki/SydneyF2F2009

    ED: Mostly stuff to get minuted resolutions
    ... as a reminder for us
    ... HTML5 + SVG is something we have to complete soon
    ... as well as Full 1.1 errata
    ... and modules

Issue 2002



    <trackbot> ISSUE-2002 -- Controlling the implicit viewBox of raster
    images used in the <image> element -- RAISED

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

      [14] http://www.w3.org/Graphics/SVG/WG/track/issues/2002

    ED: I committed a proposal for viewBax attribute on raster images
    ... CMC sent an email saying there is something similar in CSS3
    ... 'crop' property
    ... I put in a couple of test cases
    ... and I think batik and all of the other browsers except for I.E.
    produce similar results
    ... which is ignore it
    ... I'm wondering if the 'crop' might be good for us?

    CL: Question is why do they ignore viewBox

    ED: I think the spec is quite unclear, it doesn't say you can't use
    it for viewBox
    ... I guess this could qualify as an errata item, but it's more like
    a future feature
    ... I didn't find a viewer that did something else with it

    CL: And this is just for raster images?

    ED: Yes
    ... for SVG images the viewBox will effect the image
    ... I was going to put a test for it
    ... wont be too difficult to make
    ... It is quite simple to put on top of what we have anyway

    CL: Where does it really make a difference?
    ... miss match in aspect ratio?
    ... putting xMid, yMid?
    ... what are we missing

    ED: We are missing the capability to select a certain part of the

    CL: If you are talking about errata you could put that in with an
    ... if you have an image with a vewBox then the image should be blah
    ... this sort of clarification could be an errata

    <shepazu> since we are looking at <image>, I would also like to
    consider allowing @stroke properties on <image>

    <shepazu> it's a new feature, so we shouldn't add it to SVG 1.1

    ED: Should we make an errata or should we address it in Core 2.0?

    <shepazu> we should also look at this in terms of the clipPath

    CL: It's not a new feature is it?

    ED: It's definitely vague in the text, but I didn't find anything
    that explicitly overrides the viewBox for raster images

    DS: I think it's a clarification it's new behaviour
    ... because it changes conformance
    ... you are saying that you can use the viewBox on the image

    ED: It does give you an example, but it doesn't explicitly say can't
    override it

    <ed___> ED: also it doesn't say that if you specify a viewBox on a
    raster it should use pixel units

    <shepazu> shepazu: if 1.1 says you can't override it, we shouldn't
    change that in 1.1, but we could reexamine if that's useful in 2.0

    <ed___> ED: as in actual raster image pixels

    ED: SVG 1.1 says the image element has a viewBox and you can
    reference something

    <shepazu> url?

    ED: it doesn't tell you exactly how to treat viewBoxes on raster

    <ed___> [15]http://www.w3.org/TR/SVG11/struct.html#ImageElement

      [15] http://www.w3.org/TR/SVG11/struct.html#ImageElement

    <ChrisL> An 'image' element establishes a new viewport for the
    referenced file as described in Establishing a new viewport. The
    bounds for the new viewport are defined by attributes x, y, width
    and height. The placement and scaling of the referenced image are
    controlled by the preserveAspectRatio attribute on the 'image'

    ED: The next paragraph after that one explains how you handle it
    when you reference an SVG image

    CL: The next bit after that says you have to make the image as large
    as possible while preserving the aspect ratio
    ... If you specify explicitly it's the same as the SVG case, it
    covers all of it but has bits left over or it covers the edges
    ... if I have a viewBox 0 0 60 30

    <ChrisL> suppose i have an explicit viewbox 0 0 60 30 ie a 2x1

    <ChrisL> and my raster image is 400x400 pixels

    <ChrisL> its clear from the text how to fit that raster into that

    <ChrisL> depending in the value of other attributes

    <ChrisL> the only unclear part is where the viewBox is *not*
    explocitly stated

    <ChrisL> in which case, i propose an erratum that says (for that
    image) its 0 0 400 400

    <ChrisL> is that clearer?

    ED: If you what you're saying is correct, then we might need to put
    something else in for
    ... what I was proposing

    <ChrisL> the reference viewbox cannot be overidden

    ED: So I will withdraw the proposal, in which case the 'crop'
    property seems like a pretty good idea
    ... the problems it intends to solve are unaddress, i.e the issue is
    still open

    AG: The spec doesn't have any crop feature at all
    ... that will be a new feature

    ED: So is this something we will have clarify in 1.1 then?
    ... So the question is should I open a new issue?
    ... or keep it there

    CL: I think keep it there
    ... so we know how we arrived at that



    <trackbot> ISSUE-2021 -- Bounding box of <image> subject to
    aspect-ratio preservation undefined -- RAISED

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

      [16] http://www.w3.org/Graphics/SVG/WG/track/issues/2021

    ED: That's already on Core 2.0
    ... the question was raised by CMC

    CMC: Long time since I looked at this one
    ... to be honest I haven't looked at the call
    ... it's look like I've tested a couple of UAs to see what they do
    ... the comment about determining the aspect ratio using script - I
    do that at the moment

    ED: There could be other ways of solving that problem
    ... exposing the width and height of the image

    CMC: Exposing the width and height of the image would solve the

    ED: I agree it would be very nice to have
    ... when I do this currently I do it in HTML

    CL: The viewBox will determine the width and height of the image
    ... can't you query that?

    CMC: Are you saying to look at the viewBox property and get the
    width and height from that?

    CL: Yes


      [17] http://www.w3.org/TR/SVG11/types.html#InterfaceSVGFitToViewBox


      [18] http://www.w3.org/TR/SVG11/struct.html#InterfaceSVGImageElement

    ED: I don't see that interface

    <ed___> [19]http://www.w3.org/TR/SVG11/idl.html

      [19] http://www.w3.org/TR/SVG11/idl.html

    AG: You can query the viewBox but you may not get the original image
    width and height
    ... because if the viewBox doesn't match the image aspect ratio then
    ... one of the dimensions will be wrong

    CMC: Preserve aspect ratio is on SVG Image element and on SVG Fit to
    View Box interface
    ... looks like it was left out somehow
    ... I can't think why you wouldn't want to expose that

    ED: So if the viewBox was exposed would it be enough to solve the
    problem completely?

    CMC: It wouldn't solve the case of getting the original width and
    height of the image

    ED: So I still think when you define the viewPort and use viewPort
    fill you will perhaps use the space that is not covered by an image

    CMC: Not sure, but it's a good test for Tiny
    ... If you have a circle and the fill is none the stroke is none
    then the bounding box is still the circle and not nothing

    <ed___> safari also says 0,0,400,400 btw

    CMC: maybe if theviewPort fill is not none then maybe the whole area
    is the BBox, but it may make BBox less useful.

    ED: I think there are other things about image that make it less
    ... for example wanting to display images at their native resolution
    regardless of scaling
    ... it is in a way related
    ... if you are able to get the dimensions of such images
    ... I think exposing the viewBox property would be useful
    ... even though it would be less useful than exposing the intrinsic
    width and height
    ... CMC do you want to propose something?

    <scribe> ACTION: Cameron to Propose a number of different solutions
    to solving the problem of extracting the width and height of an
    image in ISSUE-2021 [recorded in

    <trackbot> Created ACTION-2455 - Propose a number of different
    solutions to solving the problem of extracting the width and height
    of an image in ISSUE-2021 [on Cameron McCormack - due 2009-02-19].



    <trackbot> ISSUE-2182 -- Consider adding new interface for easier
    use of positional properties -- RAISED

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

      [21] http://www.w3.org/Graphics/SVG/WG/track/issues/2182

    ED: It's about adding new positional properties
    ... so this suggests adding a new interface on event called
    ... it's not exactly clear what's this suggesting

    <shepazu> ISSUE-2182?

    <trackbot> ISSUE-2182 -- Consider adding new interface for easier
    use of positional properties -- RAISED

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

      [22] http://www.w3.org/Graphics/SVG/WG/track/issues/2182

    DS: We talked about this before, this is the idea of doing drag and
    drop for example
    ... you might want to get the actual position
    ... even with get client and BBox you don't get all the information
    you want
    ... what you want is the relative position of the mouse
    ... you really want to know where it appears on the screen
    ... you could also get things like transform which is a combination
    of CTM and other information
    ... I guess the key is the first part
    ... but it would be useful to have it all in one place

    ED: So something to automatically convert from client space to user

    <shepazu> yeah, more or less

    CMC: Was there anything other than X,Y that you want to expose on

    <shepazu> I can't think of anything other than x/y right now?

    CMC: or do you want to take the X,Y and do the transformation
    ... Ok

    <shepazu> I will write a proposal into the 2.0 kitchensink doc

    ED: Do you want the option to go the other way in the same

    CMC: I think if you can go one way you can do the the calculations

    ED: So DS if you can write something up in spec that would be good

    <shepazu> ACTION: shepazu to write a proposal for inuitive x/y
    method [recorded in

    <trackbot> Created ACTION-2456 - Write a proposal for inuitive x/y
    method [on Doug Schepers - due 2009-02-19].

    <shepazu> er... intuitive


      [24] http://lists.w3.org/Archives/Member/w3c-tools/2009JanMar/0002.html

CSS integration issues

    ED: I collected a bunch of issues
    ... there are two relating to CSS whitespace ISSUE-2039 and
    ... which are quite similar

    CMC: They are quite similar

    ED: I was thinking of closing the older one and just having one of
    ... we could close the old one and link back to the new one if we
    need to

    CMC: On the face of it seems like a good idea
    ... but I haven't looked at it closely either

    ED: That's the overall issue though, is looking at other CSS
    properties that we could integrate into SVG

    CMC: I think it would be good to go through all the properties we
    don't use and see if we can use some of them
    ... bit of a jump

    ED: It probably makes sense to break it down a bit
    ... A good starting point is to look at what is widely supported and
    currently not in SVG
    ... My starting point would be to go through the Opera code to see
    what we have
    ... the look at FireFox and Surfari

    <ed___> s/surfari/surfin' safari/

    CL: The problem with the whitespace property is it mixes in a few
    different things
    ... which is not helpful
    ... which is why XSL split it into a few sub properties

    ED: So which of the properties did they split it into?

    <ChrisL> [25]http://www.w3.org/TR/xsl/#white-space-treatment

      [25] http://www.w3.org/TR/xsl/#white-space-treatment

    <ChrisL> [26]http://www.w3.org/TR/xsl/#white-space-collapse

      [26] http://www.w3.org/TR/xsl/#white-space-collapse

    <ChrisL> [27]http://www.w3.org/TR/xsl/#wrap-option

      [27] http://www.w3.org/TR/xsl/#wrap-option

    CL: At least 3
    ... white-space-treatment, white-space-collapse, wrap-option
    ... line-feed-treatment

    <ChrisL> 7.31.23 "white-space"

    <ed___> [28]http://www.w3.org/TR/xsl/#white-space

      [28] http://www.w3.org/TR/xsl/#white-space

    CL: It takes the values from CSS2 and says how it maps to the XSL
    ... we don't really have wrap in SVG
    ... it's very HTML centric. All the things are good but you may want
    to do them in combination

    ED: I guess we don't have much of this problem yet
    ... line wrapping is very simplistic so far
    ... I guess it's a question of what we put in to the next major spec
    ... I'm wondering if you can use xml:space
    ... I guess you could. It would be kind of strange
    ... this seems like an area for further study

    CL: I don't think it's directly applicable
    ... I think if we were to split it up like XSL we would come up with
    different combinations
    ... that suit SVG

    ED: Is it worth asking the CSS WG to adopt new properties/behaviour?

    CL: I guess for specs after 2.1

    ED: I looked at whitespace in SVG it is rather messy

    <ed___> <text>foo<tspan>bar</tspan></text>

    <ed___> is there a space or not between foo and bar?

    ED: It also has an effect on underlining and overlining
    ... some examples were sent a long time ago to the working group

    CL: Maybe you can add a pointer to those examples
    ... in the Issue, if you find them again

    ED: So maybe we can leave this issue open for now
    ... that could be something some can do which is to go through the
    whitespace section


    CL: I thought we added href to style?
    ... I'm surprised to see it again
    ... what I think discussed it and agreed on it
    ... just never propagated to where it's suppose to be
    ... this was a long time ago
    ... this is when we decided to add a href to script
    ... but anyway, it's seems an obvious thing to do
    ... it seems easy enough to do, and brings us inline with HTML

    ED: I know there is a link element, but I haven't seen anything
    exactly the same

    CL: The only thing you need to discuss is the order of inclusion for

    ED: I think in my opinion that would take us further from HTML
    ... I think having a link element in SVG would be more useful
    ... because you could link to other resources


      [29] http://dev.w3.org/html5/spec/Overview.html#the-style-element

    CL: In some ways that is a better way - to use import

    ED: That is useful for somethings, and I have had cases where I
    needed the link element

    DS: I actually made an experiment that brings the xhtml:link element
    in SVG and it allows you to bring in CSS style sheets in SVG

    CL: In the XHTML name space I'm guessing?

    ED: Yes

    CL: So adding it to the SVG is of value why?

    DS: You don't need to use name spaces

    CL: The down side is old content breaks. It becomes interoperable

    DS: So when people use it in HTML content it would just work
    ... it would be closer to what HTML does
    ... it would be trivial for the browsers to add this

    CL: I'm worried that they might come back and say we have something

    DS: I think we should ask them

    <scribe> ACTION: Doug to Email the public list and representatives
    of the major browsers and ask if having a link element would be
    useful for them [recorded in

    <trackbot> Created ACTION-2457 - Email the public list and
    representatives of the major browsers and ask if having a link
    element would be useful for them [on Doug Schepers - due

Summary of Action Items

    [NEW] ACTION: Cameron to Propose a number of different solutions to
    solving the problem of extracting the width and height of an image
    in ISSUE-2021 [recorded in
    [NEW] ACTION: Doug to Email the public list and representatives of
    the major browsers and ask if having a link element would be useful
    for them [recorded in
    [NEW] ACTION: shepazu to write a proposal for inuitive x/y method
    [recorded in

    [End of minutes]

     Minutes formatted by David Booth's [34]scribe.perl version 1.133
     ([35]CVS log)
     $Date: 2009/02/12 21:05:43 $

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

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

Guessing input format: RRSAgent_Text_Format (score 1.00)

Succeeded: s/9for/(for/
Succeeded: s/then>/then?/
Succeeded: s/tiny/Tiny/
FAILED: s/surfari/surfin' safari/
Succeeded: s/thigns/things/
Found Scribe: anthony
Inferring ScribeNick: anthony
Default Present: ed___, [IPcaller], heycam, shepazu, anthony, ChrisL
Present: ed___ [IPcaller] heycam shepazu anthony ChrisL
Agenda: [37]http://lists.w3.org/Archives/Public/public-svg-wg/2009JanMa
Found Date: 12 Feb 2009
Guessing minutes URL: [38]http://www.w3.org/2009/02/12-svg-minutes.html
People with action items: cameron doug shepazu

      [37] http://lists.w3.org/Archives/Public/public-svg-wg/2009JanMar/0128.html
      [38] http://www.w3.org/2009/02/12-svg-minutes.html

    End of [39]scribe.perl diagnostic output]

      [39] http://dev.w3.org/cvsweb/~checkout~/2002/scribe/scribedoc.htm

Received on Thursday, 12 February 2009 22:46:35 UTC