Minutes August 30, 2012 SVG WG Telcon



  and as text:


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

                                - DRAFT -

                     SVG Working Group Teleconference

30 Aug 2012


       [2] http://lists.w3.org/Archives/Public/public-svg-wg/2012JulSep/0179.html

    See also: [3]IRC log

       [3] http://www.w3.org/2012/08/30-svg-irc


           +1.415.832.aaaa, birtles, nikos, krit, ed, [IPcaller],
           heycam, +, Rich, cyril_,
           +, Tav, Doug_Schepers




      * [4]Topics
          1. [5]CSS4 image type as paint value
          2. [6]Filter subregion clipping
          3. [7]Behaviour of feOffset dx/dy values with percentages
          4. [8]Commas vs spaces in SVG View fragment identifiers
          5. [9]maskType, and camel case elements/attributes more
      * [10]Summary of Action Items

    <trackbot> Date: 30 August 2012

    <krit> Zakim: aaaa is me

    <scribe> scribenick: nikos

CSS4 image type as paint value


      [11] http://www.w3.org/mid/FBBDBDBC-F3CD-404E-AFC1-0369A75DAA89@adobe.com

    krit: Doesn't matter about the version. I'd just like to use
    CSS image
    ... then we get linear gradient and other gradients
    ... If we use CSS image as a paint server then it's possible to
    use images or filters or anything that is defined by CSS image

    birtles: What about making paint servers part of images?
    ... a lot of CSS specs refer to image values, why not do it the
    other way around
    ... then you could use an SVG gradient in CSS

    krit: That is in CSS4 image

    <ed> so <rect fill="linear-gradient(bottom, rgb(149,227,138)
    47%, rgb(179,255,166) 74%)" .../> for example

    krit: we need to figure out how it works because it could lead
    to circular dependency
    ... The element function can reference paint servers from SVG

    heycam: Do you want paint server references just inside that
    element or do you allow urls?

    <krit> [12]http://dev.w3.org/csswg/css3-images/#image-values

      [12] http://dev.w3.org/csswg/css3-images/#image-values

    krit: I am just asking if we can use the css image type in SVG
    fill and stroke properties
    ... in the beginning I'd be fine with gradient

    <heycam> ack

    krit: image would be cool but if we just have gradient that
    would be good

    cyril_: for gradients or patterns you have the gradient limits
    that tells you how the gradient space maps to the image space
    ... how would you do that

    krit: you need to define how the bounding box is defined for
    svg and it would maybe be object bounding box

    cyril_: would the svg objects crop the image or would the image
    be entirely contained in the svg object?

    krit: you mean referencing an image with a url?

    cyril_: any image. css3 image fills an object with an image
    ... you might end up with an image size different from the svg
    object size so you need to crop, or reflect, or something

    krit: at the beginning we might just define gradient. its

    <krit> [13]http://dev.w3.org/csswg/css3-images/#gradient-type

      [13] http://dev.w3.org/csswg/css3-images/#gradient-type

    cyril_: Using percentages or integers or fixed values, you can
    say the image will take more or less than the bounding box of
    the object
    ... you have to define if you crop, or what you do

    krit: I agree with that
    ... At the beginning I'd be fine to just use gradients as this
    isn't a problem for them
    ... you just need to define a box, and we'd just use the object
    bounding box

    heycam: I think cyrils concern was that it's not clear whether
    gradients cover the entire box or whether you pad or repeat
    ... I think we need a way to specify whether you repeat in
    horizontal or vertical directions

    nikos: I think dirk is saying you use the object bounding box
    so the dimensions always match up

    cyril_: in css gradients I don't think you can specify where
    the 2 end points of the vector defining the gradient are -
    except for top or bottom

    heycam: you can give a length value

    cyril_: I'm seeing left, right, top, bottom, thats it
    ... you can't say I want the points to be 10% inside
    ... then you don't have to specify pad or repeat
    ... there is a repeating linear gradient

    krit: that's a limitation in css gradients in general, why is
    it a problem for svg?

    cyril_: I'm just saying it needs to be specified how the object
    is filled when the gradient is not big enough

    heycam: from what I can see it will always be big enough
    ... you have stops that go from 0 to 100%

    cyril_: Yeh with gradient it seems you will always fill the

    heycam: With images I think you're right about fitting.
    ... Are the only types images and gradients?

    cyril_: url image_list and gradient

    heycam: I'm sure we could define how the image renders without
    adding more controls like various background repeat properties
    ... I don't know how useful it is to solve that here
    ... maybe in that case you need to use a pattern for example

    krit: Can we resolve for linear gradient and solve the other
    problems later?

    heycam: I'm happy with it

    ed: I agree

    cyril_: what would be the benefit compared to using svg

    krit: you can apply a linear gradient to a class of object
    ... and use the same gradient for html and svg content

    cyril_: ok

    heycam: it's also an easier way to specify a gradient

    Resolution: Paint values will allow gradients from CSS3 image

    krit: CSS image 3 is already a REC


      [14] http://dev.w3.org/csswg/css3-images/#repeating-gradients

    heycam: I see you can do repeating gradient styles in CSS

    cyril_: in any case it's going to fill the whole object

    krit: will it be in the SVG2 FPWD or is it for the future?

    heycam: I think we've discussed this before in the context of
    referencing as many CSS specs as possible

    krit: so SVG 2 then
    ... next draft release

    heycam: If you have time

    <scribe> ACTION: Dirk to edit SVG 2 draft to add CSS 3
    gradients as a paint value [recorded in

    <trackbot> Created ACTION-3346 - Edit SVG 2 draft to add CSS 3
    gradients as a paint value [on Dirk Schulze - due 2012-09-06].

Filter subregion clipping

    ed: I sent my comments to the public mailing list
    ... I think it addressed both discussions
    ... feOffset and how to define input and output clipping


      [16] http://lists.w3.org/Archives/Public/www-svg/2012Aug/0143.html

    ed: so in Opera we treat feOffset not exactly as the spec tells
    us to, because if you consider the example in the mail,
    feOffset itself doesn't specify a primitive subregion - doesn't
    have x, y and width. Intuitively for me I wouldn't expect it to
    clip, I'd expect it to move the previous primitive

    krit: I would agree that we don't need to clip the offset, we
    move it around
    ... Do you clip if you move a primitive to the outside of
    filter regions then bring it back in?

    heycam: do you clip at each step or just once at the end?

    ed: Could you post an example?

    <krit> <filter id="feoffset1"
    primitiveUnits="objectBoundingBox" x="0%" y="0%"

    <krit> width="100%" height="100%">

    <krit> <feFlood width="100%" height="100%" flood-color="lime"/>

    <krit> <feOffset dx="0.1" dy="0.2"/>

    <krit> </filter>

    ed: So you move the result out and back again?
    ... what would you expect in that case?

    krit: I think the spec says it's clipped away
    ... when you move it back you are just moving transparent black

    ed: I'm not really sure what I'd expect in that case
    ... I think I might expect to be able to move the result back
    ... it would be interesting to see what the implementations do

    krit: it would be interesting to see what gaussian blur does

    ed: I think it would be interesting to have some way of letting
    the user agent find out what the filter region is
    automatically, but we'd have to be careful not to break content

    krit: In this case we definitely should clip, the question is
    does opera clip
    ... Do you clip the input or the output?
    ... that's a general question

    ed: I think we do input clipping

    krit: filter effects spec requires input and output clipping,
    which is not useful in my eyes

    ed: So do we want to control this, or do we require one
    particular way?

    krit: I think both input and output is not useful
    ... I don't care if we go with input or output

    heycam: what might break if we switched? if we specified just

    krit: we are really discussion an edge case so I wouldn't
    expect much to break

    heycam: it only matters to primitives that do things outside
    their region
    ... most filter primitives say their input and output regions
    are the same
    ... is that right?

    krit: by default, firefox's subregion depends on the previous
    subregion so if you have 2 filters of different size, it is the
    union of both
    ... when you specify x, y, w and h what should be clipped, the
    input or the output?

    ed: do you have a test case?

    krit: I have posted something to the mailing list

    ed: I'm looking for something that doesn't use feOffset

    krit: it's difficult without feOffset

    ed: We treat it differently, we don't take the union of the
    inputs, we use the filter region itself if you don't specify

    heycam: apart from whether you do clipping on input or output.
    Dirk, do you think it makes sense to special case feOffset?

    krit: if you don't have input clipping it doesn't matter
    ... in that case the subregion depends on the clipregion of the
    feOffset filter
    ... I'd have to think about it some more
    ... right now the specification wants to clip to the region

    heycam: the spec only says clip the input and output both
    ... to make feOffset more useful, would we need to change it to
    only output or only input? or is that a separate issue

    krit: I think it's separate

    ed: I think it would be nice to have an analysis of where and
    when it's useful to have each clipping method

    heycam: I think it would be good too, I find it hard to
    visualise why you'd take one or the other

    ed: There's one example in the spec but I don't think it uses
    ... There's also the example from the mail and the bug report
    ... but apart from that I don't think we have many tests for

    <scribe> ACTION: Dirk to investigate and expand on the proposal
    of sub region clipping for Filter Effects [recorded in

    <trackbot> Created ACTION-3347 - Investigate and expand on the
    proposal of sub region clipping for Filter Effects [on Dirk
    Schulze - due 2012-09-06].

    heycam: what about for the other issue of whether feOffset
    behaviour should be special?

    krit: I'll look into that as well

    ed: They're similar but not quite the same

    <krit> nikos: great, thanks. Let us share the examples next

    <krit> haha

    heycam: i imagine you could construct the filter to avoid the
    problem - don't shift outside the region

    ed: not many people write such advanced filters that they would
    run into this issue

    heycam: we'll pick up the discussion once dirk has had a look

Behaviour of feOffset dx/dy values with percentages

    heycam: does anyone support percentage values for dx and dy?

    krit: if you use 50% then it is treated as 50
    ... on webkit

    heycam: we should make percentages work or disallow them

    krit: We already support percentage - but indirectly

    heycam: why is it that dx and dy unitless values are treated as
    unit bounding box values and not ...
    ... if you have unit less values they are just user units
    ... there's nothing weird and I'd expect percentages to be
    percentages of the viewport
    ... if you have primitive space = user space on use, dx and dy
    should be percentages of the viewport?

    krit: if you supported percentages, but we don't

    heycam: do we have other primitives that take percentages?

    krit: no

    heycam: my feeling is that we should make percentages work

    krit: and for other cases?
    ... where percentages could work?

    heycam: so the issue with standard deviation is it's a number
    not a length right?


      [18] https://dvcs.w3.org/hg/FXTF/raw-file/tip/filters/index.html#FilterFunction

    heycam: in the corresponding shorthand if we are going to
    support lengths, we should take lengths in the element
    ... I'm thinking whether it would be more consistent in general
    to support that, but I'm not sure that it's important

    ed: is there any particular examples?
    ... I'm looking for some kind of testcase to try out
    ... just wondering if you had one handy

    heycam: I think dx and dy look like they go with width and
    height, you might expect them to take the same kinds of value

    krit: I agree

    heycam: I would be happy to say dx and dy take lengths and
    percentages and forget about the other things like standard

    ed: I'd like to see an example before we make any changes

    <scribe> ACTION: Dirk to provide examples of percentages with
    dx and dy in Filter Effects [recorded in

    <trackbot> Created ACTION-3348 - Provide examples of
    percentages with dx and dy in Filter Effects [on Dirk Schulze -
    due 2012-09-06].

Commas vs spaces in SVG View fragment identifiers

    <krit> [20]http://dev.w3.org/csswg/css4-images/#image-fragments

      [20] http://dev.w3.org/csswg/css4-images/#image-fragments

    heycam: Robert brought up in the mailing list some text in the
    linking chapter that talks about how you must use commas rather
    than spaces in the viewbox part of an svg fragment. You can use
    %20 to encode spaces but it's easier to use commas.
    ... there's a similar issue in preserve aspect ratio, because
    you can have the slice value after the xMinyMin part
    ... and that normally takes a space between them
    ... I think viewbox also would normally take a space, so
    there's no issue saying just use a comma
    ... I think Robert was asking for a clarification on the

    krit: I don't like spaces in iri
    ... I pasted a link to css image fragments, they comma separate
    ... I don't have a really strong opinion but I feel its more

    heycam: I agree, you don't really want to url encode

    ed: I agree with the comma, even though I don't like the svg
    view syntax.

    krit: the css specifications use uri and svg uses iri
    ... in theory there's a difference but in practice there's not
    ... do we have a strong opinion that we should use iri?

    heycam: I raised something on the mailing list about the
    differences. I didn't get a clear idea in the end whether one
    or the other should change or whether we ignore the situation

    krit: Filter Effects uses iri and the discussion on exclusions
    they want to use parts of svg that use iri
    ... it would be good to harmonise the specifications


      [21] http://lists.w3.org/Archives/Public/www-style/2012May/0772.html

    heycam: here's the mail where I asked how things in brackets
    are parsed, because I think the spec doesn't really say.
    ... I didn't really get a satisfactory answer

    ed: The Filter Effects spec uses iri because SVG 1 used iri

    heycam: If you look at the data url in the email I linked to

    krit: iri just supports more characters right?

    heycam: yes, you can use non ascii characters
    ... for uri you would have to escape them somehow
    ... the test uses a css background image that has some non
    ascii characters
    ... and that seems to work everywhere so I assume browsers are
    interpreting as iri

    krit: you tested locally?

    heycam: no it's on a server
    ... if you view my example and 'view source'

    krit: it doesn't work in Safari

    ed: It doesn't seem to wokr in Opera either

    heycam: It may be because I left a bracket out of the example
    ... I think the issue is that the css spec needs to define how
    things inside the url brackets are parsed and interpreted


      [22] http://lists.w3.org/Archives/Public/www-style/2012May/0824.html

    <heycam> [23]http://räksmörgås.josefsson.org/raksmorgas.jpg

      [23] http://r/

    heycam: That's the test I meant to do... oh wait it doesn't
    have the brackets either
    ... I tried to link to that url in background-image
    ... I think the css spec needs to say that the things in the
    brackets are interpreted as iris or whatever they need to do to
    take non ascii characters

    krit: Can you bring it up with the css group?

    heycam: well I sent the mail, I think if you want to bring it
    up you can
    ... back to the topic. I think the question is whether we allow
    commas or spaces


      [24] https://svgwg.org/svg2-draft/linking.html#SVGFragmentIdentifiers

    heycam: if you look at the grammar, you can see that the part
    of the grammar that refers to preserve aspect ratio, aspect
    params is defined in the list beneath and it's not defined
    ... given that spaces are said to be not allowed, we need to
    define it so that spaces are allowed or we can allow a comma
    ... I don't have a strong preference

    ed: i was wondering about another issue, url escaping, firefox
    did allow the url escaped spaces to work
    ... I couldn't find anything in the spec but it would be nice
    to have it clarified

    heycam: I'm not sure what what level it should do that
    ... is suspect if we look at the html spec it will define it
    ... there was meant to be a new url spec, but I don't think it
    progressed much
    ... I think it was going to define this sort of thing

    shepazu: is anyone working on it?

    heycam: I think so but I don't know
    ... I suspect that that spec would define how to encode the
    fragments and decode them
    ... that's the level it should be at
    ... I agree it would be nice to have a link to somewhere that
    defines how to parse these fragments

    <scribe> ACTION: Cameron to look at the url spec or find out
    what we need to reference to make sure url fragments have a
    well defined encoding and decoding [recorded in

    <trackbot> Created ACTION-3349 - Look at the url spec or find
    out what we need to reference to make sure url fragments have a
    well defined encoding and decoding [on Cameron McCormack - due

    heycam: Erik or anyone do you have an opinion on what to do
    with the preserve aspect ratio part?
    ... I don't have a strong opinion

    ed: this is a special case, I'd prefer if parsing was the same
    as the attributes
    ... might not be possible

    heycam: we can make it possible

    ed: that would be easier implementation wise
    ... it's not hard anyway but consistency would be nice

    shepazu: consistency means a better experience for everyone

    heycam: are there any other examples?

    shepazu: any attribute can have keywords

    <ed> requiredFeatures is space-separated I think


      [26] http://www.w3.org/TR/SVG11/struct.html#ConditionalProcessingRequiredFeaturesAttribute

    heycam: I think you can't just have an arbitrary name in there
    or the property would fail to parse
    ... I was wondering about non property attributes
    ... I don't know any off the top of my head
    ... I'm concerned whether we allow commas in preserve aspect
    ratio whether that will lead to it happening elsewhere
    ... there may not be any other cases

    shepazu: there's the text, they're not keywords, they're
    values. Like x or y for text

    heycam: we do allow commas there

    shepazu: there was a kerfuffle with stroke dash array because
    it wasn't specified
    ... we fixed that

    <shepazu> [27]http://www.w3.org/TR/SVG/attindex.html

      [27] http://www.w3.org/TR/SVG/attindex.html

    heycam: Unfortunately the type of value isn't in that table
    ... there's things that take number-space-number and they don't
    take commas

    shepazu: number-delimited-number should allow anything
    ... should allow comma or space or a combination rather
    ... oh transforms!
    ... you can have a space separated list of values and I don't
    think you can use a comma there

    heycam: I think you're right

    krit: they can be comma or space separated

    heycam: they can in the attribute but not in the property

    viewbox and zoomAndPan are the only ones I can see

    heycam: let me, suggest we allow commas in preserveApsectRatio

    <richardschwerdtfe> have to drop

    Resolution: preserveAspectRatio will allow commas in the
    attribute and that part of the view specification

    <scribe> ACTION: Cameron to update preserveApsectRatio in view
    specification to allow commas [recorded in

    <trackbot> Created ACTION-3350 - Update preserveApsectRatio in
    view specification to allow commas [on Cameron McCormack - due

maskType, and camel case elements/attributes more generally

    heycam: We might need to discuss this at the F2F

    shepazu: I think that we should not capitalise anything

    heycam: I think that's what Simon wanted
    ... at least on new things


    heycam: Maybe allowing lowercase everywhere might be the
    cleanest solution

    shepazu: I'm struggling to think of a place where
    caplitalisation would matter if we had error correction
    ... is there anywhere where capitalisation would matter?

    heycam: it matters from the perspective of making a dom call
    ... you need to use the correct capitalisation there
    ... I want to think about this more deeply
    ... it might tie in with switching modes in the SVG DOM
    ... like switching to no namespace
    ... and in that case everything is in lower case, for example.
    ... I do think it's an issue that we need to resolve.
    ... or if we keep inventing camel case names we need to make a
    concious decision to go that way
    ... we'll continue the discussion at a later point

Summary of Action Items

    [NEW] ACTION: Cameron to look at the url spec or find out what
    we need to reference to make sure url fragments have a well
    defined encoding and decoding [recorded in
    [NEW] ACTION: Cameron to update preserveApsectRatio in view
    specification to allow commas [recorded in
    [NEW] ACTION: Dirk to edit SVG 2 draft to add CSS 3 gradients
    as a paint value [recorded in
    [NEW] ACTION: Dirk to investigate and expand on the proposal of
    sub region clipping for Filter Effects [recorded in
    [NEW] ACTION: Dirk to provide examples of percentages with dx
    and dy in Filter Effects [recorded in

    [End of minutes]

     Minutes formatted by David Booth's [34]scribe.perl version
     1.136 ([35]CVS log)
     $Date: 2012/08/30 22:30:55 $

The information contained in this email message and any attachments may be confidential and may also be the subject to legal professional privilege. If you are not the intended recipient, any use, interference with, disclosure or copying of this material is unauthorised and prohibited. If you have received this email in error, please immediately advise the sender by return email and delete the information from your system.

Received on Thursday, 30 August 2012 22:33:25 UTC