Administration

<AmeliaBR> Scribenick: AmeliaBR

krit: A reminder that registration for TPAC is opened.
... we meet on Thursday for the WG meeting, with 2 hours that afternoon dedicated to the SVG community group.
... any updates on the CG?

Amelia: We have a charter. I've been working on setting up infrastructure. Need to write a blog post requesting proposals for projects.

Dirk: Also on admin. I won't be around next week. I'll ask Chris to chair.

Tav: I also won't be on the call next week.

Amelia: And it's a holiday in the US. Maybe skip? Although the week after is a travel day for anyone going to the CSS F2F, so that might get cancelled, too.

Dirk: Ok, we'll see.

Myles: Checking calendar, I'll also be gone next week.

Dirk: Ok, then let's cancel that & the week after.

<krit> ScribeNick: krit

getBBox algorithm doesn't factor in child transforms

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

AmeliaBR: SVG2 has a detailed algorithm for bounding box which wasn't in SVG 1.1. BBox on groups with children will end up in parents coordinate space.
... we got consensus and consistency. But then RobertL brought up elements with inner and outer coordinate system
... So you define coords in the parent coordinate systems and the elements own viewbox. This is not clearly specified. That also affects transforms and cumulation of transformation systems (inner or outer coord system affected?)
... we do not have consistency between browsers all the time. But looked at the current state for all browsers in all cases.

Tav: what is most useful?

AmeliaBR: giving users the choice.
... There are situations where you want the box of its cumulated child boxes.
... But shape within a parents context might give you inconsistent numbers.

krit: did you see some level of consistency?

AmeliaBR: Every UA is consistent how child transforms affect parents bounding box.
... Need to test how things work with nested SVGs or even the root SVG.

krit: Can we split the issue?

AmeliaBR: maybe we should open a separate issue.
... Example: you got a group and the child (e.g. rect) element has a transform then this transform affects the group bounding box.

Tav: would be surprised otherwise.

AmeliaBR: We have the detailed algorithm for SVG2 but we forgot the point described above.
... I can take responsibility for the edits if we agree.
... If someone has time to look at nested SVGs that would be great.

krit: To be clear: nested SVGs means inner SVG?

AmeliaBR: all elements that have an inner and outer coordinate system like all elements with a viewBox.

krit: makes sense to spec transforms on children

AmeliaBR: algo doesn't mention that coordinate systems change when going from inner to outer at all currently.

krit: lets split the issue then and agree on the first part of the issue. Someone could work on tests for the 2nd issues?

<chris> I can help on that but not this week undortunately

AmeliaBR: there is the part to figure out what should be spiced and the part about writing conformance tests.

krit: Can not commit to it but try to look at nesting as well.

AmeliaBR: Simon also brought up affect of 3D transforms on bounding box
... we should figure the 2D part out first.

proposed RESOLUTION: Transforms on the children will be transformed into the parents coordinate system and affect the parents bounding box.

RESOLUTION: Transforms on the children will be transformed into the parents coordinate system and affect the parents bounding box. Additional resolutions for rotation may follow.

<chris> sgtm

BIDI reordering across multiple 'tspan'

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

AmeliaBR: I think everyone agreed what should happen. However, some UAs don't do it. Do we need clarifications in the spec? Or just open issues to the UAs?

Tav: Inkscape is incorrect. Shaping should happen across spans.

AmeliaBR: markup shouldn't create isolation for reordering. Unless we have the one specific rule of creating layout chunks.

myles: HTML does shaping across spans
... it is also very common across websites.
... If you don't do shaping between spans it is totally broken. This is a bug we have (in WebKit?).
... we should be consistent between svg and HTML here/

AmeliaBR: agree with this statement,
... Do we need more clear in the spec what is expected?
... Right now the BIDI direction is taken on in the general section. Might be worth pulling it out in a dedicated subsection.

myles: should live close to the BIDI section but no opinion on editing in general.

AmeliaBR: There might be a number of edits required to this chapter. myles, you might be best suited to go through the section since you didn't write it and might not imply things. Would be great if you would be willing to take responsibility for.

myles: I am willing to help out on it but it might not be valuable to do specific edits but doing general reviews might.

AmeliaBR: More edits will be required even after todays discussion. The edits need to be made eventually.

krit: lets start with the review.

myles: Can not promise but might have time next month.
... we should match what CSS says. It has very detailed text.

AmeliaBR: in general we should be as consistent as possible.

proposed RESOLVED: shaping and BIDI occurs across tspan boundaries.

RESOLUTION: shaping and BIDI occurs across tspan boundaries.

proposed RESOLVED: Text shaping should be harmonised with CSS Text

RESOLUTION: Text shaping should be harmonized with CSS Text

tspan and text shaping

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

See discussions on https://github.com/w3c/svgwg/issues/635 for details

AmeliaBR: previous resolution to BIDI and harominzing with CSS Text does cover this issue.
... CSS guidance has more nuances

<chris> I think that was the best we could assume, *at the time*

AmeliaBR: Harmonizing means we drop the rule that any markup boundaries disables ligatures
... some cases might not be defined specifically at the end. CSS ends up with auto a lot.
... Should it be possible to paint half of the ligature in another color than the other? Firefox does it.
... it divides the offset distances in half

Tav: this may cause trouble for more complicated glyphs

myles: agree.
... anything like that is too complicated.

Tav: we wouldn't implement it

AmeliaBR: what should happen?
... what if the color is dynamic on selection?

myles: I would prefer to leave this up to the implementation. Firefox behaviour shouldn

t be illegal but wouldn't want to implement it. So spec should not dictate one or the other way.

krit: need to resolve?

AmeliaBR: maybe we tie this into CSS Text

myles: if this WG thinks one behavior is better than the other, CSS should do the same.

krit: does sound like we don't need another resolution. We would do what ever CSS does.
... this is covered by harmonising resolution.

Which CSS concepts should be supported in presentation attributes?

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

myles: Made a proposal as a starting point
... We resolved that we need var() last time. env() is a better fit and we will use it eventually.

AmeliaBR: the spec was not stable and when adopted it should be treated as var(). Maybe some text like that.

myles: percentages are not difficult to implement but not sure what it would be used for. lets do relative units first...
... Relative units doesn't fit the requirement that there is just one layout and the layout should not change dependent on the content it lives in (similar to PNG)

AmeliaBR: we might want to have special rules for outside SVG (or maybe not?). Maybe it makes sense to always have absolute values on SVG root?

myles: Presumably an image element would be styled with a width and height already

AmeliaBR: just an intrinsic width and height
... benefits for abs values is forcing an absolute/explict intrinsic dimension.

myles: I think I agree on that. Good argument for abs values even on SVG root.

AmeliaBR: then we have viewBox requirement on SVG root element.
... if there is none, then percentages make a difference depending on the computed viewport.
... spect ratio is special and separate from rel/abs units.

myles: If you create a native apps and you put in some things inside it and change the size the resource it might be very unexpected.

AmeliaBR: viewBox can be discussed separately.

myles: Requiring env() is future proof and if it works as var() not difficult?
... "If you support var() you should support env()"
... since var is required, env is required.

RESOLUTION: SVG Native requires env()

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/Topic: TPAC/Topic: Administration/
Succeeded: s/AmeliaBR/krit/
Succeeded: s/bounding box./bounding box. Additional resolutions for rotation may follow./
Succeeded: s/option/opinion/
Succeeded: s/Harminizing/Harmonizing/
Default Present: krit, AmeliaBR, stakagi, Tav, myles, chris
Present: krit AmeliaBR stakagi Tav myles chris
Regrets: Sairus
Found ScribeNick: AmeliaBR
Found ScribeNick: krit
Inferring Scribes: AmeliaBR, krit
Scribes: AmeliaBR, krit
ScribeNicks: AmeliaBR, krit
Found Date: 20 May 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.)