Minutes SVG F2F Seattle 2014 Day 1

Minutes:

     http://www.w3.org/2014/01/30-svg-minutes.html


and as text below:


    [1]W3C

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

                                - DRAFT -

                        SVG F2F Seattle 2014 Day 1

30 Jan 2014

    [2]Agenda

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

    See also: [3]IRC log

       [3] http://www.w3.org/2014/01/30-svg-irc

Attendees

    Present
           +1.206.675.aaaa, nikos

    Regrets
    Chair
           Erik

    Scribe
           Cameron, Brian

Contents

      * [4]Topics
          1. [5]Resolving dates for April F2F
          2. [6]should script be affected by <switch>
          3. [7]deprecating/removing hasFeature
          4. [8]adding SVG specific events to GlobalEventHandlers
          5. [9]deprecate/remove SVGDocument.rootElement
          6. [10]MPEG colored fonts meeting report
          7. [11]Percentage values on objectBoundingBox for content
             elements
          8. [12]event handler attribute reflection
          9. [13]renaming svg resize and scroll events
         10. [14]scaling back features that suck performance
         11. [15]a hazelnut in every bite
         12. [16]it goes to eleven
         13. [17]krit's keywords
         14. [18]SVG2 status
      * [19]Summary of Action Items
      __________________________________________________________

    <heycam> Scribe: Cameron

    <heycam> ScribeNick: heycam

Resolving dates for April F2F

    shepazu: where is it?

    ChrisL: Leipzig

    <ed>
    [20]https://www.w3.org/Graphics/SVG/WG/wiki/F2F/Leipzig_2014

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

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

      [21] http://libregraphicsmeeting.org/2014/

    heycam: that's 2-5 April for LGM

    ChrisL: which Wednesday to Saturday

    heycam: so meeting from Monday 7th April

    shepazu: I have Annotations workshop in SF around that time
    unfortunately

    ed: how many days?

    heycam: I probably prefer 4, so we can get a lot of work done

    ChrisL: have we got a meeting space? has anybody approached the
    university hosting the conference?

    heycam: Tav is in contact with them

    birtles: I agree 4 days is long but if we're taking the
    time/money to get there...
    ... then maybe it's worthwhile

    ChrisL: at that time of the year we'll be hopefully be trying
    to wind up and go to Last Call for SVG2

    shepazu: if we are going to have a 4 day week, I'd rather it be
    at the SVG Open one when I'll be there
    ... how about you have a 4 day meeting, where 2 or 3 days are
    the core meeting, and the final day or two is dedicated to
    working days
    ... where you try to finish up the things resolved during the
    F2F
    ... so people who need to leave after the core meeting can

    ed: so the proposal is April 7 - 10?

    krit: we should talk about who's sponsoring

    ChrisL: the university would supply a room but not food

    heycam: previously we've had F2Fs where we went out for lunch,
    and not had catering

    krit: that's OK by me

    RESOLUTION: The April F2F will be April 7-10, where the 10th is
    an optional stay-for-spec-editing day.

    ed: how about the Graphical Web F2F?
    ... it's at the end of August

    <ed>
    [22]https://www.w3.org/Graphics/SVG/WG/wiki/F2F/Winchester_2014

      [22] https://www.w3.org/Graphics/SVG/WG/wiki/F2F/Winchester_2014

    ChrisL: 27-30

    <ChrisL> [23]http://svgopen.org/2014/

      [23] http://svgopen.org/2014/

    heycam: that's another Wednesday-Saturday

    krit: regarding Leipzig, the semester holiday ends right when
    we would be meeting
    ... so maybe it will be harder to get a room there

    heycam: to get the spacing better, we should meet before
    Graphical Web IMO
    ... would we be happy with Sat-Tue? or maybe Fri-Mon?

    krit: this is a university again by the way

    <ChrisL> tpac 27 Oct to 31 Oct 2014 in Santa Clara, California

    heycam: if we met after Graphical Web, then we would be meeting
    in September and then in October for TPAC
    ... so we could do it Sat-Tue before, and make Sun the optional
    spec editing day or just a day off
    ... or Thu-Fri on, Mon-Tue on, weekend off

    ed: I don't mind either

    shepazu: let's decide the exact before-Graphical-Web dates
    later

should script be affected by <switch>

    shepazu: no

    heycam: no

    ed: no

    ChrisL: if you were designing from scratch maybe, but given how
    <script> already works now...

    heycam: I am pretty sure all implementations will run script
    without looking at <switch>

    RESOLUTION: <script> is not affected by <switch>

    <scribe> ACTION: Erik to clarify <script> is not affected by
    <switch> and will be run in there, but is still disallowed by
    the content model. [recorded in
    [24]http://www.w3.org/2014/01/30-svg-minutes.html#action01]

    <trackbot> Created ACTION-3561 - Clarify <script> is not
    affected by <switch> and will be run in there, but is still
    disallowed by the content model. [on Erik Dahlström - due
    2014-02-06].

    birtles: I don't see the point of disallowing stuff that will
    work

    ChrisL: it's disallowing stuff that people might have
    reasonable expectations of working differently

    ed: I think we should encourage people to put <script> in
    <defs>

    birtles: we could say authors SHOULDN'T put it in <script>

    ed: I think it's fine to remove the content model restriction
    but to encourage to put it in <defs>

    heycam: I'm not sure of <defs>

    ChrisL: part of the point of <defs> is for things which are
    referenced later, and hiding from being visible, which doesn't
    really apply to <script>

    action updated

deprecating/removing hasFeature

    krit: are we talking about deprecating or removing?

    birtles: the proposal from Anne was to make it always return
    true

    krit: so not removing it, but deprecating and making default
    return true
    ... if you look at the WebKit/Blink source code, we do
    something with this feature
    ... the question is is any script using it
    ... given this part of our source code is outdated it's not
    really reliable
    ... iirc, hasFeature is indirectly called by <switch>
    ... which doesn't mean anything, ...

    ChrisL: it's one of those features that sounded good, thought
    it would be the way forward, turned out it wasn't

    birtles: I think we haven't deprecated it yet right?

    krit: in HTML content true is always returned

    birtles: I think we return proper values for it

    heycam: hasFeature is defined in DOM btw

    ChrisL: it was never clear if you needed to support 100% of a
    feature to return true

    birtles: now with things like modernizr...

    krit: did someone add a use counter for hasFeature?

    birtles: a few days ago someone did I think?

    <ed>
    [25]http://code.google.com/p/chromium/issues/detail?id=335301

      [25] http://code.google.com/p/chromium/issues/detail?id=335301

    shepazu: in DOM 3 Events we come up with a logical way to make
    hasFeature work
    ... for fine grained control for reporting
    ... which was roundly rejected by anne and others
    ... which is expensive and other things which are not feature
    testable

    <birtles> the usage counter has been added to blink:
    [26]http://lists.w3.org/Archives/Public/www-svg/2014Jan/0053.ht
    ml

      [26] http://lists.w3.org/Archives/Public/www-svg/2014Jan/0053.html

    shepazu: I won't get in the way of removing it, but I think
    it's being done on outdated data

    <birtles>
    [27]https://code.google.com/p/chromium/issues/detail?id=335301

      [27] https://code.google.com/p/chromium/issues/detail?id=335301

    shepazu: I've had conversations with Paul Irish about testing
    whether certain SVG features are available, and there weren't

    Rossen_f2f: can't you piggyback off @supports for this?

    shepazu: I don't mind

    birtles: I think it's not going to work when there are bugs in
    the features that are being reported as true
    ... which you often want to test for

    ChrisL: it's not can I rely on this feature, but can I rely on
    a subset of this feature that I'm using right now?
    ... you're really saying if I use this in this way, in
    combination with this other thing, ...

    shepazu: feature detection won't work for that either

    Rossen_f2f: why wouldn't feature detection work?

    shepazu: it can't test for rendering things

    birtles: Safari on iOS 5 for example paints patterns upside
    down
    ... for that you really need to do UA string checking
    ... so I think that's an advantage of feature testing, you can
    test for exactly what you need

    ed: should we wait for the use counter results?
    ... I wouldn't mind if we returned true all the time

    Rossen_f2f: you're trying to do implementaiton detection
    through feature detection
    ... which doesn't seem to be exactly what feature detection is
    for
    ... if you want to detect "what is the rendering of something"
    ...

    krit: there's a difference between supporting a property and
    supporting it in the rendering pipeline

    Rossen_f2f: your @supports or hasFeature should still return
    false in this case
    ... I'm with Doug that hasFeature and feature detection are
    useful and good to keep
    ... still people are building solutions on top of this can impl
    versions of their apps that are best for that feature set

    krit: if you ask "do you support filters"? you might return
    true, even if you don't support all filter inputs

    sgalineau: that's true, but that's not an argument for not
    doing it at all
    ... that's why @supports gives you the ability to check for
    property values

    birtles: I'm just not sure you ever get enough granularity
    ... for animations, you could even test the supported values,
    like syncbase values, but you don't know if it supports cyclic
    dependencies

    shepazu: but you could add feature detection for specific cases
    like this
    ... but for other cases you wouldn't need to
    ... pdr just said 10% of pages use SVG, which is misleading
    because a lot of that is Modernizr

    krit: there is a thing where you can select which features to
    check for, so not all Modernizr uses will end up creating an
    SVG element

    shepazu: but people will use it poorly
    ... the case where you inject SVG because you might use it, is
    different from doing it for feature detection
    ... I think the pattern of having to download scripts that are
    getting increasingly large, as there are more features added to
    the platform
    ... and putting the onus on authors to find some feature
    detection system that is a good tradeoff between what's
    actually supported and what's not supported,
    ... I think that's us being lazy and harming authoring

    sgalineau: that's why we have @supports

    Rossen_f2f: at the end of the day, it's a poor man's
    implementation of reflection
    ... and reflection is useful

    shepazu: maybe hasFeature is not the right place to do this
    ... I'm suggesting we should have reflection at all levels of
    the stack
    ... we can remove hasFeature, but let's not say we don't need
    the functionality, because we do

    ed: let's postpone until we get the use counter results

adding SVG specific events to GlobalEventHandlers

    krit: was the editor of the spec with this interface had a
    chance to look at it?

    ed: Boris Zbarsky replied

    <ed>
    [28]http://lists.whatwg.org/htdig.cgi/whatwg-whatwg.org/2014-Ja
    nuary/041909.html

      [28]  
http://lists.whatwg.org/htdig.cgi/whatwg-whatwg.org/2014-January/041909.html

    onbegin, onend, onrepeat, onzoom

    ed: I'm proposing we don't add onbeing/onend/onrepeat
    ... for SVGZoom I'm not sure about it
    ... we could remove the prefix

    ChrisL: would it conflict it with current work on defining
    zoom?

    ed: relatedly I also posted a patch to Blink to add the global
    event handlers
    ... so you assign to .onclick on SVG elements

    heycam: what are we doing about zoom event altogether?
    ... did we discuss getting rid of the "SVG" prefix?

    ed: we did, for those that have existing counterparts
    ... so that's all the events except for SVGZoom

    krit: zooming is being discussed in CSSWG

    <ed> and endEvent/beginEvent/repeatEvent

    krit: should we check what the outcome of that is first? before
    we add a global onzoom?

    ed: it doens't need to be resolved right away
    ... I don't think SVGZoom is used much

    birtles: can we drop it even? or is it used?

    ed: it's something people have asked for
    ... for UIs zooming and panning

    Rossen_f2f: I strongly suggest waiting for what Ted comes up
    with in CSS
    ... the one thing we need to figure out is what we really need
    from a zooming feature
    ... [mentions various possible zoomings]
    ... my hope is that once they're done defining the behaviour,
    the CSSOM will follow with the appropriate events for that

    heycam: so given .onzoom isn't supported anywhere, let's not
    add it now
    ... and wait to see what broader zoom events come out of the
    CSS work we can align with

    [look to see how things are done in HTML]

    ed: so let's put .onbegin, .onend, .onrepeat on
    SVGAnimationElement

    heycam: ok

    RESOLUTION: We won't add an onzoom IDL attribute, but we will
    add onbegin, onend, onrepeat to SVGAnimationElement.

    <scribe> ACTION: Erik to add onbegin, onend, onrepeat to
    SVGAnimationElement. [recorded in
    [29]http://www.w3.org/2014/01/30-svg-minutes.html#action02]

    <trackbot> Created ACTION-3562 - Add onbegin, onend, onrepeat
    to svganimationelement. [on Erik Dahlström - due 2014-02-06].

    -- 15 minute break --

    <Tav> How do I call in?

    Tav, see /topic

    <Tav> heycam, Thanks

    <Tav> OK

deprecate/remove SVGDocument.rootElement

    ChrisL: do it

    heycam: I asked, should we add use counters?

    ed: they've been added now, we'll have to wait a couple of
    weeks to get results
    ... I still think we should mark it as deprecated in the spec

    birtles: I think we can mark it as deprecated, the results are
    useful for knowing when to remove it

    heycam: which might be immediately?

    birtles: might be!

    ed: this came up in a discussion with implementation for DOM 4,
    where we have a new XMLDocument interface, which is kind of
    used to replace SVG document

    RESOLUTION: We will deprecate rootElement in SVG 2.

    <scribe> ACTION: Erik to mention in SVG 2 that rootElement is
    deprecated. [recorded in
    [30]http://www.w3.org/2014/01/30-svg-minutes.html#action03]

    <trackbot> Created ACTION-3563 - Mention in svg 2 that
    rootelement is deprecated. [on Erik Dahlström - due
    2014-02-06].

MPEG colored fonts meeting report

    ChrisL: there was an SVG glyphs in OpenType group that
    discussed how to do this
    ... consensus was reached finally and we came up with a
    proposal that said how to do this
    ... backed up with an impl in Firefox
    ... Adobe was heavily involved in this, and has been making
    fonts, demos and promoting it
    ... this was good, and MPEG who do the ISO version of OpenType
    due to a strange historical accident, would do this for the 3rd
    edition
    ... they put out a call for proposals
    ... they were aware of four things going on
    ... one by Apple, who decided not to submit it (or document it)
    ... one by Google, which is a bunch of PNGs
    ... (currently OpenType supports rasters but only black and
    white)
    ... the PNGs can be different sizes
    ... that hits the emoji case closely
    ... MS had a different proposal which builds on TT rasterising
    ... outlines that can be hinted etc., but you can have multiple
    of them that can be stacked, and you have a palette to say what
    colours the layers have
    ... so you can do flat solid colour things
    ... can't do gradients, transparency, masking, filtering, etc.
    ... at the same time, for typographers that like things to be
    hinted, that seems a win
    ... then there's the SVG proposal, which uses secure animated
    mode, so there's no scripting, interaction
    ... but you can use any graphical support in SVG
    ... it doesn't use SVG Font's <glyph>
    ... we did some pre-harmonisation work with the MS proposal
    ... so we use the same palette information in the font
    ... that was seen as a good thing in the meeting
    ... typically the outcome of MPEG meetings is a competition
    ... and decide on a winner, then the winning company has to
    provide a reference impl
    ... each proposal was seen as having benefits/drawbacks, so the
    proposal is to stick them all in
    ... and the typographer can choose which to use
    ... we already have that with TT vs CFF outlines
    ... which also exposes a problem, because in OT2 you have to
    say which you're using
    ... if we're adding 3 more formats, that's obviously not going
    to work
    ... so they're fixing that bug
    ... the other thing was a call for some math tables that let
    you do equation typesetting
    ... the MS proposal, the only one, was accepted
    ... Vlad will incorporate the proposals and circulate a draft

    shepazu: what's the IPR policy on this?

    ChrisL: the IPR policy for the SVG glyphs in OpenType part was
    decided by the Community Group, and almost everyone has signed
    off on that
    ... so that's RF

    shepazu: anyone significant hasn't?

    ChrisL: Canon has not
    ... the policy for ISO as a whole is RAND, and all you have to
    do is say that you will give a license
    ... companies discuss about reasonable is
    ... not super happy about that
    ... but that's how it works
    ... at least for the SVG parts it's ok

    shepazu: what about for OpenType itself?

    ChrisL: there have been patents, e.g. the hinting stuff
    ... the other thing is that unlike most ISO groups, this one
    does publish the spec openly
    ... which is good except you still have to click through a
    licence
    ... in practice everyone refers to the MS version
    ... I spoke to Michelle from MS and assured me once the
    document was stable she'd incorporate it into the MS version
    ... some people were worried about the SVG one, and it
    transpired the reason why is that it would be an MPEG bake off
    ... and one would win, others would lose
    ... I'm doing a talk at LGM about this
    ... I'm starting to look at the impl landscape, most of which
    work on windows, some on mac, none on linux
    ... which let you edit various things
    ... there is some momentum though
    ... there is interest in doing it too
    ... the type industry which has traditionally sold sets of
    fonts that align, is understanding that that sucks as a
    workflow, and wants to have a single font with tables
    ... another worry about SVG was that the colours were fixed, so
    hearing that we had this palette mechanism, they were super
    happy
    ... as far as MPEG is concerned, they're at a given stage, but
    at some point in the future there will be votes and will become
    a standard
    ... no need for implementations like CR
    ... so it would be good to have in another browser, and also
    authoring tools
    ... demos made by typographers would be good too
    ... inkscape has already got a way to do SVG glyphs, which are
    going away, and wraps them up and produces a font
    ... would be good to repurpose that for SVG in OpenType

    Tav: I know there'll be a lot of FontForge people at LGM

    ChrisL: yes, though FF is a bit funky given its interface
    ... plus if you're running it on a mac you need to run X
    ... there was an effort to split FF into two parts, a library
    then a UI, that has not happened
    ... would be good to talk to Scribus people too
    ... one thing you can do with this, video games use a lot of
    coloured signage, icons, and you can have huge assets for this
    ... and recolour them etc.
    ... having a coloured font format for slotting different
    palette values, is a win
    ... and the 3D people use fonts

    <ChrisL> for amazing title sequences

    shepazu: is there a possibility to co-publish this as a W3C
    spec?

    ChrisL: the whole of OT3?
    ... there's a possibility, but MS does own the non-ISO version
    of the spec, so not sure what they would say about that

    <ChrisL> [31]https://www.microsoft.com/typography/otspec/

      [31] https://www.microsoft.com/typography/otspec/

    ChrisL: there's a bad redirect there for the licence

    shepazu: I think there could be some value at republishing at
    W3C
    ... second question is, since we are killing off SVG fonts, for
    those browsers who decided to never do SVG fonts, that's good
    news
    ... there's a chance we'll see this new SVG glyphs in other
    browsers since they already do OpenType
    ... with the shitty internationalization of the old SVG Fonts,
    it was reasonable for them not to implement it
    ... what I hated about SVG Fonts was the inverted coordinate
    system
    ... is there any possibility for us resurrecting SVG Fonts in a
    way, by embedding an OpenType font in the document?

    ChrisL: the XML serialization of OT, UFO, is very verbose
    ... the binary format is very compact, lots of tables with
    bytes
    ... by the way, WOFF is a way to wrap up any sfnt font

    Tav: would it be possible to have the table information in the
    font, but feed in the SVG glyphs to it?

    ChrisL: that would be interesting
    ... there is a demo of that, but it's kind of hacky
    ... roc made it. you load in an OpenType font, and gives you a
    textarea to enter some SVG, wraps it up and sticks it into the
    table, generates an OpenType font

    Tav: I tried to do this with inkscape, but I ran into trouble
    since we use Pango for text layout, which doesn't let you
    insert a user font
    ... I was going to intercept the layout information from Pango,
    and just draw the SVG glyph

    ChrisL: I should say, Behdad Esfabod has been at these meetings
    and is aware of this
    ... and is interested in adding this to Harfbuzz

    shepazu: maybe not right now, but this is a useful use case to
    pursue in the future

    Tav: yeah. it's a way of getting your cake and eating it too.
    ... basically saying OpenType handles all the nasty i18n layout
    stuff, and we provide a glyph

    ChrisL: one thing people brought up was that they've looked at
    SVG for the first time, and noticed that SVG has text in it
    ... what if text has fonts on it
    ... do you have a glyph with the same font?
    ... and they've followed the CSS2 reference and thought you
    need to support all the old font formats
    ... but there is a possibility we might be asked down the line
    to produce a subset for SVG for this
    ... maybe we shouldn't prompt this, but if asked we should

    shepazu: if it's well in the scope of Integration...

    ChrisL: integration is already being referenced for secure
    mode, secure animated mode

    <shepazu>
    [32]http://lists.w3.org/Archives/Public/www-svg/2014Jan/0039.ht
    ml

      [32] http://lists.w3.org/Archives/Public/www-svg/2014Jan/0039.html

    shepazu: I had a conversation with the guys from Decotype
    ... they were asking about SVG fonts, told them about groovy
    fonts
    ... they're trying to do arabic

    ChrisL: they also talked to me, and they're basing their stuff
    on altGlyph

    shepazu: I told them it's going away, and they said oh that's
    not a problem, we can do it another way
    ... but their use case is, the groovy font use case
    ... and it ties in to wanting to have shape selection in SVG
    ... I'd like to talk to you guys about ramifications of that
    ... the idea of being able to select shapes as well as text
    ... I don't know the UI for that, or care
    ... but we should say when something is selected
    ... this could also play into copy and paste of graphics, and
    annotations
    ... and that would feed into groovy text as well

    [doug draws groovy text on the board. again!]

    ChrisL: maybe we should send a liaison statement to MPEG SC29
    WG whatever

    <scribe> ACTION: Chris to send Cameron an email with details on
    how to send a liaison statement to MPEG about SVG in OpenType
    [recorded in
    [33]http://www.w3.org/2014/01/30-svg-minutes.html#action04]

    <trackbot> Created ACTION-3564 - Send cameron an email with
    details on how to send a liaison statement to mpeg about svg in
    opentype [on Chris Lilley - due 2014-02-06].

    <ChrisL> [34]http://letterror.com/fontcatalog/ltr-federal/

      [34] http://letterror.com/fontcatalog/ltr-federal/

    <scribe> ACTION: Cameron to propose something for marking up
    graphics with equivalent text [recorded in
    [35]http://www.w3.org/2014/01/30-svg-minutes.html#action05]

    <trackbot> Created ACTION-3565 - Propose something for marking
    up graphics with equivalent text [on Cameron McCormack - due
    2014-02-06].

    ChrisL: there are different optical sizes, but they're
    different fonts, for the filling of the "No" glyphs
    ... we should support that using media queries in
    SVG-in-OpenType
    ... but it's not quite possible yet, we don't yet have an
    appropriate MQ to do this

    heycam: this is related to the zoom MQ that Takagi-san wants
    ... we should work out what we need for this and give input to
    Ted etc. who are looking at zooming

Percentage values on objectBoundingBox for content elements

    <ed>
    [36]http://lists.w3.org/Archives/Public/www-svg/2014Jan/0081.ht
    ml

      [36] http://lists.w3.org/Archives/Public/www-svg/2014Jan/0081.html

    ed: I think most people who responded to the mail said they
    preferred percenteages to be relative to the object bounding
    box and not the viewport

    krit: I think it should be oBB relative because browsers do
    bounding box dimension relative to the viewport dimension
    multiplied by percentage of viewport
    ... which is very confusing
    ... all browsers do that, that's interoperable behaviour

    Tav: Batik and Inkscape does it too

    krit: the specification says something different

    heycam: do you reckon anyone relies on it?

    krit: Illustrator partly, some examples do rely on what the
    spec says [i.e. different from impls]

    heycam: and what does the spec say?

    krit: it should be a percentage of the viewport
    ... this is when you say maskContentUnits="objectBoundingBox"

    Tav: it's kind of strange that the mask would move when you
    widen the SVG

    krit: yeah

    ed: how much content would break?

    krit: people don't tend to use percentages here, because they
    don't understand the behaviour, and use 0..1 instead

    Tav: Inkscape doesn't generate using % objectBoundingBox values

    heycam: do we have tests in the test suite which support the
    current weird behaviour?

    krit: don't think so

    heycam: I think I'd be ok to be the guinea pig to try changing
    the behaviour here and see if we get any bugs

    <cabanier_> Illustrator import would break since they resolve
    percentages wrt the viewport

    <Tav>
    [37]http://tavmjong.free.fr/SVG/BOUNDINGBOX/reference_box.svg

      [37] http://tavmjong.free.fr/SVG/BOUNDINGBOX/reference_box.svg

    Tav: not sure the spec is clear whether transforms on ancestors
    of these resource elements should be taken into account

    ChrisL: if there's specific wording in the spec you should
    suggest that
    ... we should add an example in test suite for that too to file
    a bug on rsvg

    <scribe> ACTION: Tav to think of text to clarify whether
    transforms are taken into account with % objectBoundingBox
    values in resource elements [recorded in
    [38]http://www.w3.org/2014/01/30-svg-minutes.html#action06]

    <trackbot> Created ACTION-3566 - Think of text to clarify
    whether transforms are taken into account with %
    objectboundingbox values in resource elements [on Tavmjong Bah
    - due 2014-02-06].

    -- lunch break --

    <ChrisL> scribenick: chrisl

event handler attribute reflection

    ed: need wording to replicate what html5 has abour reflection
    in IDL and on-* attributes

    heycam: yes we do

    ed: reference html5 directly

    ChrisL: yes, unless its super specific

    <scribe> ACTION: erik to add ref to html5 for attr reflection
    [recorded in
    [39]http://www.w3.org/2014/01/30-svg-minutes.html#action07]

    <trackbot> Created ACTION-3567 - Add ref to html5 for attr
    reflection [on Erik Dahlström - due 2014-02-06].

renaming svg resize and scroll events

    ed: html5 has resize and scroll events, not exatly same as svg
    which is specific to a fragment

    (checks)

    ed: resize is targetted to rootmost svvg element

    heycam: (what about namespace boundaries)

    only within an svg document fragment

    krit: what is it for object or embed

    heycam: the same
    ... suprised if people are listening to svg resize on outer
    html

    krit: relative sized inline svg, change window size

    heycam: no need to worry about svg fragments in html inline.
    probably listening on html doc at the top or on window

    shepazu: unless we find somethin unliveable users will find a
    way to do this
    ... do what hytml does. but new editor is not unfamiliar with
    svg and will understand the use cases
    ... if we need changes we should say

    heycam: not aware of anything needing to change. renaming is ok
    ... try it and look for breakage

    ed: exposed on html body and window

    <ed> The onblur, onerror, onfocus, onload, onresize, and
    onscroll event handlers of the Window object, exposed on the
    body element, replace the generic event handlers with the same
    names normally supported by HTML elements.

    <ed> (from html5)

    ChrisL: so change body to body or svg

    heycam: they are actually listening to windopw

    ChrisL: we need to say they are exposed on svg element also

    ed: same for load event on window
    ... already have some wording for load events to make svg roots
    behave like body

    <ed> The ‘svg’ element exposes as event handler content
    attributes a number of the event handlers of the Window object.
    It also mirrors their event handler IDL attributes.

    <ed> (from svg2)

    ChrisL: so same wording for the others

    heycam: "a number" is vague

    ed: links to html5 to list them

    <ed>
    [40]https://svgwg.org/svg2-draft/struct.html#SVGElementEventHan
    dlerAttributes

      [40]  
https://svgwg.org/svg2-draft/struct.html#SVGElementEventHandlerAttributes

    ed: need to explicitly list them

    resolved: remove svg prefix on svgresize and svgscroll events

    action erik to remove svg prefix on svgresize and svgscroll
    events

    <trackbot> Created ACTION-3568 - Remove svg prefix on svgresize
    and svgscroll events [on Erik Dahlström - due 2014-02-06].

scaling back features that suck performance

    heycam: hearing about wanting to better handle conent on lower
    performance machines
    ... working out what to do. if hardware is there and the
    machine is slow, it works but at low fps
    ... several approaches to make the websites less beutiful but
    functional and responsive

    ChrisL: do you have specific things that slow down

    heycam: no its across the whole stack
    ... one approach is to come up with out own hueristics to scale
    back features, things to turn off
    ... eg filters, reduce rendering or switch off
    ... can conformance be relaxed to codify that
    ... do people think there are particular features to scale back

    ChrisL: worried about relaxed conf criteria being also taken as
    the typical rendering

    <ChrisL> heycam: hearing about wanting to better handle conent
    on lower performance machines

    <ChrisL> ... working out what to do. if hardware is there and
    the machine is slow, it works but at low fps

    <ChrisL> ... several approaches to make the websites less
    beutiful but functional and responsive

    <ChrisL> ChrisL: do you have specific things that slow down

    <ChrisL> heycam: no its across the whole stack

    <ChrisL> heycam: one approach is to come up with out own
    hueristics to scale back features, things to turn off

    <ChrisL> heycam: eg filters, reduce rendering or switch off

    <ChrisL> heycam: can conformance be relaxed to codify that

    <ChrisL> ... do people think there are particular features to
    scale back

    <ChrisL> ChrisL: worried about relaxed conf criteria being also
    taken as the typical rendering

    * Disconnected (No such device or address)

    ChrisL: in games is miostly user selected

    Rossen_f2f: if this is done by the user agent, afraid there
    will be fast disparity between implementations depending on
    internal efficiency
    ... so you get great disparity on the same device
    ... if they are automatic
    ... if the policy is across all devices they can be automatic
    (low medium high) as long as they are defined exactly what
    happens
    ... and user must have right to override that

    shepazu: could be user agent dependent

    heycam: to decide what to scale back, 2 approaches: spec what
    it means, or author indicates disposable features and priority

    ChrisL: authors will do what works on their UA, not test on
    otyhers

    Rossen_f2f_: ask performance wg about this

    krit: uas cvary so affect uas differently. does not necessarily
    help

    heycam: uas will auto adjust based on actual performance

    krit: not opposed to performance profiles

    Rossen_f2f_: same her, as long as testable and results will not
    vary by user agent at the same level on the same device
    ... figure out if it makes sense to sacrifice filters in medium
    or not (varies by UA)
    ... it will be sacrifice for sure

    birtles: if i have something with gpu optimisation, want to use
    that

    heycam: would not want to force user intervention
    ... bad to cripple the better implementation

    krit: use media queries for this
    ... author can decide what is important for high quality

    birtles: cant be entirely author device because many authors do
    not test widely

    heycam: bad to reduce functionality on a device that can do it

    ChrisL: have low medium high auto where auto scales by fps

    shepazu: engage with Khronos (webgl guys) about performance
    levels
    ... perfomance based characteristics. also did openvg
    ... willing to work with us. identified as a liaison item

    Rossen_f2f_: can argue both sides
    ... on mobile, browser defines the experience. need to get best
    experience possible on that device
    ... also depends on the competition

    heycam: now they can get different performance experience

    Rossen_f2f_: will also give behaviour changes

    shepazu: can we have best and worst levels for each feature
    ... say 2 uas on same hardware, one has hw accell on one thing
    is worse on something else
    ... so it would be predictsable what level it goes to
    ... level of service knocked out is independent

    Rossen_f2f_: so a minimum bar not an absolute bar

    shepazu: yes, and per feature
    ... so it is predictable

    heycam: that specificity would be good
    ... so there is a combinatorial explosion of profiles

    shepazu: maximises experience for user and author, also allows
    ua to compete on performance while still being predictable at a
    given level

    heycam: even if it is continuous, can reduce filer resolution
    for example, or should it be discrete

    shepazu: three levels

    Rossen_f2f_: low medium high

    heycam: imagine we discover that continuous perf improvement on
    filters with lower scale bitmaps. should they be allowed to
    vary or mnust they drop down to a discrete level

    shepazu: best is "do this or better"

    heycam: is that performance or rendering behaviour?

    shepazu: we set a minimum bar

    Rossen_f2f_: some impls could not make that

    Smailus: what defines what is in the profile, it changes over
    time

    Rossen_f2f_: if we have them, how does it benefit the content
    author to develop over device evolutions
    ... ua gets a better impl on the same device
    ... how would the content start to take advantage of that

    heycam: was thinking author would get perf benefir of scaling
    back features by defining how operations are done, including
    ignoring features
    ... not @media low-perf
    ... so when the usa meets te bar it uses high perf mode

    krit: these were requested four years ago already
    ... sometimes a drop shadow is purely decoration and you drop
    it

    Rossen_f2f_: media queries f=to get the current perf level

    krit: what if you still are too low perf. can you drop features

    heycam: what if you are medium level then set properties that
    use higher perf features
    ... worry about author access to perf tweaks because they age
    badly

    Rossen_f2f_: hard to define the matrix of allowed capabilities

    heycam: dont want to do that per device
    ... want it done automatically

    Rossen_f2f_: some devices will be "always high"

    heycam: dont want to test on lots of devices to get the perf.
    want guidelines on how to tel lif perf is inadequate

    ChrisL: is perf mai=nly in terms of fps

    heycam: yes
    ... can always have ginormous files, stil lwant to auto scale
    back for that

    shepazu: suggest we say its interesting buf not define today

    krit: not going anywhere concrete

    shepazu: open to proposals

a hazelnut in every bite

it goes to eleven

krit's keywords

    krit: (daws pretty pictures which we neglect to capture)

    bounding box of a stroke where there is dashing, taking into
    account miter limit, where the dashing does not cover the
    corner

    three options 1) actual painted area 2) geometric 3) maximal
    with miter limit and stroke geometry

    Rossen_f2f_: makes sense when ther is fill, not without

    krit: depends on miter limit

    birtles: and line cap

    (we don't want bounding box to oscillate if a dashed stroke
    animates start position)

    heycam: for beziers the exact tightest bound is expensive and
    not worth it eg for a repaint region

    cabanier_: mostly you want loose bounds
    ... make it as fast and loose as possible

    (discussion on getting data back from gpu)

    (which is hard and slow, by the way, and endlessly fascinating
    as a conversational topic)

    cabanier_: you get the box you need stroking

    heycam: can stroke with transparent paint, or compute in
    offscreen buffer

    shepazu: does anyone disagree with 3

    cabanier_: option 4 is convex hull of control points

    heycam: really want to avoid the marching ants problem

    birtles: if someone animates miter limit

    (no one really does)

    shepazu: asks about vector effects

    ChrisL: no implementor interest unfortunately

    cabanier_: should be a more precise version too

    shepazu: add several ones

    Rossen_f2f_: over engineering

    heycam: we should be doing that (markers, stroke, etc etc)

    krit: css gradients on object bounding box. only covers half
    the stroke!
    ... so we need something better
    ... choose stroke outline instead, for a decorated bbox

    Rossen_f2f_: exactly like semi transparent dashed borders over
    background

    heycam: bbox of control points, can we do same for stroke and
    say ignore dashing

    krit: backend engine needs to do it twice, once without dashing
    ... better to just look at points without rendering

    cabanier_: only fails with stupid miter limits

    krit: can happen

    heycam: polygon with exact points, stroke width 10px, what do
    you do

    krit: miter limit on slallest angle, add miter limit ...

    heycam: ignore ML. calc disatnace from lime by stroke width
    ... same as doing stroke path operation, same maths

    krit: so we need to do it twice

    heycam: fudge factor to pad convex hull bbox, proportional to
    stroke width

    ChrisL: added onto the four sides of the chull bbox

    <nikos> oops

    shepazu: people would find it counter intuitive

    krit: yes, now i am convinced on 3

    3 3 3 3 3 4 2 4 4

    cabanier_: perf will be really slow

    Rossen_f2f_: 3 on high, 4 on low ...

    shepazu: want to see some perf metrics and see how inaccurate 4
    is

    cabanier_: illustrator uses 4 for selection hilight

    heycam: add an issue in the spec

    shepazu: they will do the easiest one

    Rossen_f2f_: the most performance one

    shepazu: how often is bbox called

    heycam: for this new one, not at all :)

    krit: stroke bbox is in blink, not activated, gets used a lot

    birtles: in future decorated bbox will be called a lot

    krit: problem if filling with image, missing some pixels due to
    inaccuracy

    ChrisL: image size for the fill should not be affected by the
    exact position dashes fall

    <heycam>
    [41]https://hg.mozilla.org/mozilla-central/file/6f544aa66c1a/la
    yout/svg/nsSVGUtils.cpp#l1000 is what we use to work out an
    upper limit for the bbox of a stroked shape without actually
    calculating the stroke shape

      [41]  
https://hg.mozilla.org/mozilla-central/file/6f544aa66c1a/layout/svg/nsSVGUtils.cpp#l1000

    heycam: our calc for repaint region ignores miter limit, just
    stroke width
    ... so pad bbox by half stroke width

    <heycam> the input to that function is the bbox of the geometry
    that has already taken miter limit into account

    <heycam> or miters into account

    zakim?

    nikos, call into zakim plz

    krit: one dash on an ellipse ....

    <heycam>
    [42]http://lists.w3.org/Archives/Public/www-archive/2014Jan/001
    4.html

      [42] http://lists.w3.org/Archives/Public/www-archive/2014Jan/0014.html

    <heycam> ^ picture

    krit: want to add both methods to the spec and add an issue

    shepazu: representing authors and users. informed decision
    needs data

    birtles: best to gather data as we implement

    shepazu: ask the community, give the tradeoffs perf and
    precision

    krit: not happy, does not help until they implement so defers

    shepazu: option3 won the vote
    ... put issue saying maybe 4
    ... spec can be referenced at any level as long as the portion
    is stable

    (process explanations of stability criteria)

    action krit to add decorated bbox option 3 to svg2 with issue
    explaining option 4

    <trackbot> Created ACTION-3569 - Add decorated bbox option 3 to
    svg2 with issue explaining option 4 [on Dirk Schulze - due
    2014-02-06].

    break

    <heycam> -- 15 minute break --

    <birtles> Scribenick: birtles

    <scribe> Scribe: Brian

SVG2 status

    heycam: one concrete thing I'd like to discuss is out new
    cut-off date
    ... at TPAC we thought we needed more time
    ... so we extended it from the end of last year
    ... so we need a replacement date

    birtles: what is left?

    <heycam>
    [43]https://www.w3.org/Graphics/SVG/WG/wiki/SVG2_Requirements_C
    ommitments

      [43]  
https://www.w3.org/Graphics/SVG/WG/wiki/SVG2_Requirements_Commitments

    heycam: let's see what's left per-person

    <heycam> trackbot: close action-3271

    <trackbot> Closed action-3271.

    heycam: starting with Doug
    ... 19 - level of detail -- covered by zoom media queries which
    Takagi-san has been looking into and we are waiting on Ted's
    investigation into
    ... Cameron will mark this one yellow
    ... 20 - InkML trace groups -- covered by variable-width stroke
    ... 40 - Catmull-Rom curves - keep it
    ... 41 - Regular polygons and stars - keep it, work with Tav

    Doug: 47 - flip-invariant text - keep it, need to talk to
    others
    ... 52 - Tooltip - keep it, Dirk interested
    ... 91 - Bounding box text, Dirk to take
    ... 93 - content editable - Doug will look at another way of
    looking at editing markup but possibly not part of SVG2, remove

    heycam: unless you want to define how it should work if you
    have contentEditable on an ancestor HTML element

    shepazu: you should be able to edit the text

    heycam: we need to define that

    Doug: 100 - Support for key events from DOM level 3 events

    krit: didn't Rich ask about referencing DOM4?

    heycam: yes, I think he referenced DOM3 in the end

    Doug: close this issue, stuff has already happened in the spec
    ... 128 - define how border and background apply to SVG, keep
    it
    ... 129 - outline property, keep it
    ... 130 - clarify how pointer-events can hit the root SVG or
    not, Erik to take

    Chris: 28 - color management, closed
    ... 30 - non-scaling features (e.g. rectangle corners)

    krit: we don't want to extend that, we found too many issues
    with this
    ... defer it

    ChrisL: 48 - deprecate xml:space and use CSS white-space

    heycam: give the CSS part to Tav who is rewriting the text part

    ChrisL: 62 - linear interpolation for some properties which are
    currently discrete only -> pass to Brian
    ... 66 - remove requirement for width/height from foreignObject

    (discussion about whether this is possible and if we should do
    it for foreignObject only)

    ChrisL: it's a fairly simple fix for this case, I think

    krit: I don't know that it is

    heycam: if there's HTML content inside use the shrink-wrapping
    algorithm to work out the size
    ... it's like the minimum width that doesn't break a line, or
    something like that
    ... it's what you use with absolute positioning

    ChrisL: I'll do it
    ... 70 - CSS3 Color syntax - done
    ... 73 - Align CSS Value and Units

    heycam: I think I aligned some things but I haven't added new
    units etc.
    ... I'm happy to take it

    ChrisL: it's yours
    ... 76 - allow clip to reference any element

    krit: clip property is now deprecated

    <ed> [44]http://www.w3.org/Graphics/SVG/WG/track/issues/2355

      [44] http://www.w3.org/Graphics/SVG/WG/track/issues/2355

    heycam: that should actually be clip-path

    krit: this is actually now part of CSS masking
    ... but it won't be in the first level
    ... give the action to me

    (make it yellow)

    (means "handled in another spec")

    ChrisL: 82 - WOFF support - done
    ... 89 - viewport-fill(-opacity) / background-color

    (discussion about whether viewport units can be used to cover
    the use cases for this feature)

    scribe: keep it
    ... 92 - improved text re: characters/glyphs/selection etc.

    heycam: Tav is reworking a lot of text stuff now so it might be
    worth waiting to see what he's done

    ChrisL: I'll do it if he hasn't

    krit: add Tav's name to 92

    ChrisL: 115 - currentFillPaint, currentStrokePaint - done by
    heycam
    ... 119 - Use updated CSS3 specs - heycam to do
    ... 126 - Require SVG Tiny fonts - no, close with no action
    ... 127 - Make CSS mandatory - keep
    ... 131 - xlink prefix for href

    krit: I already defined this in CSS Masking

    ChrisL: I'll copy it from there

    krit: either there or filters

    ChrisL: 138 - allow masks to use alpha/luminance both - covered
    by CSS Masking
    ... 140 - masks pointing to mask elements only - covered CSS
    Masking + element()

    heycam: 1 - Backwards compat note - skip it
    ... 9 - markers done
    ... 10 - fix DOM, ongoing
    ... (lots of items done, good work Cameron!)
    ... 25 - data-* attributes, keep
    ... 26 - HTML5 global semantic attributes - keep it, need to
    check what is in HTML
    ... 27 - make property values case insensitive - I might have
    done it, need to check
    ... 33 - stroke dash adjustment - keep it, I'll see what I can
    do
    ... 36 - align the style element with the HTML5 style element,
    keep it
    ... 45 - glyph baselines
    ... the text chapter will reference CSS text for this
    ... keep it
    ... 49 - transforms on tspans - keep it

    <scribe> ACTION: Cameron to write spec text on transforming
    tspans [recorded in
    [45]http://www.w3.org/2014/01/30-svg-minutes.html#action08]

    <trackbot> Created ACTION-3570 - Write spec text on
    transforming tspans [on Cameron McCormack - due 2014-02-07].

    krit: does this belong in CSS transforms?
    ... if so please notify www-style

    heycam: do you list applicable elements in CSS Transforms?

    krit: yes

    heycam: ok, I'll do that then
    ... 54 - Support HTML document-wide events and make sure they
    apply to SVG document, keep it
    ... 57 - async and defer on script elements
    ... at first I thought this was a good idea but others
    including Hixie actually thought there was lots of craziness in
    HTML we don't want that
    ... keep it, possible drop it
    ... 69 - positioning information in MouseEvents, keep it
    ... 74 - deprecate baseline-shift, vertical align, keep it
    ... 80 - DOM method to convert <text> to outline path data

    cabanier_: that's part of the Canvas path API which is separate
    to Canvas

    heycam: but the requirement is to get actual path data
    ... so I can actually manipulate the path segments

    cabanier_: that might not be available then
    ... it might be possible
    ... it lets you get an opaque pointer to the outlines that you
    can do operations on it but not individual segments
    ... keep it
    ... 108 - inline scriptable content, keep it
    ... 109, 110 - more script stuff, keep it
    ... 118 - CSS3 definitions for text, keep it
    ... 121 - Move events to Element
    ... nothing to do (Hixie says no)
    ... 122 - Path rotation command - done
    ... 123 - Introduce evt as alias to event, give it to Erik
    ... 124 - object-fit, object-position, keep it
    ... 132 - remove restriction on tref, done

    krit: does tref still exist?

    heycam: in any case, it's already done

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

      [46] https://svgwg.org/svg2-draft/text.html#TRefElement

    birtles: 14 - fix path APIs, keep it, might still be needed
    depending on how DOM improvements go
    ... 96 - synchronization, make yellow (Web Animations)
    ... 111 - Changes to animation, move to Animation Elements spec
    (yellow)

    krit: 51 - video in SVG, Takagi-san did this already
    ... 75 - captions for video, Takagi-san did this too
    ... 139 - canvas in SVG2, Takagi-san did this too!
    ... 21 - transform on the <svg> element, keep this

    ed: 29 - non-scaling stroke, done
    ... 55 - drag&drop, we have the global event handlers

    heycam: we need to add a sentence to say this works in SVG

    ed: will do
    ... 71 - image-fit, this is now object-fit which Cameron will
    do
    ... 87 - buffered-rendering, done?

    heycam: now that we have will-change do we need it?

    ed: we could reconsider it?
    ... it's not the exact-same thing

    heycam: let's discuss this in a telcon later
    ... 88 - vector-effect, this is non-scaling stroke, done

    <heycam> ISSUE: should we have both buffered-rendering and
    will-change?

    <trackbot> Created ISSUE-2452 - Should we have both
    buffered-rendering and will-change?. Please complete additional
    details at
    <[47]http://www.w3.org/Graphics/SVG/WG/track/issues/2452/edit>.

      [47] http://www.w3.org/Graphics/SVG/WG/track/issues/2452/edit%3E.

    heycam: 116 - focal point for radial gradients, done by Dirk
    ... 117 - fr attribute for radialGradient, done by Dirk/Tav
    ... 125 - text-overflow, done
    ... 126 - SVG Tiny fonts, no longer needed

    cabanier_: 20 - variable-width stroke - will discuss tomorrow

    heycam: only others are Tab, Tav and Cyril
    ... for Tab, z-index

    (discussion about whether to keep it or not)

    scribe: keep it for now
    ... Cameron to look into it

    42 - arc in paths in easier

    heycam: I partly addressed this with the bearing commands
    ... we discussed adding all the canvas arc commands to SVG but
    I'm not sure
    ... assign it to Rik

    89 - This is just Chris now

    6 - namespace requirements, add Dirk

    8 - shadow tree, add Dirk

    39 - shared path segments, leave it with Cyril

    95 - animation element, covered by iframe work done by
    Takagi-san

    135, 136 - done in SVG2, Brian to remove from here and add to
    Animation Elements

    137 - playbackOrder - Brian to remove from SVG2 and maybe add
    to Animation Elements

    We'll cover Tav's items tomorrow

    heycam: those items without names associated we will not do
    since no one is interested

    birtles: so can we now estimate our next deadline?

    heycam: we should have a cut-off date for new features and then
    allow a few months for getting to LC
    ... and I think that cut-off date should be June 30

Summary of Action Items

    [NEW] ACTION: Cameron to propose something for marking up
    graphics with equivalent text [recorded in
    [48]http://www.w3.org/2014/01/30-svg-minutes.html#action05]
    [NEW] ACTION: Cameron to write spec text on transforming tspans
    [recorded in
    [49]http://www.w3.org/2014/01/30-svg-minutes.html#action08]
    [NEW] ACTION: Chris to send Cameron an email with details on
    how to send a liaison statement to MPEG about SVG in OpenType
    [recorded in
    [50]http://www.w3.org/2014/01/30-svg-minutes.html#action04]
    [NEW] ACTION: Erik to add onbegin, onend, onrepeat to
    SVGAnimationElement. [recorded in
    [51]http://www.w3.org/2014/01/30-svg-minutes.html#action02]
    [NEW] ACTION: erik to add ref to html5 for attr reflection
    [recorded in
    [52]http://www.w3.org/2014/01/30-svg-minutes.html#action07]
    [NEW] ACTION: Erik to clarify <script> is not affected by
    <switch> and will be run in there, but is still disallowed by
    the content model. [recorded in
    [53]http://www.w3.org/2014/01/30-svg-minutes.html#action01]
    [NEW] ACTION: Erik to mention in SVG 2 that rootElement is
    deprecated. [recorded in
    [54]http://www.w3.org/2014/01/30-svg-minutes.html#action03]
    [NEW] ACTION: Tav to think of text to clarify whether
    transforms are taken into account with % objectBoundingBox
    values in resource elements [recorded in
    [55]http://www.w3.org/2014/01/30-svg-minutes.html#action06]

    [End of minutes]
      __________________________________________________________


     Minutes formatted by David Booth's [56]scribe.perl version
     1.138 ([57]CVS log)
     $Date: 2014-01-31 01:09:40 $
      __________________________________________________________

      [56] http://dev.w3.org/cvsweb/~checkout~/2002/scribe/scribedoc.htm
      [57] http://dev.w3.org/cvsweb/2002/scribe/

Scribe.perl diagnostic output

    [Delete this section before finalizing the minutes.]
This is scribe.perl Revision: 1.138  of Date: 2013-04-25 13:59:11
Check for newer version at [58]http://dev.w3.org/cvsweb/~checkout~/2002/
scribe/

      [58] http://dev.w3.org/cvsweb/~checkout~/2002/scribe/

Guessing input format: RRSAgent_Text_Format (score 1.00)

Succeeded: s/Apirl/April/
Succeeded: s/something later/current work on defining zoom/
Succeeded: s/coloured/colored/
Succeeded: s/html fragments/svg fragments in html/
Succeeded: s/wirth/worth/
Succeeded: s/not/now/
Succeeded: s/pain/paint/
Succeeded: s/to tke/to take/
Succeeded: s/possibe/possible/
Found Scribe: Cameron
Found ScribeNick: heycam
Found ScribeNick: chrisl
Found ScribeNick: birtles
Found Scribe: Brian
Scribes: Cameron, Brian
ScribeNicks: heycam, chrisl, birtles
Default Present: +1.206.675.aaaa, nikos
Present: +1.206.675.aaaa nikos

WARNING: Fewer than 3 people found for Present list!

Agenda: [59]https://www.w3.org/Graphics/SVG/WG/wiki/F2F/Seattle_2014/Age
nda
Got date from IRC log name: 30 Jan 2014
Guessing minutes URL: [60]http://www.w3.org/2014/01/30-svg-minutes.html
People with action items: cameron chris erik tav

      [59] https://www.w3.org/Graphics/SVG/WG/wiki/F2F/Seattle_2014/Agenda
      [60] http://www.w3.org/2014/01/30-svg-minutes.html


    [End of [61]scribe.perl diagnostic output]

      [61] http://dev.w3.org/cvsweb/~checkout~/2002/scribe/scribedoc.htm


-- 
Using Opera's revolutionary email client: http://www.opera.com/mail/

Received on Friday, 31 January 2014 01:14:19 UTC