Minutes, 15 August 2013 SVG WG telcon

Minutes from this week's SVG WG telcon are below.

http://www.w3.org/2013/08/15-svg-minutes.html


    [1]W3C

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

                                - DRAFT -

                     SVG Working Group Teleconference

15 Aug 2013

    [2]Agenda

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

    See also: [3]IRC log

       [3] http://www.w3.org/2013/08/15-svg-irc

Attendees

    Present
    Regrets
           Rich

    Chair
           Cameron

    Scribe
           nikos

Contents

      * [4]Topics
          1. [5]Publishing and renaming CSSMatrix
          2. [6]Progress on subregions hinting in SVG Filters
          3. [7]Collapsing CSS Filter functions and the problem of
             color clamping on
          4. [8]Geometry API and Accessible SVG Community Groups
      * [9]Summary of Action Items
      __________________________________________________________

    <trackbot> Date: 15 August 2013

    <TabAtkins> Dear SVG: Please kill your namespaces faster. Love,
    Tab.

    <krit1> TabAtkins: we would need to add the SVG elements to the
    HTML parser

    <scribe> scribenick: nikos

    <TabAtkins> krit1++

    <TabAtkins> But really it's the xlink that's killing me today.

    <TabAtkins> Which requires only local changes to the language.

Publishing and renaming CSSMatrix

    <heycam> Removing xlink is something we can do without a lot of
    the other stuff.

    <cabanier> I thought we already agree to killing that off

    <krit>
    [10]https://dvcs.w3.org/hg/FXTF/raw-file/tip/matrix/index.html

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

    <TabAtkins> Yeah, but it's not edited in yet. ^_^

    <krit> [11]http://dev.w3.org/fxtf/matrix/

      [11] http://dev.w3.org/fxtf/matrix/

    heycam: we haven't published this yet?

    krit: correct
    ... 2 issues
    ... first is name. CSS WG doesn't want CSS prefix

    heycam: dictionary ones don't matter since they're not exposed
    in script
    ... interfaces intended to be used outside probably shouldn't
    have css in the name

    krit: suggestion was either TransformationMatrix or
    TransformMatrix
    ... I don't have others

    heycam: if we named it Matrix, there might be a risk of
    conflicting with scripts that define Matrix already

    krit: we also have conflict with other working groups
    ... was discussed on fxtf mailing list
    ... was suggested to name it Deprecated Matrix

    heycam: ugly name!

    cabanier: web gl want to have something more primitive
    ... not useful for authors. The reason we are doing this is to
    make operations easier for them

    heycam: I'm not convinced by argument that we shouldn't have it
    becaues JS authors can write something that can run faster
    ... browsers can implement with native js behind the scenes and
    avoid the overhead

    <TabAtkins> I'm down with TransformMatrix.

    krit: because Matrix is so generic, I don't think it's a bad
    idea to have a prefix

    heycam: you said CSS WG has already resolved to publish? what
    was their final view on name? have an issue in the spec?

    krit: we need the name for the url though so it's problematic
    to do that

    heycam: I think it would be fine, even if we call it CSSMatrix
    or TranformMatrix to have the url as just matrix
    ... I'm fine with publishing and including an issue

    krit: CSS WG suggested SVG WG takes care of publication

    heycam: couple of other issues open in the spec
    ... 1. w part of the point

    krit: the main is whether we use float or doubles
    ... Mozilla wants floats. Apple wants double
    ... difference is 10 times on mobile
    ... javascript just uses double
    ... so it's just the internal calculation results
    ... currently I am using doubles in the spec

    heycam: I don't think we need to resolve that before publishing
    ... what is the plan for replacing SVGMatrix with CSSMatrix?

    krit: The whole point of this is to replace SVGMatrix

    heycam: so we'll just use CSSMatrix. Won't have any
    inheritance.

    krit: It's backwards compatible, except the new matrix won't
    throw exceptions as SVGMatrix did

    heycam: I also remember roc was concerned about the matrix
    object being used for 3d and 2d
    ... meaning you need the extra components

    krit: I think he's ok with it now

    heycam: I'll check with him

    resolution: Publish first public working draft of new matrix
    specification

    <scribe> ACTION: Cameron to organise FPWD publication of new
    matrix specification [recorded in
    [12]http://www.w3.org/2013/08/15-svg-minutes.html#action01]

    <trackbot> Created ACTION-3517 - Organise fpwd publication of
    new matrix specification [on Cameron McCormack - due
    2013-08-22].

Progress on subregions hinting in SVG Filters

    <krit> [13]http://www.w3.org/Graphics/fx/wiki/Filter_effects

      [13] http://www.w3.org/Graphics/fx/wiki/Filter_effects

    krit: Erik put together an implementation matrix
    ... We need to specify exactly how subregions are calculated
    ... I would like feedback on the table
    ... especially where we have question marks
    ... we're not clear on how to calculate subregions for some
    filters at the moment
    ... it's important that the filter region doesn't clip things
    you don't want clipped
    ... a lot of people don't understand the 10% margin

    heycam: I never liked it. It's not usually what you want
    ... are you suggesting to remove filter region primitive
    attribute?

    krit: no
    ... if they are not present then the user agent should
    calculate automatically

    heycam: so changing the default

    krit: in a way that fixes content

    heycam: I'd be in favour of that

    krit: so we need to specify what unbound? is for each in the
    table

    heycam: for filters like feFlood or feTurbulence that
    conceptually have infinite output, what would we define apart
    from 'implementation needs to work out how much of the final
    rendered element to keep'

    krit: we could specify 120%. it's not nice though

    heycam: can't we just state it needs to be large enough so that
    it doesn't affect filter output?

    krit: If you use feFlood and it will fill the whole SVG file.
    ... could use the viewPort

    heycam: feFlood is a special case though
    ... why can't we say something like 'minimal area based on how
    that filter primitive is used in the filter chain'

    krit: Need to specify that content looks equal on all
    implementations

    heycam: I think that can be achieved by saying the filter
    primitive is big enough so that it doesn't look different
    ... when the element is rendered, there will be some clipping
    at some point
    ... then you can determine the smallest rectangle based on how
    it is used in the filter chain
    ... we can require UAs to generate the filter primitive at the
    required size

    krit: I agree. feFlood is still the problem though

    heycam: If you didn't have any other clipping, then feFlood
    would fill the viewport

    krit: Would have to check about breaking content

    heycam: do you feel we need to specify how to calculate the
    area for that primitive?

    krit: I think that's a good idea
    ... to ensure consistency between implementations

    heycam: I'd be fine if we had something like that written down.
    Do you want to do that?

    krit: yes

    <scribe> ACTION: Dirk to specify how to calculate automatic
    filter region for unbounded primitives [recorded in
    [14]http://www.w3.org/2013/08/15-svg-minutes.html#action02]

    <trackbot> Created ACTION-3518 - Specify how to calculate
    automatic filter region for unbounded primitives [on Dirk
    Schulze - due 2013-08-22].

Collapsing CSS Filter functions and the problem of color clamping on

    intermediate results

    krit: a lot of filter effects short hands can be represented
    with a color matrix
    ... ideally you can collapse the filter chain to a single
    operation on the matrix
    ... but we currently define that values should be clamped at
    each stage
    ... do we want to keep current behaviour or can we relax the
    specification to allow optimisation in this case?
    ... it's a balance between performance and ease of authoring

    heycam: is there a benefit to clamping at each filter? is that
    something authors would need or want?
    ... there are similar thinks in CSS with color values
    ... I can't remember where exactly but it talks about allowing
    values to go out of range and clamp in the final step
    ... so there might be precedence

    nikos: I think it would be confusing for authors to get
    different results depending on whether a shorthand is used or
    not

    heycam: my feeling is that we should allow intermediate results
    to go out of range and clamp at the end

    <krit> :D

    krit: initially I was for clamping at the end. Now i'm not
    sure. There are cases where you can guarantee that you don't
    need to clamp
    ... so I support clamping at each step now

    heycam: I can't see an author use for clamping each stage
    ... if there was one I think it would be better to have
    explicit control to opt in to that

    krit: there is another case. contrast 200% then another filter
    primitive with contrast 50% and they wonder why they don't get
    the same result
    ... it's a corner case though. I don't think it's actually
    useful to do that.

    heycam: I can imagine cases where an image has colour values
    that are almost fully bright and you apply a brightness filter
    and you want to clamp
    ... I'm not sure which I prefer

    krit: I think we should keep the clamping for now

    shepazu: I've seen some pretty crazy stuff come out of
    authoring tools

    heycam: I'm not sure how much performance benefit there is from
    collapsing down to a single operation on a colour matrix
    ... I think implementations often slow down with filters
    because they are creating lots of off-screen surfaces
    ... here that shouldn't matter as you can work on the same
    surface

    resolution: maintain clamping colour matrices for filter
    effects at each step in the filter chain

Geometry API and Accessible SVG Community Groups

    shepazu: there are 2 community groups you guys might be
    interested in

    1. SVG accessibility

    <shepazu> [15]http://www.w3.org/community/svga11y/

      [15] http://www.w3.org/community/svga11y/

    <shepazu>
    [16]http://www.w3.org/community/svga11y/2013/08/15/roadmap/

      [16] http://www.w3.org/community/svga11y/2013/08/15/roadmap/

    2. geometry API

    <shepazu>
    [17]http://www.w3.org/community/geometryapi/wiki/Use_Cases_and_
    Requirements

      [17] http://www.w3.org/community/geometryapi/wiki/Use_Cases_and_Requirements

    <shepazu> [18]http://www.w3.org/community/geometryapi/

      [18] http://www.w3.org/community/geometryapi/

    use cases and requirements doc (in progress)

    SVG accessibility is unclear. There's few normative
    requirements, a lot comes from the doc that Charles wrote about
    mapping and authoring guidelines

    shepazu: very old. refers to SVG 1.0
    ... After talking to accessibility experts. The state of SVG is
    ok, but there's a lot of tests that need to be run
    ... so the whole point of this group is to write tests and
    write requirements
    ... we're going to have a workshop/hackathon

    heycam: sounds good. for me I don't feel I have the knowledge
    to know what we need to change in SVG

    krit: who would attend the workshop?

    shepazu: there's about 16 people in the group now.
    ... we want: 1. Accessibility experts who can help us test. 2.
    People who use accessibility features. 3. SVG people
    ... and at least one 'testing' expert
    ... I gave a presentation about accessible data visualisation
    and people were really interested
    ... that's where this came from
    ... first step is to make a bunch of tests, run them and create
    an implementation report

    nikos: what's the make up of the group. Who do you need?

    shepazu: we have lots of interested accessibility experts.
    ... they should be able to find people who use accessibility
    features
    ... there's two or three people who are pretty good with SVG
    ... would be good to have Rich in the group
    ... looking for someone from Adobe
    ... I'm looking at September for the hackathon
    ... October at the graphical web would be good. Cyril, Tav, and
    Nikos will be there
    ... so we can chat about that and try to organise a time that
    is good for everyone
    ... The other group is the geometry API community group
    ... the goal there is to come up with a geometry api
    (SURPRISE!)
    ... we want to meet use cases for SVG primarily. But if we
    satisfies use cases for other web tech that's ok.
    ... I want to be able to do things like calculate intersection
    of shapes

    cabanier: Dirk and I signed up

    shepazu: If we can come out with a simple set of use cases and
    requirements that we might include in SVG 2

    krit: should get some SKIA guys in the group

    cabanier: is this part of SVG or is it just something that
    interfaces with SVG?

    shepazu: I guess you could interact with other web tech

    krit: it would be great to have a document that everyone could
    reference

    shepazu: it would be good to have more people in the group to
    define the use cases that are important
    ... it would be good to have a matrix library (SKIA has), point
    and vector maths
    ... need to drive requirements on those
    ... in conclusion. It would be good to get people into the
    groups to drive the conversation and keep them going

Summary of Action Items

    [NEW] ACTION: Cameron to organise FPWD publication of new
    matrix specification [recorded in
    [19]http://www.w3.org/2013/08/15-svg-minutes.html#action01]
    [NEW] ACTION: Dirk to specify how to calculate automatic filter
    region for unbounded primitives [recorded in
    [20]http://www.w3.org/2013/08/15-svg-minutes.html#action02]

    [End of minutes]


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, 15 August 2013 21:46:18 UTC