SVG Working Group Teleconference -- 11 Jul 2013

<trackbot> Date: 11 July 2013

<krit> argh

<krit> ScribeNick krit

<heycam> ScribeNick: krit

SVGDOM text takes textLength=0 into account?

<heycam> 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> 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 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

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

<ed> 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 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 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> 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> 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> 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 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> 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

- DRAFT -

SVG Working Group Teleconference

11 Jul 2013

Attendees

Contents