<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

Define basis for percentage transform on patterns, gradients, clipPath

<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

review of html 5.3

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

Finalize at-risk items per David's spreadsheet

<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

more features at risk

dstorey: nothing else on the DOM side

issues

<BogdanBrinza> topic: stroke-bounding-box and non-scaling-stroke

<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.)