Meeting minutes 11-7-2013 SVG WG

Hi all,

Here are the meeting minutes from 11-7-2013 SVG WG http://www.w3.org/2013/07/11-svg-minutes.html

Greetings,
Dirk

   [1]W3C

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

                               - DRAFT -

                    SVG Working Group Teleconference

11 Jul 2013

   [2]Agenda

      [2] http://lists.w3.org/Archives/Public/public-svg-wg/2013JulSep/0002.html

   See also: [3]IRC log

      [3] http://www.w3.org/2013/07/11-svg-irc

Attendees

   Present
   Regrets
   Chair
          ed

   Scribe
          krit, heycam

Contents

     * [4]Topics
         1. [5]SVGDOM text takes textLength=0 into account?
         2. [6]should textLength=0 disable rendering
         3. [7]behavior lengthAdjust=spacing wehn glyphs are wider
            as specified text length
         4. [8]thoughts on lengthAdjust modes
         5. [9]continuing (or not) to mint new integer constants
            for existing IDL attributes
         6. [10]filterRes attribute on <filter> element
         7. [11]removing xmlns from the spec
     * [12]Summary of Action Items
     __________________________________________________________

   <trackbot> Date: 11 July 2013

   <krit> argh

   <krit> ScribeNick krit

   <heycam> ScribeNick: krit

SVGDOM text takes textLength=0 into account?

   <heycam>
   [13]http://lists.w3.org/Archives/Public/www-svg/2013Jul/003.htm
   l

     [13] http://lists.w3.org/Archives/Public/www-svg/2013Jul/003.html

   heycam: text chaper doesn't say how they affect the SVGDOM

   <nikos> /me had a blank. what's the passcode?

   heycam: explains mail of link

   ed: for text computed length, not sure. you give textlength by
   setting text length
   ... not sure, but we should not return that value
   ... you want computed thing

   heycam: should we have different values for text substring
   length?

   ed: hm
   ... substringlength, how does it work?
   ... look
   ... same as textcomuputelength but not all the length

   heycam: yes, should work on scaled glpoh?

   s/glyoh/glyph/

   heycam: tesxt comp length the only one that differs

   ed: should we have two dfferent methods?

   heycam: maybe?

   ed: haven;t used substringlength that much, so don't konw

   heycam: have no strong feeling

   ed: what do UAs do?

   heycam: doing it right now
   ... FF substrlength works on original length
   ... seems unclear
   ... chrome also returns original unscaled length of substring

   <heycam> [14]http://mcc.id.au/temp/tl.svg

     [14] http://mcc.id.au/temp/tl.svg

   krit: Safari 22
   ... IE10 99.999

   heycam: well then...

   krit: presto has 22 as well

   heycam: Batik 100.5
   ... think prefer unscaled

   ed: yeah

   krit: do you get the 100 somehow else?

   heycam: is the value of textLength

   krit: then I am in favor for 22

   RESOLUTION: getSubstringLength does not take other text metrics
   into account and returns unscaled text length

   <scribe> ACTION: heycam will make getSubstringLength not take
   other text metrics into account and returns unscaled text
   length in spec [recorded in
   [15]http://www.w3.org/2013/07/11-svg-minutes.html#action01]

   <trackbot> Created ACTION-3510 - Will make getSubstringLength
   not take other text metrics into account and returns unscaled
   text length in spec [on Cameron McCormack - due 2013-07-18].

should textLength=0 disable rendering

   heycam: yes
   ... spec does not explicitly say what happens for textlengh=0.
   stop rendering? ignore attribute?
   ... 2 options 1) disable rendering 2) normal text length
   ... or third one: not disable rendering but really scale to one
   dimension

   krit: do we also scale stroke?

   heycam: think spec is not clear but would expect stroke not
   scale

   krit: have an example?

   heycam: not right now, but can make one

   Tav: discussion is silly
   ... it is meant to be for small changes on text length, not for
   extreme values, just for small corrections

   heycam: think you are right

   krit: we could still specify edge cas

   e

   <heycam> [16]http://mcc.id.au/temp/tl2.svg

     [16] http://mcc.id.au/temp/tl2.svg

   <ed> [17]http://jsfiddle.net/95QSD/

     [17] http://jsfiddle.net/95QSD/

   krit: examples show that stroke is not scaled

   heycam: Tab would be in favor to scale down to 1D
   ... think I agree

   Tav: agree as well

   RESOLUTION: Scale text to 1 dimension on textLength=0

   <scribe> ACTION: heycam modify spec to Scale text to 1
   dimension on textLength=0 [recorded in
   [18]http://www.w3.org/2013/07/11-svg-minutes.html#action02]

   <trackbot> Created ACTION-3511 - Modify spec to Scale text to 1
   dimension on textLength=0 [on Cameron McCormack - due
   2013-07-18].

behavior lengthAdjust=spacing wehn glyphs are wider as specified text
length

   heycam: odd behavior when engthAdjust=spacing when text length
   less than widest glyph
   ... in FF 10 we ended up positioning other glyphs to first one
   ... think Chrome did it as well
   ... it ends up shifting glyphs
   ... but don't think it is useful behavior
   ... ddaly suggested setting text length to width of widest
   glyph

   ed: seems reasonable

   heycam: all glyohs would be aligned right
   ... like glyphs getting closer and closer

   RESOLUTION: minumum textLength is the width of wides glyph when
   lengthAdjust=spacing

   <scribe> ACTION: heycam to change spec to set minumum
   textLength to width of wides glyph whenlengthAdjust=spacing
   [recorded in
   [19]http://www.w3.org/2013/07/11-svg-minutes.html#action03]

   <trackbot> Created ACTION-3512 - Change spec to set minumum
   textLength to width of wides glyph whenlengthAdjust=spacing [on
   Cameron McCormack - due 2013-07-18].

thoughts on lengthAdjust modes

   heycam: have 2

   <heycam>
   [20]http://lists.w3.org/Archives/Public/www-svg/2013Jul/0012.ht
   ml

     [20] http://lists.w3.org/Archives/Public/www-svg/2013Jul/0012.html

   heycam: first scale text in both dimension instead just
   horizontal
   ... it often might be preferable glyphs looking ok when scaled

   Tav: not sure if that is the case

   <richardschwerdtfeger> I need to answer a call. I will stay on
   IRC

   Tav: specially on buttons when you have different text length
   and the font size looks different then

   heycam: you are right

   ed: maybe we should specify a box and let text fit the box?
   might not help as well

   heycam: sounds complicated

   Tav: think this is a 5% max change
   ... mainly dependent on font
   ... don't see a need to change the height at all

   heycam: you can get quite diffeent length from the same text
   but different length

   Tav: you hope that the author has a good fallback

   <heycam> [21]http://mcc.id.au/2013/textLength.svg

     [21] http://mcc.id.au/2013/textLength.svg

   Tav: you can find fonts that are quite different
   ... at Chrome, right one looks fine

   heycam: doesn't look bad

   Tav: you just have an extreme example

   heycam: ok
   ... 2nd one was making textlength adjustment only to do when
   scaling down but not up

   ed: sounds like a min max thing

   Tav: don't make it too complicated!!!

   heycam: ok

continuing (or not) to mint new integer constants for existing IDL
attributes

   <heycam>
   [22]http://lists.w3.org/Archives/Public/www-svg/2013Jul/0019.ht
   ml

     [22] http://lists.w3.org/Archives/Public/www-svg/2013Jul/0019.html

   heycam: discussed it on transforms
   ... when ever we have new enumeration values, we wouldn't
   introduce new numeric constance
   ... since that is a bit of an antipattern in he web
   ... we decided to not introdcue new constant number and return
   unknown value for new types
   ... and give an easier way to access to them
   ... new marker orient value has the same
   ... third would be unkonw instead of an constant value
   ... seems awkward
   ... Tab doesn't want new constants because this seems bad. not
   having it would authors force not to use it anymore

   ed: are there alternatives?

   <heycam> readonly attribute SVGAnimatedEnumeration orientType;

   <heycam> readonly attribute SVGAnimatedAngle orientAngle;

   <heycam> attribute DOMString orient;

   heycam: describes new attributes
   ... that is the easier way to get the types
   ... I forgot that we already have an alternative

   krit: means we don't want new constants?

   heycam: yeah, just was thinking the other day that it might not
   be that bad to add
   ... since there is oposition, we stay that course

   ed: fine with me

filterRes attribute on <filter> element

   <heycam> ScribeNick: heycam

   krit: filterRes can be specified by the author to reduce or
   increase resolution that the filter is operating in
   ... usually it's done to reduce the resolution so it operates
   faster

   … I've never seen a real life use case

   … it's unlikely the author can predict the right resolution for
   a particular device, and for this to be future proof

   … the question is whether this does more harm than good

   … and whether we should remove it from the spec

   … from the implementation PoV, Presto/Blink/WebKit implement it
   correctly, Firefox not that much

   ed: I think I've only seen it used properly for making things
   faster

   … typically that looks pretty bad

   … as you say, it's hard to predict the resolution of the target
   device

   krit: all devices have different resolutions

   … the way to calculate the filter changes over time, from
   software to hardware, so it make not make sense at all to do it

   … it could block some implementations

   ed: so you're suggesting to deprecate or remove it?

   krit: I'm more in favour of removing it directly, but would
   understand if people want to deprecate first

   …roc suggests to remove it immediately

   heycam: agree, if we think it's a bad thing, remove it straight
   away, not say we're going to remove it

   ed: which things does it affect? feColorMatrix?

   krit: feDisplacementMap maybe

   … and blur

   … every filter primitive is affected by filter resolution,
   really

   ed: I was thinking of kernelUnitLength

   krit: we could remove it from Filters, but have a note pointing
   to 1.1 and say that we removed it for this and this reason

   ed: wouldn't have a big impact on content, so would be fine to
   remove

   krit: with or without a note?

   Tav: I think you should put a note in

   heycam: sounds fine to me as well

   RESOLUTION: Remove filterRes from Filters spec, with a note
   pointing out why it was removed.

   <scribe> ACTION: Dirk to remove filterRes. [recorded in
   [23]http://www.w3.org/2013/07/11-svg-minutes.html#action04]

   <trackbot> Created ACTION-3513 - Remove filterRes. [on Dirk
   Schulze - due 2013-07-18].

removing xmlns from the spec

   Cyril: I had an action to remove the xmlns prefix

   … it wasn't so obvious. please let at my email.

   <krit> krit: ScribeNick

   <Cyril>
   [24]http://lists.w3.org/Archives/Public/www-svg/2013Jul/0023.ht
   ml

     [24] http://lists.w3.org/Archives/Public/www-svg/2013Jul/0023.html

   <ed> ScribeNick: krit

   Cyril: we have 3 attributes taking the xlink prefix
   ... one is deprected anyway
   ... for xml:base
   ... there is an issue in the draft talking about the base
   element in HTML
   ... in HTML it allows it in the HMTL namespace but just for XML
   element, for all others, the base attribute is used
   ... either we keep xml:base, do it HTML5 way
   ... or keep it in no ns
   ... see email for details

   <Cyril> "conference is restricted at this time"

   <Cyril> I'll continue on IRC

   <Cyril> what do people think?

   <Cyril> how should we clean the xml:base thing ?

   <heycam> I think xml:base="" is not useful

   <heycam> I don't think we should add a base=""

   <heycam> if anything, add <base> like HTML

   <Cyril> should we go the HTML way: keep xml:base and add base ?

   <heycam> but even then I would avoid it unless people think
   it's useful :)

   <Cyril> so you would prefer just having the <base> element?

   <heycam> so there is a difference

   <heycam> <base> applies to the entire document

   <heycam> xml:base="" applies only to the subtree that it is on

   <Cyril> yes, there can be only one <base> element

   <heycam> I would be surprised if people are using xml:base="",
   to be honest

   <Cyril> should we aks the HTML WG if they will keep it ?

   <heycam> well

   <heycam> I think maybe keeping xml:base="" behaviour, in XML
   documents, is needed

   <heycam> since it's something the XML spec describse

   <Cyril> so we would go for option d) in my email then?

   <heycam> what about open e)

   <heycam> *option

   <heycam> leave xml:base=""

   <heycam> don't introduce <base> :)

   <heycam> forsake SVG-in-HTML users

   <Cyril> ok

   RRSAgent: make minutes

Summary of Action Items

   [NEW] ACTION: Dirk to remove filterRes. [recorded in
   [25]http://www.w3.org/2013/07/11-svg-minutes.html#action04]
   [NEW] ACTION: heycam modify spec to Scale text to 1 dimension
   on textLength=0 [recorded in
   [26]http://www.w3.org/2013/07/11-svg-minutes.html#action02]
   [NEW] ACTION: heycam to change spec to set minumum textLength
   to width of wides glyph whenlengthAdjust=spacing [recorded in
   [27]http://www.w3.org/2013/07/11-svg-minutes.html#action03]
   [NEW] ACTION: heycam will make getSubstringLength not take
   other text metrics into account and returns unscaled text
   length in spec [recorded in
   [28]http://www.w3.org/2013/07/11-svg-minutes.html#action01]

   [End of minutes]
     __________________________________________________________


    Minutes formatted by David Booth's [29]scribe.perl version
    1.138 ([30]CVS log)
    $Date: 2013-07-11 21:37:15 $
     __________________________________________________________

     [29] http://dev.w3.org/cvsweb/~checkout~/2002/scribe/scribedoc.htm
     [30] 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 [31]http://dev.w3.org/cvsweb/~checkout~/2002/
scribe/

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

Guessing input format: RRSAgent_Text_Format (score 1.00)

Succeeded: s/0//
Succeeded: s/glyoh/glpoh/
FAILED: s/glyoh/glyph/
Succeeded: s/substringlength/substringlength that much/
Succeeded: s/Tav/Tab /
Succeeded: s/whenlengthAdjust=spacing/when lengthAdjust=spacing/
Succeeded: s/think/thing/
Succeeded: s/to/too/
Succeeded: s/Opera/Presto/
Found ScribeNick: krit
Found ScribeNick: heycam
Found ScribeNick: krit
Inferring Scribes: krit, heycam
Scribes: krit, heycam
ScribeNicks: krit, heycam

WARNING: No "Present: ... " found!
Possibly Present: Cyril IPcaller P10 Rich_Schwerdtfeger ScribeNick TabAt
kins Tav aabb aacc aadd cabanier ed glenn heycam jaseg joined krit nikos
 pdr plh plinss richardschwerdtfeger stearns svg thorton trackbot xml
You can indicate people for the Present list like this:
        <dbooth> Present: dbooth jonathan mary
        <dbooth> Present+ amy

Agenda: [32]http://lists.w3.org/Archives/Public/public-svg-wg/2013JulSep
/0002.html
Found Date: 11 Jul 2013
Guessing minutes URL: [33]http://www.w3.org/2013/07/11-svg-minutes.html
People with action items: dirk heycam modify spec

     [32] http://lists.w3.org/Archives/Public/public-svg-wg/2013JulSep/0002.html
     [33] http://www.w3.org/2013/07/11-svg-minutes.html

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



   End of [34]scribe.perl diagnostic output]

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

Received on Thursday, 11 July 2013 21:39:27 UTC