minutes, Tokyo 2013 SVG F2F Day 1, 3 June 2013

Minutes from day 1 of the Tokyo 2013 SVG F2F meeting:

   http://www.w3.org/2013/06/03-svg-minutes.html



    [1]W3C

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

                                - DRAFT -

                     SVG Working Group Teleconference

03 Jun 2013

    [2]Agenda

       [2] http://www.w3.org/Graphics/SVG/WG/wiki/F2F/Tokyo_2013/Agenda

    See also: [3]IRC log

       [3] http://www.w3.org/2013/06/03-svg-irc

Attendees

    Present
           Jun, Cyril, Tav, Tab, Satoru, Yusuke, Tomoaki, Cameron,
           Rik, Dirk, Nikos, Brian, Shane

    Regrets
    Chair
           Cameron

    Scribe
           Cyril

Contents

      * [4]Topics
          1. [5]agenda
          2. [6]should fill-rule apply to text elements?
          3. [7]marker orientation issues
          4. [8]feBlend issues
          5. [9]enable-background issues
          6. [10]What makes a stacking context?
          7. [11]buffered rendering
          8. [12]Stacking contexts, cont.
          9. [13]review of hatches
         10. [14]multiple paint servers on one element
      * [15]Summary of Action Items
      __________________________________________________________

    <trackbot> Date: 03 June 2013

    <TabAtkins> Hrm. I got confused and came up to Mori tower for
    some reason. Is the best way to fix this to head back down and
    use the subway again?

    <heycam> TabAtkins, no, but it is about 15 minutes walk

    <cabanier> scribenick: cabanier

    <heycam> TabAtkins, (Mori tower is right where my hotel is)

    <heycam> TabAtkins, do you have a map? it's a reasonably
    straightforward route

    <TabAtkins> kk

    <TabAtkins> i have google maps?

    <TabAtkins> kinda?

    <shans__> TabAtkins: I can come get you if you want

    <TabAtkins> heh, sure

    <TabAtkins> <3

    <TabAtkins> birtles: Yeah, I have that up, but it doesn't stop
    me from being dumb.

    <shans__> TabAtkins: OK, I'll meet you at the bottom of the
    mori tower?

    <TabAtkins> yeah, i'm at the starbucks

    <shans__> TabAtkins: alright, be there in 10

    <TabAtkins> yay!

agenda

    heycam: are there missing topics?

    … don't worry about scribing

    <TabAtkins> Shane has found me! Coming in.

should fill-rule apply to text elements?

    heycam: in svg 1.0, it applies to shapes and text

    … but does it make sense?

    Tav: maybe for SVG in OpenType?

    heycam: does it make sense to control how the path data is
    interpreted?

    krit: per glyph or the whole word?

    heycam: my feeling is that it's not very useful

    … so wanted to see if other people feel the same way

    … I discovered because a site was using

    cabanier: yes, it should have no effect

    … you are supposed to define them so that are unaware of the
    fill rule

    … outlining glyphs should be unaware of winding rules

    heycam: our implementation was slower for even odd

    krit: we rely on the rendering engine so it doesn't affect the
    winding

    nikos: so, subpixel-aa is also turned off

    heycam: yes
    ... what if the glyphs overlap?

    cabanier: they should paint separately and not interact with
    each other anyway

    heycam: so, should they work?

    everyone: no

    heycam: so we'll change the text so it doesn't aooky

    Cyril: maybe this is for SVG fonts?

    heycam: that's possible
    ... for SVG in OpenType, there's no way either

    resolution: fillrule does not apply to text

marker orientation issues

    tav: I added it

    … basically there are inconsistencies between browsers

    … you can look at the examples

    <krit> [16]http://paullebeau.com/svg2/markers/

      [16] http://paullebeau.com/svg2/markers/

    … and there's also the question of rectangles

    … what do you do with rounded corners

    heycam: I remember making a test for this

    … I have a feeling that the spec should define this

    … ie angle coming from 2 different directions

    krit: is there a spec issue of is it just implemenation

    Tav: it might be just implementaion

    … for 2 subpath, they should not be treated as 1

    … I think

    (looking over the examples)

    heycam: looks like rendering issue

    tav: what with the double point?

    heycam: I wonder what the spec says?

    … (reading) it seems that you get 2 markers for double points

    krit: why would you draw points on top?

    tav: maybe in animations

    krit: I would expect the markers over each other

    tav: you always get the discontinuity

    krit: I'm more talking about transparent markers

    heycam: taking a look at the 'correct' version, I think he is
    right

    krit: do we need to change the spec

    heycam: yes, it should be make clearer. for instance the
    orientation shouldn't be in an appendxi

    … it could benefit from being rewritten

    … orientation is also used for motion path orientation

    krit: text on a path

    heycam: yes when the glyph is on the point

    … it sounds like we agree with his findings

    TabAtkins: we can't use his exact wording

    … because he wants to use coincident points to be ignorder

    heycam: he may be talking about the orientation

    … do we all agree that there should be rendering for each
    point?

    tav: yes

    resolution: we agree with his finding to determine the
    orientation of the marker and we should paint a marker for each
    vertex even if they coincide

    heycam: he also suggest a new value for the orient attribute

    TabAtkins: that seems to make easy double arrows

    heycam: given that you need to duplicate marker elements

    TabAtkins: no, it will flip it around. the name is unclear

    … start or reverse seem better names

    heycam: I like the idea but not the name

    tav: autoreverse?

    TabAtkins: 'auto-reverse'

    … could it be multi-value

    heycam: not sure. let me check

    <birtles> (discussed that 'auto-reverse' is used on
    animateMotion's rotate attribute with different meaning so it
    could be confusing)

    … currently the value for marker orient is exposed as IDL
    attributes

    … orient type which is an animated enumeration

    — and the angle value

    … maybe we can resolve on this new value

    resolution: we'll have a new value for orient attribute to do
    the right thing for arrow heads

    TabAtkins: there's an issue where there are begin and end
    markers on closed paths

    heycam: I find it odd that the open subpaths don't have an end

    TabAtkins: that's what the spec said. It's on path element
    itself

    heycam: closed subpaths should only have marker mids?

    all: yes

    heycam: markers on rects and ellipses

    (previous topic)

    (discussion on just moveto's creating markers)

    krit: we have patches to make that happen

    heycam: I thought we had tests for all this

    … but I can't find it

    … so we should decide something

    … I think it would be most consistent to paint both

    krit: this is strange

    TabAtkins: the problem is that this is a spec change

    heycam: looking at subpaths makes more sense but it seems that
    most implementations already agree on the just looking per path
    element

    … I'd be most happy with the small change

    TabAtkins: it all seems broken

    <TabAtkins> TabAtkins: All the existing renderings are broken.
    >_<

    krit: we should add a note that it may change in the future

    resolution: we'll keep start and end markers apply to the whole
    path

    <TabAtkins> Hey shepazu, WRITE STAR.

    <TabAtkins> Alternately, send me your notes and I'll write it.

    <shepazu> TabAtkins, I'll write star

    <shepazu> or at least start it

    heycam: there was 1 remaining topic on markers

    … rectangles, ellipses, etc

    tav: what about rounded corners?

    TabAtkins: all the remaining elements should define the
    equivalent path

    heycam: you'd probably want to use marker pattern

    … should that be doable

    TabAtkins: yes

    birtles: it would be useful to have path equivalents for the
    rect and ellipse

    <birtles> (for variable-width stroke)

    resolution: closed subpaths should get no start or end markers

    <AlexD> +1 to that

    heycam: I already have an action to come up with equivalent
    paths for rects and ellipses

    <AlexD> Make sure ellipses use ellipse segments, not beziers!

    cabanier: yes

    TabAtkins: Canvas already defines this

    … it uses it as 4 arc paths

    <AlexD> Nice

    heycam: I have the action so we can draw the dashes correctly

    <TabAtkins> Canvas doesn't define it as 4 arc paths - it does
    it as one continuous arc. But still, its start point is the
    rightmost point.

    <TabAtkins> So we should match.

    … maybe we can copy rect over from svg tiny 1.2

    <AlexD> We already have tests for dashing around rects & Arcs
    so should be easy to check they match

    <AlexD> Ellipses, sorry

    TabAtkins: yes, canvas has it with the start in upper left and
    going clockwise

    <heycam> AlexD, good point

    <AlexD> e.g. shapes-ellipse-03-t.svg

    resolution: we need to have markers on rect, circle and ellipse
    and all basic shapes (in case of stars)
    ... rounded rects start at straight horizontal line of the top
    left
    ... rounded rects wind clockwise and include 0 length segments
    when the rounder corner is 50%
    ... for ellipses and circles, the path starts at right-most
    point and consists of 4 arcs going clockwise and each are 90
    degrees

    <scribe> ACTION: heycam to integrate the marker resolutions in
    the spec [recorded in
    [17]http://www.w3.org/2013/06/03-svg-minutes.html#action01]

    <trackbot> Created ACTION-3496 - Integrate the marker
    resolutions in the spec [on Cameron McCormack - due
    2013-06-10].

    <TabAtkins> ScribeNick: TabAtkins

feBlend issues

    cabanier: feBlend as defined today does blending an
    compositing.
    ... This is usually fine today, but if you blend with
    backgroundIMage, you'll get double compositing, and there's no
    way to avoid it.

    <Tav>
    [18]http://tavmjong.free.fr/INKSCAPE/MANUAL/images/FILTERS/Filt
    ers_Background.svg

      [18] 
http://tavmjong.free.fr/INKSCAPE/MANUAL/images/FILTERS/Filters_Background.svg

    cabanier: We can either change feBlend (seems to be the only
    way)
    ... We can add an attr to feBlend, so it doesn't do the
    compositing.
    ... That is, do the "normal" compositing only.

    krit: [draws an example]

    cabanier: There's too much existing content out there for us to
    change the default behavior.
    ... And if you don't use backgroundImage, it's not bad, and
    sometimes good, to composite eagerly.
    ... So choices are add an attribute that stops compositing, or
    try to detect when backgroundImage is the input, and don't
    composite.

    krit: I like the attribute, because it might sometimes be
    useful to do the extra composite.

    [some side discussion about naming]

    TabAtkins: So it looks like just dropping backgroundImage
    compositing would be web-compatible?

    heycam: Anything else with this problem?

    cabanier: feComposite, but that's much more intentional.

    krit: There are more use-cases that might want only blending,
    so doing the attr seems better.

    ACTION krit to define a new attribute (nocomposite?) on feBlend
    that turns off the compositing effect.

    <trackbot> Created ACTION-3497 - Define a new attribute
    (nocomposite?) on feBlend that turns off the compositing
    effect. [on Dirk Schulze - due 2013-06-10].

    RESOLUTION: Keep feBlend's current behavior (where it blends
    and composites), but add an attribute that turns off
    compositing.

enable-background issues

    cabanier: Today, e-b has a really long description.
    ... I think IE implemented it, and Opera, but nobody else.

    TabAtkins: I think roc is against it, and we (blink) have
    similar concerns.

    cabanier: Yeah, it's really expensive.
    ... The way it's defined today you have to render twice - once
    to use as the background.
    ... Nice for authors, but hard/slow to implement.
    ... Adobe apps do something similar under the hood, which we
    can add in the future.

    heycam: Isn't there a trick to keep you from double-rendering?

    cabanier: Yes, but there are still issues where you have to
    keep two sets of pixels, and that kills performance.

    <AlexD> double rendering? Isn't it just a backing store that
    you bitblt as the second pass? Blts are fast:-)

    <nikos> [19]http://www.svgopen.org/2005/papers/abstractsvgopen/

      [19] http://www.svgopen.org/2005/papers/abstractsvgopen/

    heycam: I think e-b isn't explained well in the spec, and if
    impls have a trick that can make it not so slow, the spec
    should define this.
    ... But you're saying that even with that trick, due tto the
    arch. of accel. compositors, it'll still be slower.

    cabanier: Yeah. We can revisit this in the future, but we
    should get the basics right now.
    ... We can define similar things to HTML's "stacking contexts"
    - if you ahve a <g> with opacity, it's a stacking context.

    <AlexD> The requirements to support e-b are the same as
    supporting filters. So if you can accelerate filters you should
    be able to accelerate e-b. Need hard data to falsify this
    claim:-)

    No, it's not the same.

    You can do filters with one copy of the data in a single gpu
    pass.

    <AlexD> <g> with opacity already requires some intermediate
    thing - however you can do it with a pixel sequential renderer
    and no backing store.

    You don't have to go retrieve data from a different gpu pass in
    order to render them.

    [some discussion about transforms and stacking contexts]

    <AlexD> agreed Tab, and you can model e-b in a similar way

    <AlexD> backing stores can be a last resort fallback

    cabanier: So I think we should get rid of e-b, and say that
    certain elements create a fresh background.

    krit: e-b can still be used to create an isolation group for
    filters.
    ... That's what's done in Opera/IE.

    <AlexD> If we get rid of e-b, then it should be replaced by
    something better, like PDFs transparency groups which are a
    better model

    cabanier: It can also be used to make non-isolated groups.

    krit: Some properties need to create isolated groups by default
    anyway. For example, opacity needs to be an isolated group
    independently of e-b.
    ... We already have some impls of e-b, and I'm not keen ot have
    it removed without asking the impls about it.

    cabanier: In the current spec langauge, it says you *must* use
    e-b for blending to work. We don't want that either.

    krit: e-b gets less necessary with the definition that some
    other properties make isolation groups.

    <AlexD> I agree, haven't seen a strong argument that it's not
    implementable. Current architectures for H/W accelerate
    shouldn't degrade the model...

    cabanier: If we can just change e-b without breaking the web,
    that's fine too.
    ... To summarize, everything that creates a stacking context,
    creates an isolated group.

    heycam: So what's the use of e-b outside of that?

    [something about the effects of removing e-b from the spec]

    heycam: So when do you want e-b? Somewhere when there's not
    already an isolated group?

    cabanier: Yeah, but there are several proeprties which can make
    isolation without any other effects, and the 'isolation'
    property specifically for that.

    heycam: Okay, so it sounds easy to get rid of e-b, use
    'isolation' or stackign contexts when you want to turn off
    background blending.
    ... As long as people don't think there's strong use-cases for
    people using the more complicated e-b stuff.

    <AlexD> Maybe we can try to get some data about how much it's
    used in the wild. Does Inkscape support it to isolate layers,
    etc.

    [rehashing of previous conversation]

    krit: To be clear, e-b is implementable, just not with the perf
    characteristics we want.

    <AlexD> Then you need to write better code krit:-) GPUs are so
    slow...

    [discussion of the values that 'isolate' has and their
    meanings]

    <krit> AlexD: yeah, that is why I wrote everything for the CPU
    :P

    <cabanier> cabanier: the issue is not GPU performace, the
    problem is that you need at least 2 extra readbacks from the
    backbuffer and 3 writes to the input buffer

    heycam: Regardless of discussion over ease of implementation,
    because current impls dont' do it and don't want to do it, the
    spec should leave it out for the moment.

    <AlexD> Again we need to get hard data on whether it's used.
    Currently it acts as a spot to run your filter chain back to.
    So we need to at least address that case.

    <cabanier> cabanier: which accesses the memory a lot more which
    will drain your battery

    heycam: If Alex can convince people later, we can add it.

    krit: [wants a value for 'isolate' that prevents isolation of
    descendants even with stacking contexts. Pointed out that we
    can add this later and have 'auto' respond to it]

    RESOLUTION: Remove e-b from this level of Filters.

    <AlexD> For the record I'm not for or against, just want to
    make sure we don't break existing content in the field

    krit: Should I remove e-b silently, or have a note?

    several: Seems useful to have a note pointing back to the old
    definition.

What makes a stacking context?

    cabanier: Anything in CSS that makes a stacking context -
    transforms, filters, etc.

    heycam: Do you really want every transform attr to make a
    stacking context?

    <AlexD> NOOOO!

    cabanier: No, but we want to be simple and consistent with CSS.
    ;_;

    krit: We all agree that SVG transforms are oftne just used for
    moving things around, and are quite basic, rather than
    something that requires stacking contexts.
    ... But impls all do normal CSS stuff.

    cabanier: Maybe we can say that 2d transforms in SVG dont' make
    a stackign context?

    heycam: If you want the same kinds of optimizations, maybe you
    do want stacking contexts.

    cabanier: Like smooth transitions, yes.

    krit: Does FF do transform transitions in hardware? WebKit
    doesn't do it yet (all software for SVG), but we want to change
    that.

    heycam: Same.
    ... Seems like this will suck.

    cabanier: It will.

    krit: Rik tried to specify it around whether you're animating
    or not, but it didn't gain consensus - ugly flash when you
    change.

    cabanier: So maybe we can just differentiate 2d vs 3d - 2d
    doesn't make a stacking context in SVG.

    heycam: What if authors definitely want a separate layer, but
    ar ejust using 2d transforms?

    TabAtkins: Use a null 3d transform, or just use 'isolate'.

    heycam: Ah, I think I might be okay with using 'isolate' to get
    the stacking context.

    Cyril: That seems to make sense.

    <AlexD> I like isolate better than the 3d transform hack

    krit: I think in practice implementors are going to use the
    same code as in HTML/CSS, so 2d transforms will be isoalting as
    well.
    ... I think we should add an agenda for Wed to ask the other
    CSS implementors.

    cabanier: Back to the original context, also filters and
    opacity cause stacking contexts.

    Cyril: z-index also makes a stacking context?

    heycam: Yes, just like CSS.

    Tav: Question about that - we have someone wanting to
    implementing connectors in Inkscape.
    ... You have symbols for the components, want connectors on
    different layers, etc.
    ... Suppose my symbol has things with different levels.
    ... And I want to have multiple symbols sometimes interleave?

    [explanation of how stacking contexts work]

    [conclusion is - it'll work, but making the symbol itself a
    stacking context will prevent it]

    Cyril: [discussion of a layer use-case]

    heycam: BAck to main discussion, are people expecting blending
    to work through opacity?

    cabanier: Probably, but it's hard to make work.

    krit: We make them isolated groups, and I think FF does too.
    ... Also masks and clips are stacking contexts.

    cabanier: Why are clips?

    TabAtkins: They're basically inverses of each other.

    heycam: Simple clips can be done simpler than masks, but
    complex clips (with overlapping curves, or text, etc.) might
    use the same code path.

    krit: Remember, this is the firsst level of blending. In the
    next level, we can do "real" blending, so it can go through
    stackign contexts, etc.

buffered rendering

    Cyril: It's a hint.

    krit: That's the problem. Blink is looking to implement it.
    ... So it can make a stackign context sometimes - "auto" is
    determined by the engine.
    ... So we should change "auto" to mean "don't make an image
    buffer".

Stacking contexts, cont.

    [I meant that 'buffered-rendering' also causes stackign
    contexts.

    RESOLUTION: buffered-rendering:auto/dynamic never create a
    stacking context; "static" does.

    <Cyril> scribe: Cyril

    <scribe> scribeNick: Cyril

    heycam: someone should actually note those things that create a
    stacking context in the spec

    <scribe> ACTION: Rik to note those things that create a
    stacking context in the spec [recorded in
    [20]http://www.w3.org/2013/06/03-svg-minutes.html#action02]

    <trackbot> Created ACTION-3498 - note those things that create
    a stacking context in the spec [on Rik Cabanier - due
    2013-06-10].

    heycam: the rendering model chapter should reference the
    compositing/blending

    nikos: I did start updating it

    <heycam> [21]https://svgwg.org/svg2-draft/render.html

      [21] https://svgwg.org/svg2-draft/render.html

    cabanier: the CSS compositing spec references that and extends
    it

    [22]https://dvcs.w3.org/hg/FXTF/rawfile/tip/compositing/index.h
    tml#module-interactions

      [22] 
https://dvcs.w3.org/hg/FXTF/rawfile/tip/compositing/index.html#module-interactions

    cabanier: we believe that CSS Blending and CSS Filters
    currently extend SVG 1.1 and don't need to reference SVG 2

    krit: it depends on when SVG 2 goes to CR state

    cabanier: there needs to be a link back from SVG 2 to those 2
    specs
    ... does this mean those 2 specs need to be at CR stage ?

    krit: no

review of hatches

    <Tav> [23]https://svgwg.org/svg2-draft/pservers.html#Hatches

      [23] https://svgwg.org/svg2-draft/pservers.html#Hatches

    Tav: I'd like people to review it and tell me if it is ok

    krit: how would you implement hatches ?

    tav: creating a pattern on the fly could work

    krit: hatch as a dimension

    tav: inifinite in one direction
    ... you can go to one tile but need to be carefull at tile
    boundary
    ... I would make the tile the size of the whole thing
    ... as long as you take car of the boundaries, it should work

    heycam: can you summarize the new elements

    <AlexD> Take a look at my open source hatching that I emailed
    ages ago - it's really easy to hatch. You generate the bound
    box of the thing being filled, generate the lines and clip them
    against the polygon.

    tav: the hatch element copied from the pattern element

    <heycam> AlexD, but does that work if you want to use the hatch
    in the stroke of a shape?

    <heycam> (unless you have good stroke-to-path routines)

    <AlexD> Yes - you have to generate the outline of the stroke of
    course

    tav: the hatch has a pitch to repeat

    <AlexD> [24]http://www.ishtek.com/hpgl2.htm

      [24] http://www.ishtek.com/hpgl2.htm

    tav: the hatch has a path which defaults to a line
    ... and an offset from the origin

    heycam: can you choose the origin ?

    tav: yes, that's copied from patterns

    <AlexD> Source code is [25]http://www.ishtek.com/gl2-0_1.zip

      [25] http://www.ishtek.com/gl2-0_1.zip

    <shepazu> (isn't the problem with patterns a matter of
    implementation, not an inherent problem with the spec?)

    tav: the fdifference between a normal path and a hatch path,
    you don't have to provide the original move to
    ... if not, the y is 0 and x is that last x value
    ... that's how you get the continuous

    heycam: why y = 0 ?

    tav: because you're repeating in the y direction
    ... look at the 1st squiggle example

    krit: why do you need to introduce a hatchPath element? why not
    reuse the path element?

    Tav: no initial move to
    ... it's necessary to repeat
    ... examples 9 and 10 show the difference between having the
    initial move to or not

    krit: why do you need the angle attribute since you have the
    transform attribute ?

    tav: maybe not needed then ...

    krit: it can be confusing in which order they apply

    tav: I have to think about it

    nikos: should the d attribute be called differently ?

    krit: I'm worried about the transform attribute
    ... we already have the gradientTransform ...

    tav: that's fine with me, I just copied over from pattern

    heycam: this brought the issue of capitalization of elements
    ... we did not resolve firmly on it
    ... especially given the HTML parsing algorithm
    ... each new mixedCase name that we introduce we need to update
    the HTML parser

    krit: I think we should continue with our naming

    heycam: and update the HTML spec ?
    ... otherwise the casing will not be preserved
    ... I'm pretty sure there will be a problem if we don't do
    anything
    ... we could say that both names work in the DOM

    krit: is it only when SVG elements are not used in an SVG
    subtree ?

    heycam: no, even if in an SVG subtree because the HTML parser
    won't know that new element

    Tav: that must be trivial to fix

    heycam: yes, but that could create problem between parsing and
    DOM manipulations
    ... maybe it's not a big deal because people won't be doing
    that
    ... one solution could be to allow both cases to produce the
    same DOM element
    ... because if we don't allow that we have to file a bug on the
    HTML spec

    krit: can you fill hatch paths ?

    Tav: no
    ... that needs to be clarified

    krit: what about filters ?

    heycam: and markers ?
    ... can you use the normal stroke properties ?

    Tav: yes
    ... even variable width stroke, but it depends on the use case

    heycam: it makes sense to allow all stroke properties
    ... you could do overlapping, which you can't easily do with
    patterns

    Tav: overflow on the parent is not defined

    <AlexD> Yes, and it does that in GL/2 i.e. hatch lines are
    clipped, then the stroke can go outside the original shape with
    line ends, etc.

    heycam: if overflow is set to hidden, then there must be some
    rectangular region used for clipping

    tav: the rectangular region is infinite length

    (tav drawing on the board)

    krit: there would be a difference between overflow x and
    overflow y

    Tav: it would be nice to have overflow on patterns

    krit: it was implemented but then removed from the spec

    Tav: it would be easier for authors

    heycam: I do it 4 times and clip the middle

    krit: it was not implemented by Opera and Firefox

    Tav: can we revisit that for SVG 2

    heycam: let's start without it

    Tav: any other issue that people see ?

    heycam: I would start with the assumption that all stroke
    properties work

    krit: should all paint servers work ?

    Tav: like a hatch inside a hatch ?
    ... why not if it can be implemented easily

    <AlexD> Mmmm, fractal hatching:-)

    heycam: most people won't use it
    ... if you have a hatch whose stroke properties references a
    paint sever defined in terms of objectboundingbox
    ... which bounding box would you use, the small one or the
    infinite one ?

    krit: can we leave that undefined for now
    ... unspecified

    heycam: I don't think it should stay unspecified

    TabAtkins: it is a mistake to leave it undefined

    Tav: we could say only solid colors for now

    RESOLUTION: Hatch will only support solid color paint servers

    Cyril: can you reuse a path?

    Tav: that's not really the same as another path?
    ... currently there is only a hatchPath and it cannot reference
    something else

    krit: I would leave it like that

    heycam: there is a xlink:href attribute on the hatch element

    break

    <TabAtkins> /break

    <TabAtkins> [Presentation from IDPF about "Advanced Hybrid
    Layouts" to get input from SVGWG for some questions.]

    <TabAtkins> [Slides will be published shortly.]

    example of "intra-navigation rendition" for Comics using SVG:
    [26]http://concolato.wp.mines-telecom.fr/2013/03/28/svg-comics/

      [26] http://concolato.wp.mines-telecom.fr/2013/03/28/svg-comics/

    works only in Firefox

    <TabAtkins>
    [27]http://www.whatwg.org/specs/web-apps/current-work/multipage
    /the-map-element.html#attr-area-shape

      [27] 
http://www.whatwg.org/specs/web-apps/current-work/multipage/the-map-element.html#attr-area-shape

    heycam; we could have the overflow property apply to the view
    element

    krit: does it need to be the view element ?

    TabAtkins: yes because there is no nested svg element
    ... it has to be a view

    krit: you could use the view element with use elements

    IDPF: would you feel offended if we added our own attribute

    heycam: we would prefer to define it in SVG

    TabAtkins: it sounds useful for general SVG

    IDPF: multi-lingual manga, tapping an area or moving the mouse
    over to change the language
    ... it dosn't work on tablet

    birtles: you can use SVG animations

    TabAtkins: or HTML with hidden option elements
    ... with pure HTML, no JavaScript

    heycam: relies on the fragment changing and links?

    TabAtkins: using check boxes and radio buttons and
    pseudo-classes
    ... use check to display none
    ... you can cycle between language

    birtles: if your UA supports SVG animations, it would be a lot
    simpler and more semantically intersting to use SVG

    IDPF: what about CSS animations?

    TabAtkins: some of it will be only possible in SVG animations
    ... what about scaling to 100 languages

    IDPF: with menus maybe

    TabAtkins: JS would become more useful

    IDPF: could you use SVG animations to store your language
    preference

    Cyril: maybe using SMIL state

    birtles: you could use the switch element

    krit: I would not rely on the switch element

    IDPF: how well is the support for animation

    birtles: well in all browsers except IE

    krit: but you could use JS libraries

    [28]http://concolato.wp.mines-telecom.fr/2013/03/28/svg-comics/

      [28] http://concolato.wp.mines-telecom.fr/2013/03/28/svg-comics/

    <TabAtkins>
    data:text/html;charset=utf-8,<!DOCTYPE%20html>%0A<div%20id%3Dba
    ckground>%0A%20%20<input%20name%3Dfoo%20type%3Dradio%20id%3Di1%
    20checked><label%20for%3Di2>1%2C%202%2C%203<%2Flabel>%0A%20%20<
    input%20name%3Dfoo%20type%3Dradio%20id%3Di2><label%20for%3Di3>%
    E4%B8%80%2C%20%E4%BA%8C%2C%20%E4%B8%89<%2Flabel>%0A%20%20<input
    %20name%3Dfoo%20type%3Dradio%20id%3Di3><label

    <TabAtkins>
    %20for%3Di1>i%2C%20ii%2C%20iii<%2Flabel>%0A<%2Fdiv>%0A<style>%0
    Ainput%2C%20input%3Anot(%3Achecked)%20%2B%20label%20%7B%20displ
    ay%3A%20none%3B%20%7D%0A<%2Fstyle>

    <TabAtkins> D'oh, terrible link handling.

    IDPF: How should we capture regions ?

    <TabAtkins>
    [29]http://software.hixie.ch/utilities/js/live-dom-viewer/saved
    /2271

      [29] http://software.hixie.ch/utilities/js/live-dom-viewer/saved/2271

    <TabAtkins> ^^^ Example of cycling language via HTML.

    <TabAtkins> (And it can be powered up with a "default language"
    selection as well.)

    IDPF: Should we use SVG views, SVG elements in the rendition
    tree or SVG elements in <defs>

    Cyril: you want to describe metadata

    IDPF: yes
    ... a tree of regions
    ... for navigation
    ... the rest is flat

    heycam: is the description of the hierarchy inside or outside
    the SVG document ?

    IDPF: outside

    <TabAtkins> (Also, the basic mechanics in my example are
    captured in a draft CSS spec on my blog, and the CSSWG is
    interested in pursuing it, so this might be usable for SVG as
    well.)

    TabAtkins: if you extend media fragment to add a polygon that
    might do a lot

    IDPF: yes

    Cyril: it would be good to add the metadata in the SVG document
    to enable viewing it with browsers
    ... possibly with JS navigation logic

    IDPF: why having both views and fragment identifiers ?

    heycam: maybe for flexibility

    TabAtkins: yes it depends on who is the author of the document

    <birtles> SVG version of above:
    [30]http://software.hixie.ch/utilities/js/live-dom-viewer/saved
    /2272

      [30] http://software.hixie.ch/utilities/js/live-dom-viewer/saved/2272

    heycam: we can answer to the IDPF questions in a liaison
    ... we need also to wok on the clipping question

    TabAtkins: overflow should clip the content
    ... I will take the question to the CSS group
    ... and we need to work on swapping text around

    heycam: there is also a work on custom media queries

    TabAtkins: to avoid creating a class attribute on the body
    (modernizr)

    IDPF: we are wondering if we should use media queries for text
    direction or language

    TabAtkins: it should work
    ... your use cases seem appropriate for MQ
    ... some properties like luminance are in CSS MQ 4

    <heycam>
    [31]http://www.w3.org/mid/CAAWBYDBbJ5qSDZzHAvThdA9W0PDmEOTh7+Ap
    LaQYtHwi6U0o_Q@mail.gmail.com

      [31] 
http://www.w3.org/mid/CAAWBYDBbJ5qSDZzHAvThdA9W0PDmEOTh7+ApLaQYtHwi6U0o_Q@mail.gmail.com

    heycam: in summary we need to answer how to represent non
    rectangular view, clip them, swap text, more media queries

    <TabAtkins> Also: where to put region information?

    <TabAtkins> heycam: Keep it in content where possible.

    heycam: we can consider that for SVG 2
    ... you need to point to the views from outside
    ... and for browser fallback to use # to those views and have
    sensible behavior

    IPDF: we like CR

    heycam: the original plan was to have a stable version at the
    end of this year
    ... but I'm not sure we can make that
    ... we could right a separate specification if that would make
    your life easier

    IDPF: yes that would
    ... we would need to decorate semantically the views

    heycam: I think that would be fine for you to define the
    semantics in the SVG document in a different namespace

    IDPF: yes that's our plan
    ... also order would be significant

    heycam: arbritrary authoring tools might not preserve the order

    IDPF: but we might need to represent the order in our external
    navigation metadata documet

    heycam: I will gather our ideas and send that as a liaison

    <scribe> ACTION: heycam to gather ideas for solving IDPF issues
    and send that as a liaison [recorded in
    [32]http://www.w3.org/2013/06/03-svg-minutes.html#action03]

    <trackbot> Created ACTION-3499 - Gather ideas for solving IDPF
    issues and send that as a liaison [on Cameron McCormack - due
    2013-06-10].

    <heycam> ScribeNick: heycam

multiple paint servers on one element

    Tav: sometimes you want a crosshatch

    … you could have multiple fills on an object

    … it might be useful to have a colour fill and with a hatch on
    top

    … how to specify this?

    … maybe a comma separated list?

    krit: and what about the fallback value?

    … fill/stroke have a paint server reference and a fallback
    value

    … how does that work?

    TabAtkins: just like background, the last thing would be a
    colour

    … and you'd fall back to that

    … it's comma separated, but the last layer can be a colour

    krit: you have a space separated fallback colour in fill/stroke
    now

    heycam: why not have <paint> for each item?

    krit: then we need to define the paint order. we should do it
    like background-image.

    heycam: so it's backwards?

    Tav: that's how I'd do it

    krit: what about having fill-attachment, fill-clip, ...?

    TabAtkins: do we really want that? it might be a good idea,
    but...

    heycam: allow that for stroke as well?

    Tav: yeah

    RESOLUTION: We will allow multiple paints in the fill and
    stroke properties in SVG 2.

    <TabAtkins> Comma-separated, painting first layer on top, last
    on bottom. Only last layer can be a color or have a fallback
    color.

    cabanier: what about the other stroke properties, like
    stroke-width?

    heycam: having a comma separated list of stroke-dasharrays
    would be problematic

    … we could wrap them in a function if we need to, though

    krit: I don't want to support those yet

    … let's just do fill and stroke properties, and leave stroke-*
    properties as single items for now

    heycam: ok

    <scribe> ACTION: Tav to put multiple fills/strokes in SVG 2.
    [recorded in
    [33]http://www.w3.org/2013/06/03-svg-minutes.html#action04]

    <trackbot> Created ACTION-3500 - Put multiple fills/strokes in
    SVG 2. [on Tavmjong Bah - due 2013-06-10].

    RESOLUTION: <hatch angle> will be renamed <hatch rotate>.
    ... <hatch rotate> will allow angle units.

Summary of Action Items

    [NEW] ACTION: heycam to gather ideas for solving IDPF issues
    and send that as a liaison [recorded in
    [34]http://www.w3.org/2013/06/03-svg-minutes.html#action03]
    [NEW] ACTION: heycam to integrate the marker resolutions in the
    spec [recorded in
    [35]http://www.w3.org/2013/06/03-svg-minutes.html#action01]
    [NEW] ACTION: Rik to note those things that create a stacking
    context in the spec [recorded in
    [36]http://www.w3.org/2013/06/03-svg-minutes.html#action02]
    [NEW] ACTION: Tav to put multiple fills/strokes in SVG 2.
    [recorded in
    [37]http://www.w3.org/2013/06/03-svg-minutes.html#action04]

    [End of minutes]
      __________________________________________________________

Received on Monday, 3 June 2013 08:32:58 UTC