SVG Working Group Teleconference -- 27 Aug 2015

<trackbot> Date: 27 August 2015

<scribe> Scribe: Cameron

<scribe> ScribeNick: heycam

Embedded content chapter

cyril: I wanted to fix a few things in this chapter
... adding examples, making it clear that the video element has to be in the HTML namespace
... but there are a few sentences that were not very clear to me
... the linked to section for the placement of video etc. doesn't actually talk about placement
... it talks about viewport
... why is there a link to that section that has x/y/width/height defined
... does this mean that x/y/width/height are on the video element? I don't think that is the intent
... there's also a sentence that says the HTML5 elements contribute to bounding box calculations
... and if you look at the bbox computations it talks about video's x/y/width/height
... so iframe/etc is not touched compare HTML?

heycam: yes

cyril: so the bbox calculations should be fixed

nikos: is the intention that you put it in a group so you can place it?

heycam: that, or transform, or top/left/width/height properties

<scribe> ACTION: Cameron to update the bbox section for HTML video etc. elements [recorded in http://www.w3.org/2015/08/27-svg-minutes.html#action01]

<trackbot> Created ACTION-3817 - Update the bbox section for html video etc. elements [on Cameron McCormack - due 2015-09-03].

cyril: if we agree that audio/video/canvas/iframe don't have x/y/width/height defined by SVG, then the section needs to be updated
... there are currently subsections like 11.5, 11.6, for each of the four elements, and they're all exactly the same text
... I don't think it's necessary
... having just one section that describes these elements overall is sufficient
... I started adding what Erik said, being explicit that these elements render
... but we don't say anything about the fallback content
... if you have an HTML element in the HTML namespace, like a <p>, inside the <video>, acting as fallback content, should it render?

heycam: that is a good question

cyril: seems like we have everything there for that to work

ed: which spec should defined what should happen
... the unknown element handling doesn't cover this case
... it covers only unknown elements that you find as direct children of an SVG namespaced element

cyril: I'll leave it as an issue in the spec

Tav: suppose I have Inkscape with a video element in it
... what are would the video cover?

<TabAtkins> Do you want me to go ahead and write up the SVG Layout spec?

cyril: from what we said earlier, it would be given by the top/left/width/height CSS properties

heycam: [explains how width/height of auto values and the width/height attributes on video etc. work]

cyril: do we agree "Placement of the referenced resource" which defines x/y/width/height, is only applicable to the image element?

BogdanBrinza: yes

cyril: ok, I'll move that to the image element

Rossen: I would expect that people will either use transform, just a regular CSS transform, to offset the video element to where they want it to be
... so <video style="transform: translate(10,20)">
... and sizing will be handled by width/height/min-width/min-height properties etc.
... the rest of the box model, margins and top/left/right/bottom, which are positioning properties, I'm seeing a harder time how those can be used
... in CSS, the positioning properties are also sometimes used to drive layout
... if you have width:auto;left:0;right:0, it will stretch the size of the element
... I don't think there's such a concept in SVG

nikos: it would with the current definition

BogdanBrinza: SVG only has explicit positioning

cyril: since we defined the containing block is the viewport, it would just work
... don't know if we want that though

Tav: I don't want that

cyril: we could say CSS positioning properties do not apply in an SVG context
... and only use transform

Rossen: if you want to minimize the imapct of CSS to SVG, to its bare minimum, then you have to ignore all of the positioning
... you'll need sizing, so width/height/min-width/etc.
... positioning in CSS is very contextual. if you depend on left/right, then what about grid columns and rows, they're also positinioing properties
... I'd prefer to reduce the set of properties that apply
... because there seems to be missing x/y for positioning of the element, the easy way is to use transform

BogdanBrinza: or wrap it in a <g> or <svg>

Rossen: I would avoid element explosion, I wouldn't want to see empty elements created just for the sake of positioning
... transform should just work

heycam: ok, I am fine with that

RESOLUTION: video etc. are positioned only with transform, not with top/left properties, but still sized with width/height properties
... Fallback content in video etc. should work, just as it does in HTML.

cyril: the last bit is the namespace
... the HTML elements are required to use a namespace prefix when it's an XML parser
... when it's an HTML parser, that prefix is not needed

heycam: it won't work in inline SVG in HTML
... until we ask for the HTML parser to be updated

cyril: I'll add a note too that adding it using the DOM APIs will work

bounding boxes of empty elements

http://jsbin.com/qapopukifi/edit?html,output

Rossen: the problem is getBBox and the way it works in different implementations at the moment
... it's non-interoperable
... current spec text is weak in defining exactly what happens, when you have zero area rect
... so there a couple ways of handling this
... the way of following normal geometric logic, or completely ignoring it
... and doing something more performant
... based on the example that I have, I see that Firefox is taking the "performant" path, which is to ignore geometry
... and if you have a zero area rectangle, just return a (0,0,0,0) rect
... which means you lose position, and potentially one dimension that is non-zero
... <rect x=10 y=10 width=100 height=0>
... Firefox returns (0,0,0,0) for its bbox
... Chrome is doing something similar
... the argument for following simply geometry, a rect is a rect, regardless if it's empty or not, has positinon and two dimensions which may or may not be zero
... this helps editors, etc., you always want to know where the rectangle is
... for browsers, which are basically able to determine that this is not going to render, during paint, then you can just ignore the whole thing
... not allocate any data for such elements, and always return the (0,0,0,0) for getBBox
... the main question is, first, which of these do we want
... then, it would be good to have concrete spec describing what needs to happen
... my selfish preference is to take the path of returning (0,0,0,0)

<ed_paris__> https://svgwg.org/svg2-draft/coords.html#BoundingBoxes

Tav: what is useful for the user?

Rossen: you can make further arguments and say from the OM point of view, if you're making some kind of collision detection with these non-zero width or non-zero height elements, I may decide that there's still a collision there
... I'm not arguing against geometry, but I also see the perf benefits

nikos: what do you see getBBox used for

Rossen: we have interop behaviour when the area is non-zero
... I want consistency
... either way
... but prefer the (0,0,0,0)

ed: the spec right now says the position should be included in the bounding box, afaict

<ed_paris__> https://svgwg.org/svg2-draft/coords.html#BoundingBoxes

heycam: don't feel too strongly, slightly prefer returning "useful" values

Rossen: authors will surely want that
... if you position an empty div somehwere and get bounding rect, you'll get an empty rect at that place

heycam: and if the zero sized shape is in a group and you get the bbox of the group, it's included?

Rossen: yes

<ed_paris__> the bbox algo should probably say to use the x,y,width,height properties, not attributes (for <image> for example)

RESOLUTION: bbox of SVG graphical elements must include the position and maybe one non-zero dimension if its area is zero. and this includes <text x y> with no content.

<scribe> ACTION: Cameron to fix bbox for this. [recorded in http://www.w3.org/2015/08/27-svg-minutes.html#action02]

<trackbot> Created ACTION-3818 - Fix bbox for this. [on Cameron McCormack - due 2015-09-03].

<scribe> ACTION: Cameron review bbox algorithm for the new geometry properties [recorded in http://www.w3.org/2015/08/27-svg-minutes.html#action03]

<trackbot> Created ACTION-3819 - Review bbox algorithm for the new geometry properties [on Cameron McCormack - due 2015-09-03].

<scribe> ACTION: Cameron to verify that "parse a declaration" is the right thing for the style attribute [recorded in http://www.w3.org/2015/08/27-svg-minutes.html#action04]

<trackbot> Created ACTION-3820 - Verify that "parse a declaration" is the right thing for the style attribute [on Cameron McCormack - due 2015-09-03].

Structure chapter status

<ed_paris__> https://www.w3.org/Graphics/SVG/WG/wiki/SVG2_Chapter_Assessment#Document_Structure_.28Erik.29_.5Breadiness_3.5D

ed: I've stricken out the things I've done
... down to 13 open issues, maybe the count went up a bit, I added some for the unknown elements
... but I think we're closer now
... a bunch of these are issues related to animation, so those will be closed soon

birtles: I'm working on those animation ones now

ed: so mostly it's issues around <use> and unknown elements
... the rest I think is editorial work, and in fairly good shape
... so maybe we could say that it's a 4 now

promoting d to a property

heycam: upstairs in the FXTF meeting people were in favour of going ahead with it
... thought we might already have had a resolution on this, but it seems not
... this would be using the same property syntax as used in Motion Path, i.e. path("M 0,0 ...")
... and explicitly not supporting other CSS Shapes just yet

RESOLUTION: Promote d to a property, using path() functions, keeping the current syntax for the presentation attribute.

<scribe> ACTION: Cameron to promote d to a property [recorded in http://www.w3.org/2015/08/27-svg-minutes.html#action05]

<trackbot> Created ACTION-3821 - Promote d to a property [on Cameron McCormack - due 2015-09-03].

display:none on markers

nikos: according to the spec, display doesn't apply to <marker>
... firefox does apply it
... chrome and safari don't
... since it seems to apply to most group elements, seems like it would be reasonable to include

heycam: for Gecko I think it's easier to pay attention to display:none on the marker
... because we don't build frames for it

birtles: we should just fix this bug in Firefox
... a lot of illustrator output doesn't work because of referencing display:none symbols
... illustrator has been updated and doesn't do that now, but there probably still is existing content out there

SVG 2 chapter status update

heycam: Cyril's Introduction chapter is basically done
... just one editorial issue remaining
... let's count it as a 5
... next is the Rendering chapter

nikos: that's a 5 now
... one issue that Dirk added, which I don't understand
... it just says that in SVG 1.1, the definition for clip and something else followed on here
... so maybe if someone else could see if you can work out if there's an issue there
... and if not I'll just remove the issue

<nikos> file:///Users/nikos/svg/w3c/svgwg.tidyforpublication/build/publish/render.html#issue11

<nikos> https://svgwg.org/svg2-draft/render.html#issue11

heycam: just remove it
... the chapter already talks about clipping and overflow
... next chapter is Types
... did a lot of rewriting of SVG DOM stuff
... reworded to making methods/attributes more concise too
... document struct, erik gave his update before
... next, Styling
... I've done about 2/3 of the rewrite
... should be able to finish this this afternoon

https://svgwg.org/svg2-draft/styling.html#PresentationAttributes

scribe: two main changes to get review from other people for
... one is the choice of which properties get presentation attributes, and on which elements they're supported
... see the link above
... second is the set of properties that are required to be supported in an SVG 2 user agent

https://svgwg.org/svg2-draft/styling.html#RequiredProperties

Tav: yesterday I was talking about the new font-variant properties, and font-feature-settings

heycam: ok I'll add that
... next is Geometry Properties
... that was already a 5 I think
... next is coords

nikos: I think it's better than 2
... only 5 unresolved issues
... I think there was concern about viewport/canvas term use being inconsistent
... so that would be a bit of effort to go over
... most issues left are around bbox section

heycam: they're my issues, so I'll look at them

nikos: I'd at least put it up to a 3

heycam: next is Paths
... that's already a 5
... next is Shapes
... still a 5
... next is Text
... a lot of work has been done, but a lot still needs to be done
... Tav and I came up with a plan for the chapter and an organisation we agree with

Tav: currently there are no normative issues for discussion, but some might come up
... also some specs we're referring to are changing, like css-inline, writing-modes

BogdanBrinza: sounds more than 2 then

Tav: certainly not more than 3
... 3 if you round up
... I plan on working on it a lot this month, so should be above a 3 by then

heycam: next is Embedded Content, ready for review
... cyril started review

BogdanBrinza: biggest issue was placement of elements
... rest is editorial
... so I would leave it at 5

heycam: after that is Painting
... I haven't done much on this chapter
... but there are no normative issues to discuss
... just write some examples, clarify some wording
... next is Paint Servers

Tav: IDLs have been taken care of
... I've taken care of most of the issues
... to be sure it's a 5 I'd have to have a read through

heycam: let's list it as 5 now
... I'll go through the hatch content model issue with you after this
... next, Scripting and Interactivity

BogdanBrinza: was 4, probably similar

heycam: next is Linking

BogdanBrinza: ready for review
... biggest issues were Media Fragments, and we discussed them this week

heycam: let's aim for all 5s by around TPAC, that will give us 3 months before the Sydney F2F at which we'll publish a CR
... if Text has trouble reaching 5 by October, we can help out at that point
... those 3 months we'll use for reviewing the spec as a whole, cleaning up wording, etc.

<nikos> http://paris.ilovebuvette.com

RRSAgent: make minute

RRSAgent: make minutes

- DRAFT -

SVG Working Group Teleconference

27 Aug 2015

Attendees

Contents