Minutes, 31 May 2012 SVG WG telcon

[forwarded from the member-only w3c-svg-wg mailinglist - ed]


Here are the meeting minutes of 2012/05/31 of the SVG WG:




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

                                 - DRAFT -

                      SVG Working Group Teleconference

31 May 2012



     See also: [3]IRC log

        [3] http://www.w3.org/2012/05/31-svg-irc





       * [4]Topics
           1. [5]SVG 2 update
           2. [6]seattle/paris F2F
           3. [7]SVG 2 styling
           4. [8]should we remove
           5. [9]Remove glyph orientation vertical and horrizontal
           6. [10]should we remove
           7. [11]Removing kerning property in favour for
           8. [12]Should opacity property apply to markers
           9. [13]Meaning of overflow: auto for SVG elements
          10. [14]overflow-x/overfllow-y
       * [15]Summary of Action Items

     <trackbot> Date: 31 May 2012

     scribenick krit

     <heycam> scribenick: krit

SVG 2 update

     ed: when do we publish first draft

     heycam: july

     ed: a lot of edits are not in the spec yet
     ... get the tings into the spec that you assigned for



     heycam: more actual spec edits

     ed: I did some edits
     ... like text-overflow
     ... I went through my actions and am working on some edits, but
     they are not yet ready to be committed
     ... any updates to discuss?

     cyril: can we have a link to the chapter where the edits were

     ed: on the wiki?

     cyril: yes, a link on the wiki to the change on the spec
     ... it could help

     Tav: it could move

     cyril: e.g z-index, where is it?

     Tav: I don't remeber :)

     cyril: found i


     Tav: might be good to have a link

     krit: Question, what styling on element definition?

     heycam: have not tried the lrecently one

     Tav: as a proposal, a table seems to be ok
     ... problems with table might be semantcis, but that is ok and
     can be fixed later
     ... SVG 1.1 has certain IDs that are used
     ... but there seems no trouble to switch to heycam proposal
     without it

     heycam: yes i think that is ok

     Tav: me too

     heycam: you are aksing because of edits that you are doing?

     krit: yes, I would like to have a style at the beginning

     heycam: can be changed later easily

     Tav: yes

     heycam: I finished most of marker stuff
     ... I am not happy about the 2nd part of the marker spec, but
     it can be discussed on the list

     cyril: I reviewed marker and have a list of changes, send it
     tomorrow to the list

     Tav: everyone is interessted on it, so it might be better

     cyril: I mean public list or wg list

     <cyril> we should use www-svg for technical discussion

     heycam: we should use www-svg

     general agreement to www-svg

     ed: next topic

seattle/paris F2F

     cyril: I made tests with Alan in Seattle
     ... he just used desktop client, we the equipment
     ... it worked
     ... the adobe equipment could work as well
     ... we have to confirm that the meeting are done as discussed



     cyril: I think the time slots of cameron are fine

     Tav: will we be able to call in?
     ... maybe i can go to seattle with the help of inkscape
     ... (small chance)

     cyril: I thought it would be helpful for people from europe

     Tav: yeah, but am not in paris at that time

     ed: I would come

     cyril: jwatt?

     heycam: unlikely

     cyril: who else would come to paris?
     ... so far we have 3?
     ... Is it worth to have a meeting in paris for just three?
     rooms are empty anyway
     ... we have polycom equ. so we have everything for video
     ... fine if we are just 3?

     ed: yes

     krit: did all people already assigned so far?

     cyril: 9 so far
     ... doug is not

     krit: I'll take car of hotel opertunities for seattle

     heycam: time is good. We can publish WD a couple of days later

     resolve: We go with the proposed time slots, meeting split to
     Seattle and Paris

     resolution: We go with the proposed time slots, meeting split
     to Seattle and Paris

SVG 2 styling



     krit: I just was not happy about the red color on elements
     ... continue with smaller and bold text for attributes and

     heycam: I am fine if there are solutions that make it better
     ... list of quted attribute or element list might look scarry

     krit: do you have an example?

     heycam: try to get an example?

     [19]https://svgwg.org/svg2-draft/shapes.html#RectElement --
     click the "show" next to "presentation attributes"

       [19] https://svgwg.org/svg2-draft/shapes.html#RectElement

     krit: looks ok for me
     ... quotes are inside of links on attributes and elements, but
     outside for properties

     heycam: I try to change it and look how it looks liek

     Tav: heycam: but it is good as it is

     has an example of this note

       [20] https://svgwg.org/svg2-draft/pservers.html#MeshGradients

     krit: current style looks great, will we have the same style on

     heycam: yes, with exception of background
     ... for WD, do we want to publish it without background colors?


       [21] https://svgwg.org/svg2-draft/text.html#TextOverflowProcessing

     krit: I think so, yes

     ed: that is fine for me
     ... yellow background should be reviewable text

     krit: but do we want to have backgrounds on WD at all?

     heycam: might be ok to have different styles for publishing WD
     ... we don't want to have annotations either

     krit: property and attributes have different blueish colors

     heycam: yes, planned

     krit: what for presentation attributes, should they be the
     attribute blue, or property blue?

     heycam: they should have the attribute blue



     krit: at the moement spec is not talking about presentation
     attr, but about the property, does this change for current
     attributes that move to presentation attributes as well?

     heycam: they might later, yes

     ed: next topic


       [23] http://lists.w3.org/Archives/Public/www-svg/2012May/0100.html

should we remove glyph-orientation-{horizontal,vertical}?

Remove glyph orientation vertical and horrizontal

should we remove glyph-orientation-{horizontal,vertical}?

     heycam: In CSS3 it will be a text orientation property
     ... it is not in gecko, but in opera and webkit
     ... is it ok to remove it yet?
     ... the current writing mode spec has some possibility to use
     the SVG orientation property
     ... so should this spec still have that? is it necessary?

     Tav: we might be the wrong people to ask

     heycam: since CSS has it, do we need it in SVG? Do we want to
     continue with CSS?

     krit: does CSS has angles for text orientation?

     heycam: might be limited
     ... but angle on SVG must be a multiple of 90deg


       [24] http://dev.w3.org/csswg/css3-writing-modes/#text-orientation0

     krit: upside down text is not possible for CSS

     heycam: yes
     ... not sure about vertical text implementations

     Tav: inkscape has it

     krit: webkit as well

     ed: opera has some support for it

     heycam: Iam aslo happy to keep it in the spec



     nikos: Is it already deprecated?

     heycam: I think so
     ... maybe not
     ... if people are confortale enough we can remove it.
     ... or first deprecating?

     Tav: I don't know

     nikos: we need feedback from japan first

     ed: doe we have an action for someone?

     heycam: yes

     <scribe> ACTION: heycam will look into how removing
     GlyphOrientationHorizontalProperty would influence the web
     [recorded in

     <trackbot> Created ACTION-3299 - Will look into how removing
     GlyphOrientationHorizontalProperty would influence the web [on
     Cameron McCormack - due 2012-06-07].

Removing kerning property in favour for font-kerning


       [27] http://lists.w3.org/Archives/Public/www-svg/2012May/0101.html

     <heycam> letter-spacing

     heycam: only webkit implements kerning
     ... it gives posibility to override kerning of font
     ... and turn off automatical kerning
     ... font-kerning can turn on and off automatic kenring\
     ... you could get all functionality of kerning with turn off
     kerning with font-kerining and letter-spacing
     ... do we want to remove duplicated behavior?

     ed: I think so

     krit: the quetion is if authors can still rely on specs, if we
     remove parts that are specified later.

     heycam: if implementations haven't picked up things, we are in
     a lucky position that we still can change behavior

     ed: on the other hand kerning is more doing letter-spacing, so
     it is not doing what it suposed to

     heycam: I was able to find 5examples where kerning was used

     krit: is it already deprecated?

     heycam: it is not

     krit: At least we can agree to deprecate it

     heycam: as longer it remains on the spec, as more likely it
     will be used
     ... my preference is to remove it

     krit: I don't have a strong feeling

     ed: any objections to remove it?

     resolution: remove kerning from spec
     ... remove kerning property from SVG spec

     Tav: we should note that it got removed and how to get the same

     heycam: good idea

     <scribe> ACTION: heycam remove kerning and mention to use
     font-kerning and letter-spacing instead [recorded in

     <trackbot> Created ACTION-3300 - Remove kerning and mention to
     use font-kerning and letter-spacing instead [on Cameron
     McCormack - due 2012-06-07].

Should opacity property apply to markers

     krit: does spec disallow it?

     heycam: no
     ... question is from implementations point of view

     krit: would be more interessting to have marker and stroke as
     one piece

     <ed> so this is talking about <marker
     opacity="0.5">...</marker>, right?

     heycam: I know what you mean, could be interessting

     <heycam> ed, yes

     Tav: we could use the new keywords

     krit: that wouldn't solve the problem that you see that they
     are not one piece

     nikos: that is something the nec compositing spec can help
     with, let me find a link

     krit: the spec does allow opacity on markers, so you are asking
     for disallowing it explicitly?

     <nikos> if they're in a knock-out group it would solve the
     problem of the stroke and the marker looking like different


       [29] https://dvcs.w3.org/hg/FXTF/rawfile/tip/compositing/index.html

     <nikos> section 8.3 I think you were referring to Cam

     heycam: not really. Just wanted to discuss it, was not aware
     that it is allowed at that point

     nikos: was added by rik, and he propably want to work more on

     heycam: looks like we can get the behavior that dirk wants

     krit: well, we were asked about it on webkit

     (talks about marker and stroke being one unit)

     ed: sounds reasonable

     <heycam> ISSUE: consider allowing stroke and markers to be
     rendered as one unit wrt opacity

     <trackbot> Created ISSUE-2443 - Consider allowing stroke and
     markers to be rendered as one unit wrt opacity ; please
     complete additional details at
     [30]http://www.w3.org/Graphics/SVG/WG/track/issues/2443/edit .

       [30] http://www.w3.org/Graphics/SVG/WG/track/issues/2443/edit

     <g opacity="0.5"><line marker="url()"></g>

     <heycam> ISSUE-2443: Maybe the Compositing spec will allow

     <trackbot> ISSUE-2443 Consider allowing stroke and markers to
     be rendered as one unit wrt opacity notes added

     ed: next topic?

Meaning of overflow: auto for SVG elements

     krit: is it about overflow-x/-y

     heycam: related
     ... in CSS it means scrollbars if if affects a bigger region
     ... in SVG means the same as visible
     ... auto means in CSS never paint outside the bix, while in SVG
     always outside the box
     ... proposal: change behavior to CSS described behavior
     ... the current behavior of gecko

     ed: might cause more clipping and perf lost on SVG

     heycam: auto is not the default value

     ed: true, hm not sure

     krit: I would agree heycam because of consitence with cSS spec

     ed: I am not sure if the CSS definition even applies to SVG
     since there's no scrolling in svg

     heycam: For me it is more about scrolling
     ... in HTML content it will clip to the content
     ... no scrollbars
     ... so it is more like hidden invisible
     ... overflow: scroll means the same a overflow: hidden in SVG

     ed: I think heycam arguments are good

     <ed> I'd agree that auto is more similar to scroll, which in
     svg is the same as hidden

     heycam: anyone against changing defintion of overflow: auto

     resolution: Accept the proposal of heycam to go the CSS way for
     overflow: auto

     <scribe> ACTION: heycam will change behavior to CSS way for
     overflow: auto [recorded in

     <trackbot> Created ACTION-3301 - Will change behavior to CSS
     way for overflow: auto [on Cameron McCormack - due 2012-06-07].



       [32] http://lists.w3.org/Archives/Public/www-svg/2012May/0094.html

     heycam: should both apply the same way like for HTML
     ... don't see any reason why we shouldn't do that

     krit: think it can be a benefit for authors

     ed: it is not more confusing than having CSS Transforms on box
     ... what is the usecase in SVG?

     krit: different clipping behvairo

     heycam: how is it done on webkit?

     krit: not fully sure



     heycam: anyway, implementations are different now

     krit: any conclusion?

     ed: we should at least define what it should do
     ... would like to see more usecases, but it might make sense

     <scribe> ACTION: heycam will work on usecases for overflow-x/-y
     [recorded in

     <trackbot> Created ACTION-3302 - Will work on usecases for
     overflow-x/-y [on Cameron McCormack - due 2012-06-07].

     RRSAgent: make minutes

Summary of Action Items

     [NEW] ACTION: heycam remove kerning and mention to use
     font-kerning and letter-spacing instead [recorded in
     [NEW] ACTION: heycam will change behavior to CSS way for
     overflow: auto [recorded in
     [NEW] ACTION: heycam will look into how removing
     GlyphOrientationHorizontalProperty would influence the web
     [recorded in
     [NEW] ACTION: heycam will work on usecases for overflow-x/-y
     [recorded in

     [End of minutes]

      Minutes formatted by David Booth's [39]scribe.perl version
      1.136 ( [40]CVS log)
      $Date: 2012/05/31 22:34:55 $

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

Scribe.perl diagnostic output

     [Delete this section before finalizing the minutes.]
This is scribe.perl Revision: 1.136  of Date: 2011/05/12 12:01:43
Check for newer version at

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

Guessing input format: RRSAgent_Text_Format (score 1.00)

Succeeded: s/I get throw my actions but did not commit yet/I went throu
gh my actions and am working on some edits, but they are not yet ready
to be committed/
Succeeded: s/heycam/    cyril/
Succeeded: s/heycam/cyril/
Succeeded: s/??/nikos/
Succeeded: s/applies to SVG/applies to SVG since there's no scrolling i
n svg/
Found ScribeNick: krit
Inferring Scribes: krit

WARNING: No "Present: ... " found!
Possibly Present: Doug_Schepers ISSUE ISSUE-2443 P20 P21 P25 Tav aaaa c
yril ed glenn heycam https krit nikos resolve scribenick thorton trackb
You can indicate people for the Present list like this:
          <dbooth> Present: dbooth jonathan mary
          <dbooth> Present+ amy



WARNING: No meeting chair found!
You should specify the meeting chair like this:
<dbooth> Chair: dbooth

Found Date: 31 May 2012
Guessing minutes URL:
People with action items: behavior change heycam kerning mention remove

       [43] http://www.w3.org/2012/05/31-svg-minutes.html

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

     End of [44]scribe.perl diagnostic output]

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

Erik Dahlstrom, Core Technology Developer, Opera Software
Co-Chair, W3C SVG Working Group
Personal blog: http://my.opera.com/macdev_ed

Received on Friday, 1 June 2012 11:33:57 UTC