SVG Working Group Teleconference -- 13 Mar 2014

<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 http://lists.w3.org/Archives/Public/public-svg-wg/2014JanMar/0116.html

<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> http://www.abito.de/

Scribe

<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 a11ky/
... 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

<heycam> https://www.w3.org/Graphics/SVG/WG/wiki/Proposals/AttributeWhitespace

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 numbers?
... and should we do that as well? it is not in your proposal

ed: it is nicer if you can require properly written attribute values
... 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 HTML
... 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> http://www.w3.org/TR/html5/infrastructure.html#valid-non-negative-integer

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

<ed> http://www.w3.org/TR/html5/embedded-content-0.html#attr-dim-width

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

<ed> https://www.w3.org/Graphics/SVG/WG/wiki/Proposals/AttributeWhitespace#Length_values.2C_type:_.3Clength.3E

heycam: I started this at some point

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

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 auto
... 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 keyword
... 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 false
... 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

+URL

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 http://www.w3.org/2014/03/13-svg-minutes.html#action01]

<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

now

<heycam> current draft: https://xa.yimg.com/kq/groups/12860955/740362423/name/w14124_14496-22_WD6_3rd_ed-redline%2Ezip

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 <http://www.w3.org/2005/06/tracker/irc> for help.

trackbot, make minutes

<trackbot> Sorry, krit, I don't understand 'trackbot, make minutes'. Please refer to <http://www.w3.org/2005/06/tracker/irc> for help.

- DRAFT -

SVG Working Group Teleconference

13 Mar 2014

Attendees

Contents

Shipping paint-order

meetin at TPAC

whit space attribute

SVG in open type fonts requirements

Summary of Action Items

Scribe.perl diagnostic output