minutes, SVG WG Leipzig F2F 2014 minutes, day 1



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

                                - DRAFT -

                     SVG Working Group Teleconference

07 Apr 2014


       [2] https://www.w3.org/Graphics/SVG/WG/wiki/F2F/Leipzig_2014/Agenda

    See also: [3]IRC log

       [3] http://www.w3.org/2014/04/07-svg-irc


           Cameron, Rik, Dirk, Chris, Satoru, Erik, Brian,
           David_Vest, Tav, Nikos, Philip_Rogers


           birtles, Cameron


      * [4]Topics
          1. [5]Charter
          2. [6]ISSUE-2364: SVG2 has not yet defined whether a root
             element can act as a proximal event target
          3. [7]SVG Sizing
          4. [8]overflow, clip on viewport creating SVG elements
          5. [9]bbox for text calculations
          6. [10]white space in attributes
          7. [11]Media queries in switch
      * [12]Summary of Action Items

    <trackbot> Date: 07 April 2014

    <ChrisL> interesting font demo

      [13] http://www.babelstone.co.uk/Fonts/ThrorsMap.html

    <ChrisL> [14]http://libregraphicsmeeting.org/2014/program/

      [14] http://libregraphicsmeeting.org/2014/program/

    <birtles> Scribenick: birtles

    <scribe> Scribe: birtles


    <ChrisL> [15]http://www.w3.org/Graphics/SVG/2012/charter

      [15] http://www.w3.org/Graphics/SVG/2012/charter

    ChrisL: our charter has expired just recently
    ... that's not a problem
    ... it was pointed out that it was expiring
    ... but there seemed to be no concern
    ... I suggest we ask for the same charter as the current but
    with minor updates
    ... if we've added/dropped specs, changed WG liaisons
    ... we need update that
    ... I suggest we drop liaison from XML Core
    ... they're not developing any new features, at least none we
    care about
    ... we might want to add some new liaisons
    ... now sure about Oasis, not sure if we're doing anything
    ... we've got EPUB but we might want to add the interest group
    ... there seems to be a lot of activity there at the moment
    ... we should get requirements from them
    ... they are mostly feeding into CSS but they might have some
    for us
    ... most of the other groups are still going
    ... we have ICC but I wonder if we should have OpenICC too
    ... it's an organisation but not as formal as ICC
    ... we have MPEG listed (for SVG-in-OpenType)
    ... but the rest looks ok but we can drop the Hypertext
    Coordination group

    heycam: what about the P&F WG

    ChrisL: we should keep that liasion
    ... the work on accessibility in happenning in the SVG WG

    krit: our charter is not compatible with the PF WG
    ... the work should go on there, our goals are not aligned

    heycam: we discussed that recently in the telcon
    ... and said it doesn't really matter where it happens
    ... but some on the mailing list said that it would be better
    if those specs where published by bother groups
    ... like we do for FXTF
    ... for patent coverage
    ... the proposal was for there to be a join TF but the
    documents would be published under the PF WG

    ChrisL: what was the reason?

    heycam: for simplicity and since that item isn't under our
    current charter
    ... but given we're rechartering...

    ChrisL: we do have an item like that under our charter

    krit: yes

    ChrisL: there has been other work on accessibility that is
    going into the SVG spec itself
    ... what do they want? another note?
    ... does their document add new features?

    heycam: I think the primary purpose is to describe the mapping
    of SVG features when you don't use aria-role
    ... in HTML they have a table for that
    ... I think they want that for SVG

    ChrisL: why don't we just add it to SVG?

    krit: for HTML I think it's a separate spec

    cabanier: I think they have both

    krit: there is some separate document

    ChrisL: if they want to write a non-normative document with
    guidelines that's fine
    ... I'm concerned about them changing SVG

    heycam: I think it would be normative text

    krit: I would be concerned if we need to join PF WG just to
    work on this doc

    heycam: if there's a TF there should be public mailing list

    ChrisL: it should be a public mailing list

    heycam: so should we go back and add this to our charter since
    we're rechartering?

    ChrisL: I think that sounds good
    ... what's the title of the document

    heycam: SVG2 Accessibility User Agent Implementation Guide
    ... there is a stub document



    <scribe> ACTION: ChrisL to update the charter [recorded in

    <trackbot> Created ACTION-3601 - Update the charter [on Chris
    Lilley - due 2014-04-14].

    <scribe> ACTION: ChrisL to talk to Michael Cooper about UAG
    [recorded in

    <ChrisL> deliverables www.w3.org/Graphics/SVG/2012/charter

    <trackbot> Created ACTION-3602 - Talk to michael cooper about
    uag [on Chris Lilley - due 2014-04-14].

    ChrisL: here's a link to the previous charter's deliverables
    ... it listed SVG2
    ... what about SVG Parameters
    ... has that gone away since CSS variables came about?

    heycam: SVG parameters can do slightly more but I'm not sure
    there's enough push to do SVG parameters as well
    ... can be have a section on things we might work on

    ChrisL: yes, we can have "will work on if time" specs
    ... SVG integration: we still haven't published that
    ... there has been discussion of that recently

    krit: I don't think it has sufficient security support to
    publish a FPWD yet
    ... we need to fix the issues first then we should publish it

    heycam: so it should stay in the list

    ChrisL: for color management we will keep it in SVG2 for now
    since the separate spec hasn't been taken up by CSSWG yet
    ... join work recommendations...
    ... what about css animations and web animations, does one
    replace the other or do both get published in parallel?

    krit: yes, both in parallel

    ChrisL: then we should add web animations here

    nikos: we should update the links to the compositing spec

    <nikos> [19]http://www.w3.org/TR/compositing-1/

      [19] http://www.w3.org/TR/compositing-1/

    birtles: we should also probably add animation elements:
    ... it's paused at the moment
    ... but we decided it should go under the SVGWG

      [20] https://svgwg.org/specs/animation-elements/

    ChrisL: tiling and layering, did that get added to SVG2?

    heycam: part of it has, like the iframe stuff
    ... the media query stuff has been shunted off to the CSS
    working group

    stakagi: the zooming module is yet to be added

    heycam: I think that is covered by the media query work
    ... is there anything else?

    stakagi: that's all

    heycam: so there's no separate document for tiling and layering
    since it is all in other specs?

    stakagi: not at this stage

    heycam: do we need to say where previous items have ended up?

    ChrisL: that can be in a separate document linked to from the
    ... how about vector effects?
    ... nothing has happened in the last two years
    ... are implementors interested in it?

    pdr: what about the non-scaling stroke discussion

    ChrisL: we currently have that as the only vector effect, less
    interest from browsers in doing the full flexible syntax

    krit: I don't think it's going to happen in the near future
    ... the current priorities are performance and interoperability

    (discussing the element-based syntax for vector effects from
    SVG 1.2 full)

    ed: there is a standalone spec for this too



    ChrisL: there are a number of new elements similar to fe but ve

    krit: but many of these things can be done with

    ChrisL: we seem to be carving off canned effects and putting
    those in directly
    ... which is better than nothing

    krit: we have currentFill etc. are now in SVG2 right?

    heycam: yes

    ChrisL: so should we just drop this for now?

    heycam: my preference it to keep pushing forward with canned
    ... since it's easier to handle from an implementation point of
    ... the element syntax feels heavy weight and I think has held
    back filter effects adoption

    krit: I agree, the elements worry me

    ChrisL: is it easier to implement...

    heycam: it's easier to implement both because the set of
    features covered is smaller but also you don't have to track
    changes to all these different elements

    ed: so the path reversal is in Path2D?
    ... I think having a javascript API for this is useful I think

    krit: does that need to be native though?

    Tav: it would be good to be able to share path edges in a
    declarative way
    ... the other thing we most often get asked for is offsetting
    the stroke

    heycam: last time we discussed path referencing was at TPAC
    last year
    ... and Cyril had a proposal for a piece command using an ID

    nikos: that didn't actually give you shared edges
    ... it let you re-use path edges but it didn't actually share

    ChrisL: so let's remove vector effects as a separate work item
    ... rename SVG accessbility item to the SVG2 User Agent
    Implementation Guide
    ... about graphics API?

    heycam: I think that was Doug's idea of an API like canvas that
    could either produce immediate canvas or declarative graphics

    ChrisL: that's clearing not happenning so let's drop it
    ... connectors?

    Tav: I worked on it a little bit

    ChrisL: should we keep it around?

    Tav: yes, I'd like to

    ChrisL: layout (new)?

    heycam: I wrote up the requirements but I haven't had a chance
    yet... might do in the next 2 years though, I'd like to keep it

    ChrisL: SVG Glyphs for OpenType Font
    ... the group has formed and passed its work onto the ISO group
    and then shut down
    ... so we should just keep it as a liaison
    ... so remove SVG Glyphs for OpenType Font line item
    ... pagination and slides?

    heycam: that was part of the SVG print spec?

    ChrisL: I saw something about that in the Inkscape meeting

    Tav: I had a number of people asking about multi-page SVG
    ... there's demand for it
    ... I did my presentation with JessyInk which splits up the
    graphic into slides

    ChrisL: there is clearly a need for it

    Tav: I might work on it


      [22] http://dev.w3.org/SVG/modules/mae/master/MediaAccessEvents.html

    heycam: if someone might work on it, we should keep it

    ChrisL: media access events
    ... none of the editors are in the WG
    ... the spec hasn't been updated for 6 years
    ... it appears to be totally different to what's happenning in
    the WebApps WG
    ... we should drop it

    heycam: should we publish as a note?

    ChrisL: yes, publish as a note and drop

    <scribe> ACTION: Cameron to publish media access events as a
    note [recorded in

    <trackbot> Created ACTION-3603 - Publish media access events as
    a note [on Cameron McCormack - due 2014-04-14].

    ChrisL: we have Japanese text layout requirements
    ... that is now published and is finished
    ... I don't think it needs to be on the charter now since it's
    ... since there are now other requirements docs that are coming
    out (Latin text - EPUB, Indic etc.)
    ... I think it's difficult to get all the requirements
    ... but we're not involved in these

    heycam: are these mostly to do with text or do they involve
    graphics too?

    ChrisL: it's mostly text
    ... anything else to add?

    heycam: what about the maintenance ones?
    ... should they continue to be there?

    ChrisL: yes, they will

    heycam: can we remove the completed ones?

    ChrisL: we should keep them since we might need to publish
    updated versions
    ... any other documents to add?

    krit: what about the geometry API?
    ... Rik, Simon Pieters from Opera, and I are working on another
    ... it hasn't been published as a WD yet
    ... it's an FXTF spec

    <krit> Geometry interfaces module:

      [24] http://dev.w3.org/fxtf/geometry/Overview.html

    heycam: in the decision policy section in the charter
    ... we talked about asynchronous decision making recently

    ChrisL: I have wording prepared for that
    ... would that be suitable?

    heycam: sounds good

    ChrisL: there's a roadmap page on the wiki


      [25] https://www.w3.org/Graphics/SVG/WG/wiki/Roadmap

    ChrisL: we need to, as a group, keep it up to date

ISSUE-2364: SVG2 has not yet defined whether a root element can act
as a proximal event target

    ed: the question is "should the SVG root be a target for
    pointer events"
    ... we never defined it
    ... we purposely made it undefined in 1.1
    ... we said "we should define it properly in SVG2"
    ... (it relates to whether you can click the viewport)


      [26] https://svgwg.org/svg2-draft/interact.html#PointerEventsProp

    <ed> [27]https://svgwg.org/svg2-draft/interact.html#hit-testing

      [27] https://svgwg.org/svg2-draft/interact.html#hit-testing

    ed: actually section 17.5.1 ^
    ... last paragraph

    "This specification does not define the behavior of pointer
    events on the rootmost ‘svg’ element for SVG images which are
    embedded by reference or inclusion within another document,
    e.g., whether the rootmost ‘svg’ element embedded in an HTML
    document intercepts mouse click events; future specifications
    may define this behavior, but for the purpose

    of this specification, the behavior is

    scribe: this wording is from the 1.1 spec

    krit: is SVG image something you embed in the HTML document?

    heycam: for <img> the whole rectangle it needs to capture
    clicks on the whole rectangle

    ed: this is about inline sVG

    ChrisL: clearly the wording here is confusing

    heycam: we should define both scenarios anyway

    <stakagi> iframe?

    ed: we need to define the behavior for all scenarios

    krit: should this definition go into SVG2 or is it fine to have
    in the SVG2 integration spec?

    heycam: some stuff still should go in SVG2 such as standalone
    SVG documents
    ... the other cases (inline, reference by image, iframe etc.)
    should probably be covered in the SVG integration spec
    ... what do implementations do at the moment for top-level

    ed: I think it differs... I think you can use pointer-events
    but the default setting is different
    ... I've mostly tested inline

    <scribe> ACTION: Erik to prepare spec text for pointer-events
    on root SVG elements for SVG2 and SVG Integration spec and make
    edits [recorded in

    <trackbot> Created ACTION-3604 - Prepare spec text for
    pointer-events on root svg elements for svg2 and svg
    integration spec and make edits [on Erik Dahlström - due

    ed: do we need to introduce new keyword values?
    ... bounding box is probably not the right word

    heycam: probably
    ... would it be safe to have pointer-events on the root SVG
    element catch events by default?

    ed: it's currently not defined

    krit: It might already work like that

    ed: we need spec text anyway
    ... if I find we need a new keyword I'll propose one but I
    think it's preferable if we don't

    heycam: looks like it already does that in Firefox and Chrome

    krit: and webkit

    ed: so we just need to define that


SVG Sizing

    <heycam> presentation


    davvel (David Vest): I prepared some slides to introduce the

    scribe: it's about integration of SVG/CSS, how to compute the
    viewport size
    ... both the inline case and the external case

    (goes through the slides)

    scribe: case 1: SVG has no fixed width/height, but has a fixed
    size container

    ChrisL: I understand what Firefox does, but not why the other
    browsers using the containing block

    davvel: I think it's because the default width/height of the
    SVG is 100%

    ChrisL: so they're assuming the percentages are CSS percentages
    when the spec says they're not

    davvel: Case 2: width only with viewbox
    ... (i.e. intrinsic ratio)

    ChrisL: I think Firefox is doing what the spec says

    pdr: the specs are inconsistent here
    ... there's no correct solution since there are several
    contradictory specs

    davvel: Case 3: external reference, intrinsic ratio, specified

    heycam: did you test with iframe (test case uses object)?
    ... it might differ

    davvel: I did test with iframe and yes, the behavior was
    different but I think it should not be
    ... the results here are totally different
    ... I've been using the CSS replaced element algorithm as the
    starting point and SVG and providing input to this algorithm

    (goes through slides about intrinsic size, ratio etc.)

    pdr: how do browsers calculate the intrinsic ratio? using the
    viewBox as you say?

    davvel: mostly, IE sometimes doesn't

    (discussion about the Web compatibility of percentage
    width/height and why these percentages were defined to be
    different to CSS percenatges)

    Mozilla bug:

      [30] https://bugzilla.mozilla.org/show_bug.cgi?id=668163

    pdr: I think this proposal is based on the assumption that NOT
    mapping SVG width/height to CSS properties is not
    ... and I'm not sure if that's still the case

    ChrisL: there was also a push to map more attributes to
    properties for animation purposes

    davvel: it would be good if we don't have to map width/height
    to properties

    (continuing with presentation)

    krit: with your proposal, the SVG inline case is the same as
    the SVG image case

    heycam: what of the comments Jonathan Watt made was, "does that
    really make sense"?
    ... for externally referenced files is it sensible to say "this
    document should take up such-and-such a percentage of where it
    is embedded"
    ... since you might embed it in different places
    ... I think this proposal makes it eaiser for authors to
    understand what's going on
    ... but I'm not sure it makes sense

    davvel: in the Webkit/Blink test suite if you have a percentage
    on an externally referenced SVG it uses it twice
    ... IE does it too

    krit: I like that this proposal lets you choose between the
    different behaviors

    ChrisL: also auto is a new value so there shouldn't be a
    compatibility issue

    pdr: I think auto is somewhat confusing but if this gets us
    consistent behavior I'm in favour
    ... I actually support the presentation mapping. I *didn't*
    agree with your reasoning for it, but I support the mapping

    (discussion about the original problem case)

    heycam: I think in this case the author doesn't want the image
    to fill up the whole containing block, they should have to mark
    that up specifically

    pdr: do you think they wanted 350px150px in that case?

    heycam: no, I think they didn't say what they wanted

    davvel: but in that case an iframe would be 300x150 px

    heycam: and it would be good to be consistent with that
    ... there are no other cases where without an explicit
    indication the content fills up the whole containing block

    pdr: there seems to be consensus that davvel's proposal seems

    birtles: I find the mapping of width/height to be helpful from
    a authoring point of view

    ChrisL: I want SVG to be scalable by default

    pdr: so this proposal is different in that by default it would
    fit to 350px x x150px

    krit: I think the behavior is not always great for the user but
    the consistency is important

    pdr: what changes are required for this to happen? any changes
    to CSS?

    davvel: no

    ed: what about the changes to CSS 2.1 where it is currently
    suggestion but should be a requirement?

    (currently the used value of width in 10.3.2 is undefined and
    then subsequently defined)

    ChrisL: I'd like to run it by Tab since I've heard him talk
    about this before

    <scribe> ACTION: ChrisL (or pdr) to get Tab's feedback on
    davvel's SVG sizing proposal [recorded in

    <trackbot> Created ACTION-3605 - (or pdr) to get tab's feedback
    on davvel's svg sizing proposal [on Chris Lilley - due

    heycam: if percentages can be resolved to something, can they
    give you the intrinsic size of the SVG?

    davvel: no, that's what we want to get rid of

    heycam: can percentages in an external document be sensibly
    used when you don't know where it will be embedded?
    ... it might not always make sense, but I think it's preferable
    to be consistent
    ... I don't think there's any other reasonable thing to make
    those percentages mean

    ChrisL: if you want to make some SVG is scalable, then you put
    a viewbox and you either say nothing for width/height or use

    davvel: that's right
    ... for the width it will go as big as it can
    ... and for the height it will use the intrinsic ratio to
    calculate it

    ChrisL: if you want to make something a fixed size then you
    simple say width:3.5in etc. and it will work as expected

    davvel: right

    ChrisL: they are the only use cases that matter
    ... percentages other than 100% never made sense
    ... the third use case is to make stuff which does not preserve
    its aspect ratio (e.g. backgrounds)

    (discussion how this is possible with preserveAspectRatio and
    100% width/height etc.)

    ChrisL: we need a test suite with all the permutations

    davvel: I already have that

    birtles: are they in a format we can automate?

    davvel: I've used the web platform system for <object> tests

    ChrisL: are you familiar with the CSS system (Shepherd etc.)?
    It's pretty neat
    ... I've spoken to Peter Linss about this to do one-off
    conversions so that the database of properties includes SVG

    heycam: I think he may have already done this

    ChrisL: then you can go from properties to the tests that cover

    heycam: for the case where containing div has width/height auto
    (and auto all the way up), and SVG has no width/height but has
    a viewbox, what is the behavior?

    davvel: it will use the viewport width

    heycam: how far is IE from this proposal?

    davvel: currently pretty far

    RESOLUTION: Unless there is feedback to the contrary (e.g. from
    Tab), accept David Vest's SVG sizing proposal

overflow, clip on viewport creating SVG elements

    ed: this came from from a webkit bug
    ... it relates to whether or not you can specify
    overflow:visible on inline SVG
    ... which I think IE does by default
    ... which is different to other browsers which clip by default

    heycam: what is the initial value for overflow?

    ed: it's complicated
    ... lots of cases


      [32] https://svgwg.org/svg2-draft/masking.html#OverflowProperty

    ed: if you have a standalone SVG document, currently all
    browsers clip to the viewport
    ... do we want to allow SVG to apply overflow to standalone

    heycam: does HTML have an equivalent?
    ... if you replace the SVG document with a paragraph that has
    some overflow
    ... what if you put width/height properties on the root <html>
    ... what does that mean for things rendered outside that?

    davvel: the default is visible

    ed: that's the default in CSS

    heycam: then we should do that same

    pdr: is that Web compatible?

    krit: the question is really whether it should be controllable
    or not, not what the default should be
    ... in SVG we have clip and overflow and the clip property
    clips to the viewport as its initial value

    ed: I think it only applies with overflow:hidden etc.

    krit: I think they're independent
    ... so even if you say overflow:visible it will still be
    clipped due to the clip property
    ... and CSS masking removes this
    ... so it allows the use case ed brought up
    ... so we need to do more work on the definition of the
    overflow property

    ed: the second thing I wanted to ask was about overflow:auto in
    SVG is defined to mean visible
    ... but in CSS it is suggested to clip to the region and use

    heycam: it makes more sense to treat it as hidden rather than
    visible since in CSS you never paint outside the region since
    you have scrollable regions

    ed: how do we want to treat overflow-x/y?
    ... these are independent so you can have overflow in just one

    heycam: CSS defined some combinations of overflow that don't
    make sense
    ... do we want those in SVG?
    ... I think you can have both visible/hidden but some
    combinations of scrollable don't make sense
    ... I would like overflow-x/y to be useable in SVG

    (break, lunch: 1hr)

    <cabanier> scribenick: cabanier

    ed: IE has the root as visible
    ... other say SVG root overflow should be hidden

    <heycam> in Firefox's UA style sheet: svg:not(:root) {
    overflow: hidden; }

    krit: that is strange because the spec says overflow hidden
    ... we should say that all svg should say hidden

    heycam: I think if we can get away with adding new rules

    ChrisL: it's the only way to add a new value

    heycam: so IE allows overflow visible on the root?

    <pdr> Blink's UA styleshee as wellt: svg:not(:root) { overflow:
    hidden }

    heycam: for outer most svg elements that are inline

    krit: the spec says that the root should be visible so IE is


      [33] https://svgwg.org/svg2-draft/masking.html#OverflowProperty


      [34] https://svgwg.org/svg2-draft/intro.html#TermRootmostSVGElement

    ed: no, this is for the root-most/outer-most element

    <pdr> Previous discussion on this from 2008:


    ed: it doesn't necessarily mean the same thing
    ... we want to be able to allow to override overflow
    ... at the moment, firefox, chrome and webkit all do overflow:

    cabanier: can you override it?

    ed: yes
    ... in IE you can say
    ... in other browser you can specify it but it doesn't work

    heycam: exactly how the spec defines this will depend on the
    next topic

    RESOLUTION: outer-most svg elements of inline fragments will be
    overflow: hidden by default
    ... overflow should not be ignored for outer-most SVG elements
    for both inline and standalone cases

    heycam: we talked about scrollable viewport in switserland
    ... to do zoom and pan
    ... to have scrollable viewport

    krit: we had requests from google to have scrollable content

    pdr: how is this applicable to mobile browser

    heycam: this is for all elements

    cabanier: so not just the root?

    heycam: inner SVG elements

    krit: not on symbol for instance, only viewport creating

    pdr: my concern is that this is a graphics format

    heycam: you can do this to with foreignobject

    ChrisL: scrollable has historically been a difference between
    css and html

    pdr: I agree

    ChrisL: it would be good to be able to request scroll bar
    ... I've seen people create scrollbars in svg

    heycam: maybe people used to write whole applications in svg

    ed: today scroll and hidden means the same
    ... if we allow scrollbars, does CSS do anything with that

    heycam: the specs don't say anything

    ed: maybe it's up to the user agent to decide

    krit: it's up to the UA to decide

    pdr: will the width have the ... (?)

    krit: filters can paint outside the boundingbox

    <pdr> The issue of what determines the width: which bounding
    box do we use?

    heycam: if you have contents that will scroll, you'd have to
    anticipate that
    ... today you can have scrollbars on a standalone doc

    ed: but not inside the document

    davve: there is something with background

    heycam: is anyone thinking it's bad idea to have scrollable

    ed: would it ever be a pannable viewport, or would it be the

    heycam: css needs a way for viewports to scroll beyond their
    viewport region
    ... that might be a way to do arbitrary panning
    ... panning could use viewport scrolling, but not just yet

    ed: can we put that off?

    heycam: that's ok for me

    RESOLUTION: svg:svg elements should allow overflow: scroll to
    create scrollbars

    krit: where does the origin of this viewbox come from

    pdr: I don't think there's a way to set it to negative

    heycam: if you have a viewbox [10 10 20 20]

    krit: maybe we don't want scrolling but panning

    cabanier: how about the size of the scrollable area

    krit: yes, that needs to be decided

    pdr: what is the bounding box of this thing?
    ... html has the inner and outer box
    ... or something to that effect

    heycam: we still need to define what those CSS properties such
    as offset width means for SVG

    krit: maybe take viewport?

    heycam: maybe we don't need to delve into the details
    ... how about for outermost inline SVG elements?

    ed: every browser clips today

    heycam: maybe overflow isn't the right thing to cause this
    clipping to happen
    ... maybe there should be no way to affect the rendering

    ed: do we want allow that to happen?

    heycam: if scrollbars can appear (?)

    ed: is there ever a use case to not have scroll bar

    heycam: would you ever want the content outside of a short SVG
    to be painted?

    ChrisL: maybe if you have a symbol?

    Tavmjong: we talked about this in a telecon
    ... andreasa asked for that

    ChrisL: scroll bars in symbols would be bad

    heycam: we need to have some wording there

    ed: today we imply that there should be scroll bars for
    standalone svg elements

    heycam: we still need some wording for short svg's to be

    RESOLUTION: overflow property on root svg elements still
    controls if there should be scrollbars but there should be a
    clipping rectangle that
    ... is the size of the svg element's viewport

    ed: the current spec says that within SVG content the value
    'auto' means visible
    ... should we change that

    heycam: it might be if we can come up with a solution
    ... for instance if the appearance of scrollbars makes things
    ... noone's using auto today so it would be safe to use it

    ed: do we want to keep the spec or should we change it?

    heycam: if we allow for scrollable viewports it makes sense to
    change it
    ... for viewport establishing elements where scroll bars don't
    make sense, overflow:auto would be visible
    ... for svg:svg, auto will mean scrollbars will appear if the
    overflow region is bigger than the viewport

    pdr: why are marker and pattern different?
    ... we are adding special cases for certain elements

    heycam: one reason is that these elements are not rendered

    krit: it makes it more compex for instance on patterns. because
    you have to calculate how you tile them

    heycam: how about mask?

    pdr: yes, that wouldn't make much sense

    krit: how about 'element()' in firefox, would it copy the
    scroll bars?

    heycam: I believe so yes
    ... we need to add a bunch of spec text to make sure that a
    pattern with overflow:hidden does the right thing
    ... I worry about getting the coordinate system right

    pdr: maybe it's best to get some implementor feedback

    heycam: you can have an issue in the spec and wait for that

    <scribe> ACTION: ed to figure out the overflow behavior in SVG
    [recorded in

    <trackbot> Created ACTION-3606 - Figure out the overflow
    behavior in svg [on Erik Dahlström - due 2014-04-14].

    heycam: we need to work out or put an issue in the spec whether
    that patterns have scrollable viewports

bbox for text calculations


      [37] http://lists.w3.org/Archives/Public/www-svg/2014Mar/0030.html

    ed: we discussed this on a call but didn't come to a conclusion

    ChrisL: I had some comments
    ... the full glyph cell is not the ink bounding box

    heycam: is it origin + ascent + descent

    ChrisL: full glyph cell is adding rectangles, is to use all
    ... do we need bounding boxes for hit detection and text
    selection? I think not

    nikos_: how about negative advances?

    ChrisL: the advance is separate from that

    heycam: it sounds like we do need different bbox's because some
    glyphs might go over and you don't want to select them

    ChrisL: in practice people put transparent rects on top of the

    <ed> [38]http://jsfiddle.net/L7pgW/18/

      [38] http://jsfiddle.net/L7pgW/18/

    ed: I made some examples

    krit: the italic is the browser?

    ed: yes.

    <ed> [39]http://jsfiddle.net/L7pgW/22/

      [39] http://jsfiddle.net/L7pgW/22/

    ed: this is a case where the gradient is started where the
    character starts
    ... filters have this issue too

    heycam: we talked about these for stroke/mask bbox
    ... should we extend this to extent for ink coverage

    tbah: what you might want it the bbox and the (?)
    ... (conversation about using em to size a gradient)

    ed: as an author I would expect the gradient to fill the
    bounding box

    heycam: do we have interoperable behavior?
    ... for what the size of the bbox is?

    ed: no

    heycam: the dictionary to getbbox can included stroke and
    markers but not for the ink coverage
    ... one option is to union the ink region and the glyph cell
    ... the other is just to get the tight bounding box
    ... it's possible to extend the dict for horizontal and

    ed: I would like getbbox to return the ink coverage
    ... most of the time you want to know what is drawn

    heycam: we already have that information

    ed: yes, you need to know where things were

    heycam: we use the lose ink bounds
    ... the tight glyph bounds might be more expensive
    ... we should do the union of the glyph boxes and the ink

    tbah: that should catch the majority of the use cases

    how about japanese text

    scribe: all glyphs are the same size

    <scribe> ACTION: getBBox and resource bounding box (for
    gradients, mask, etc) to return the union of the glyph cells
    and ink extends by default. [recorded in

    <trackbot> Error finding 'getBBox'. You can review and register
    nicknames at

      [41] http://www.w3.org/Graphics/SVG/WG/track/users%3E.

    RESOLUTION: getBBox and resource bounding box (for gradients,
    mask, etc) to return the union of the glyph cells and ink
    extends by default.

    heycam: do we allow control to get just the ink extends?

    ed: can we reuse the same method?
    ... we have a method called getTextExtend



    ed: do we need to make getBBox more complex or rely on these

    heycam: are you leaning towards not extending getbbox?

    ed: if so, we should be able to do the same on gradients, for
    instance gradientUnits="some_new_value"

    heycam: maybe we can ignore that for now since it complicates
    the API

    nikos: most cases where you want the tight box, you might want
    to hit test against it too

    ed: I could go with a clarification

    RESOLUTION: for now we won't provide APIs for a tight ink
    bounding box on text for getBBox or gradient object bounding
    box or hit detection

    ed: are text decoration part of the bbox?

    krit: CSS had discussions on this
    ... right now css doesn't gradients, just color

    heycam: the boundingbox in that case is the element
    ... an underline could go outside of the element
    ... it makes sense to include them

    krit: then there would be 2 definitions of bounding box

    heycam: I don't want decoration to be painted differently

    <ed> [43]https://svgwg.org/svg2-draft/text.html#TextDecoration

      [43] https://svgwg.org/svg2-draft/text.html#TextDecoration

    RESOLUTION: text decoration to be included in the bounding box



    <heycam> [45]http://dev.w3.org/csswg/css-inline/

      [45] http://dev.w3.org/csswg/css-inline/

    (krit discussing issue with text baselines, etc)

    <ed> ACTION: ed to do spec edits for bounding boxes of text
    elements: give the union of full glyph cells and the painted
    area, and include text decorations in the bbox (change for
    getBBox too) [recorded in

    <trackbot> Created ACTION-3607 - Do spec edits for bounding
    boxes of text elements: give the union of full glyph cells and
    the painted area, and include text decorations in the bbox
    (change for getbbox too) [on Erik Dahlström - due 2014-04-14].

    <ChrisL> ideographic = descender depth

    <ChrisL> alphabetic = 0

    <ChrisL> central = (ascender height - descender depth) / 2

    <ChrisL> middle = x height / 2

    <ChrisL> these seem good fallback definitions we could reuse

    <scribe> ACTION: krit to talk to Alan Stearns about adding
    fallback baseline calculations to the CSS line layout spec and
    if they will stay in the spec [recorded in

    <trackbot> Created ACTION-3608 - Talk to alan stearns about
    adding fallback baseline calculations to the css line layout
    spec and if they will stay in the spec [on Dirk Schulze - due

    <heycam> Scribe: Cameron

    <heycam> ScribeNick: heycam

white space in attributes



    ed: I went through all the attribute types we use in SVG, made
    a big table summarising
    ... I was looking for whether trailing/leading white space is
    allowed and ignored
    ... comparing with HTML5
    ... it's inconsistent, but at least for some of the numerical
    types it should be possible to make it consistent
    ... we discussed this in a telcon, and I went over it once more
    to add test cases for each of the subsections
    ... we could go through each type by type and see the test

    <ed> [49]http://jsfiddle.net/wxJa9/

      [49] http://jsfiddle.net/wxJa9/

    ed: this is for <number>
    ... there aren't many of these in HTML
    ... the only ones I could find are on <input>

    ChrisL: is HTML5 the right thing to be comparing to here?
    ... and not CSS properties?

    heycam: these are all non-CSS property attributes we're looking

    ed: this example is inconsistently handled across browsers
    ... HTML5 has different constraints for validators vs browsers
    ... for the content to be valid, it has to be a proper number
    in the right format and without any garbage or white space
    ... but for display, it strips away the white space and junk
    ... and returned in a correct form if you ask for it in the DOM
    ... even in HTML5 this example doesn't work the same way across
    ... for integer values it's a bit more consistent
    ... in the first section I listed the browsers I tested
    ... Firefox/Chrome/Presto did not allow white space and
    garbage; IE did allow white space and garbage

    <ed> [50]http://jsfiddle.net/hxz46/

      [50] http://jsfiddle.net/hxz46/

    ed: that's the SVG test case
    ... here Firefox/Chrome do not allow the white space and
    garbage; IE allows white space but not garbage, Presto allows

    <ChrisL> <input type="range" step=" 500e-3nord" min="0"
    max="10"/> works

    pdr: in these examples this is not stripping white space in the
    ... so only leading and trailing white space
    ... is that your intention?

    ed: we could add tests for those
    ... so the first question is do we want to allow white space
    and garbage

    ChrisL: for garbage, that would probably have different levels
    of support

    ed: the HTML5 parsing algorithm does allow it

    heycam: so IE is the only one following the spec

    krit: for things that just take numbers, WebKit/Blink are
    ... that's how we do the parsing in SVG

    ed: I looked at the functions in Blink, and it's passing a flag
    whether to allow it

    ChrisL: if HTML5 defines what to do with numeric attributes,
    then following the exact same algorithm makes it convenient
    ... it's slightly worrying that only one browser implements

    ed: there are only a handful of HTML attributes that take a
    ... for integers it was much more consistent

    <ed> [51]http://jsfiddle.net/6BQGF/

      [51] http://jsfiddle.net/6BQGF/

    ChrisL: the thing that worries me is that if there's only one
    browser implementing it properly, that requirement will be

    ed: that is the test for integers
    ... white space and garbage is allowed across all browsers
    ... negative values for width doesn't work in some browsers,
    but that's different from the white space handling
    ... anyway, all browsers allowed white space / garbage

    pdr: HTML doesn't have lists like SVG
    ... is there any danger there?

    ed: for SVG lists, I think generally white space is allowed

    pdr: I'm wondering if we use that algorithm for a specific
    number, but for a list that doesn't allow commas...?

    krit: I would be in favour of allow leading / trailing white
    ... to allow garbage at the end is a bit strange

    ChrisL: it means you constrain what you can later add

    ed: I guess that's why there are different conformance classes
    in HTML?

    krit: do we want to allow browsers to be less restrictive
    ... we don't need to enforce it...

    Tav: I'd like to avoid the situation where it renders well in
    the browser but then imported in Inkscape it doesn't work

    ed: I think the main thing I found was that there are some
    minor inconstencies whether leading white space is allowed in
    ... so it seemed like a good thing to check everything

    pdr: for the trailing garbage, I disagree
    ... why follow something different from HTML?

    ChrisL: what if we have an attribute like x="4e10" and we start
    off as an integer, what if we want to extend that later?
    ... to accept scinot?

    ed: note that you still get the "4"

    pdr: I see
    ... when the HTML folks made this decision, how did they handle
    this future constraint?

    ChrisL: maybe since it's only a handful of elements it wasn't a

    heycam: what is the benefit here?
    ... simplifies implementations slightly
    ... what about for authors?

    ed: had a bug reported where white space was allowed in firefox
    but not in chrome
    ... can't remember which attribute it was

    pdr: I think it makes sense to align

    cabanier: if you only want one algorithm, then you're going to
    need to accept trailing garbage then

    ChrisL: to be clear, the two objections aren't "no I'll tie
    myself to the mast" objections, they're just worries
    ... worry about it being dropped from HTML, and future
    constraining extensions
    ... but if the group agrees they want to do that I'm fine with

    ed: next is length values
    ... IE allowed white space, no garbage; others don't allow
    ... for enumerated values, everyone agrees no white space or

    heycam: I feel like length parsing is more like CSS parsing
    ... so white space seems good to allow
    ... what about CSS comments?

    ed: so for number and integer, stripping leading/trailing white
    space and trailing garbage, being consistent with HTML5, is my
    first proposal

    krit: who doesn't allow garbage in SVG integer attributes?

    <ed> [52]http://jsfiddle.net/Gaw2P/

      [52] http://jsfiddle.net/Gaw2P/

    ed: compare to the bottom right subtest
    ... which is numOctaves="1"

    krit: in Safari we don't render the 5th one
    ... what does that indicate?

    ed: it doesn't use any fallback value

    heycam: I think if we have some implementations that accept the
    white space and garbage and others not, then we'll eventually
    all converge to that behaviour
    ... so may as well jump to that state now

    krit: I'm OK with accepting leading/trailing white space

    pdr: go for browser compatibility instead of parser

    krit: well, the browser uses a parser...

    pdr: spec parsers

    ed: I think it's mostly consistent in disallowing the garbage
    ... in transform lists for example

    krit: for numbers I would be skeptical because of that
    exponential number example
    ... for integers we only have a few attributes
    ... so is it worth it?

    ed: there are other cases where white space is allowed when the
    spec says no

    krit: I am supporting the white space

    ed: to be clear, I don't want to allow white space everywhere
    ... for enumerated values, like accumulate="none | sum"
    ... I guess we could allow white space

    Tav: but HTML does not

    <ed> [53]http://jsfiddle.net/eT7jz/

      [53] http://jsfiddle.net/eT7jz/

    ed: all browsers agree there not to allow white space

    krit: safari allows the white space there

    pdr: I wouldn't have expected that to be different from chrome

    krit: but the HTML spec doesn't want white space
    ... I think it's strange, but acceptable, to not allow white
    space in enumerated attributes

    ed: we imported a few attributes from HTML5, the boolean values
    for controls="", default="", etc. on <video> and <audio>
    ... we currently don't have anything like that
    ... in SVG
    ... so it makes sense to follow SVG there

    krit: filter effects too

    ed: they don't allow white space or values other than the
    attribute name itself

    krit: I think it's strange it doesn't allow true/false

    ed: for url values, all values allow leading/trailing white
    space, which is stripped
    ... the spec currently says it's not allowed
    ... so I think we should allow it there
    ... xlink:href=""
    ... we now have <video src=""> too

    pdr: what about a data URL that's not base64 encoded
    ... with trailing white space. that's an actual difference.

    ed: I think white space is stripped there

    RESOLUTION: URL attributes will be parsed like in HTML, by
    stripping leading/trailing white space.

    pdr: I think not allowing garbage is ok for length etc.
    ... what about for attributes that we later promote to

    krit: you would start to allow white space

    ed: but that's ok, it's more relaxed

    RESOLUTION: We will allow leading/trailing white space on
    integer,number,length,angle but not trailing garbage.

    ed: the rest of the data types, leave them as they are

    <scribe> ACTION: Erik to update attribute parsing according to
    these resolutions. [recorded in

    <trackbot> Created ACTION-3609 - Update attribute parsing
    according to these resolutions. [on Erik Dahlström - due

Media queries in switch

    ChrisL: was the previous discussion in favour of this?

    heycam: yes I think so

    <ChrisL> good

    [heycam explains what media="" would allow]

    pdr: why not fix media queries in CSS to allow this kind of

    ChrisL: selector syntax is not really designed for doing switch
    cases like this
    ... we already have these test attributes, that we inherited
    from SMIL
    ... seems a natural extension to those
    ... this gives them a simple way to combine media queries with

    davve: the <switch> element has really low usage
    ... is there a use case we want to cover by this?

    krit: you could do the same with classes...

    pdr: this is somewhat torturing the <switch> statement's

    krit: I don't want to encourage people to use <switch>, really

    pdr: the example that estelle is showing is a proposal that is
    copying a <picture> element example, but doing it in SVG
    ... isn't this duplicating?
    ... that doesn't seem like a good idea

    heycam: if this is the same thing as the <picture> element can
    do maybe we should just have that





    heycam: one difference is that the <picture><source> elements
    have to refer to external resources

    pdr: they could be data: URL encoded

    birtles: we were discussing having media="" on <iframe> too
    ... not sure if it's possible to get into cyclic dependencies
    with <switch> and media=""

    pdr: in this blog post they have SVG-as-image referencing
    external background-images, and I don't think that would work
    in implementations
    ... I think this blog post is saying why have <picture> when
    SVG can do this already, but I think <picture> is going to
    ... so if we have <picture> in SVG in the future, I don't think
    we should extend <switch>



    heycam: so I guess there are a few ways to handle this use case

    (a) extend <switch> with media=""

    (b) write style sheets with media queries, as you can do
    currently, but with a bit of duplication within them

    (c) extend @media in CSS to allow switching, to avoid the

    (d) extend <picture> to allow subtrees, so you don't need to
    use external references

    ed: there is <style media=""> too

    [some discussion about avoiding fetching resources in
    non-condition-matching branches]

    <ChrisL> f) keep inviting new responsive elements and then
    rejecting them until the heat death of the universe

    <stakagi> resource piorities?



    heycam: if preventing loading external resources is something
    important for the use case, then (b) and (c) aren't appropriate
    ... (a) or (d) are

    <scribe> ACTION: Cameron to reply to www-svg mail to say what
    can be done with existing @media queries and if <picture>
    exists in SVG [recorded in

    <trackbot> Created ACTION-3610 - Reply to www-svg mail to say
    what can be done with existing @media queries and if <picture>
    exists in svg [on Cameron McCormack - due 2014-04-14].

    <scribe> Chair: Cameron

Summary of Action Items

    [NEW] ACTION: Cameron to publish media access events as a note
    [recorded in
    [NEW] ACTION: Cameron to reply to www-svg mail to say what can
    be done with existing @media queries and if <picture> exists in
    SVG [recorded in
    [NEW] ACTION: ChrisL (or pdr) to get Tab's feedback on davvel's
    SVG sizing proposal [recorded in
    [NEW] ACTION: ChrisL to talk to Michael Cooper about UAG
    [recorded in
    [NEW] ACTION: ChrisL to update the charter [recorded in
    [NEW] ACTION: ed to do spec edits for bounding boxes of text
    elements: give the union of full glyph cells and the painted
    area, and include text decorations in the bbox (change for
    getBBox too) [recorded in
    [NEW] ACTION: ed to figure out the overflow behavior in SVG
    [recorded in
    [NEW] ACTION: Erik to prepare spec text for pointer-events on
    root SVG elements for SVG2 and SVG Integration spec and make
    edits [recorded in
    [NEW] ACTION: Erik to update attribute parsing according to
    these resolutions. [recorded in
    [NEW] ACTION: getBBox and resource bounding box (for gradients,
    mask, etc) to return the union of the glyph cells and ink
    extends by default. [recorded in
    [NEW] ACTION: krit to talk to Alan Stearns about adding
    fallback baseline calculations to the CSS line layout spec and
    if they will stay in the spec [recorded in

    [End of minutes]

Received on Monday, 7 April 2014 15:38:30 UTC