SVG Working Group Teleconference -- 12 Feb 2009

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

ISSUE-2002

ISSUE-2002?

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

<trackbot> 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 image

CL: If you are talking about errata you could put that in with an example
... 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 element?

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 iamges

<ed___> 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' element.

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 rectangle

<ChrisL> and my raster image is 400x400 pixels

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

<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

ISSUE-2021

ISSUE-2021?

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

<trackbot> 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 currently
... 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 problem

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

<ed___> http://www.w3.org/TR/SVG11/types.html#InterfaceSVGFitToViewBox

<ed___> http://www.w3.org/TR/SVG11/struct.html#InterfaceSVGImageElement

ED: I don't see that interface

<ed___> 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 useful
... 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 http://www.w3.org/2009/02/12-svg-minutes.html#action01]

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

ISSUE-2182

ISSUE-2182?

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

<trackbot> 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 'getPosition'
... 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> 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 space?

<shepazu> yeah, more or less

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

<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 automatically
... 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 interface?

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 http://www.w3.org/2009/02/12-svg-minutes.html#action02]

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

<shepazu> er... intuitive

<heycam> 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 ISSUE-2172
... which are quite similar

CMC: They are quite similar

ED: I was thinking of closing the older one and just having one of them
... 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> http://www.w3.org/TR/xsl/#white-space-treatment

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

<ChrisL> 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___> http://www.w3.org/TR/xsl/#white-space

CL: It takes the values from CSS2 and says how it maps to the XSL ones
... 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 list

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

ISSUE-2049

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 CSS

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

<ed___> 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 already

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 http://www.w3.org/2009/02/12-svg-minutes.html#action03]

<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 2009-02-19].

- DRAFT -

SVG Working Group Teleconference

12 Feb 2009

Attendees

Contents