minutes, 8 January 2015 SVG WG telcon

Minutes for the telcon are here:

   http://www.w3.org/2015/01/08-svg-minutes.html

and below as text.



    [1]W3C

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

                                - DRAFT -

                     SVG Working Group Teleconference

08 Jan 2015

    [2]Agenda

       [2] http://lists.w3.org/Archives/Public/www-svg/2015Jan/0009.html

    See also: [3]IRC log

       [3] http://www.w3.org/2015/01/08-svg-irc

Attendees

    Present
           [IPcaller], ed, heycam, Doug_Schepers, stakagi,
           +1.425.463.aaaa, birtles, krit, Rich_Schwerdtfeger,
           cabanier, nikos, Tav, Thomas_Smailus

    Regrets
    Chair
           Cameron

    Scribe
           Cameron

Contents

      * [4]Topics
          1. [5]SVG 2 assessment
          2. [6]SVG Hinting
      * [7]Summary of Action Items
      __________________________________________________________

    <trackbot> Date: 08 January 2015

    <stakagi> zakim ??P5 is me

    <heycam> ScribeNick: BogdanBrinza

    First topic: transform on svg / ed

    <ed>
    [8]http://lists.w3.org/Archives/Public/www-svg/2014Dec/0003.htm
    l

       [8] http://lists.w3.org/Archives/Public/www-svg/2014Dec/0003.html

    The link clarifies the transform as a property

    though not clear how it should be applied

    how to put this on fragment for example

    birtles: So how to apply it to fragments?

    ed: Few option - apply inside/ outide svg

    if that's defined in style - apply this as part of normal SVG
    layout

    Firefox currently the only who does that as part of layout

    birtles: Useful distinction of style transform vs property

    ed: suggestion - so we need to describe in SVG spec how that is
    supposed to work

    2. we need to agree how it's supposed to work

    e.g. attribute should work the same as style transform

    have we discussed before the viewbox and the order of
    transforms on the element

    for example everybody agrees that porperty should apply as the
    attribute

    but if one has viewBox and transform - which order do those
    apply

    ed: Would expect transform spec should define this

    Dirk: can add this as it's currently does not mention SVG
    element

    * <svg> element

    SVG embedded in HTML is normal HTML element and outer transform
    would apply first then viewbox would apply to root element
    inside

    tav: that is easy way to describe this

    Dirk: <svg> is special because it has viewbox attribute
    ... but transform does nothing to <html> element

    and for <svg> that might be confusing

    So if I have a style on svg root that says transform: scale

    in HTML context that would be scaled and in standalone context
    wouldn't be?

    Tav: right

    but from authoring perspective it's inconsistent when it
    applies vs when it doesn't

    Tav: consider svg as a viewport on the other content, so
    transforms would apply outside

    We should do whatever html is doing for the root element - so
    <svg> should act as if transform is applied as to outside
    element

    and panning and zooming should be described in the same sense -
    not as changing viewport, but as a transform on the root

    <Smailus> Apologize... stuck in another meeting; will be on
    shortly.

    ed: the order of the transform does matter and there were some
    equations how we're supposed to zoom

    Eric do you know what implementation supports transform on svg
    element?

    As attribute only Firefox currently supports that, as style
    property - other browsers

    <ed> [9]http://jsfiddle.net/6pnnkoz3/5/

       [9] http://jsfiddle.net/6pnnkoz3/5/

    <ed> <svg style="transform:scale(2)">

    <ed> <circle cx="50%" cy="50%" r="25%" fill="blue"/>

    <ed> </svg>

    <ed>
    [10]http://lists.w3.org/Archives/Public/www-svg/2014Dec/0013.ht
    ml

      [10] http://lists.w3.org/Archives/Public/www-svg/2014Dec/0013.html

    <richardschwerdtfeger> ok

    <richardschwerdtfeger> next week it is

    Bogdan: looking at the sample IE is the same as Chrome and Eric
    mention other browsers as the same

    ed: the follow up is to agree that transform should apply from
    outside

    and both cases html/standalone should work the same way

    ed: would like to fix those resolutions

    Any objections to have property and style attrubute work the
    same on <svg> element and apply outside?

    (no objections)

    RESOLUTION: transform property applies conceptually to the
    outside of <svg> element and there is no difference between
    prsentation attribute and style property

    we can be more clear in SVG spec to call this as new feature

    also might be in transform spec as well

    <scribe> ACTION: ed to call out transforms working the way we
    resolved as new feature [recorded in
    [11]http://www.w3.org/2015/01/08-svg-minutes.html#action01]

    <trackbot> Created ACTION-3691 - Call out transforms working
    the way we resolved as new feature [on Erik Dahlström - due
    2015-01-15].

    <ed> #svgVIew(viewBox(...))

    ed: If you specify svg viewBox as attribute in style and
    transform all on root element

    how would that apply - in what order

    <ed>
    [12]http://lists.w3.org/Archives/Public/www-svg/2014Dec/0015.ht
    ml

      [12] http://lists.w3.org/Archives/Public/www-svg/2014Dec/0015.html

    this came as complaints from some old testsute

    correction: the above combination is of transform and fragment,
    not style attribute

    if you give transform fragment syntax and make this apply
    inside svg element

    this might be confusing on how this is supposed to work

    ed: the spec doesn't clarify how this is supposed to work
    especially in combination with viewBox

    currently if you specify fragment that would override transform
    you had, same should apply to viewBox

    what implementation support tranform on the root?

    ed: I would guess this would work like html root

    we need to know implementations that support transforms in
    fragment declaration and how this interacts with attribute

    ed: the worry is real usage - transform + svgView syntax

    how likely we'll see somthing like this?

    so we'd like to see what we all are doing here at the moment

    <scribe> ACTION: ed to get tests that would show what
    implementations are doing with transforms in fragments now
    [recorded in
    [13]http://www.w3.org/2015/01/08-svg-minutes.html#action02]

    <trackbot> Created ACTION-3692 - Get tests that would show what
    implementations are doing with transforms in fragments now [on
    Erik Dahlström - due 2015-01-15].

    <heycam> Scribe: Cameron

    <heycam> ScribeNick: heycam

SVG 2 assessment

    BogdanBrinza: I have a document that I want to put somewhere
    ... Rossen and I put this together
    ... we spent some time looking at the issues/actions
    ... we tried to put some "readiness" of different parts of the
    spec
    ... I want to put this document in front of us soon
    ... there are some big parts that have more
    problems/instability than others
    ... so I'd like to get some more attention to them
    ... the first chapter with the most issues is the Document
    Structure chapter
    ... specifically, <svg>, <desc>, <title> and Conditional
    Processing
    ... looks like it has lots of issues
    ... the next one is Text, and specifically shape-inside
    property
    ... next is Painting chapter, particularly dashing
    ... it looks like the new properties added have some issues
    that need resolving
    ... the last big one is Paint Servers; it doesn't have any
    particular area that sticks out, but the first half has a bunch
    of open issues
    ... I can put this spreadsheet on the wiki
    ... it would be worth looking at the specific issues and
    working to resolve them
    ... around 50 issues
    ... I'll follow up with specific issues on the mailing list

    Zakim: ack

    shepazu: I have some experience with wiki tables, if you send
    me the document I'll convert it into a wiki table quickly

    BogdanBrinza: off topic, we also made some progress on SVG
    Hinting
    ... with some specific proposals

    krit: I added/opened some issues on the GitHub page for the
    spec
    ... so that's also an option

    shepazu: yeah, I think it's a good idea to have this
    spreadsheet that summarises everything. but we should break it
    out.
    ... those things we all agree, we should break out to
    individual issues on the spec

    ed: Bogdan, you went through the spec; did you mostly look for
    issues called out in the spec? or were you looking for
    reviewing / finding issues outside of those already mentioned?

    BogdanBrinza: both
    ... we looked at the spec with fresh eyes
    ... there's a correlation; if there were issues called out on a
    section, then there were concerns we had already
    ... this came up particularly in the Painting chapter
    ... those comments will be in the spreadsheet

    ed: to the group: how do we want to handle FIXMEs in the spec?
    issues in the spec, or a bug tracker?

    heycam: I put issues inline in the spe

    spec

    scribe: but I don't mind them being tracked in GitHub issues or
    whereever

    Tav: I like them being in the spec

    krit: that's fine, but for issue discussion it's not good

    ed: the issue numbers change too

    heycam: we can keep the inline notes and link them to whereever
    we're having the discussion

    Tav: I'll be spending more time on spec editing over the next
    month

    <scribe> ACTION: Get the SVG 2 issues document on the wiki with
    Doug's help [recorded in
    [14]http://www.w3.org/2015/01/08-svg-minutes.html#action03]

    <trackbot> Error finding 'Get'. You can review and register
    nicknames at
    <[15]http://www.w3.org/Graphics/SVG/WG/track/users>.

      [15] http://www.w3.org/Graphics/SVG/WG/track/users

    <scribe> ACTION: Bogdan Get the SVG 2 issues document on the
    wiki with Doug's help [recorded in
    [16]http://www.w3.org/2015/01/08-svg-minutes.html#action04]

    <trackbot> Created ACTION-3693 - Get the svg 2 issues document
    on the wiki with doug's help [on Bogdan Brinza - due
    2015-01-15].

SVG Hinting

    BogdanBrinza: one thing Chris Lilley mentioned was how
    implementations depending on scale factors, non-integer pixel
    scaling issues
    ... one of the way to improve that was making sure paths/lines
    end up at integer pixels when you start or end the line/path
    ... that by itself would address a large body of the feedback
    ... likewise, we do want to prototype something to better align
    shapes
    ... including nearby shapes
    ... using some simple heuristics, e.g. if the shapes are
    grouped together with <g> you might try harder to ensure
    they're rendered at the same pixel

    shepazu: for example if there are two states with a common
    border, you want to signal that they share a common border if
    they're transformed

    BogdanBrinza: instead of signalling, you could know this by the
    document structure and ordering
    ... so an implementation detail on how we can improvde the
    rendering without requiring additional markup

    shepazu: you're saying do it automatically. would that be
    implementaiton specific? or would we specify that when things
    are grouped/transformed together, you should use this algorithm
    to make sure the pixels align

    BogdanBrinza: the latter is definitely preferable
    ... before speccing, prototyping would be good to see how well
    it works

    shepazu: speccing for interoperability, which would be great,
    in addition to implicit signals we should have an explicit
    signal because when you're structuring a document you're
    structuring for different reasons
    ... you could need to have shapes in different groups for
    certain reasons

    BogdanBrinza: I would agree with that, yes
    ... we've been looking at a look of CSS/HTML compat issues
    ... authors are trying to align things but don't get it exactly
    right
    ... but yes some authors might want explicit control for this

    shepazu: or just optimise according to different signals than
    the default

    Tav: would be good to have before and after images

Summary of Action Items

    [NEW] ACTION: Bogdan Get the SVG 2 issues document on the wiki
    with Doug's help [recorded in
    [17]http://www.w3.org/2015/01/08-svg-minutes.html#action04]
    [NEW] ACTION: ed to call out transforms working the way we
    resolved as new feature [recorded in
    [18]http://www.w3.org/2015/01/08-svg-minutes.html#action01]
    [NEW] ACTION: ed to get tests that would show what
    implementations are doing with transforms in fragments now
    [recorded in
    [19]http://www.w3.org/2015/01/08-svg-minutes.html#action02]
    [NEW] ACTION: Get the SVG 2 issues document on the wiki with
    Doug's help [recorded in
    [20]http://www.w3.org/2015/01/08-svg-minutes.html#action03]

    [End of minutes]

Received on Thursday, 8 January 2015 21:37:03 UTC