SVG Working Group Teleconference -- 07 Apr 2014

<trackbot> Date: 07 April 2014

<ChrisL> interesting font demo http://www.babelstone.co.uk/Fonts/ThrorsMap.html

<ChrisL> http://libregraphicsmeeting.org/2014/program/

<birtles> Scribenick: birtles

<scribe> Scribe: birtles

Charter

<ChrisL> http://www.w3.org/Graphics/SVG/2012/charter

ChrisL: our charter has expired just recently
... that's not a problem
... it was pointed out that it was expiring
... but there seemed to be no concern
... I suggest we ask for the same charter as the current but with minor updates
... if we've added/dropped specs, changed WG liaisons
... we need update that
... I suggest we drop liaison from XML Core
... they're not developing any new features, at least none we care about
... we might want to add some new liaisons
... now sure about Oasis, not sure if we're doing anything there
... we've got EPUB but we might want to add the interest group
... there seems to be a lot of activity there at the moment
... we should get requirements from them
... they are mostly feeding into CSS but they might have some for us
... most of the other groups are still going
... we have ICC but I wonder if we should have OpenICC too
... it's an organisation but not as formal as ICC
... we have MPEG listed (for SVG-in-OpenType)
... but the rest looks ok but we can drop the Hypertext Coordination group

heycam: what about the P&F WG

ChrisL: we should keep that liasion
... the work on accessibility in happenning in the SVG WG

krit: our charter is not compatible with the PF WG
... the work should go on there, our goals are not aligned

heycam: we discussed that recently in the telcon
... and said it doesn't really matter where it happens
... but some on the mailing list said that it would be better if those specs where published by bother groups
... like we do for FXTF
... for patent coverage
... the proposal was for there to be a join TF but the documents would be published under the PF WG

ChrisL: what was the reason?

heycam: for simplicity and since that item isn't under our current charter
... but given we're rechartering...

ChrisL: we do have an item like that under our charter

krit: yes

ChrisL: there has been other work on accessibility that is going into the SVG spec itself
... what do they want? another note?
... does their document add new features?

heycam: I think the primary purpose is to describe the mapping of SVG features when you don't use aria-role
... in HTML they have a table for that
... I think they want that for SVG

ChrisL: why don't we just add it to SVG?

krit: for HTML I think it's a separate spec

cabanier: I think they have both

krit: there is some separate document

ChrisL: if they want to write a non-normative document with guidelines that's fine
... I'm concerned about them changing SVG

heycam: I think it would be normative text

krit: I would be concerned if we need to join PF WG just to work on this doc

heycam: if there's a TF there should be public mailing list

ChrisL: it should be a public mailing list

heycam: so should we go back and add this to our charter since we're rechartering?

ChrisL: I think that sounds good
... what's the title of the document

heycam: SVG2 Accessibility User Agent Implementation Guide
... there is a stub document

<heycam> https://github.com/SVG-access-W3CG/new-note-draft/blob/master/svgaccess.html

<scribe> ACTION: ChrisL to update the charter [recorded in http://www.w3.org/2014/04/07-svg-minutes.html#action01]

<trackbot> Created ACTION-3601 - Update the charter [on Chris Lilley - due 2014-04-14].

<scribe> ACTION: ChrisL to talk to Michael Cooper about UAG [recorded in http://www.w3.org/2014/04/07-svg-minutes.html#action02]

<ChrisL> deliverables www.w3.org/Graphics/SVG/2012/charter

<trackbot> Created ACTION-3602 - Talk to michael cooper about uag [on Chris Lilley - due 2014-04-14].

ChrisL: here's a link to the previous charter's deliverables
... it listed SVG2
... what about SVG Parameters
... has that gone away since CSS variables came about?

heycam: SVG parameters can do slightly more but I'm not sure there's enough push to do SVG parameters as well
... can be have a section on things we might work on

ChrisL: yes, we can have "will work on if time" specs
... SVG integration: we still haven't published that
... there has been discussion of that recently

krit: I don't think it has sufficient security support to publish a FPWD yet
... we need to fix the issues first then we should publish it

heycam: so it should stay in the list

ChrisL: for color management we will keep it in SVG2 for now since the separate spec hasn't been taken up by CSSWG yet
... join work recommendations...
... what about css animations and web animations, does one replace the other or do both get published in parallel?

krit: yes, both in parallel

ChrisL: then we should add web animations here

nikos: we should update the links to the compositing spec

<nikos> http://www.w3.org/TR/compositing-1/

birtles: we should also probably add animation elements: https://svgwg.org/specs/animation-elements/
... it's paused at the moment
... but we decided it should go under the SVGWG

ChrisL: tiling and layering, did that get added to SVG2?

heycam: part of it has, like the iframe stuff
... the media query stuff has been shunted off to the CSS working group

stakagi: the zooming module is yet to be added

heycam: I think that is covered by the media query work
... is there anything else?

stakagi: that's all

heycam: so there's no separate document for tiling and layering since it is all in other specs?

stakagi: not at this stage

heycam: do we need to say where previous items have ended up?

ChrisL: that can be in a separate document linked to from the charter
... how about vector effects?
... nothing has happened in the last two years
... are implementors interested in it?

pdr: what about the non-scaling stroke discussion

ChrisL: we currently have that as the only vector effect, less interest from browsers in doing the full flexible syntax

krit: I don't think it's going to happen in the near future
... the current priorities are performance and interoperability

(discussing the element-based syntax for vector effects from SVG 1.2 full)

ed: there is a standalone spec for this too

<ChrisL> http://dev.w3.org/SVG/modules/vectoreffects/master/SVGVectorEffects.html

ChrisL: there are a number of new elements similar to fe but ve

krit: but many of these things can be done with vector-effects/paint-order

ChrisL: we seem to be carving off canned effects and putting those in directly
... which is better than nothing

krit: we have currentFill etc. are now in SVG2 right?

heycam: yes

ChrisL: so should we just drop this for now?

heycam: my preference it to keep pushing forward with canned effects
... since it's easier to handle from an implementation point of view
... the element syntax feels heavy weight and I think has held back filter effects adoption

krit: I agree, the elements worry me

ChrisL: is it easier to implement...

heycam: it's easier to implement both because the set of features covered is smaller but also you don't have to track changes to all these different elements

ed: so the path reversal is in Path2D?
... I think having a javascript API for this is useful I think

krit: does that need to be native though?

Tav: it would be good to be able to share path edges in a declarative way
... the other thing we most often get asked for is offsetting the stroke

heycam: last time we discussed path referencing was at TPAC last year
... and Cyril had a proposal for a piece command using an ID reference

nikos: that didn't actually give you shared edges
... it let you re-use path edges but it didn't actually share them

ChrisL: so let's remove vector effects as a separate work item
... rename SVG accessbility item to the SVG2 User Agent Implementation Guide
... about graphics API?

heycam: I think that was Doug's idea of an API like canvas that could either produce immediate canvas or declarative graphics

ChrisL: that's clearing not happenning so let's drop it
... connectors?

Tav: I worked on it a little bit

ChrisL: should we keep it around?

Tav: yes, I'd like to

ChrisL: layout (new)?

heycam: I wrote up the requirements but I haven't had a chance yet... might do in the next 2 years though, I'd like to keep it

ChrisL: SVG Glyphs for OpenType Font
... the group has formed and passed its work onto the ISO group and then shut down
... so we should just keep it as a liaison
... so remove SVG Glyphs for OpenType Font line item
... pagination and slides?

heycam: that was part of the SVG print spec?

ChrisL: I saw something about that in the Inkscape meeting

Tav: I had a number of people asking about multi-page SVG
... there's demand for it
... I did my presentation with JessyInk which splits up the graphic into slides

ChrisL: there is clearly a need for it

Tav: I might work on it

<ChrisL> http://dev.w3.org/SVG/modules/mae/master/MediaAccessEvents.html

heycam: if someone might work on it, we should keep it

ChrisL: media access events
... none of the editors are in the WG
... the spec hasn't been updated for 6 years
... it appears to be totally different to what's happenning in the WebApps WG
... we should drop it

heycam: should we publish as a note?

ChrisL: yes, publish as a note and drop

<scribe> ACTION: Cameron to publish media access events as a note [recorded in http://www.w3.org/2014/04/07-svg-minutes.html#action03]

<trackbot> Created ACTION-3603 - Publish media access events as a note [on Cameron McCormack - due 2014-04-14].

ChrisL: we have Japanese text layout requirements
... that is now published and is finished
... I don't think it needs to be on the charter now since it's done
... since there are now other requirements docs that are coming out (Latin text - EPUB, Indic etc.)
... I think it's difficult to get all the requirements
... but we're not involved in these

heycam: are these mostly to do with text or do they involve graphics too?

ChrisL: it's mostly text
... anything else to add?

heycam: what about the maintenance ones?
... should they continue to be there?

ChrisL: yes, they will

heycam: can we remove the completed ones?

ChrisL: we should keep them since we might need to publish updated versions
... any other documents to add?

krit: what about the geometry API?
... Rik, Simon Pieters from Opera, and I are working on another API
... it hasn't been published as a WD yet
... it's an FXTF spec

<krit> Geometry interfaces module: http://dev.w3.org/fxtf/geometry/Overview.html

heycam: in the decision policy section in the charter
... we talked about asynchronous decision making recently

ChrisL: I have wording prepared for that
... would that be suitable?

heycam: sounds good

ChrisL: there's a roadmap page on the wiki

<ChrisLilley> https://www.w3.org/Graphics/SVG/WG/wiki/Roadmap

ChrisL: we need to, as a group, keep it up to date

ISSUE-2364: SVG2 has not yet defined whether a root element can act as a proximal event target

ed: the question is "should the SVG root be a target for pointer events"
... we never defined it
... we purposely made it undefined in 1.1
... we said "we should define it properly in SVG2"
... (it relates to whether you can click the viewport)

<ed> https://svgwg.org/svg2-draft/interact.html#PointerEventsProp

<ed> https://svgwg.org/svg2-draft/interact.html#hit-testing

ed: actually section 17.5.1 ^
... last paragraph

"This specification does not define the behavior of pointer events on the rootmost ‘svg’ element for SVG images which are embedded by reference or inclusion within another document, e.g., whether the rootmost ‘svg’ element embedded in an HTML document intercepts mouse click events; future specifications may define this behavior, but for the purpose

of this specification, the behavior is implementation-specific."

scribe: this wording is from the 1.1 spec

krit: is SVG image something you embed in the HTML document?

heycam: for <img> the whole rectangle it needs to capture clicks on the whole rectangle

ed: this is about inline sVG

ChrisL: clearly the wording here is confusing

heycam: we should define both scenarios anyway

<stakagi> iframe?

ed: we need to define the behavior for all scenarios

krit: should this definition go into SVG2 or is it fine to have in the SVG2 integration spec?

heycam: some stuff still should go in SVG2 such as standalone SVG documents
... the other cases (inline, reference by image, iframe etc.) should probably be covered in the SVG integration spec
... what do implementations do at the moment for top-level document?

ed: I think it differs... I think you can use pointer-events but the default setting is different
... I've mostly tested inline

<scribe> ACTION: Erik to prepare spec text for pointer-events on root SVG elements for SVG2 and SVG Integration spec and make edits [recorded in http://www.w3.org/2014/04/07-svg-minutes.html#action04]

<trackbot> Created ACTION-3604 - Prepare spec text for pointer-events on root svg elements for svg2 and svg integration spec and make edits [on Erik Dahlström - due 2014-04-14].

ed: do we need to introduce new keyword values?
... bounding box is probably not the right word

heycam: probably
... would it be safe to have pointer-events on the root SVG element catch events by default?

ed: it's currently not defined

krit: It might already work like that

ed: we need spec text anyway
... if I find we need a new keyword I'll propose one but I think it's preferable if we don't

heycam: looks like it already does that in Firefox and Chrome

krit: and webkit

ed: so we just need to define that

(break)

SVG Sizing

<heycam> presentation https://docs.google.com/presentation/d/1POUiroOBbLmXYlQKf0pIR8zVkHWH9jRVN-w8A4aNsIk/

davvel (David Vest): I prepared some slides to introduce the problem

scribe: it's about integration of SVG/CSS, how to compute the viewport size
... both the inline case and the external case

(goes through the slides)

scribe: case 1: SVG has no fixed width/height, but has a fixed size container

ChrisL: I understand what Firefox does, but not why the other browsers using the containing block

davvel: I think it's because the default width/height of the SVG is 100%

ChrisL: so they're assuming the percentages are CSS percentages when the spec says they're not

davvel: Case 2: width only with viewbox
... (i.e. intrinsic ratio)

ChrisL: I think Firefox is doing what the spec says

pdr: the specs are inconsistent here
... there's no correct solution since there are several contradictory specs

davvel: Case 3: external reference, intrinsic ratio, specified height

heycam: did you test with iframe (test case uses object)?
... it might differ

davvel: I did test with iframe and yes, the behavior was different but I think it should not be
... the results here are totally different
... I've been using the CSS replaced element algorithm as the starting point and SVG and providing input to this algorithm

(goes through slides about intrinsic size, ratio etc.)

pdr: how do browsers calculate the intrinsic ratio? using the viewBox as you say?

davvel: mostly, IE sometimes doesn't

(discussion about the Web compatibility of percentage width/height and why these percentages were defined to be different to CSS percenatges)

Mozilla bug: https://bugzilla.mozilla.org/show_bug.cgi?id=668163

pdr: I think this proposal is based on the assumption that NOT mapping SVG width/height to CSS properties is not web-compatible
... and I'm not sure if that's still the case

ChrisL: there was also a push to map more attributes to properties for animation purposes

davvel: it would be good if we don't have to map width/height to properties

(continuing with presentation)

krit: with your proposal, the SVG inline case is the same as the SVG image case

heycam: what of the comments Jonathan Watt made was, "does that really make sense"?
... for externally referenced files is it sensible to say "this document should take up such-and-such a percentage of where it is embedded"
... since you might embed it in different places
... I think this proposal makes it eaiser for authors to understand what's going on
... but I'm not sure it makes sense

davvel: in the Webkit/Blink test suite if you have a percentage on an externally referenced SVG it uses it twice
... IE does it too

krit: I like that this proposal lets you choose between the different behaviors

ChrisL: also auto is a new value so there shouldn't be a compatibility issue

pdr: I think auto is somewhat confusing but if this gets us consistent behavior I'm in favour
... I actually support the presentation mapping. I *didn't* agree with your reasoning for it, but I support the mapping

(discussion about the original problem case)

heycam: I think in this case the author doesn't want the image to fill up the whole containing block, they should have to mark that up specifically

pdr: do you think they wanted 350px150px in that case?

heycam: no, I think they didn't say what they wanted

davvel: but in that case an iframe would be 300x150 px

heycam: and it would be good to be consistent with that
... there are no other cases where without an explicit indication the content fills up the whole containing block

pdr: there seems to be consensus that davvel's proposal seems good

birtles: I find the mapping of width/height to be helpful from a authoring point of view

ChrisL: I want SVG to be scalable by default

pdr: so this proposal is different in that by default it would fit to 350px x x150px

krit: I think the behavior is not always great for the user but the consistency is important

pdr: what changes are required for this to happen? any changes to CSS?

davvel: no

ed: what about the changes to CSS 2.1 where it is currently suggestion but should be a requirement?

(currently the used value of width in 10.3.2 is undefined and then subsequently defined)

ChrisL: I'd like to run it by Tab since I've heard him talk about this before

<scribe> ACTION: ChrisL (or pdr) to get Tab's feedback on davvel's SVG sizing proposal [recorded in http://www.w3.org/2014/04/07-svg-minutes.html#action05]

<trackbot> Created ACTION-3605 - (or pdr) to get tab's feedback on davvel's svg sizing proposal [on Chris Lilley - due 2014-04-14].

heycam: if percentages can be resolved to something, can they give you the intrinsic size of the SVG?

davvel: no, that's what we want to get rid of

heycam: can percentages in an external document be sensibly used when you don't know where it will be embedded?
... it might not always make sense, but I think it's preferable to be consistent
... I don't think there's any other reasonable thing to make those percentages mean

ChrisL: if you want to make some SVG is scalable, then you put a viewbox and you either say nothing for width/height or use width:auto;height:auto

davvel: that's right
... for the width it will go as big as it can
... and for the height it will use the intrinsic ratio to calculate it

ChrisL: if you want to make something a fixed size then you simple say width:3.5in etc. and it will work as expected

davvel: right

ChrisL: they are the only use cases that matter
... percentages other than 100% never made sense
... the third use case is to make stuff which does not preserve its aspect ratio (e.g. backgrounds)

(discussion how this is possible with preserveAspectRatio and 100% width/height etc.)

ChrisL: we need a test suite with all the permutations

davvel: I already have that

birtles: are they in a format we can automate?

davvel: I've used the web platform system for <object> tests

ChrisL: are you familiar with the CSS system (Shepherd etc.)? It's pretty neat
... I've spoken to Peter Linss about this to do one-off conversions so that the database of properties includes SVG properties

heycam: I think he may have already done this

ChrisL: then you can go from properties to the tests that cover them

heycam: for the case where containing div has width/height auto (and auto all the way up), and SVG has no width/height but has a viewbox, what is the behavior?

davvel: it will use the viewport width

heycam: how far is IE from this proposal?

davvel: currently pretty far

RESOLUTION: Unless there is feedback to the contrary (e.g. from Tab), accept David Vest's SVG sizing proposal

overflow, clip on viewport creating SVG elements

ed: this came from from a webkit bug
... it relates to whether or not you can specify overflow:visible on inline SVG
... which I think IE does by default
... which is different to other browsers which clip by default

heycam: what is the initial value for overflow?

ed: it's complicated
... lots of cases

<ed> https://svgwg.org/svg2-draft/masking.html#OverflowProperty

ed: if you have a standalone SVG document, currently all browsers clip to the viewport
... do we want to allow SVG to apply overflow to standalone documents?

heycam: does HTML have an equivalent?
... if you replace the SVG document with a paragraph that has some overflow
... what if you put width/height properties on the root <html>
... what does that mean for things rendered outside that?

davvel: the default is visible

ed: that's the default in CSS

heycam: then we should do that same

pdr: is that Web compatible?

krit: the question is really whether it should be controllable or not, not what the default should be
... in SVG we have clip and overflow and the clip property clips to the viewport as its initial value

ed: I think it only applies with overflow:hidden etc.

krit: I think they're independent
... so even if you say overflow:visible it will still be clipped due to the clip property
... and CSS masking removes this
... so it allows the use case ed brought up
... so we need to do more work on the definition of the overflow property

ed: the second thing I wanted to ask was about overflow:auto in SVG is defined to mean visible
... but in CSS it is suggested to clip to the region and use scrollbars

heycam: it makes more sense to treat it as hidden rather than visible since in CSS you never paint outside the region since you have scrollable regions

ed: how do we want to treat overflow-x/y?
... these are independent so you can have overflow in just one direction

heycam: CSS defined some combinations of overflow that don't make sense
... do we want those in SVG?
... I think you can have both visible/hidden but some combinations of scrollable don't make sense
... I would like overflow-x/y to be useable in SVG

(break, lunch: 1hr)

<cabanier> scribenick: cabanier

ed: IE has the root as visible
... other say SVG root overflow should be hidden

<heycam> in Firefox's UA style sheet: svg:not(:root) { overflow: hidden; }

krit: that is strange because the spec says overflow hidden
... we should say that all svg should say hidden

heycam: I think if we can get away with adding new rules

ChrisL: it's the only way to add a new value

heycam: so IE allows overflow visible on the root?

<pdr> Blink's UA styleshee as wellt: svg:not(:root) { overflow: hidden }

heycam: for outer most svg elements that are inline

krit: the spec says that the root should be visible so IE is correct

<ed> https://svgwg.org/svg2-draft/masking.html#OverflowProperty

<ed> https://svgwg.org/svg2-draft/intro.html#TermRootmostSVGElement

ed: no, this is for the root-most/outer-most element

<pdr> Previous discussion on this from 2008: http://lists.w3.org/Archives/Public/public-svg-wg/2008JulSep/0347.html

ed: it doesn't necessarily mean the same thing
... we want to be able to allow to override overflow
... at the moment, firefox, chrome and webkit all do overflow: hiddne

cabanier: can you override it?

ed: yes
... in IE you can say
... in other browser you can specify it but it doesn't work

heycam: exactly how the spec defines this will depend on the next topic

RESOLUTION: outer-most svg elements of inline fragments will be overflow: hidden by default
... overflow should not be ignored for outer-most SVG elements for both inline and standalone cases

heycam: we talked about scrollable viewport in switserland
... to do zoom and pan
... to have scrollable viewport

krit: we had requests from google to have scrollable content

pdr: how is this applicable to mobile browser

heycam: this is for all elements

cabanier: so not just the root?

heycam: inner SVG elements

krit: not on symbol for instance, only viewport creating elements

pdr: my concern is that this is a graphics format

heycam: you can do this to with foreignobject

ChrisL: scrollable has historically been a difference between css and html

pdr: I agree

ChrisL: it would be good to be able to request scroll bar
... I've seen people create scrollbars in svg

heycam: maybe people used to write whole applications in svg

ed: today scroll and hidden means the same
... if we allow scrollbars, does CSS do anything with that

heycam: the specs don't say anything

ed: maybe it's up to the user agent to decide

krit: it's up to the UA to decide

pdr: will the width have the ... (?)

krit: filters can paint outside the boundingbox

<pdr> The issue of what determines the width: which bounding box do we use?

heycam: if you have contents that will scroll, you'd have to anticipate that
... today you can have scrollbars on a standalone doc

ed: but not inside the document

davve: there is something with background

heycam: is anyone thinking it's bad idea to have scrollable viewport

ed: would it ever be a pannable viewport, or would it be the default

heycam: css needs a way for viewports to scroll beyond their viewport region
... that might be a way to do arbitrary panning
... panning could use viewport scrolling, but not just yet

ed: can we put that off?

heycam: that's ok for me

RESOLUTION: svg:svg elements should allow overflow: scroll to create scrollbars

krit: where does the origin of this viewbox come from

pdr: I don't think there's a way to set it to negative

heycam: if you have a viewbox [10 10 20 20]

krit: maybe we don't want scrolling but panning

cabanier: how about the size of the scrollable area

krit: yes, that needs to be decided

pdr: what is the bounding box of this thing?
... html has the inner and outer box
... or something to that effect

heycam: we still need to define what those CSS properties such as offset width means for SVG

krit: maybe take viewport?

heycam: maybe we don't need to delve into the details
... how about for outermost inline SVG elements?

ed: every browser clips today

heycam: maybe overflow isn't the right thing to cause this clipping to happen
... maybe there should be no way to affect the rendering

ed: do we want allow that to happen?

heycam: if scrollbars can appear (?)

ed: is there ever a use case to not have scroll bar

heycam: would you ever want the content outside of a short SVG to be painted?

ChrisL: maybe if you have a symbol?

Tavmjong: we talked about this in a telecon
... andreasa asked for that

ChrisL: scroll bars in symbols would be bad

heycam: we need to have some wording there

ed: today we imply that there should be scroll bars for standalone svg elements

heycam: we still need some wording for short svg's to be clipped

RESOLUTION: overflow property on root svg elements still controls if there should be scrollbars but there should be a clipping rectangle that
... is the size of the svg element's viewport

ed: the current spec says that within SVG content the value 'auto' means visible
... should we change that

heycam: it might be if we can come up with a solution
... for instance if the appearance of scrollbars makes things narrower
... noone's using auto today so it would be safe to use it

ed: do we want to keep the spec or should we change it?

heycam: if we allow for scrollable viewports it makes sense to change it
... for viewport establishing elements where scroll bars don't make sense, overflow:auto would be visible
... for svg:svg, auto will mean scrollbars will appear if the overflow region is bigger than the viewport

pdr: why are marker and pattern different?
... we are adding special cases for certain elements

heycam: one reason is that these elements are not rendered directly

krit: it makes it more compex for instance on patterns. because you have to calculate how you tile them

heycam: how about mask?

pdr: yes, that wouldn't make much sense

krit: how about 'element()' in firefox, would it copy the scroll bars?

heycam: I believe so yes
... we need to add a bunch of spec text to make sure that a pattern with overflow:hidden does the right thing
... I worry about getting the coordinate system right

pdr: maybe it's best to get some implementor feedback

heycam: you can have an issue in the spec and wait for that

<scribe> ACTION: ed to figure out the overflow behavior in SVG [recorded in http://www.w3.org/2014/04/07-svg-minutes.html#action06]

<trackbot> Created ACTION-3606 - Figure out the overflow behavior in svg [on Erik Dahlström - due 2014-04-14].

heycam: we need to work out or put an issue in the spec whether that patterns have scrollable viewports

bbox for text calculations

<ed> http://lists.w3.org/Archives/Public/www-svg/2014Mar/0030.html

ed: we discussed this on a call but didn't come to a conclusion

ChrisL: I had some comments
... the full glyph cell is not the ink bounding box

heycam: is it origin + ascent + descent

ChrisL: full glyph cell is adding rectangles, is to use all
... do we need bounding boxes for hit detection and text selection? I think not

nikos_: how about negative advances?

ChrisL: the advance is separate from that
...

heycam: it sounds like we do need different bbox's because some glyphs might go over and you don't want to select them

ChrisL: in practice people put transparent rects on top of the text

<ed> http://jsfiddle.net/L7pgW/18/

ed: I made some examples

krit: the italic is the browser?

ed: yes.

<ed> http://jsfiddle.net/L7pgW/22/

ed: this is a case where the gradient is started where the character starts
... filters have this issue too

heycam: we talked about these for stroke/mask bbox
... should we extend this to extent for ink coverage

tbah: what you might want it the bbox and the (?)
... (conversation about using em to size a gradient)

ed: as an author I would expect the gradient to fill the bounding box

heycam: do we have interoperable behavior?
... for what the size of the bbox is?

ed: no

heycam: the dictionary to getbbox can included stroke and markers but not for the ink coverage
... one option is to union the ink region and the glyph cell
... the other is just to get the tight bounding box
... it's possible to extend the dict for horizontal and vertical
...

ed: I would like getbbox to return the ink coverage
... most of the time you want to know what is drawn

heycam: we already have that information

ed: yes, you need to know where things were

heycam: we use the lose ink bounds
... the tight glyph bounds might be more expensive
...
... we should do the union of the glyph boxes and the ink coverage

tbah: that should catch the majority of the use cases

how about japanese text

scribe: all glyphs are the same size

<scribe> ACTION: getBBox and resource bounding box (for gradients, mask, etc) to return the union of the glyph cells and ink extends by default. [recorded in http://www.w3.org/2014/04/07-svg-minutes.html#action07]

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

RESOLUTION: getBBox and resource bounding box (for gradients, mask, etc) to return the union of the glyph cells and ink extends by default.

heycam: do we allow control to get just the ink extends?

ed: can we reuse the same method?
... we have a method called getTextExtend

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

ed: do we need to make getBBox more complex or rely on these methods

heycam: are you leaning towards not extending getbbox?

ed: if so, we should be able to do the same on gradients, for instance gradientUnits="some_new_value"
...

heycam: maybe we can ignore that for now since it complicates the API

nikos: most cases where you want the tight box, you might want to hit test against it too

ed: I could go with a clarification

RESOLUTION: for now we won't provide APIs for a tight ink bounding box on text for getBBox or gradient object bounding box or hit detection

ed: are text decoration part of the bbox?

krit: CSS had discussions on this
... right now css doesn't gradients, just color

heycam: the boundingbox in that case is the element
... an underline could go outside of the element
... it makes sense to include them

krit: then there would be 2 definitions of bounding box

heycam: I don't want decoration to be painted differently

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

RESOLUTION: text decoration to be included in the bounding box calculations

<krit> http://wiki.apache.org/xmlgraphics-fop/LineLayout/AlignmentHandling

<heycam> http://dev.w3.org/csswg/css-inline/

(krit discussing issue with text baselines, etc)

<ed> ACTION: ed to do spec edits for bounding boxes of text elements: give the union of full glyph cells and the painted area, and include text decorations in the bbox (change for getBBox too) [recorded in http://www.w3.org/2014/04/07-svg-minutes.html#action08]

<trackbot> Created ACTION-3607 - Do spec edits for bounding boxes of text elements: give the union of full glyph cells and the painted area, and include text decorations in the bbox (change for getbbox too) [on Erik Dahlström - due 2014-04-14].

<ChrisL> ideographic = descender depth

<ChrisL> alphabetic = 0

<ChrisL> central = (ascender height - descender depth) / 2

<ChrisL> middle = x height / 2

<ChrisL> these seem good fallback definitions we could reuse

<scribe> ACTION: krit to talk to Alan Stearns about adding fallback baseline calculations to the CSS line layout spec and if they will stay in the spec [recorded in http://www.w3.org/2014/04/07-svg-minutes.html#action09]

<trackbot> Created ACTION-3608 - Talk to alan stearns about adding fallback baseline calculations to the css line layout spec and if they will stay in the spec [on Dirk Schulze - due 2014-04-14].

<heycam> Scribe: Cameron

<heycam> ScribeNick: heycam

white space in attributes

https://www.w3.org/Graphics/SVG/WG/wiki/Proposals/AttributeWhitespace

ed: I went through all the attribute types we use in SVG, made a big table summarising
... I was looking for whether trailing/leading white space is allowed and ignored
... comparing with HTML5
... it's inconsistent, but at least for some of the numerical types it should be possible to make it consistent
... we discussed this in a telcon, and I went over it once more to add test cases for each of the subsections
... we could go through each type by type and see the test cases

<ed> http://jsfiddle.net/wxJa9/

ed: this is for <number>
... there aren't many of these in HTML
... the only ones I could find are on <input>

ChrisL: is HTML5 the right thing to be comparing to here?
... and not CSS properties?

heycam: these are all non-CSS property attributes we're looking at

ed: this example is inconsistently handled across browsers
... HTML5 has different constraints for validators vs browsers
... for the content to be valid, it has to be a proper number in the right format and without any garbage or white space
... but for display, it strips away the white space and junk
... and returned in a correct form if you ask for it in the DOM
... even in HTML5 this example doesn't work the same way across browsers
... for integer values it's a bit more consistent
... in the first section I listed the browsers I tested
... Firefox/Chrome/Presto did not allow white space and garbage; IE did allow white space and garbage

<ed> http://jsfiddle.net/hxz46/

ed: that's the SVG test case
... here Firefox/Chrome do not allow the white space and garbage; IE allows white space but not garbage, Presto allows both

<ChrisL> <input type="range" step=" 500e-3nord" min="0" max="10"/> works

pdr: in these examples this is not stripping white space in the middle
... so only leading and trailing white space
... is that your intention?

ed: we could add tests for those
... so the first question is do we want to allow white space and garbage

ChrisL: for garbage, that would probably have different levels of support

ed: the HTML5 parsing algorithm does allow it

heycam: so IE is the only one following the spec

krit: for things that just take numbers, WebKit/Blink are accepting
... that's how we do the parsing in SVG

ed: I looked at the functions in Blink, and it's passing a flag whether to allow it

ChrisL: if HTML5 defines what to do with numeric attributes, then following the exact same algorithm makes it convenient
... it's slightly worrying that only one browser implements that

ed: there are only a handful of HTML attributes that take a float
... for integers it was much more consistent

<ed> http://jsfiddle.net/6BQGF/

ChrisL: the thing that worries me is that if there's only one browser implementing it properly, that requirement will be dropped

ed: that is the test for integers
... white space and garbage is allowed across all browsers
... negative values for width doesn't work in some browsers, but that's different from the white space handling
... anyway, all browsers allowed white space / garbage

pdr: HTML doesn't have lists like SVG
... is there any danger there?

ed: for SVG lists, I think generally white space is allowed

pdr: I'm wondering if we use that algorithm for a specific number, but for a list that doesn't allow commas...?

krit: I would be in favour of allow leading / trailing white space
... to allow garbage at the end is a bit strange

ChrisL: it means you constrain what you can later add

ed: I guess that's why there are different conformance classes in HTML?

krit: do we want to allow browsers to be less restrictive
... we don't need to enforce it...

Tav: I'd like to avoid the situation where it renders well in the browser but then imported in Inkscape it doesn't work

ed: I think the main thing I found was that there are some minor inconstencies whether leading white space is allowed in SVG
... so it seemed like a good thing to check everything

pdr: for the trailing garbage, I disagree
... why follow something different from HTML?

ChrisL: what if we have an attribute like x="4e10" and we start off as an integer, what if we want to extend that later?
... to accept scinot?

ed: note that you still get the "4"

pdr: I see
... when the HTML folks made this decision, how did they handle this future constraint?

ChrisL: maybe since it's only a handful of elements it wasn't a problem

heycam: what is the benefit here?
... simplifies implementations slightly
... what about for authors?

ed: had a bug reported where white space was allowed in firefox but not in chrome
... can't remember which attribute it was

pdr: I think it makes sense to align

cabanier: if you only want one algorithm, then you're going to need to accept trailing garbage then

ChrisL: to be clear, the two objections aren't "no I'll tie myself to the mast" objections, they're just worries
... worry about it being dropped from HTML, and future constraining extensions
... but if the group agrees they want to do that I'm fine with it

ed: next is length values
... IE allowed white space, no garbage; others don't allow anything
... for enumerated values, everyone agrees no white space or garbage

heycam: I feel like length parsing is more like CSS parsing
... so white space seems good to allow
... what about CSS comments?

ed: so for number and integer, stripping leading/trailing white space and trailing garbage, being consistent with HTML5, is my first proposal

krit: who doesn't allow garbage in SVG integer attributes?

<ed> http://jsfiddle.net/Gaw2P/

ed: compare to the bottom right subtest
... which is numOctaves="1"

krit: in Safari we don't render the 5th one
... what does that indicate?

ed: it doesn't use any fallback value

heycam: I think if we have some implementations that accept the white space and garbage and others not, then we'll eventually all converge to that behaviour
... so may as well jump to that state now

krit: I'm OK with accepting leading/trailing white space

pdr: go for browser compatibility instead of parser compatibility?

krit: well, the browser uses a parser...

pdr: spec parsers

ed: I think it's mostly consistent in disallowing the garbage
... in transform lists for example

krit: for numbers I would be skeptical because of that exponential number example
... for integers we only have a few attributes
... so is it worth it?

ed: there are other cases where white space is allowed when the spec says no

krit: I am supporting the white space

ed: to be clear, I don't want to allow white space everywhere
... for enumerated values, like accumulate="none | sum"
... I guess we could allow white space

Tav: but HTML does not

<ed> http://jsfiddle.net/eT7jz/

ed: all browsers agree there not to allow white space

krit: safari allows the white space there

pdr: I wouldn't have expected that to be different from chrome

krit: but the HTML spec doesn't want white space
... I think it's strange, but acceptable, to not allow white space in enumerated attributes

ed: we imported a few attributes from HTML5, the boolean values for controls="", default="", etc. on <video> and <audio>
... we currently don't have anything like that
... in SVG
... so it makes sense to follow SVG there

krit: filter effects too

ed: they don't allow white space or values other than the attribute name itself

krit: I think it's strange it doesn't allow true/false

ed: for url values, all values allow leading/trailing white space, which is stripped
... the spec currently says it's not allowed
... so I think we should allow it there
... xlink:href=""
... we now have <video src=""> too

pdr: what about a data URL that's not base64 encoded
... with trailing white space. that's an actual difference.

ed: I think white space is stripped there

RESOLUTION: URL attributes will be parsed like in HTML, by stripping leading/trailing white space.

pdr: I think not allowing garbage is ok for length etc.
... what about for attributes that we later promote to properties?

krit: you would start to allow white space

ed: but that's ok, it's more relaxed

RESOLUTION: We will allow leading/trailing white space on integer,number,length,angle but not trailing garbage.

ed: the rest of the data types, leave them as they are

<scribe> ACTION: Erik to update attribute parsing according to these resolutions. [recorded in http://www.w3.org/2014/04/07-svg-minutes.html#action10]

<trackbot> Created ACTION-3609 - Update attribute parsing according to these resolutions. [on Erik Dahlström - due 2014-04-14].

Media queries in switch

ChrisL: was the previous discussion in favour of this?

heycam: yes I think so

<ChrisL> good

[heycam explains what media="" would allow]

pdr: why not fix media queries in CSS to allow this kind of switching?

ChrisL: selector syntax is not really designed for doing switch cases like this
... we already have these test attributes, that we inherited from SMIL
... seems a natural extension to those
... this gives them a simple way to combine media queries with <switch>

davve: the <switch> element has really low usage
... is there a use case we want to cover by this?

krit: you could do the same with classes...

pdr: this is somewhat torturing the <switch> statement's intentions

krit: I don't want to encourage people to use <switch>, really

pdr: the example that estelle is showing is a proposal that is copying a <picture> element example, but doing it in SVG
... isn't this duplicating?
... that doesn't seem like a good idea

heycam: if this is the same thing as the <picture> element can do maybe we should just have that

<pdr> http://coding.smashingmagazine.com/2013/06/02/clown-car-technique-solving-for-adaptive-images-in-responsive-web-design/

<ChrisL> http://www.w3.org/Graphics/SVG/Test/20110816/harness/htmlObject/struct-cond-01-t.html

heycam: one difference is that the <picture><source> elements have to refer to external resources

pdr: they could be data: URL encoded

birtles: we were discussing having media="" on <iframe> too
... not sure if it's possible to get into cyclic dependencies with <switch> and media=""

pdr: in this blog post they have SVG-as-image referencing external background-images, and I don't think that would work in implementations
... I think this blog post is saying why have <picture> when SVG can do this already, but I think <picture> is going to happen
... so if we have <picture> in SVG in the future, I don't think we should extend <switch>

also http://coding.smashingmagazine.com/2014/03/05/rethinking-responsive-svg/

heycam: so I guess there are a few ways to handle this use case

(a) extend <switch> with media=""

(b) write style sheets with media queries, as you can do currently, but with a bit of duplication within them

(d) extend <picture> to allow subtrees, so you don't need to use external references

ed: there is <style media=""> too

[some discussion about avoiding fetching resources in non-condition-matching branches]

<ChrisL> f) keep inviting new responsive elements and then rejecting them until the heat death of the universe

<stakagi> resource piorities?

<birtles> https://dvcs.w3.org/hg/webperf/raw-file/tip/specs/ResourcePriorities/Overview.html

heycam: if preventing loading external resources is something important for the use case, then (b) and (c) aren't appropriate here
... (a) or (d) are

<scribe> ACTION: Cameron to reply to www-svg mail to say what can be done with existing @media queries and if <picture> exists in SVG [recorded in http://www.w3.org/2014/04/07-svg-minutes.html#action11]

<trackbot> Created ACTION-3610 - Reply to www-svg mail to say what can be done with existing @media queries and if <picture> exists in svg [on Cameron McCormack - due 2014-04-14].

<scribe> Chair: Cameron

- DRAFT -

SVG Working Group Teleconference

07 Apr 2014

Attendees

Contents