<scribe> scribenick: chris
BogdanBrinza: question to chris and liam, update on progress?
chris: huh?
BogdanBrinza: Microsoft AC said PLH was checking on progress, not happy with progress
chris: demonstrate progress by publishing, making DoC
BogdanBrinza: so, issue by issue or items at risk? Looking for actionable issues like the one Dirk sent
<BogdanBrinza> GitHub: https://github.com/w3c/csswg-drafts/issues/892
dirk: introduced transform box,
as it is different in html and svg. Problem with resource
elements
... not clear what the reference box should be
... already have this in SVG 1.1, patternUnits,
clipPathUnits
... indirect referene box, x y etc resolve relative to
that
... suggest using same reference box for the transforms esp
percentage values
... easiest and most straightforward way
AmeliaBR: reviewed before call,
most sensible approach. No easy way to do transform box.
... what Dirk prooposes is consistent with how gradient
transform is implemented everywhere. pattern transform needs
better interop, so good guidance. And also for clipPath and
mask
... consistent where we have web compat
dirk: not clearly defined that it also defines the reference box, spec needs to be clearer
AmeliaBR: yes we need spec
text
... in clipping and masking and svg2
tav: and test cases
(general agreement)
RESOLUTION: use indirectly defined reference boxes for transforms on resource elements. transform box does not apply to graphics elements.
dirk: I will do the spec work
AmeliaBR: we need tests, they will need to be manual tests as affect rendering
dirk: we have some tests for
clippath but not with transforms or percentage units
... 3 more issues on transform spec, need to be discussed by
css wg. then will republish
... want wider review
dirk: deadline was 3 days ago
BogdanBrinza: should we review?
AmeliaBR: nothing SVG specific except maybe shadow dom and custom elements
dirk: svg still excluded from custom elements
AmeliaBR: yes
dstorey: the W3C version does not have the mixins we need or the new features
chris: agree with david, we need to reference the whatwg version anyway because of mixins
BogdanBrinza: so nothing svg specific, and out of date, so no comments. will summarise our comments
AmeliaBR: did file an issue on the html spec, was too late for 5.3
BogdanBrinza: changes are from
how the web works today. resolved bugs.
... low interest for html 5.3
<BogdanBrinza> https://onedrive.live.com/view.aspx?cid=fd9e7123283f274c&page=view&resid=FD9E7123283F274C!594647&parId=FD9E7123283F274C!103&app=Excel
BogdanBrinza: can finalize the spreadsheet
dirk: new option parameter for
getBBox
... have a webit impl but depends on stroke bounding box
... any other implementor interest?
AmeliaBR: is it publicly exposed? behind flag?
dirk: there is a patch. can back out to 2.1 if no other implementors
AmeliaBR: or leave it and mark as at risk
dirk: pref to not have to many at risk
BogdanBrinza: agree, better to move to 2.1
<liam> [no objections here, mark it as at risk and move on with life, we need to publish :-) ]
krit: good to publish FPWD or 2.1 soon
<Tav> +1
liam: yes, we resolved to do this at same time as 2.0 updated CR
RESOLUTION: Keep getBBox extended in 2.1, remove from 2.0. If implementations happen as we get closer to REC - we'll get it back
BogdanBrinza: busy recently, hope to do edits this week
AmeliaBR: and we need a proper DoC from the last 2 years worth of comments
dstorey: nothing else on the DOM side
<BogdanBrinza> GitHub: https://github.com/w3c/fxtf-drafts/issues/279
krit: referencing stroke bbox
more now, and this does not take into account non scaling
stroke. Is it the bbox or some hueristic of the stroke. We
resolved on hueristic in the past to be comparable in all
browsers. otherwise result is library dependent.
... some cannot compute at all, others do not give a tight
bbox
<AmeliaBR> Current definition/algorithms for the different bounding boxes: https://svgwg.org/svg2-draft/coords.html#BoundingBoxes
krit: agreed to use hueristics,
more consistent and easier for developers
... if we keep it we need to clarify effect of NSS
chris: sounds like we should stay with the hueristic
tav: what is the hueristic?
<krit> https://drafts.fxtf.org/css-masking-1/#compute-stroke-bounding-box
krit: (looks for link) object bbox and then extending based on stroke properties
AmeliaBR: should check for mitred corners, but should use effective stroke width after NSS
krit: NSS graphical effect so not really geometric
<liam> [ https://svgwg.org/svg2-draft/painting.html#TermStrokeShape"Authors should be aware that the shape of a stroke may in some cases, such as at extremely tight curves, differ across platforms." ]
liam: spec says stroke shape may differ across platforms. same in PostScript. depends on precision of floating point.
<liam> [hence arguably not testable]
AmeliaBR: also non uniform scales, which mess up the coordinate system for stroke bbox on unscaled stroke
krit: yes, need to do in viewport
coordinate space
... but do we want to, or leave it entirely up to browsers?
Affects masking, wll be incosistent
AmeliaBR: should not depend on parent coordinate space. if we integrate NSS then it depends on parent context as well
Tav: authors would not expect things to change with NSS
AmeliaBR: warn authors that using these together will not be useful
Tav: what situation would make them do that
AmeliaBR: like a mask image sized to the drawn area of the shape, then when scaled you expect the mask to scale too but it does not, with NSS
krit: need to specify what happens anyway
AmeliaBR: small intersection of effects, ok to say not supported, but needs a clear warning where they are defined
Tav: ok, good. lets not spend much time, little practical use
AmeliaBR: most important is consistent implementations
liam: and with stroke bounding box. will not be pixel fidelity
krit: give hueristic as a
fallback, or say it must be used. in both cases, computing NSS
bbox geometrically is not easy
... prefer to get consistency, so not a tight bbox
chris: i would prefer we exclude it
AmeliaBR: exact computation or a generous hueristic (over rather than under-estimate)
krit: already in the masking spec
AmeliaBR: examples of cases where the mask is a worst case?
krit: will add to the issue
AmeliaBR: would like to see some
diagrams. and feedback from other implementors
... other implementors please give your opinions
BogdanBrinza: Microsoft does not have a strong opinion, but want it to be easy for implementors
krit: differences between the graphics libraries
BogdanBrinza: we don't support NSS yet
krit: this comes up even for ordinary stroke
This is scribe.perl Revision: 1.152 of Date: 2017/02/06 11:04:15 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/tranf/transf/ Succeeded: s/getBBox/ new option parameter for getBBox/ Present: krit AmeliaBR chris liam Tav stakagi Found ScribeNick: chris Inferring Scribes: chris Found Date: 04 Jun 2018 People with action items: 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]