Meeting minutes 2014-03-13


here are the meeting minutes from March 13 2014:




                               - DRAFT -

                    SVG Working Group Teleconference

13 Mar 2014



   See also: [3]IRC log



          cabanier, krit, [IPcaller], heycam, nikos, stakagi,
          Rich_Schwerdtfeger, birtles, Tav, ed




     * [4]Topics
         1. [5]Shipping paint-order
         2. [6]meetin at TPAC
         3. [7]whit space attribute
         4. [8]SVG in open type fonts requirements
     * [9]Summary of Action Items

   <cabanier> meeting in an hour?

   cabanier: I think so, no?

   so 20min

   cabanier: we set the meeting to UTC instead of Boston time. So
   it is independent of time shifts

   <heycam> I wonder if I got it right in my message here


   <heycam> I said Pacific time would move from 1:30 to 12:30, but
   it's just coming up to 1:30 now...

   <heycam> maybe I got those two around the wrong way

   <cabanier> heycam: yes. it was 12:30. now it's 1:30

   <heycam> ok

   <heycam> no matter how many times I try to get timezones
   right... :)

   <heycam> trackbot, start telcon

   <trackbot> Date: 13 March 2014

   <nikos> [11]



   <scribe> ScribeNick: krit

Shipping paint-order

   heycam: Tav did you loo at it

   Tav: yes, in FF and Chrome
   ... works fine

   heycam: shall we resolve?

   krit: I created a patch for WebKit
   ... landing today or tomorrow
   ... unprefix and no compiler flag
   ... will be in webkit
   ... what di yoiu want to resolve?

   heycam: if it is ok to ship

   krit: I would say yes

   heycam: agree
   ... resoltuion

   nikos: sounds ok from what I hear

   RESOLUTION: The WG is happy with implementations shipping
   paint-order in release builds

   heycam: we sip erik's topics for now

meetin at TPAC

   heycam: the chairs were asked if we meet
   ... I think we decided already that we want
   ... but want to verify

   krit: last week in october

   Tav: in SF

   heycam: ppl are complaining having it over halloween

   krit: would like not to overlap with CSS WG
   ... think the CSS WG is meeting monday tuesaday already IIRC

   nikos: I think Doug expressed that he would like to meet early

   heycam: prefer monday tuesday but not overlap with CSS WG

   krit: think there will be possibilities to meet with other WGs
   from 111AM to 3PM
   ... I would be interested in meeting with the a11ky group

   richardschwerdtfeger: we are doing implementation guides for
   browsers too
   ... so good idea
   ... in CA?

   krit: yes Santa Clara

   richardschwerdtfeger: we did not talk about it yet
   ... a11ky will probably meet
   ... will meet with doug about ARIA

   krit: I would be interested

   richardschwerdtfeger: there is a lot that needs to come
   together to get a11ky working
   ... we are coordinating with HTML5 and other and maybe put it
   on github
   ... I will be editor on SVG2 A11ky guide
   ... will meet next week first time. Shall we do a task force?

   heycam: think it makes sense

   richardschwerdtfeger: shall the work be done on github

   heycam: what ever editors want to do

   richardschwerdtfeger: we are getting toward on DOM and one
   ... did someone work on tab index yet?

   krit: think ed did

   ed: working on it
   ... still in review
   ... hope to land it soon in Blink

   richardschwerdtfeger: I got a bug open on mozilla

whit space attribute



   ed: I want to modify attr parsing rules
   ... compared the types with HTML5
   ... to see if we have parsing differences
   ... covered research in the link
   ... some have additional restrictions on range for numbers or
   how many numbers you can specfiy
   ... mostly floats

   krit: I think in filters we have some integers

   ed: I'll get to it
   ... HTML5 has validation requirments
   ... no wsp before or after numbers
   ... but relaxed on other types
   ... in my testing sometimes leading whitespaces are allowed
   ... for HTML5

   ecdwanted to see if we are consistent on parsing rules

   ed: but couldn't quite tell
   ... not sure if it is consistent with how integers are allowed
   .. more relaxed
   ... HTML doesn't have many floating points anyway

   heycam: does what you said apply to most attributes or mainly
   ... and should we do that as well? it is not in your proposal

   ed: it is nicer if you can require properly written attribute
   ... maybe give validation errors but still accept it
   ... would like to have it constant between SVG and HTML

   krit: didn't you say that HTML is not consistent?

   ed: implementations are not consistent
   ... HTML is very clear although you have to read it forward and
   backward a couple of times
   ... so it is hard to get a clear picture what is excepted when

   heycam: do you want to di it by type?

   ed: seems fine
   ... yellow cells means "mostly" allow wsp
   ... integers are interpreted more or less the same in SVG and
   ... but for length and percentage might not be consistent

   krit: where do we support length and percentage in HTML?

   ed: don't think there is something like that in HTML

   krit: what about width <img>?



   ed: they just support integer
   ... but the spec is non-normative there



   ed: it says it has to be in CSS pixels

   krit: if there is a unit?

   ed: might be ignored
   ... don't think HTML5 has length attar values
   ... SVG has some
   ... most don't say that they take percentage



   heycam: I started this at some point

   krit: same for me
   ... in the past we just said length and it meant percentage as

   heycam: for coords it is the same

   ed: filters link to SVG1.1 for coord

   krit: I can remove <coord> from Filter effects if needed

   ed: don't think it is significant
   ... looked a t mesh gradients
   ... x, y are undefined how they parse
   ... there was a case with width on canvas and video that means
   ... we don't say what it maps tp


   heycam: we copied it from img
   ... would we support wsp for keyword + number?

   ed: don't think we allow yet

   heycam: ... would we allow wsp for length but not for the
   ... do you have a proposal?

   ed: not through all examples
   ... but would like to be consistent
   ... boolean -> particular rules bit no wsp and no true and
   ... don't think we have any rule for that
   ... id values mostly from ARIA
   ... and id attr itself
   ... text values allow mostly wsp
   ... some ignore wsp some take it as value
   ... but did not check all which take wsp and which don't
   ... event handlers content attributes are parsed to JS rules
   ... and allow wsp
   ... not to SVG to decide
   ... lang values are inconsistent
   ... have different definitions for that
   ... cause of land xml:lang source lang
   ... some allow lists some one vlaues
   ... browsing context values
   ... special parsing rules form html
   ... media queries allow wsp at least on <source?

   heycam: should allow wsp

   ed: would be nice to get tyne same defintion
   ... url's can have wsp
   ... SVG doesn't allow wsp's
   ... and IRI URI differences


   ed: are wsp's allowed for transforms?

   krit: yes they are

   heycam: sounds like we should not alliw wsp's for enumerations

   ed: for viewer UAs yes, not sure for validators

   heycam: think we should be consistent

   krit: we may need to consider if wsp can have a meaning
   sometimes. but most of the time it shouldn't. So I am fine with
   allowing wsp's

   ed: will write some tests to check interoperability between UAs
   and come back
   ... do we want to produce the tables automatically somehow?

   heycam: we can try that

   krit: is it important to know if UAs are interoperable if we
   discuss chaging the behavior?

   ed: would be nice to know what implementations do

   krit: sure but takes time
   ... did you want to check interop between implementaiotn on SVG
   or HTML and SVG?

   ed: want to check if one implementation in HTML parses each
   type or ignore the values
   ... want to verify if I understand HTML correctly
   ... then go on and check SVG

   krit: ok

   <scribe> ACTION: ed to test behavior on type parsing in HTML
   and SVG [recorded in

   <trackbot> Created ACTION-3600 - Test behavior on type parsing
   in html and svg [on Erik Dahlström - due 2014-03-20].

   heycam: so we come back to that next week?

   ed: yes

   heycam: we have 4 min left6

SVG in open type fonts requirements

   heycam: the OT spec with SVG glyph needs comments
   ... there is an open issue about text elements and foreign
   object? should it be disabled
   ... think w agreed on foreignObject
   ... but didn't discuss text
   ... but think it makes sense to not allow it
   ... would just be tricky to specify font usage
   ... specified on SVG1 but intention is unversioned

   krit: what about future elements?

   heycam: should we add a definition for a collection of elements
   in SVG integration spec
   ... ppl seem to like this approach

   krit: can that be done in a future version of OT SVG?

   heycam: it already references SVG integration and I would
   suggest to have a WD

   krit: don't think that I would want that for current version of
   SVG integration

   heycam: we can discuss that later

   krit: we discussed theree things to the last one: I'd suggest
   putting the collection of supported elements into SVG OT
   ... does MPEG allow referencing EDs?

   heycam: not sure, but that is what we do noe


   <heycam> current draft:


   krit: I would prefer having the collection

   heycam: would you be ok referencing integration spec?
   ... thnk comments are to next week and review is in April

   krit: don't think svg integration is ready till then

   heycam: shall I bring it up on the mailing list?

   krit: probably better

   trackbot, make minutes

   <trackbot> Sorry, krit, I don't understand 'trackbot, make
   minutes'. Please refer to
   <[18]> for help.


   trackbot, make minutes

   <trackbot> Sorry, krit, I don't understand 'trackbot, make
   minutes'. Please refer to
   <[19]> for help.


Summary of Action Items

   [NEW] ACTION: ed to test behavior on type parsing in HTML and
   SVG [recorded in

   [End of minutes]

    Minutes formatted by David Booth's [21]scribe.perl version
    1.138 ([22]CVS log)
    $Date: 2014-03-13 21:42:58 $


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 [23]


Guessing input format: RRSAgent_Text_Format (score 1.00)

Succeeded: s/TabAtkins/Tav/
Succeeded: s/would like to meet early/I think Doug expressed that he wou
ld like to meet early/
Succeeded: s/ed/krit/
Succeeded: s/heycam/ed/
Succeeded: s/ed/heycam/
Succeeded: s/asp/wsp/g
Succeeded: s/UAs/viewer UAs/
Succeeded: s/heycam/krit/
Found ScribeNick: krit
Inferring Scribes: krit
Default Present: cabanier, krit, [IPcaller], heycam, nikos, stakagi, Ric
h_Schwerdtfeger, birtles, Tav, ed
Present: cabanier krit [IPcaller] heycam nikos stakagi Rich_Schwerdtfege
r birtles Tav ed
Agenda: [24]
Found Date: 13 Mar 2014
Guessing minutes URL: [25]
People with action items: ed


WARNING: Input appears to use implicit continuation lines.
You may need the "-implicitContinuations" option.

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


Received on Thursday, 13 March 2014 21:45:47 UTC