W3C home > Mailing lists > Public > www-svg@w3.org > October 2013

Minutes, 17 October 2013 SVG WG telcon

From: Nikos Andronikos <nikos.andronikos@cisra.canon.com.au>
Date: Fri, 18 Oct 2013 08:34:39 +1100
Message-ID: <526057EF.7070100@cisra.canon.com.au>
To: <www-svg@w3.org>
Minutes from this week's SVG WG telcon are below.

html version:

text version:


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

                                - DRAFT -

                     SVG Working Group Teleconference

17 Oct 2013


       [2] http://lists.w3.org/Archives/Public/public-svg-wg/2013OctDec/0016.html

    See also: [3]IRC log

       [3] http://www.w3.org/2013/10/17-svg-irc


           Erik, Luc, Tav, Rich




      * [4]Topics
          1. [5]Publish CSS Masking as LCWD
          2. [6]Should perspective affect object bounding box of
             SVG elements?
          3. [7]Confirm location and dates for 1st F2F of 2014
          4. [8]SVG Glyphs in OpenType specification
      * [9]Summary of Action Items

    <trackbot> Date: 17 October 2013

    <stakagi> zakim ??P6 is me

    <scribe> scribenick: nikos

Publish CSS Masking as LCWD

    krit1: Can we publish?


      [10] https://dvcs.w3.org/hg/FXTF/raw-file/tip/masking/index.html

    krit1: short summary about changes
    ... syntax hasn't changed except one exception
    ... initial draft supported multiple layers of mask
    ... question was if it's possible to combine different masks or
    if it would be mask on mask
    ... so we delayed layers to next level until this is workedo ut

    heycam: so you can only specify one layer

    krit1: yes
    ... having multiple mask layers can be useful but how do you
    combine the mask?
    ... in webkit, you mask with each in turn
    ... but you might want to combine masks and then apply
    ... needs to be discussed more
    ... not worth waiting

    heycam: should be possible to define the first process you
    said? applying masks in turn
    ... should be possible to compute a single mask that does that?

    krit1: the problem is you always lose something
    ... imagine having a composite operator between the masks and
    then apply the result

    heycam: I think it's fine to leave that to later

    cyril: what is the difference compared to what svg had in the
    ... are features different or just css integration?

    krit1: the idea was to have a spec for html and svg world
    ... yes when combined with mask-box
    ... no because you could do a lot of things with svg mask
    element that you can now do with masking using an image
    ... it gets easier, but not necessarily more powerful

    birtles: we do have alpha and luminance masking

    krit1: both are implemented in webkit as of a couple of weeks


      [11] http://lists.w3.org/Archives/Public/public-fx/2013OctDec/0056.html

    birtles: did you see the discussion on public-fx on how how the
    properties are animated?

    krit1: all properties define if animatable or not
    ... what will work on mask properties will also apply to
    background properties
    ... mask-box-image-slice is not animatable at the moment

    heycam: is the background version of image-slice property

    krit1: yes it's called border-image-slice

    heycam: why is the mask one not animatable?

    krit1: I think it's the auto value cannot be animated
    ... but I think maybe it could be

    RESOLUTION: publish LCWD of CSS Masking.

    heycam: which group will handle publication?

    krit1: I asked ChrisL to handle it

Should perspective affect object bounding box of SVG elements?

    krit1: object bounding box is a construct we have in svg for a
    long time
    ... it's the union of all bounding boxes of it's children
    including transforms
    ... as an example. You have group element with child rect.
    Child rect has scale of 2 then bounding box of the rect will be
    twice as big for the group element
    ... CSS transforms we have a lot more properties
    ... importantly, persepective and perspective-origin
    ... the persepective has percentage values
    ... the spec currently says for all properties, percentage
    values are resolved against object bounding box
    ... if the object bounding box includes perspective there is a
    circular dependency
    ... one option is to stick to definition of svg 1.1

    heycam: that means ignoring the transform property and all of
    the other perspective
    ... can you remind me what is the plan for transform
    presentation attribute and property?
    ... are they meant to be the same thing?

    krit1: transform attribute will be presentation attribute
    ... that means for transform property we have cascade
    ... so you could just look at the presentation attribute not
    the whole cascade
    ... I don't think we should go that way though

    heycam: I agree

    krit1: other solution is object bounding box does not included
    ... so that we do not have the problem resolving
    ... third solution - all percentage values are resolved against
    the viewport

    heycam: do we have to consider the transform properties because
    we might have the individual perspective properties in that

    krit1: I don't think that's a problem. They apply as a
    transform function
    ... no dependency on parent or child

    heycam: if you have transform-origin with percentage values and
    transform property with list and one is a perspective
    ... would there be a cyclic dependency?
    ... what's different?

    krit1: transform just takes transform functions that are
    multiplied together
    ... persepective is not an exception
    ... it's just another function
    ... I would suggest we look at the 3d part
    ... for getting the bounding box
    ... perspective property on other hand is devised from the
    ... parent perspective multiplied by transform of current
    ... that's the difference
    ... between perspective function and property
    ... I don't think it's actually that useful

    heycam: option 2 was to ignore perspective property when
    calculating the bounding box
    ... is that all situations (getBBox as well as bounding box for
    gradients for example)

    krit1: it should be all situations
    ... the problem with option 3 is it's not intuitive
    ... and doesn't fit well with html world
    ... would also be different to transform and transform-origin

    heycam: if you add a small amount of perspective and
    transform-origin is in a different position, that would be bad

    krit1: in general perspective and 3d transforms are complex
    ... can wait on a resolution if people need time to digest

    heycam: my feeling is that number 2 sounds like the best

    krit1: I'd be in favour of 2

    heycam: in html if you have perspective and call getClientRect
    ... how does that work with perspective, etc

    krit1: main difference is that getClientRect does not included

    heycam: is there no function for getting actual bounding box
    with transforms in html?

    krit1: transform doesn't modify the layout

    <krit1> shepazu: speak!

    shepazu: you're talking about whether perspective should change
    ... Dirk you were saying no?

    krit1: correct
    ... perspective on child element comes from the parent. Problem
    is that perspective can have percentage values that need to be
    resolved against object bounding box. But object bounding box
    needs the percentage values to be calculated
    ... bounding box inclueds the size of transformed children, but
    not the transform on the actual element

    s/is modified by/inclueds/

    shepazu: I'd like to see it written up

    krit1: we need a solution for resolving the dependencies

    heycam: the issue is when you use percentage values in
    transform-origin and the percentages are relative to the shape
    you are transforming. But the perspective can change the
    bounding box of the shape being transformed
    ... so there's a cyclic dependency

    shepazu: there's an internal way of getting the bounding box
    ... but that's not what we're exposing to the user
    ... we are exposing a convenience function

    heycam: the issue isn't calculating the bounding box. The issue
    is having the percentage values influence the bounding box
    ... this isn't the case for regular transforms or html content

    shepazu: I'd like to see a diagram of this to clarify

    krit1: the browser has this problem internally
    ... we could move discussion to the mailing list? I tried to
    explain on public-fx

    shepazu: there's the bounding box - the internal calcualtion of
    ... and the return value of the get bounding box function
    exposed to users
    ... they don't have to return the same result
    ... we could introduce a change to affect this
    ... I'll try to explain
    ... let's say we have a new bounding box function getBBox2
    ... it can return whatever we want because there's no
    dependency chain

    krit1: it can't be calculated internally
    ... we expose exactly what we calculate internally

    heycam: implementations at the moment. If they supported 3d
    transforms on SVG. There is no way to mathematically resolve
    the percentage values

    shepazu: I think we're talking about two different issues

    [heycam summarises]

    krit1: let's continue on the mailing list

Confirm location and dates for 1st F2F of 2014

    heycam: Dirk you've been co-ordinating with CSS?

    krit1: CSS group is happy to meet for half day as I said
    ... fx on second half of 29th Jan
    ... SVG on 30-31 Jan
    ... in Seattle
    ... I've booked the rooms

    RESOLUTION: SVG WG will meet in Seattle 30-31 January 2014 with
    FX half day on 29th January

SVG Glyphs in OpenType specification

    heycam: There was a second coloured fonts meeting which Chris
    was at
    ... he sent a summary to the list
    ... that was one of the reasons Sairus wanted the spec
    ... the spec will serve as introduction to the discussion for
    ISO in January
    ... so that was the point of moving the community group draft
    to spec text

    cyril: Chris is saying there are 4 proposals
    ... Microsoft's, Apple's, etc

    heycam: Google and Apple are bitmap formats
    ... Google is something like embedding PNGs
    ... Microsoft has solid coloured filled vectors

    cyril: in terms of process. There's a call for proposals in ISO
    ... how does the community group satisfy the requirements?

    heycam: someone needs to write up a document addressing how the
    specification matches each requirement
    ... there are requirements around lower power devices
    ... it seems the list of requirements covers all the bases


      [12] http://lists.w3.org/Archives/Public/public-svg-wg/2013OctDec/0020.html

    cyril: I think normally one is picked to continue and the
    interesting parts of others are merged in

    nikos: there's already been some merging - Microsoft palettes
    into SVG in OT

    heycam: one font could have the palette table plus Microsoft's
    multi coloured glyph table and SVG and use the palette in both

    krit1: benefits of the other proposals are that they are easy
    to implement in the font system
    ... but they do not have animations or things like that

    nikos: but there's no way to specify a colour that wasn't
    already defined in the font?

    shepazu: Does Adobe have a position?

    krit1: I'm not sure. Sairus is obviously working on SVG in OT
    but I don't know if it's personally motivated or on behalf of
    the company

    cyril: who will be representing SVG in OT at the MPEG meeting?

    heycam: I'm not sure
    ... in San Jose so convenient for Sairus

    cyril: meeting is 13th-17th
    ... I will be there

Summary of Action Items

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, 17 October 2013 21:35:10 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 22:54:46 UTC