<ericwilligers> I just joined https://mit.webex.com/mit/j.php?MTID=m7ba9f827ad378ddf988554eb274f6f96

<ericwilligers> Call: +1-617-324-0000 Meeting number: 646 162 710

<krit> ScribeNick: krit

CR for Geometry Interfaces Module Level 1

https://drafts.fxtf.org/geometry/

Geometry Interfaces is an CR already. CSS WG agreed to publish an updated CR. Asking the WG to do the same.

AmeliaBR: have there been changes?

krit: yes, couple of singificant changes since last publication. Implemented interoperable.

AmeliaBR: Does FXTF still exist? Not in the SVG charter.
... but ok to give support.

krit: objection to an updated CR?

RESOLUTION: SVG WG ok with updated CR of Geometry Interfaces.

<foreignObject> and <svg:use>

GitHub: https://github.com/w3c/svgwg/issues/511

<myles> ScribeNick: myles

krit: THat was ported by Amelio from Mozilla. <use> in 1.1 and in 1.2 is allowed to refer to foreign object. However, only firefox actually does that.
... Emilio would be fine to drop this support in firefox. and therefore from teh spec.

AmeliaBR: in SVG 1.1, there was a restriction on directly reusing foreignobject but that was confusing because you could reuse a group that contained a foreign object, that's why it was dropped. THere were concerns with maintinain state like an HTML checkbox between the shadow version and the original version. That's the way it works. There's state in HTML elements that aren't part of styles and attributes.
... I'm trying to remember the text in SVG 2 right now. Whether we have any restrictions at all.

krit: AFAIK there are no restrictions w/r/t foreignObject. Perhaps in the shadow tree?
... I'm also not sure.

AmeliaBR: We don't have any specific mention of foreignObject in the <use> section.

krit: Even so, coming back to it, Firefox is the only browser that supports that, i doubt that inkscape, and definitely Illustrator, support it. Because the request comes from Firefox, do we agree to drop support?
... Are there plans in Blink or WebKit to implement?

AmeliaBR: We would have to clearly define what it means to clone an HTML element inside <use> Otherwise if we encourage people to support it, we will have implementations that are not interoperable.

krit: myles, dino: Do you have any plans?

dino: we don't have any plans.

ericwilligers: <silence>

krit: I would be fine with dropping foreignObject, but it's up to the other members.

ericwilligers: we don't have any plans to support it.

<dino> dropping foreignObject from <use> right? not dropping it completely.

krit: yes

myles: That includes foreignObject inside <g>, right?

krit: yes

myles: it's a good idea to drop it.

AmeliaBR: we would still need to figure out what that means because you might have a <use> that references a tree, where somewhere inside is a <foreignObject>. Does that make the entire reference illegal, or does it just silently drop the html element. What do browsers do?

krit: WebKit and Blink just ignore the <foreignObject> and its descendents, the rest of the tree is still valid

AmeliaBR: that sounds the most useful.
... as long as its feasible.

RESOLUTION: <foreignObject> in referenced subtrees of the <use> element would not be considered for the shadow tree

Remove un-implemented `pointer-events` "painted" rules for images

GitHub: https://github.com/w3c/svgwg/issues/322

krit: This is about the part of pointer events for raster images. I don't know why it's specific to raster images. ANyway, the spec says you look at the pixels inside the raster image and check the transparency. If the pixel is transparent, it isn't considered in the image for pointer events. Suggestion: Drop this requirement because it's not implemented anywhere

AmeliaBR: It's not implemented anywhere, that's the deciding factor. The reason it's not implemented is because of security concerns, not wanting script to be able to access the pixel data of an image that might be cross origin.

krit: it's a good excuse.

AmeliaBR: The main thing it comes down to: It's not implemented, it's not consistent with HTML, and I can't see anyone out there relying on it because there aren't really any other interactive implementations other than browsers

krit: Proposal: Just rely on the bounding box of the element. I made a pull request to just remove the spec text about transparent pixels

AmeliaBR: I haven't looked at the PR, but it sounds good

RESOLUTION: Image pixel data isn't used for hit testing

SVGTransform's setMatrix method should take a DOMMatrix2DInit

GitHub: https://github.com/w3c/svgwg/issues/326

krit: we already changed the interface from DOMPointInit, that would pretty much be the same thing, except DomMatrixReadOnly to DOMMatrix2DInit

AmeliaBR: the only question: Whether those methods copy the matrix or create a new matrix with the same data
... whether they reference the exact same data or create a copy of it

krit: they currently do not reference the object
... in your terms, it would be a copy

AmeliaBR: it says it's do a new matrix, so it's not about preserving the exact object. so in that case no there's no reason not to be able to use a dictionary with the same properties as a matrix, it doesn't need to be a particular class type. Sounds good to me. There was another message .... ?
... CreateTransformFrom <inaudible> okay, that sounds the same

RESOLUTION: Replace DOMPoint with DOMPoint2DInit with SetMatrix() and createSVGTransformFromMatrix()

vector-effect host coordinate space is not "screen"

Github: https://github.com/w3c/svgwg/issues/582

<krit> https://svgwg.org/svg2-draft/painting.html#PaintingVectorEffects

krit: if you look at the definition for host coordinate system, there are two specification texts: ☝️

<krit> https://svgwg.org/svg2-draft/coords.html#VectorEffects

👆

krit: the first is a defintion for how everything gets painted. Refers to a "screen" value. The screen coordinate system is the initial coordinate system. Doesn't need to be the device coordinate system. It's the coordinate system of the canvas
... the second link ist he definition of the vector-effect property: screen, viewport.

<inaudible>

krit: screen references the same thing as the painting section, but viewport says the nearest viewport is used as the host coordinate system. Neither are correct, but there is interop between firefox, webkit and blink to a degree.
... I would explain it as in the host coordinate system is the furthest viewport of the current SVG fragment which doesn't include any boudnaries of other namespaced elements

AmeliaBR: I liket he wording you found in SVG 1.1, clearly breaking out to other layout, then you're resetting the baseic transfomration
... but at the same time, it would be more useful if it was based to the screen, like get screen ppm is...

krit: get screen ppm is defined to refer to the documetn root, which is something else. Ideally, both would be defined the same way

AmeliaBR: The definition of that would need to get updated
... It might be what impelmentations do. I need to check whether it's implemented, and how. It might be good to align, but let's concentrate on vector-effect. Let's focus on what's imjplemented and interoperable, even if it isn't the device coordinate space or the init coordinate space
... I prefer an implementation that didn't have separate rules for transformations on SVG vs transformations on parent CSS layout box. I prefer that we were able to approach those transformations and cumulative transformations, and the vector-effect dealt with that same cumulative effect. But I would also like to get this spec finalized, and if that means matching what everyone has implemented, then that's the sort of compromise I can make. But it

depends if all the browsers are interoperable among themselves.

krit: there's 1 case where they're not interoperable, blink is interoperable to webkit but not to firefox
... Firefox would go up to the SVG root element, but BLink would stop before the root

AmeliaBR: that's not a shadow root, it's a foreignObject content switch

krit: that's the only interop issue.
... I believe it used to be the same as WebKit and blink, but somehow behavior changed. But we still have 2 interoperable implementations, webkti and blink

AmeliaBR: a foreign object inside would switch to CSS layotu mode, but if there's SVG inside that, you switch to SVG layout mode. But there's a box that follows CSS rules

krit: Is it defined this way in SVG 2?

AmeliaBR: It's defined that way for children of foreignObject are supposed to behave as children of HTML elements.

krit: It should be easy for WebKit to also have this switch on the foreignObject. If it's easy, we can do that, and follow the blink implementation
... it's always easier this way than the other way around

myles: we don't want to hold up standardization. It's a corner case, we won't push either way

AmeliaBR: <svg> direclty inside <foreignObject> is rare

krit: let's keep this one out for now and resolve on the general idea
... proposed resolution: The host coordinate system is the furthest SVG viewport without switching namespace contexts?
... I put up a pull request, which I think was an SVG fragment that can be .... any element in that fragment being in the SVG naemspace, but that's something that ....

AmeliaBR: You can just say in teh resolution "as defined in SVG 1.2 Tiny"

RESOLUTION: The host coordinate system is the furthest SVG viewport as defined in SVG 1.2 Tiny

How does vector-effect=non-scaling-stroke interact with the stroke-dash* properties

Github: https://github.com/w3c/svgwg/issues/323

krit: <reads issue title>
... the question here is when we draw a stroke with a dash array, which coordinate space would the dash array be drawn, the original one or the new one? That's defined by the painting order, draw the stroke as specified by the stroke paint computed ... mumble
... "Compute the shape of the stroke"

<krit> https://svgwg.org/svg2-draft/painting.html#PaintingVectorEffects

krit: I think it's specified already, but does anyone have anything to add here? The section in the stroke of the vector effects shows how you get back to the host coordinate system. It follows to compute the shape of the stroke section. It should clarify the issue.

AmeliaBR: As Chrome commented on the issue, I think all these properties should have the same scale adjustment. Otherwise it would be very confusing. It would be non-uniform scales.

krit: right.
... that is my main concern as well.
... You would have triangular, a^2 + b^2 = c^2 ...

AmeliaBR: yeah.

krit: I'm not sure, can we close this as no fix? not invalid, but already defined?

AmeliaBR: it does need clearer text.
... ... to make it clear what should happen. We should state that this isn't ideal for some use cases, and we've decided not to chagne for thsoe use cases.

krit: so, add a note.

myles: adding a note, or an example, even, would be great.

isPointInFill/isPointInStroke and display: none and other specifics

Github: https://github.com/w3c/svgwg/issues/456

krit: This is a more general issue that gets more visible with the new presentation attributes, x, y, widht, height, etc. that we have for geometry objects. To describe the issue, we have interfaces like isPointInFill, isPointInStroke, getBBox, that is supposed to return values independent of the state of teh element (like if it's attached to the DOM)
... the reality is that firefox can't return correct results if it's display none. But with the presetnation attributes on geometry attribute,s the same issue comes up on WebKit and blink, which is an implemetation detail, both are not able to provide correct results if you have display:none or its' not attached tot he DOM
... The proposal is we allow UAs in certain situations to not return the correct result. First we need to agree to allow UAs to not return the correct results in certain situations.
... I think it was a proposed text from emilio which is "if a UA is not able to lay out an element, it would need to return an incorrect result for these interfaces" and the spec would give non-normative examples with display:none, or elements not attached to the dom tree.
... Example: <rect> w/ width= and height=, those are now CSS properties, so if you have display:none, none of the browsers would be able to compute the dimension of the <rect>. Implementation detail but that's a fact.

<ericwilligers> Why not say that we throw if display is none or the element is not attached?

krit: I would like to specify that for all those interfaces there are exceptions where UAs would not need to return the correct value.

myles: I'm worried about using the term "lay out" normatively in a psec. Let's gather more specific requirements for when the result can be wrong?

ericwilligers: why not just throw?

krit: that's not the question.
... myles - i agree it would be cool to specify them, but optimization steps might not allow it. So we can't be specific about the entire collection, we can't use "might" or "may", it might work as well

AmeliaBR: defs shouldn't be treated differently than any other case of display:none
... The way we define how defs work in SVG 2 is it forces display:none
... so it shouldn't be different.
... there shouldn't be a difference between author display:none and automatically display:none

krit: we could say "elements that don't get rendered"

AmeliaBR: visible:hidden is different.

krit: yeah, we woul dneed to specify what "Rendering" means

AmeliaBR: that is specified. we have definitions what it means for elements not to be rendered.

krit: can we use this term? UAs may return on elements that do not get rendered?

AmeliaBR: yeah

ericwilligers: Can't we just say the 3 cases: display:none, <defs>, and is that it?
... or its' not attached
... and I suggest we should throw

krit: In CSS we already ahve a term that describes those cases, so we can use that term

RESOLUTION: Elements that "do not get rendered" may not correct the correct, expected value for methods that require calculating the geometry of an element. (Does not include getCTM() or getScreenCTM())

AmeliaBR: transforms are separate from geometry, I guess.

RESOLUTION: Elements that "do not get rendered" may not correct the correct, expected value for methods that require calculating the geometry of an element. (Also includes getCTM() or getScreenCTM())

AmeliaBR: wait, no no no no
... you don't need geometry to calculate the CTM!!!

krit: You probably want the transform properties to get the CTM.

AmeliaBR: Darn it.
... okay.

krit: what about getCTM() and getScreenCTM()? In some situation, they already return null. How about we use this behavior for the above situations, too?
... So getCTM() and getScreenCTM() would return null for these situations, and we still have to decide on the others.

AmeliaBR: My strong feeling is that it should return something that is obviously not available, and can't be mistaken for a real result that is not the correct result

krit: Firefox throws already (NSError, an internal error...) I don't see any interop problems here.
... getBBox() already throws in Firefox, so there's probably no issue

ericwilligers: getTotalLength() will also probably have to throw.

krit: agreed.
... can we resolve on those methods that are not able to return null would throw?

AmeliaBR: the other option is to return NaN
... or a BBox with all values set to NaN

krit: that doesn't require a try catch

AmeliaBR: it might be cleaner to have a try catch

myles: let's not use NaNs because they are silently propagated

krit: sounds like we prefer throwing.

AmeliaBR: Firefox is already throwing, so there's precident
... Any preferences for which error to throw? Or we could send it back to Github

krit: Let's make a PR and discuss it there.
... That's what HTML does.
... We are out of time.

RESOLUTION: getCTM(), getScreenCTM() return null in this situation, everything else throws a to-be-determined exception in this situation.

krit: If you have issues, please add the label on the Github issue.
... Thank you much for calling in!

none

<krit> trackbot, end telcon

This is scribe.perl Revision: 1.154  of Date: 2018/09/25 16:35:56  
Check for newer version at http://dev.w3.org/cvsweb/~checkout~/2002/scribe/

Guessing input format: Irssi_ISO8601_Log_Text_Format (score 1.00)

Succeeded: s/don't support/support/
Succeeded: s/sane/the same/
Succeeded: s/either wa/either way/
Succeeded: s/titel/title/
Succeeded: s/tohers/others/
Succeeded: s/correct value/real result that is not the correct result/
Default Present: krit, Tav, ericwilligers, AmeliaBR, dino, stakagi
Present: krit Tav ericwilligers AmeliaBR dino stakagi
Found ScribeNick: krit
Found ScribeNick: myles
Inferring Scribes: krit, myles
Scribes: krit, myles
ScribeNicks: krit, myles
Found Date: 12 Nov 2018
People with action items: 

WARNING: Input appears to use implicit continuation lines.
You may need the "-implicitContinuations" option.


WARNING: IRC log location not specified!  (You can ignore this 
warning if you do not want the generated minutes to contain 
a link to the original IRC log.)