SVG Working Group Teleconference -- 05 Mar 2015

<trackbot> Date: 05 March 2015

<scribe> Scribe: Cameron

<scribe> ScribeNick: heycam

computed value for <length>

<ed> https://lists.w3.org/Archives/Public/www-svg/2015Mar/0005.html

ed: I was reviewing the spec, and I found that we have some properties that use <length> grammar from CSS
... and in our spec we say what the computed value is
... for some of our properties we don't say "absolute <length>" for the computed value
... I propose we align with the rest of CSS and have <length> computed values be absolute

AmeliaBR: so the effect would be if you do getCS you would get the px value equivalent, rather than a percentage etc.?

ed: yes
... well percentage is special, but other units yes you would get px back

AmeliaBR: as you say, it's what CSS does

krit: percentage would still be a percentage in the computed value

ed: if no one objects to that, I'd be happy to udpate the spec

(no objection)

RESOLUTION: Properties defined in SVG will have <length> values compute down to absolute px values.

<scribe> ACTION: Erik to update SVG 2 to make properties with <length>s compute down to absolute px values. [recorded in http://www.w3.org/2015/03/05-svg-minutes.html#action01]

<trackbot> Created ACTION-3763 - Update svg 2 to make properties with <length>s compute down to absolute px values. [on Erik Dahlström - due 2015-03-12].

ed: we sometimes define the parsing as <length> | <percentage> | <number>
... but most numbers use <length> | <percentage>

AmeliaBR: I think there's text that says "a bare number is a length with an implicit unit"

<AmeliaBR> https://svgwg.org/svg2-draft/types.html#InterfaceSVGLength

<AmeliaBR> correction: https://svgwg.org/svg2-draft/types.html#syntax

<AmeliaBR> Quote: "The insertion of the <number> symbols allows for unitless length and angles to be used in presentation attribute while disallowing them in corresponding property values."

heycam: what I tried to do was make presentation attributes accept numbers implicitly (because properties defined in CSS specs don't include number explicitly)
... for properties defined in SVG, though, they include number explicitly

krit: I don't think we need wording here for presentation attributes
... because CSS defines that presentation attributes allow unit-less numbers

heycam: can you please give me a link to that text

<scribe> ACTION: Cameron Talk to Tab about implicit number units in properties [recorded in http://www.w3.org/2015/03/05-svg-minutes.html#action02]

<trackbot> Created ACTION-3764 - Talk to tab about implicit number units in properties [on Cameron McCormack - due 2015-03-12].

AmeliaBR: I wanted to clarify the wording you've got there: "unitless numbers can only be allowed in presentation attributes"
... whereas currently we allow unitless numbers in SVG-specific style properties
... like stroke-width
... even if you're declaring that in a style sheet
... would we be disallowing that?

krit: for these properties, they need to specify <number> as well
... stroke-dasharray, stroke-width, etc.

heycam: I did intend to put <number> explicitly in stroke-width etc.

krit: I don't think we want to have numbers on the geometry properties
... every new property should follow the general CSS way of defining properties
... stroke-width, stroke-dasharray, stroke-dashoffset and baseline-shift are the ones WebKit supports
... so for cx, cy, etc. we don't have the quirks mode enabled and so numbers aren't accepted

ed: for the geometry ones I haven't allowed numbers in blink either

AmeliaBR: do we want to add a note to encourage authors to always put explicit units?

heycam: yes I think that'd be good

krit: I think Tab suggested using quirks mode for these properties to get the numbers
... but adding <number> explicitly is fine as well
... I agree about adding a note

<scribe> ACTION: Add a note about avoiding unitless values [recorded in http://www.w3.org/2015/03/05-svg-minutes.html#action03]

<trackbot> Error finding 'Add'. You can review and register nicknames at <http://www.w3.org/Graphics/SVG/WG/track/users>.

<scribe> ACTION: Cameron Add a note about avoiding unitless values [recorded in http://www.w3.org/2015/03/05-svg-minutes.html#action04]

<trackbot> Created ACTION-3765 - Add a note about avoiding unitless values [on Cameron McCormack - due 2015-03-12].

AmeliaBR: so all existing presentation attributes accept number as an alternative to length

heycam: hypothetical question: if we introduced a new SVG property that wasn't previously an attribute, would we accept a number in the presentation attribute?

krit: I'd say yes

AmeliaBR: yes, good for consistency

ed: the remaining question in my email was regarding how units are supposed to be handled when you serialize or interpolate values while animating
... and I found that implementations differ
... was wondering if this was defined in CSS
... so getCS and CSS Animations
... what happens if you animate from 2em to 10ex for example?
... what happens to the values in between?

krit: I think there is no definition in CSS yet for this

ed: was just wondering if it's defined somewhere

heycam: shouldn't this be defined in Transitions/Animations?

<AmeliaBR> http://dev.w3.org/csswg/css-transitions/#animatable-types

krit: maybe should be, but isn't

"when both values are lengths, interpolated as lengths" ...

AmeliaBR: to go between 10px and 100%, you go beteween calc(10px + 0%) and calc(0px + 100%)

heycam: oh, I forgot transitions/animations work between computed values
... so you'll have two px values

SVG 2 Chapter Assessment

https://www.w3.org/Graphics/SVG/WG/wiki/SVG2_Chapter_Assessment

heycam: I only got 2 of my 3 chapters done

ed: since we started at the top last time, let's start at the bottom this time
... next available person, Text?

Text Issue 3 - semantics of foreignObject

Tav: there was an issue in the spec asking to define the semantics of foreignObject
... I'm not sure we even have to talk about foreignObject here at all

just before https://svgwg.org/svg2-draft/text.html#TextLayoutContentArea

"If more complex layout is required (bulleted lists, tables, etc.), text can be rendered in another XML namespace such as XHTML [XHTML] embedded inline within a ‘foreignObject’ element. (Note: the exact semantics of this approach are not completely defined at this time.) "

heycam: how about just turn that paragraph into a note and point to the foreignObject chapter for more complex text layout support

Tav: ok, sounds good

Issue 13, 15: Allow 'shape-inside', 'shape-outside' to reference an image

Tav: in the Shapes spec, these can link to images

<ed> https://svgwg.org/svg2-draft/text.html#TextShapeInside

Tav: so you reference an image and a threshold, it's defining a shape using an image

heycam: what is the issue? is that allowed?

AmeliaBR: it is supported in a number of browsers in HTML

Tav: so we should just allow it

heycam: in terms of restrictions on external images, etc., that should be in Integration

Tav: ok

Issue 35: Does shape-padding effect text laid out using 'extent'

Tav: so where define an are to put text in (using 'extent') do we allow shape-padding to affect that?
... my feeling is no

AmeliaBR: if you want to lay out text in a padding rectangle, you can create a rectangular shape and use shape-padding on it

heycam: ok, that makes sense then

Issue 54, 55, 56, 57 - should shadownodes ever be returned in getIntersectionList/getEnclosureList/checkIntersection/checkEnclosure?

ed: so say you have a rectangle, and you want all elements that are within the rectangle
... if you had a <use> in there, would you expect the elements referenced by the <use> to be returned, or just the <use> itself?
... I think my initial feeling is that it should just return the <use> element

AmeliaBR: I would say so too
... that avoids some issues; if you're talking about individual nodes, or part of the <use> is fully enclosed but not the entire thing
... maybe long term we could have an extra parameter
... but by default, we should just return entire elements in the main DOM

heycam: I think that makes sense

ed: I haven't done any testing, though I would be surprised if an implementation returned shadow nodes

AmeliaBR: last I checked, these methods aren't implemented in firefox

RESOLUTION: getIntersectionList and friends can return a <use> but not the elements it references

<scribe> ACTION: Erik to make getIntersectionList and friend return a <use> but not the elements it references [recorded in http://www.w3.org/2015/03/05-svg-minutes.html#action05]

<trackbot> Created ACTION-3766 - Make getintersectionlist and friend return a <use> but not the elements it references [on Erik Dahlström - due 2015-03-12].

Issue 49 and 50 - issues belong in geometry or styling chapters (should be defined once for all presentation attributes)

ed: what does SVGAnimatedLength return for the attributes we made properties
... I think this is a general issue
... should probably address this in the styling

heycam: I have an issue to do that in the Types chapter

ed: so I can remove mine?

heycam: yes that's fine

Issue 48 - we need to reference HTML.next for this, can we do that? html5 REC doesn't have this

ed: there was some definition for the title and activeElement on SVGSVGElement
... which are defined in HTML.next but not HTML5 (W3C versions)

heycam: I guess we have to then

ed: ok
... there is a W3C WD version has these; I'll check

Issue 39 and 40 - types chapter removed the list-of-t definition, use HTML's set of space-separated tokens definition instead?

ed: i want to use this HTML definition
... e.g. for requiredFeatures
... it's a simple string-like attributes

heycam: I was going to use that algorithm to use this algorithm for the class attribute
... so I was going to add another case in the attribute parsing section

Issue 34 - wasn't entirely clear from f2f minutes, should scripts in external <use> documents run?

ed: wasn't clear from the minutes that scripts run in external documents
... if the <script> is outside the subtree you're referencing

AmeliaBR: if it's outside, I wouldn't expect it to run

heycam: I can't recall the discussions we had on this, but I think not running the script is good

AmeliaBR: right now we have an option to use a whole external file; we should be clear what happens with script

heycam: so what about not running script in the resource document, and also not in the cloned shadow tree?

ed: I think this could use some testing too
... so I will probably do taht
... but trying to restrict scripting would be good

AmeliaBR: was a decision made about <use> referencing a <foreignObject>?
... some browsers copy the <foreignObject> content, some don't

ed: I don't think we've discussed that issue

AmeliaBR: you're only supposed to reference graphics content, but you can have a <foreignObject> in a <g>
... so what happens if you have other, non-graphical content within a <g>

BogdanBrinza: for IE, it gets cloned and rendered like a regular <use> element
... there's no special behaviour for foreignObject
... (though we don't have public builds for that yet)

AmeliaBR: do you know whether the copy is an interactive copy? or just an image of the original object?
... e.g. if it has form controls?

BogdanBrinza: I am not sure... but I can try it, good question
... if it's cloned it should be interactive

ed: would appreciate some help with testing this

BogdanBrinza: I can help with Windows/OSX testing

ed: mostly asking for help with writing tests

BogdanBrinza: I can help with that too
... we do have some tests you can reuse

<scribe> ACTION: Bogdan to help Erik test unusual elements inside <use>d subtrees [recorded in http://www.w3.org/2015/03/05-svg-minutes.html#action06]

<trackbot> Created ACTION-3767 - Help erik test unusual elements inside <use>d subtrees [on Bogdan Brinza - due 2015-03-12].

Issue 32 - drop the offending paragraph? Still add example?

ed: this is about the <use> element
... there's a paragraph that talks about visibility

<ed> https://svgwg.org/svg2-draft/struct.html#UseElement

ed: and how visibility:hidden does something particular
... not sure it's necessary to have this paragraph
... the issue asks why visibility is called out specially
... and that it might be better to have an example to show what it's trying to describe
... not sure what the example would be like, thouhg
... I'd be happy just dropping that para

AmeliaBR: I think it's an interesting example, but definitely should be an informative note or example, not part of the normative text

ed: just not sure there's a good example not shown by the other examples

<scribe> ACTION: Amelia to think of an example of struct.html issue 32 [recorded in http://www.w3.org/2015/03/05-svg-minutes.html#action07]

<trackbot> Created ACTION-3768 - Think of an example of struct.html issue 32 [on Amelia Bellamy-Royds - due 2015-03-12].

Issue 23 - other namespaced markup in title and desc, what is the purpose?

ed: I think the issue is to say what this purpose is

heycam: presumably to include some more structured descriptions rather than just plain text

AmeliaBR: and originally also so that you could have complex fallback content, in a browser that didn't support SVG
... that's no longer relevant though
... I'm pretty sure the main purpose is so you can have structured content inside <desc>

heycam: note also the HTML parsing algorithm allows HTML content inside here

AmeliaBR: I'm not sure if there's much of a benefit within <title>, but some browsers do support within <title> and some don't
... a weird random thing
... maybe that should be cleaned up

heycam: within SVG documents or HTML title?

<AmeliaBR> http://stackoverflow.com/questions/23626422/tooltip-to-display-in-two-separate-lines-not-working-in-firefox/25690802#25690802

AmeliaBR: so this may have been coming from this comment that external namespaces are OK
... so some support within title

Tav: I don't really like the idea of having in there
... maybe white-space:pre-line?

AmeliaBR: that's the other thing that's changed since SVG 1.1
... in the title="" in HTML you can put line breaks
... so either way isn't conforming to specs, but all browsers allow one way or the other
... either with or a hard line break

heycam: and that's a hard line break without setting the white-space property?

AmeliaBR: yes
... and only for <title>

Tav: putting a seems wrong to me
... allowing white space to be preserved seems more compatible

AmeliaBR: and with the new white-space option, I think that will be more reasonable

Tav: you can style your title

AmeliaBR: it's tricky, because tooltips aren't styled with CSS
... I have no idea whether white-space:pre would apply

heycam: do you think we need a issue in here to define this kind of thing?

<scribe> ACTION: Erik to add purpose for markup within title/desc [recorded in http://www.w3.org/2015/03/05-svg-minutes.html#action08]

<trackbot> Created ACTION-3769 - Add purpose for markup within title/desc [on Erik Dahlström - due 2015-03-12].

<scribe> ACTION: Erik to add an issue to describe the behaviour of markup within title/desc (regarding line breaking, at least) [recorded in http://www.w3.org/2015/03/05-svg-minutes.html#action09]

<trackbot> Created ACTION-3770 - Add an issue to describe the behaviour of markup within title/desc (regarding line breaking, at least) [on Erik Dahlström - due 2015-03-12].

Are xpointer target fragments still supported?

AmeliaBR: ChrisL says XPointer stuff should all have been removed from the spec
... so I think we can just remove this

ed: yes I think that's right

<scribe> ACTION: Amelia to clean up the reference to XPointer in the spec [recorded in http://www.w3.org/2015/03/05-svg-minutes.html#action10]

<trackbot> Created ACTION-3771 - Clean up the reference to xpointer in the spec [on Amelia Bellamy-Royds - due 2015-03-12].

trackbot, end telcon

- DRAFT -

SVG Working Group Teleconference

05 Mar 2015

Attendees

Contents