<scribe> ScribeNick: krit

[svg-native] Decide whether reusable graphical elements are needed

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

kris: we had this on the previous agenda but didn't cover all

myles: I think we had symbols, masks, gradients sharing stops and use.

AmeliaBR: we grouped inner SVG with symbols
... mask is still up for debate

myles: I think all implementations implementing masks use an offscreen buffwer
... so there are limitations like pixel density before drawing on a offscreen buffer and you need a big enough buffer which might be problematic on certain devices
... those are the cons.
... The pros are that it is very common

AmeliaBR: I can not comment in general but on Blink they are similar
... both are handled with compositing

some discussion about AA on clip path and masks

<AmeliaBR> > The raw geometry of each child element exclusive of rendering properties such as fill, stroke, stroke-width within a clipPath conceptually defines a 1-bit mask (with the possible exception of anti-aliasing along the edge of the geometry)

<AmeliaBR> from https://drafts.fxtf.org/css-masking-1/#ClipPathElement

krit: Masking draws a shape on an offscreen buffer which causes AA. Then this buffer is used with compositing which adds another level of AA. This is not allowed for clipping masks where only the clipped result (drawing the clipped content on the backdrop) is allowed to be anti-aliased

AmeliaBR: not normative in the spec though. We could agree that a clipping path is a vector operation.

myles: so the difference would be very subtle. Can it be tested?

krit: it is and we can not test it since AA depends on HW and SW implementation.

myles: I don't think that, if there are differences, they would matter for masking.
... As far as I know, there is no implementation that can use masking w/o an offscreen buffer.

AmeliaBR: reason I mentioned it is that the discussion should also be about clipping.

myles: most implementations implement clipping and masking differently. So implementation burden might differ. I would claim they do differ.

krit: just to add to the comment from myles: there might be implementations that implement masking and clipping the same way, there are implementations that don't.
... Do we know implementations that do not support masking?

myles: the MS one doesn't... let me verify

krit: I meant on the rendering level... D2D does support it, right?
... beside the argument of the offscreen buffer, all rendering implementations probably are able to support masking.

<myles_> https://docs.microsoft.com/en-us/windows/win32/direct2d/svg-support doesn't support masking

krit: the other question would be about the implementation complexity of <mask> itself.

AmeliaBR: you mean the creation of a local coordinate system?
... clipping path and patterns are similar to mask and have some kind of a local coordinate space though not all create a viewport with viewBox or similar
... One option might be to support masks and clip path but only userSpaceOnUse or objectBoundingBox depending which one is easier to implement.

krit: I'd like us to get into this direction.

myles: So if we did accept masking then we would be asking MS to add masking to their implementation because they don't support it today.
... how would you implement masking with the streaming interface SVG Native Viewer has?

krit: Thinking about it it would be very difficult but should be possible

AmeliaBR: we all agree that clip path is necessary? So clip path will be part of SVG Native?

myles: I think this is right

AmeliaBR: so the question is about mask

myles: from an illustration point of view: how often do authors use masking?

krit: most content uses clipping path but there are cases where ppl use actual masking. For SVG Tiny export we rasterise it.

myles: we should get more feedback from implementers.

AmeliaBR: especially to discuss what is difficult about masking. myles could you open a new issue please?

myles: I'll do
... I think this is all for this bug

Chairing next week

krit: will not be able to call in next week. Would some one able to chair next week?

AmeliaBR: I could even though there is a holiday.

krit: there is the possibility to skip next weeks meeting.

AmeliaBR: We could create an early agenda for the week after next week and next week will be a work-on-your-items week

Defer onfocusin and onfocusout

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

AmeliaBR: it really depends on the feedback we get from HTML
... I wonder if we could have some wording. I wonder why we have them part of the events. They don't seem to be part of the standard mixins.
... If HTML gets them we get them automatically.

myles: sounds like a good argument to defer until HTML gets them.

AmeliaBR: we should not be defining them other than by using HTMLs mixins and definition

krit: were they part of SVG 1.1?

AmeliaBR: no, we don't say anything anywhere. They are just listed in the element definitions and the definitions have disappeared.
... Propose to remove them for now. Assuming that they will be included by HTML's mixins, they will get included in HTML.
... They actually were in SVG 1.1

krit: Still support your proposal but should add a note then

AmeliaBR: we have a note for other events where we now use HTML's definition. We can add a note that they should only be implemented in a way theat they are consistent with HTML.

RESOLUTION: Remove from SVG2 but automatically include again when defined by HTML. Add a note.

How should ResizeObserver work for SVG layout elements?

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

AmeliaBR: ppl should look about it and comment what would makes sense

krit: is it ready for discussion?

AmeliaBR: in CSS we said SVG elements with CSS layout box should behave like all other CSS layout box elements
... So I created an issue for SVG elements that are not using the CSS layout box. Should we map the CSS layout box terms to SVG or should we do it differently? What are the use cases for SVG?

krit: looking at use case first might make sense. Who should primiatly look at those? Implementers? Authors?

AmeliaBR: both. But we should come up with boxes that are rapidly caculatable.

krit: everything that creates a new SVG viewport might be easy. Everything else needs to compete the Object bounding box which might not easy to compute for text and paths.

myles: Not sure if SVG viewport only would be useful. Nested SVG might be useful still but would be shame not to support it everywhere.

krit: having more feedback from actual authors and users of resize observers would be great
... do we want to provide any options

AmeliaBR: Options are 1) there is nothing to observe on SVG layout (only CSS layout box elements). We could have the option to support bounding box observation in the future.

myles: authors might not know the terminology

AmeliaBR: talking in spec terms
... 2) What is currently in the spec: any request for observing an element just returns the SVG object bounding box.
... 3) Try to map CSS layout box to equiviland SVG boxes. padding box to object bounding box...
... there is no implementation that exposes stroking bounding box

krit: we do the mapping for some CSS properties

AmeliaBR: but not in a consistent way yet

krit: might not easy to make it consistent but it still is a possibility.
... my personal preference would be the mapping. As said, competing the bounding box is not always fast. On the other hand, it isn't always in CSS either.

<myles_> https://github.com/w3c/csswg-drafts/issues/4116

Images with layout information

GitHub: https://github.com/w3c/csswg-drafts/issues/4116

myles: there are different ways to get the effect
... images could have additional information inside
... logos are often presented in SVG.
... maybe we could add a attribute to the SVG root.
... there is another option like system artwork which have their own information that should be used.

krit: there was a proposal to the CSS WG which was called something like Content Aware Zoom or Scale. The idea was to specify an area that must be focused. Depending on the space, more or less of the image gets displayed. We should look if your proposal can be aligned with it. I do support working on it.

AmeliaBR: We should not only look at baseline alignment. And coordinate with CSS.
... If we talk about text layout we have very different properties.

krit: consider bringing it up to SVG CG

AmeliaBR: we should look if there is a cSS proposal first and then we should look at SVG and where we would work on it.

trackbot, end telcos

<trackbot> Sorry, krit, I don't understand 'trackbot, end telcos'. Please refer to <http://www.w3.org/2005/06/tracker/irc> for help.

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/pros/cons/
Succeeded: s/suttle/subtle/
Succeeded: s/mixing/mixins/
Default Present: krit, AmeliaBR, myles, stakagi
Present: krit AmeliaBR myles stakagi
Regrets: sairus Chris Tav
Found ScribeNick: krit
Inferring Scribes: krit
Found Date: 29 Jul 2019
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.)