SVG Working Group Teleconference -- 24 May 2010

<trackbot> Date: 24 May 2010

<ed> Focus for the first two days: finish SVG 1.1 F2

<ChrisL> hey guys i will be a long in a minute, just geting a taxi there from my hotel. sorry to be late

<ed> http://www.w3.org/Graphics/SVG/WG/track/products/1

<ChrisL> what room are you in (or is it signposted)?

<ChrisL> hey guys i will be a long in a minute, just geting a taxi there from my hotel. sorry to be late

<ChrisL> what room are you in (or is it signposted)?

<ed> there's a sign outside the door, it's just to the right after you enter

<ChrisL> thanks

<ChrisL> see you in a few

<shepazu> ChrisL: take a right out of the lobby, there's a sign on th wall, it's the Luxemburg room

<ed> moved ACTION-2386 to SVG 2.0, after discussion with jwatt and pdengler

<shepazu> AlexD: we're really just starting now

<shepazu> scribeNick: shepazu

<AlexD> Thanks shepazu!

ACTION-2386

ACTION-2676

<ed> http://www.w3.org/Graphics/SVG/WG/track/actions/2676

<ed> changes here: http://dev.w3.org/SVG/profiles/1.1F2/publish/svgdom.html#SVGDOMOverview

"Fix the 1.1 second edition wording for values that are accessed where no attribute was provided"

ed: in most cases, you get a 0 value if you get it through the DOM
... each attribute has a default value
... for example, on the svg element, width and height have a default value of '100%'
... and that is what's returned when you access it though the SVG DOM
... but it's not exactly clear in the spec....
... with the core DOM, getAttribute will give you 'undefined'

<pdengler> The spec states "If the attribute is not specified, the effect is as if a value of '100%' were specified."

<ed> data:image/svg+xml,<svg xmlns="http://www.w3.org/2000/svg"><script>alert(document.documentElement.width.baseVal.value)</script></svg>

jwatt: but it's not clear what svg.width.baseVal.value should be

ed: I think it makes more sense to initialize them all to the same value

pdengler: but it's useful to get and change that value

ChrisL: ok, it's more clear for width and height, but what about other attributes?
... width and height are special cases

ed: filterRes is an example where it changes
... and another is textLength, where it depends on the size of the text string

ChrisL: width and height are special so that it scales automatically

jwatt: I think if it's not defined, it should throw an exception
... we don't want users to get the wrong values

pdengler: what is the meaning of "the effect is as if"?

ChrisL: text-length allows an explicit override for text length, in case the actual length isn't correct
... we've got specific cases where a particular default value is defined, but where we haven't done that, we need to we need to define them

pdengler: the SVG DOM should reflect the default value

<ChrisL> The core dom has no knowledge of the element and attribute sematics while a specific dom does.

shepazu: I think it might confuse authors that .getAttribute and .baseVal.value returning different values would be confusing

ChrisL: but that's why we have the SVG DOM... it adds useful functionality for authors

ed: when you ask for a text element text-length and there wasn't one specified in the markup, you should get the same value as the SVG DOM function that defines the same value

<ed> getComputedTextLength

<ed> myTextElement.textLength.baseVal.value should be the same as myTextElement.getComputedTextLength()

<ChrisL> for text length, the textLength attribute is an override

shepazu: is this the long-term change we want?

ed: yes

ChrisL: we should include the list in the issue in the spec

ed: we can say that wherever it's not defined elsewhere, these values should be used

jwatt: if the filterRes attribute is not set, and you read the value from filterRes attribute value from the filterRes JS property (which will be 0), and set the value, it will disable rendering

<ed> i'm just checking the changlog, seems I did change it once, to be fully covering all types

<ed> http://dev.w3.org/cvsweb/SVG/profiles/1.1F2/master/svgdom.html.diff?r1=1.17&r2=1.18&f=h

ed: with the textLength, and you change the string, is it changed live?

ChrisL: yes, unless the value is set explicitly in the markup

<AlexD> How is that going to work? If textLength becomes the equivalent of getComputedTextLength then fonts need to be instantiated, etc. Doesn't make sense to me.

<ChrisL> alex, i just said that too

(bad scribing)

<AlexD> OK, sorry.

<ChrisL> well, you couldn't hear me from there :)

<ChrisL> i was agreeing with you

<pdengler> If the attribute is not specified, the effect is as if a value of '100%' were specified.

<jwatt> the spec says "If the attribute is not specified, the effect is as if the author's computation exactly matched the value calculated by the user agent"

ed: but percentages are relative to the viewport

<ed> break for lunch

<AlexD> Lucky I have the BBQ on, enjoy...

<ChrisL> problem is we want a default value that says "no scaling" and the value is a length, so it needs to be number, and 100% is relative to the viewport so won't work

<ChrisL> and "non" won't work either

<ChrisL> ok, lunch

<ChrisL> back from lunch

<ed> myTextElm.textContent ="mystring";

<ed> var foo = myTextElm.textLength.baseVal.value

<ed> myTextElm.textContent ="mystring updated with more text";

<ed> myTextElm.textLength.baseVal.value = foo;

<ed> what value does 'foo' have?

<jwatt> foo never changes

<jwatt> however

<jwatt> myTextElm.textLength.baseVal.value will change, then change back

<pdengler> scibenick: pdengler

<pdengler> scribenick: pdengler

shepazu: Let's go back to use cases. When woulod I as a developer want this.

jwatt: When is getComputedTextlength useful

ed: It's easier to use than bbox when you only want textlength as the string, because you have to use getbbox.width instead

shepazu: Ok, which is harder: text.getComputedTextLength() or getBbox().width

ChrisL: The textLength property has an effect on rendering (thus changing the boundingbox)

ed: getComputedTextLength() does not look at textlLength at all

shepazu: The use case is: find out what the textLength is so I can change soemthing else (put a box around it); change some other element to match the tetxLength

jwatt: All of those things can be done with get bbox

shepazu: Or I want to see if it's the right length and change it

ed: When you have a textLength attribute set, it might squeeze or stretch text

jwatt: But wouldn't that be the same as bbox?

ed: Yes, but it would not be getComputedTextLength()

shepazu: (on white board)

<AlexD> Isn't getBBox around all of the text, whilst getComputedTextLength handling advance width only? I thought that was the case, so fancy fonts have a longer GetBBox.width than what getComputedtextLength returns.

<ed> right

<ed> but getComputedTextLength also depends on the font as I read the spec

<ed> but it doesn't care about the 'textLength' attribute

<fat_tony> scribenick: fat_tony

<scribe> scribe: anthony

<pdengler> jwatt: the textength jscript property, if the textLength is not set, then the value should return the same value as getComputedtextLength()

<pdengler> jwatt: If it is set, then it will return what is set

<AlexD> Does that imply that textLength sets the advance width lengths as opposed to the Bbox lengths - I hope so...

<AlexD> i.e. the stretch/contraction based on char ABC widths etc. that only takes into account advance, not glyph extent.

Yes

Summary: Let's just postpone resolving the case where the text is not in the document

For the case where the textLength attribute is not set the textLength property will return the same value as the getComputedTextLength() method

<AlexD> Resolved, move on...

and add a note saying that 'when the textLength attribute is set, the values returned by the textLength property and by getComputedText() method will likely be different.'

<ed> will do the changes mentioned as part of ACTION-2676

<ed> http://www.w3.org/Graphics/SVG/WG/track/products/1

<ed> ACTION-2461?

<trackbot> ACTION-2461 -- Jonathan Watt to suggest some rewritten text for these suspend methods -- due 2009-02-23 -- OPEN

<trackbot> http://www.w3.org/Graphics/SVG/WG/track/actions/2461

<ed> moved to SVG 2.0

<ed> ACTION-2469?

<trackbot> ACTION-2469 -- Jonathan Watt to flesh out the intrinsic sizing erratum with text backported from 1.2T -- due 2009-02-24 -- OPEN

<trackbot> http://www.w3.org/Graphics/SVG/WG/track/actions/2469

<ed> moved to SVG 2.0

<ed> http://www.w3.org/Graphics/SVG/WG/wiki/Test_Suite_1.1F2

<ed> people doing actions on 1.1F2 and testsuite

We'll divide the testsuite work up

We need to fix the three fields in all the tests

Doug, you review from animate-dom-01-f.svg to filters-comptran-01-b.svg

Chris, you review from filters-conv-01-f.svg to painting-stroke-02-t.svg

JWatt, you review from painting-stroke-03-t.svg to struct-frag-05-t.svg

I will review from struct-frag-06-t.svg to types-dom-07-f.svg

<ChrisL> Run the test. No interaction required.

<AlexD> Have to leave now, happy reviewing.

filters-conv-01-f.svg to painting-stroke-02-t.svg

need to change operatorScript to "Run the test. No interaction required.

<ed> ok, starting on animate-elem-11-t

<ed> animate-elem-12 done

<pdengler> checked tests from filters-turb-02-f to fonts-elem-01-t

<ed> animate-elem-13 done

<ed> trackbot, end telcon

- DRAFT -

SVG Working Group Teleconference

24 May 2010

Attendees

Contents

ACTION-2386

ACTION-2676

Summary of Action Items

Scribe.perl diagnostic output