<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
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
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
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.
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.)[End of scribe.perl diagnostic output]