<scribe> ScribeNick: dael

astearns: We'll give people a couple more minutes to call in
... We'll skip items 6, 8, and 10 on the agenda
... Anything anyone would like to add or change?

fantasai: Did you mean 9 instead of 8?

astearns: You said 6 and 10

fantasai: Yes. For 9 we wanted Oriol.

astearns: Oh, I'm sorry. it is 6 9 and 10 to skip

Dropping "synthesizing super/sub-scripts" requirement

github: https://github.com/w3c/csswg-drafts/issues/2796

chris: Let me give a DoC link

<chris> https://drafts.csswg.org/issues?spec=css-fonts-3&doc=pr-2018

chris: One remaining issue. There's an advisement in the spec if you have open type font that has some...

<fantasai> What issue is this?

chris: If it has some open type features for sub scripts and super scripts but doesn't cover all glyphs the spec advises not to use and to synth them. No one does that and it's at risk in CR. As it's at risk and there's not impl interest I opened issue to downgrade to should or may.

<fantasai> https://drafts.csswg.org/issues?spec=css-fonts-3&doc=pr-2018#issue-9

chris: There was some obj, florian not happy

florian: My concerns is since the glyphs supported won't line up it may be semantically confusing. None-lined up may be multi level superscript.

chris: THat's possible. The example was choosen to be particularly bad.
... This isn't a new issue. The advice to switch off the real superscript and sub script is well intentioned but not impl. We could defer the entire thing to L4. We didn't get consensus around changing html stylesheet

fantasai: THis isn't the reason for html stylesheet. THat's because can't do many levels subscript

chris: agree

florian: I agree that just because this is bad we don't have an good answer. I don't want to block and if downgrade to should is what we can do that's what we have

chris: We have downgrade to may, should, or move to L4. I prefer should.

florian: We should put pressure as well as doing should.

<Zakim> liam, you wanted to ask how that works with content-editable when you add the first unsupported character

liam: I wanted to point out it's not an edge case. content editable the user adds an unsupported character. It's an edge case, but it has to work.

chris: Yes, it would mean previously superscript char would have to be rendered differently. But I'm not aware of anyone doing it.

florian: I'm okay with this.

astearns: Obj to change to should in L3 and pushing for it in L4

fantasai: As long as it's clear you have to synth individual super and sub script

chris: Yes

RESOLUTION: change to should in L3 and pushing for it in L4

Request transition to Proposed Recommendation

astearns: Last issue done. Test suite passes?

<chris> https://test.csswg.org/harness/results/css-fonts-3_dev/grouped/filter/1/

chris: There's one non-passing test and that's [missed] and that feature is only in L4. We are good to go.

astearns: Objections to request transition to proposed rec to fonts L3?

<fantasai> https://github.com/w3c/csswg-drafts/commit/1a5b9bcb0a2aac317c08f95bb63d6158d22eb862

fantasai: Looking at edits. Looks like they're not correct
... ^ second switch from must to should shouldn't be changed afaict

chris: Let me look
... You're correct. I'll fix

fantasai: As long as that's fixed I"m fine.

astearns: Objections with that change?

florian: Do we have a report detailing the tests or jsut a statement tests are fine? An impl report.

chris: Yeah. [missed] If you remove filter

<chris> https://test.csswg.org/harness/results/css-fonts-3_dev/grouped/

astearns: chris put the link in IRC

fantasai: One more question

chris: There's 475 tests that pass from before. Do people see that?

fantasai: The 3rd change from must to should [reads] I'm trying to understand what it's about. I think it's that font metrics for supr and sub script don't match actual glyphs and if you apply text decoration it'll be misplaced if you use those metrics. But in a proper font where the metrics match correctly you don't want to synth you want to use actual glyphs
... I think that one should be a may. If the UA can detect there won't be a problem it should ideally use non-synth. I think it was incorrect as a must in the first place

chris: Another thing when we get to this in L4 with optical sizing the font itself can change its size. I want to re-open this on fonts 4.

fantasai: Yeah, but I think go to a may in this level should be fine.

chris: Okay.

astearns: Anyone concerned?
... Okay, let's do that
... Any additional changes?
... With the two changes, objections to proposed rec for fonts L3?

<fantasai> Chris, you probably want to move your comment about the GH issue up to the actual change

<fantasai> also

RESOLUTION: Request transition to proposed rec for Fonts L3

<chris> welcome!

astearns: Congrats and thanks chris for the work getting the test suite up to snuff and everything tidied away

end

florian: Where are we with UI?

chris: [missed] Thursday

<chris> and waiting for your response florian on the other spec

Containing block of filter, plus effect when applied to the root element

github: https://github.com/w3c/fxtf-drafts/issues/11#issuecomment-360240933

chrish: I believe we skipped this last week because dbaron wasn't there. Is that correct?

astearns: It was because you weren't. If we have you and krit we can discuss

chrishtr: We resolved in same issue to make filter containing block for all elements except when filter is on root. Reason for carve out is to avoid breaking fixed pos elemetns
... Example is applying an a11y filter on entire webpage and you don't want that to break fixedpos, just be more readable.
... as currently stands root element is nto the containing block for fixed pos elements. Means scroll of the fixed position element escapes the filter. Problem because in general it doesn't really make sense to have clips and scrolls escape filters because they can move pixels and it becomes strange or impossible to impl.
... I proposed that filter on the root gets applied after scroll and clip but before scrollbars. Can still aplly filter to the whole page, but it will apply clip and scroll correctly and scrollbar is on top.
... Any feedback on this?

smfr: Sounds fine. I thinkt hat means the filte ron the root prop to the canvas

chrishtr: Right, last week it was details of how it applies to the canvas and this is making sure it pushes up to canvas and not apply before scroll and clip

bradk: Don't quite understand the scrollbar comment.

chrishtr: Only root scrollbars of the frame. Scrollbars of root frame would never be able to eb filtered

bradk: Why is that bad compared to other scrollbars?
... Would ti be good if I'm reversing screen?

chrishtr: In some use cases I don't think it is. Root of a UA thing the web page should effect. Scrollbars in page are an effect of the page. It's a gray area but makes sense to carve out.

rbyers: No strong feeling, but seems odd.

chrishtr: Applies to iframes as well. If you had it on the root of the iframe it wouldn't be filtered. I don't feel super strongly but it seems good to not let content mess up the root scrollbar of the page

Rossen_: I want to make sure I get proposal. currently filters will establish a stacking context as well as containing block and being containing block for fixed pos?

chrishtr: Unless it's on the root of the page. Proposal is in addition w apply filter after scrolla nd clip

Rossen_: Initial containing block in this case?

chrishtr: I don't think it's changed.

<astearns> PR under discussion: https://github.com/w3c/fxtf-drafts/pull/263/files

Rossen_: Way we defined so far is this is the root containing block which in your description...that's what confuses me...currently if nothing becomes a containing block the initial one will be the containing block. IT's defined as it being the root cotnaining block. You're trying to reverse that which means to me something above containing block or I'm missing something.

chrishtr: I dont think this changes containing blocks, just order in which things apply.

fantasai: I'm trying to understand what we're doing. Seems changes are very aggressive and I don't understand why it's a good thing. THere's several things...first, we're making anything with a filter be acontaining block for abspos and fixedpos elements. And the filter is fixed for viewport in the same way as a background is fixed.

smfr: I don't think that's true
... It's only if filter is on the root

fantasai: Yeah.
... So if I want a filter for the entire page and not this weird layered thing I can't do that. But that seems what I'd want most of the time. THe filter being a fixed thing that doesn't move it re-filters every time I scroll and the page could shimmer as I scroll. Seems weird
... Also don't understand why making it fixed pos containing block. I think we did that for transforms because figuring out static pos is confusing, but I don't know why doing that for filters

Rossen_: And more confusing because if you have filters become containing block for fixed pos and opacity for example is a containing block but not for fixed. This whole thing is kind of messy.

chrishtr: WG already resolved ot make filter a containing block except for on root.

krit: And it's in the spec.

chrishtr: This is an adjustment. 2nd, why should it be a containing block: Because otherwise the drawing algo to the screen is ill defined. Filter can move pixel and so can't commute with a clip. There's also a perf reason with compositing and GPU accl. THat's one of the main reasons transform is containing block

fantasai: Does clipping clip abspos element whose ancestor is a container?

chrishtr: Follows containing block chair. ANd that's the problem. That's what leads to these obnoxious cases

<TabAtkins> <relpos><clip><abspos/></clip></relpos>

fantasai: I Have an element with clip applied. Inside element there is a child that's abspos and the containing block is an ancestor of the element with clip. If I use overflow then the abspos is not clipped. But if I use clip what happens?

chrishtr: Then clip:rect will clip. Or clip path

fantasai: But if I say overflow:hidden no clip?

chrishtr: Correct.

fantasai: Seems weird.

chrishtr: Containing blocka nd overflow clip and scroll are weird and unfortunate.

smfr: That's a fundimental design mistake with CSS

chrishtr: And this discussion is a result of that. Making filter containing block is one of a series of changes we need to make it make sense

fantasai: My view is when I'm applying a graphical effect to an element I expect it to be everything in the element. Seems odd at a higher level. Fixed pos being effected seems odd to me. Seems weird that I want to apply a filter would change layout.

chrishtr: yep

fantasai: Random set of properties that effect look of something in a subtle way, but these ones effect layout.

chrishtr: Yep. consiquence that they apply to whole subtree but containng block is defined elsewhere

smfr: How does this work with opacity?

chrishtr: It doesn't effect px so it can be special cased.

fantasai: Why can't filter applyt containing block chain and not subtree? Wouldn't that solve it?

chrishtr: Leads to other problems. I wrote a bunch of design docs on ideas like that and it's just really difficult to resolve these issues. The contaning block thing is different then subtree for stacking context.
... THe WG resolved the thing o nthe containing block. Best not to re-litegate.

Rossen_: We resolve and revisit. So that we resolved doesn't mean we can't rediscuss.

chrishtr: Okay

astearns: On the other hand since the thing under discussion depends on that resolutiona nd is required for that previous resolution we could resolve on this because it makes current spec consistent and then revisit containing block bit

krit: Even then there's do we want entire page with filter o jsut what's on the viewport. Has impact on things like blur.

chrishtr: If you want filter to apply to fixedpos descendents you need to define how that works.

fantasai: And in a large part of cases without fixed pos it'll be strange and unexpected.
... What kind of filters do people use? A whole bunch. Do you expect recalc as yous scroll? Page will shift as you scroll. WHen I look at a page and it's a thing I expect it to be a static thing that shifts under viewport. With a filter it doesn't do that.

chrishtr: An invert filter. You won't be able to tell. Only a blur where you can see. Blur is the problematic and is illdeefined otherwise

TabAtkins: For blur to do what you want fantasai you have to render the entire page to a texture and then clip what's in your viewport. THat's untennitable.

fantasai: That is what I'd expect

TabAtkins: It's impossible to do in a reasonable way

fantasai: If you define root to not do that then authors who don't want shimmer as you scroll they'll apply to the descendant of the root and you're in the same place for perf.

smfr: It's important to try and define filter for the way you want [missed]

chrishtr: Suppose you apply scroll after blur, what does that mean? A filter is applied atomically to a texture. Then you have two textures, one for fixed and one for not. For me it's not perf, it also leads to simpler compositing algo.

fantasai: If I had fixed pos elements on my page and I decided to blur the entire page I would expect that the entire page, everything under fixed pos, would be blurred all at once. If you imaging viewport as a cutour in a cardboard and the paper is under as you movet he cardboard it's all blurred. And the fixed position things on the cardboard I would have applied the blur. If there was a red boarder at the top of the footer it would bleed over the page.
... As an author that's what I would expect

chrishtr: The problem is fixed pos content isn't fully separated because containing block and stacking context aren't related. z index and interwave with rest of page.

krit: I'm not sure we're getting to a conclusion. Should we discuss at Sydney F2F? I dont' be there but maybe all parties discussing.

chrishtr: I won't be there, but I'm okay with others talking at F2F

smfr: I won't be there

fantasai: I'd rather get common cases to work and if necessary change how we do stacking rather then do something that's not what people expect to preserve current rules of stacking context.

smfr: Sounds like like a complexification of the current rules not simplification

krit: Impl mostly do what spec says. It would be interweved on the page, not composited.

fantasai: I haven't looked at stacking context rules in details. Yes they're interweved, but how many pages do that? not meany. You can say if there's a filter on the root we don't interweave anymore. Most pages won't see that but then you can have the filters applied in the way authors would expect.

astearns: I suggest we take discussion back to github and bring up use cases. We've talked generally about kinds of pages authors would want, but concrete examples would be helpful. Of fixed pos and interweaving. Have thos in mind as we come to discuss again

chrishtr: Okay

astearns: Thanks for taking us through this chrishtr. We'll come back to this.

Presentation attribute as start or end value of a CSS transition

github: https://github.com/w3c/csswg-drafts/issues/2684

krit: In SVG we have the transform attribute which is a presentation attr which mean sit contributes to css pipeline and we can set a transform and it would interfere in hierarchy with itself.
... If we have a transform with a list and define a transition on the same element, should it take transofrm into account or just ignore? I'm asking for ignore. 2 browsers do that and 2 take it into account.

<krit> https://codepen.io/krit/pen/XqvqyG?editors=1100

krit: codepen^
... You can see that there's a transform on the rect and a transition in css. For webkit you see it transforms and then transforms. blink and edge take the transform from the transform attr and then transition to the value.
... I'd like to ignore as that makes the most sense. So can a transform attr contribute as a start or end value?
... I'm asking for edge or blink behavior.

astearns: Conserns with standardizing on blink or edge?

smfr: Good to match other presentation attributes

<chris> LGTM

astearns: And there's a Mozilla comment saying it's because they haven't made transform a presentation element yet

RESOLUTION: use edge behavior

krit: Syntax and some transform are different then on css. Example is rotate which is 1 value in css, 3 in SVG.
... If we have a transition from a transform presentation attribute with 3 value rotate to css, css would not understand. Edge here ignores the origin so the element jumps and then contiues. Blink composes from one matrix to another
... Webkit and FF ignore.
... Proposal would be to make this rotate with 3 values to a matrix and do matrix decomposition

astearns: This is an edge case b/c 3 value isn't used much?

krit: Yes. Edge case because css does not have 3 value so it's not often used.

smfr: Unfortunate that you fall back to matrix for something that's a rotate...you'll never do rotate [missed] turning into rotate translate

krit: You could change rotate to a rotate translate, but that could be worse becuase it doesn't match any transform function. So we'd still fallback

<TabAtkins> (I support the rotate(3-arg) being incompatible with anything.)

krit: Proposal is if there's a rotate with 3 values and have a transition it gets composed to a matrix and we have matrix decomposition for a animation

smfr: No alternate proposal and I don't object. It's okay, it's just that if author is trying to rotate we will fallback

krit: Can we agree on matix decomposition?

astearns: Objections to make this rotate with 3 values to a matrix and do matrix decomposition

<chris> ok I guess

RESOLUTION: make this rotate with 3 values transition to a matrix and do matrix decomposition

the used value for border-box

github: https://github.com/w3c/csswg-drafts/issues/999#issuecomment-391431901

krit: transform-box has a couple fo defined boxed. Issue is we have mapping defined for fill and stroke fallbacks. THe mapping between html and svg boxes it request more values to supported value of transform-box. border-box on svg fallsback to stroke-box but we don't have that exposed.
... Proposal is every fallback we define would also be definable on transform. We'd add content box and stroke box

smfr: Which spec will define the boxes?

krit: Each spec defines mapping.

fantasai: It would be fine to import the mapping to transform spec as it's more mature then fill/stroke

krit: Currently transform and masking do what we defined for fill/stroke. We're adding the keywords for the spec behavior so users can spec directly

astearns: Concerns with adding these values?

fantasai: sgtm

smfr: I think I'm okay with [missed]

astearns: Sounded like smfr if okay but is not sure transforms is right place for dfinitions

fantasai: Not sure where else. I guess fill/stroke is fine, but it's a very early-stage WD

krit: That's why masking and transform already define it, but they do it the same way

astearns: Given things move in different velocities we may defer to fill and stroke in a future transforms
... Objections to add these keywords to transform-box property?

RESOLUTION: add these keywords to transform-box property

end

<fantasai> https://wiki.csswg.org/planning/sydney-2018

astearns: Thanks everyone and we'll talk next week. If you're not on wiki for Houdini and CSS and you're coming, please add yourself.

<astearns> trackbot, end meeting

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/Oriel/Oriol/
Succeeded: s/post and you have opacity it would trap/pos and opacity for example is a containing block but not for fixed/
Succeeded: s/blocka nd/block and/
Succeeded: s/per/perf/
Succeeded: s/[missed]/like a complexification of the current rules/
Succeeded: s/clarification/simplification/
Succeeded: s/fine/fine, but it's a very early-stage WD/
Default Present: dael, astearns, zheng_xu, plinss, florian, fantasai, rachelandrew, Rossen_, antenna, antonp, jensimmons, alex_antennahouse, tgraham, melanierichards, gregwhitworth, chrishtr, TabAtkins, chris, myles, krit, bradk, leaverou, liam, tantek
Present: dael astearns zheng_xu plinss florian fantasai rachelandrew Rossen_ antenna antonp jensimmons alex_antennahouse tgraham melanierichards gregwhitworth chrishtr TabAtkins chris myles krit bradk leaverou liam tantek
Found ScribeNick: dael
Inferring Scribes: dael

WARNING: No meeting chair found!
You should specify the meeting chair like this:
<dbooth> Chair: dbooth

Found Date: 20 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.)