<scribe> ScribeNick: dael

Rossen_: We'll start at 9:02 PT.
... It's a couple minutes past, let's get going
... Wanted to call if there are extra items for the agenda

How to interpolate min/max/clamp?

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

AmeliaBR: I agenda+ it, though thinking of it for next week.
... We're starting to get consensus, at least TabAtkins and I and Alan C agree
... We have new math functions including these functions. We don't have anything that defines how work in animations and transitions. They generally work on computed values and these functions exist at computed time so need to define how to interpolate
... Proposal is that interpolation would be a linear interpolation of the terms where the functions on the initial side of interpolation are scaled to to multiplied by 0 and on the result side the scaled up from 0 to 1. Intermediary result is the sum of those terms
... Important benefits of the approach is you can define the intermediary value as a computed value without needing to sub in values from layout. And you can do mathematical simplification and it won't change result
... If author wants different interpolation like changing power and want power interpolated instead of results they can do by custom properties and interpolate the custom prop rather then final mathematical expression

Rossen_: Other comments or thoughts?

AmeliaBR: Prop: For interpolation math functions are treated as atomic algebraic terms. You interpolate a calc expression that is the sum of all the terms

<dbaron> weighted sum, I hope :-)

Rossen_: Okay. Any objections?

<fremy> LGTM

AmeliaBR: Yes, weighted sub by the interpolation factor

s/sum.sum

<TabAtkins> Aka, if interpolating between any two expressions A and B, the interpolation is *defined as* calc(.X*A + (1-.X)*B) (plus any algebraic simplifications)

<svoisen> jensimmons: There are links for both calendars at the bottom of this message https://lists.w3.org/Archives/Member/w3c-css-wg/2017OctDec/0076.html

RESOLUTION: For interpolation math functions are treated as atomic algebraic terms. You interpolate a calc expression that is the weighted sum of all the terms

Substitution of invalid variables into other variables

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

Rossen_: I'm not sure who the commentor is

TabAtkins: One of our implementors.
... This isn't appropriate for agenda + though. Still discussing in issue.

AmeliaBR: I tagged b/c looked like a conclusion, but still something not resolved.

github: none

Computed gradient colors

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

TabAtkins: With regards to images we have boiler plate for computed values. That doesn't technically cover things like absolutinzing colors and links. B/c it's boiler plate, things like gradient colors don't turn into consistent versions per spec.
... But we don't want copy/paste from boiler plate to mean something. proposal is we 1) define what a computed image is which does absolutizing and then 2) file bugs to make sure everyone serializes in same way across usages

AmeliaBR: For gradients key things is colors insidegradient should behave like colors everywhere and links like links. We don't have cross browser so need impl to update

<gregwhitworth> mozilla folks: do you all have any compat issues from this, I presume not - but thought I'd ask if you've ever had reports

AmeliaBR: Second is having one definition os what should happen to make consistency. I think that goes in replaced images and everywhere references it.

<dbaron> I don't know of them off the top of my head -- though that doesn't mean we haven't.

AmeliaBR: gregwhitworth asked on IRC. Mozilla currently is doing things as we want them to be done. They're the only one. Question was on compat complaints on that?

dbaron: I don't know of any. We could search but I haven't heard of any escallated

gregwhitworth: That's good enough for me. Thanks.

dbaron: Is this mostly a gradient thing?

TabAtkins: I believe that's the only thing in image that exposes colors and links. If anyone supports image() like we want that does take a color and would be impacted, but no one impl yet.

AmeliaBR: Also filter image function with I think is in Safari. Will need to be defined.

dbaron: Only compat bugs I find with gradients is 0 vs 0deg and a graphics bug. Doesn't seem relevant here

Rossen_: Okay
... Additional thoughts? Sounds like we have consensus on expected behavior and what clarifications to spec are needed. Don't see pushback

<fantasai> +1 to the change

Rossen_: Objections?

Prop: Add section to CSS images defining computed value of an image type. This value has colors links and lengths all made absolute per usual computed value rules for those sub types

TabAtkins: and fix specs referring to images to make sure use correct language

RESOLUTION: Add section to CSS images defining computed value of an image type. This value has colors links and lengths all made absolute per usual computed value rules for those sub types and fix specs referring to images to make sure use correct language

svg interaction

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

bkardell: Sounds like have agreement what it's doing with SVG element and maybe some cases AmeliaBR described is looking at wrong box. I think gregwhitworth agreed.

Rossen_: Can you summerize?

bkardell_: Resize observer observes a box. First take was content and expanded to border.
... In SVG terms means things linse svg rendering context where box is translated into svg viewport. THose dimensions are adjusted for viewport. In main doc where thinking about css boxes you want css boxes.
... Difference between element inside svg or svg itself is easiest example

AmeliaBR: Current spec has special rules for svg elements. As spec and impl those special rules are used for all svg elemnents, even those with css box so you can't use resize observer to see if your svg has been resized.
... That's where we have agreement from gregwhitworth this is unintentional oversite. Elements with css layout boxes you should be able to observe those values.
... THis is a spec change that requires impl change to match.
... Question of what to do about svg elements that don't have css layout boxes I don't know if there's clear agreement. No matter the box you ask for you get svg bounding box

<fantasai> https://github.com/w3c/csswg-drafts/issues/857 is relevant here

gregwhitworth: AmeliaBR I think what you said is fine. Id on't have knowledge on inner workings of svg. WE have bounding box as universal thing, but you say it won't be useful inside svg. Majority of use cases would end up doing what bkardell_ tried. Having the fallback where it doesn't have a css box fallback to the svg bounding box. Seems reasonable to me.
... Maybe other svg folks can think about it as well

<fantasai> See e.g. https://drafts.fxtf.org/fill-stroke/#fill-origin

bkardell_: I don't knwo use cases for what you would observe inside an svg. I guess I can think of some. Seem different and more complex. Missing the one fitting in where this thing has a css box and it's not reporting it.

Rossen_: Defining this on css boxes sounds more sane then defining on anything that creates a bounding box. Effect of computing trees and subtrees will be intense.
... I'm leaning toward agreeing with bkardell_ and stick to defining the behavior on css box

gregwhitworth: Sounds like based on your and AmeliaBR expertese there isnt value for bounding box. Could remove svg special case

emilio: It sounds fine to just not have. If it's on css bounding boxes. We had discussin on resize observer v2 about different types of boxes. Wierd if you get svg bounding box when that's not what you asked for. I'm good with restricting to those with css bounding boxes.

fantasai: As we were defining how svg doesnt have border box. There are definitions in fill and stroke that we adopt that map things like border box in a standard way. If we're going to allow any kind of lookup on svg shapes we should be consistent with that resolution

AmeliaBR: Not sure we got that adoped beyond one spec.

fantasai: Had a resolution though. If specs were updated is separate. BUt we said we'd do it across all specs so they're consistent. Resize observer shoudln't be exception. If we're allowing it to be set on svg shape should be consistent

bkardell_: I think there's 2 ends to this. One is if SVG bounding boxes should be reported. If they have css content boxes they should be, most basic version os resize observer is at least that

<gregwhitworth> Proposed Resolution: Remove special case for SVG which will allow SVG elements to be observed rather than using the svg bounding box

bkardell_: If my svg resizes I should be able to observe that
... According to spec and impl you can't. At a minimum we'd like that resolved.

Rossen_: I think that's where everyone is leaning. We spent some time in the past defining top level viewport. as far as I remmeber we defined as viewport that is generated by svg/svg element. That's the outermost element that creates a box.
... It essentially lives in css/html world and governed by css rules. You can apply anything to that box you can apply to other boxes. Inside that it's the svg world. Until you hit a foreign element that transitions from svg back into css world and creates a css box

<AmeliaBR> `svg:root, *:not(svg|*) > svg, svg|foreignObject > svg { /* SVG elements with CSS layout box */}`

Rossen_: It's very natural and reasonable to expect both these boxes would be included in resize observer. If that's explicitly omitted or forbidden by resize observer we need to adjust the spec.

AmeliaBR: We have clear agreement svg elements with css layout boxes should be able to observer the css layout boxes from resize observer.
... Pasted in IRC the definition of those elements as a css selector.
... Those svg elements have a css layout box and you should be able to observe it

Rossen_: fantasai will this contradict anything you said?

fantasai: no

Rossen_: What you mentioned is important. As we add spec around what we map in terms of boxes and css box concepts I want to make sure we won't add additional confusion.

<fantasai> https://github.com/w3c/csswg-drafts/issues/857 is the issue where we resolved the box correspondance

Rossen_: Is that going to be the case?

<fantasai> See definitions at https://drafts.fxtf.org/fill-stroke/#fill-origin

fantasai: I think it's fine. Since the boxes AmeliaBR mentioned don't have strokes there's nothing we need to worry about. But we should make sure specs align going forward

AmeliaBR: Improtant thing is when we have the corrispondance they don't override actual boxes. If you have a padding box we don't defer to stroke bounding box.

<bkardell_> can we punt the things specifically inside of svg to a level 2, is that what emelio was asking for ?

AmeliaBR: Aspect without clear agreement is what happens for svg elements that don't have css layout boxes. Current spec is they always give regular bounding box. fantasai comments come down to they should give a specific svg bounding box with a direct corrisponance to css bounding box. My concern is could be difficult to compute for a fast api

<fantasai> bkardell_, yes, as long as we're comfortable with how it's not working right now and that we can change and update it in the future

AmeliaBR: THe bounding boxes in general, browsers have rough and dirty calc and precise calc. Rough is for dirty paint

<bkardell_> fantasai, I think this is the important part - can we resolve on that?

Rossen_: Let's take this with svg wg. If svg wg has rec for how resize observer shoudl be defined on non-css boxes let's discuss later. Want to close those topic

<bkardell_> +1

Rossen_: prop: svg elements generating css layout boxes are included as part of resize observer and resize observer rectangles
... Obj?
... With definition of layout box is `svg:root, *:not(svg|*) > svg, svg|foreignObject > svg { /* SVG elements with CSS layout box */}

<bkardell_> rossen - is there a second resolution necessary for punting some of what is in the spec currently to v2

RESOLUTION: svg elements generating css layout boxes are included as part of resize observer and resize observer rectangles with a definition of `svg:root, *:not(svg|*) > svg, svg|foreignObject > svg { /* SVG elements with CSS layout box */}

bkardell_: Do we need second resolution to punt some of spec that deals with stuff that's not that to a v2? I think even fantasai was saying as long as comfortable with not working now...i think that's want emilio asked for

AmeliaBR: Right now we have a spec and browsers matching. We don't have clear agreement spec is wrong. Unless rushing to get spec to pub why don't we have discussion about what spec should be and make edits after

Rossen_: I would agree. I don't think ready for second resolution

Limits on text-underline-offset to preserve semantic meaning

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

jensimmons: txt-underline-offset lets authors move up and down, speaking in latin. negative is up, positive is down, 0 is baseline.
... impl is in Safari and they clamped it to avoid turning underline into strikethrough. In Safari clamp was at any negative number and what happens is it disappears. Impl in FF behind a flag. When I've been looking at this last image is best. I think legitimate use cases to let it rise up. Do we want to have any kind of clamp? Maybe want to prevent use as strikethrough and have a mid-line clamp. Or we say no clamp, we'll trust authors.

<jensimmons> https://codepen.io/jensimmons/pen/wLrjGG?editors=1100

jensimmons: You can style strikethroughs, though you can't move upa nd down.
... Codepen in irc if people want to look at this

florian: I agree with jensimmons Use cases seem legit and I wouldn't want to block. If we want generous clamping or no clamp is different. All jensimmons cases have different color on underline. If it's same color could be different.

fantasai: We have a shorthand that lets you set both.

<bradk> +1 no clamping at all

Rossen_: Making properties depend on each other is not great.

<fantasai> +1 to Rossen

AmeliaBR: I agree these are neat effects. Important to recognize different text decor have different semantic meanings. strikethrough is different then underline.

<bradk> Underlines are behind the text and strikethroughs are in front of the text right?

<jensimmons> AmeliaBR that's why I explained how strikethroughs can be styled.

<astearns> bradk: yes

AmeliaBR: Don't want to encourage wrong text decoration because one has a lot of flexibility in rendering and the other doesn't. There will always be rendering in less complete css impl. And the basic is on the a11y tree where it's this is an underline or a strikethrough
... As far as outcomes for clamping, I don't nec. mean need to clamp

<jensimmons> bradk — yes. Underlines are behind. Strikethroughs are in front.

<bradk> Text decorations are not semantic

AmeliaBR: We want to encourage people to use correct text decor. If a visual effect is past the point where it really is an underline it shouldn't be represented by an underline. If the visual effect is a strikeout it should be using one. If facilities for a strikeout modification aren't as good as an underline might be a problem.

myles: Suggesting add same controls on strikethrough?

AmeliaBR: Might be nec.

myles: Thanks for all these examples jensimmons. I think you've shown where we draw the boundry is not the right place. It is important to distinguish between the 2. I think UA should be allowed to place limits. Perhaps ours are not best
... Would be bad if in one browser look struck through and other looks em. I would prefer a should try and distinguish between strike through text and underlined text. Once those limits are agreed can spec

Rossen_: We're not hearing dauwhe

<Rossen_> dauwhe: can you perhaps summarize over IRC at least?

dbaron: I was on queue to suggest that given problems we may want text strikethrough offeset sooner. jensimmons said in introduction that 0 was relative to baseline rather than initial position. If going to add strike through and maybe overline offset might have different conclusions of 0

<bradk> +1 Offset overline and strike-though offsetting.

fantasai: 0 depends on text underline position porperty. It defaults to alphabetic-ish. If we get specific offset we snap to alphabetic offsel so you ahve something stable. If you chose a different position that becomes origin of offset

dbaron: Okay. Given concern...seems likely authors will use underlines for things not underlines if we give them more controls then strike through and overline. Esp strike through. I rec. it's a lot of properties but it's work thinking through.

myles: We've heard plenty of authors asking for underline control. I know of 0 for strike through and overline.

<bradk> Why not text-decoration-offset?

<jensimmons> q

Rossen_: Because they can do it with underline. Only partly kidding. We don't want to give something where they use underline all the time

dbaron: Poss want single property to move all

fantasai: I don't think so. If you have 2 or 3 might not want up by same amount

<astearns> I'm a bit worried about hacks to get around clamping - adding a blank line to the beginning, then giving an underline a large offset to move it to the next line below gets you back into the 'looks like strikethrough' case

dbaron: But 2 or 3 is rare so not clear worth another property

<fantasai> dbaron, text-undelrine-offset inherits

<fantasai> dbaron, so that you can set it once and forget about it

<Rossen_> adk jensimmons

<fantasai> dbaron, so making it apply to all the lines wouldn't be very usable

jensimmons: I agree with dbaron we should think about strike through and overline to mitigate abuse of underlines. Maybe they haven't asked for but lots of things with typographic get lumped in one giant bucket.

<astearns> +1 to interop - I don't see a big need to allow UA inconsistency here

<fantasai> +1 to astearns and jensimmons

jensimmons: Also think we shoudl have interop. I don't want too lose for browsers because could be painful for authors. If in one browser underline looks great and an untested browser the underline disappears is dangerous. I think disappearing is bad. Maybe have it not move so if you say -10 it clamps and doesn't move.
... I would be fine with a clamp if it's a magical mid-line. Maybe at x height?

<bradk> +1 to dbaron and jensimmons

<AmeliaBR> +100 to clamping (if it is used) being clamping the offset, not making the underline disappear

jensimmons: Some of the things in the issues like check for color contrast could get really complex and over engineered and hard to impl. I want to keep simple and make it possible to impl. I'm not a browser engineer maybe it's easy.

myles: One other point is if underlines can go arbitrarily far you might have to scroll down 5 pages to get the underline. So if you invalidate one piece of content you have to redraw whole page.

jensimmons: Makes sense to have a clamp to the line box.

dbaron: I think underlines are ink but not scrollable overflow

myles: Yes, but if page is 3 viewports tall might be at bottom

Rossen_: Yeah, I'm with dbaron .
... Are we considering underlines that are visually...missing th term but the ones that break underline when something else is around. Or is this jsut solid line segments

myles: Skipping in our impl only considers text the underline is on. It won't skip next line of paragraph

<Rossen_> dauwhe, can you talk yet?

fantasai: I wanted to agree with jensimmons. Making argument about if underline should allowed to be ihgher because we thinks so, don't want that clamp. Reasonable distance of text clamp makes sense. Needs to be able to leak outside line box, but not by lots. Maybe text *1.5

<jensimmons> +1 for allowing past the line box — yeah, maybe can't be two lines boxes away or something

fantasai: I think jensimmons case of using central baseline is fine.

<jensimmons> right now, btw, Safari allows any distance down — will go very far. There's not a clamp yet

myles: For small text it's hard to get underline, like 5pm text, hard to get it in the linebox. Has to have case outside line box. Some general same clamping is important. Prob not where our impl does it today.

Rossen_: bkardell_ you're next

bkardell_: My questions are big so will ask in another forum

Rossen_: I don't think we'll resolve. Meta idea of if we want any kind of clamping.

<fantasai> myles, I'd use the greater of the line box boundary or slightly outside the descent (e.g. 0.25em past descent or 0.5em past descent)

Rossen_: I rememebr last time we discussed we resolved to continue work. Without specific number or formula can we resolve we want some kind of clamping for underline offset? THat way we know we have a direction and won't have half group say no clamping.

<tantek> could it be clamped to the linebox?

fantasai: I think need to decide if clamping to enforce underline-ness or if we're looking for reasonable distance of text

<fantasai> tantek, no, because line box can be smaller than the text

Rossen_: Both require clamping.

<tantek> to resolve the "underline down to page 5" problem

<fantasai> tantek, see my comment to myles above

<tantek> fantasai is there some box that contains the text?

Rossen_: In favor of continuing discussion. Can we resolve we want some clamping as part of underline offset either to enforce semantic meaning of underline or to keep it within visual distance

bkardell_: I heard different things talking about semantics. I don't know that someone can explain what they mean in a minute. the semantics seem wishy-washy

<florian> I want clamping for one, not the other, so I'm not sure what to do about a resolution to clamp for either...

fantasai: We all agree clamping withing reasonable distance of text is something UA can do

<dauwhe> https://github.com/w3c/csswg-drafts/issues/4059#issuecomment-510145258

AmeliaBR: If we allow visual effects, we allow them. I don't see a reason to clamp in either direction.

<tantek> I'm (a little) worried about the effect on printing, e.g. do text decorations count as part of widows and orphans computations?

<astearns> box-shadow not clamping is a good argument against not clamping here

Rossen_: Let's continue that in the issue.

<bradk> -/+ 1em clamp

fantasai: Can we resolve on being able to clamp within range of text?

Rossen_: That's what I was pushing for.

<dbaron> I'd note *normal* underlines often extend outside the font's bounding box at the bottom

<bkardell_> I'm fine with that much

fantasai: Just resolving a clamp to keep line in reasonable range of the text

<tantek> would prefer more discussion before a resolution on this - that seems too wishy washy

<dbaron> (especially if they're wavy, etc.)

AmeliaBR: I have an objection. I don't see that as a strong argument. Paint can be all over page from box shadow.

<tantek> defer resolution please

jensimmons: It's after the hour, I think need to do another time.

Rossen_: We'll do that next week.
... Thank you everyone, we'll continue next week.

end

<jensimmons> Dave said (in the issue, since his phone didn't work) I worry that clamping can result in a bad author experience. It's quite frustrating when you change the value of a property but there is no visible change. Even worse is changing a value of the property and the line disappears.

<jensimmons> More generally, why is CSS now restricting what authors can do? I can create unreadable text in a thousand different ways. CSS gives authors tremendous power, and talented people can use features in unexpected and beautiful ways. Is it the role of the CSS Working Group to say that some designs are OK, and some designs shouldn't even be possible?

<Rossen_> trackbot, end meeting

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/mask/math/
WARNING: Bad s/// command: s/sub.sum
Succeeded: s/sub/sum/
Succeeded: s/visual/ink/
Default Present: dael, Rossen_, rachelandrew, dauwhe, plinss, florian, AmeliaBR, svoisen, antonp, smfr, gregwhitworth, jensimmons, oriol, TabAtkins, dbaron, bkardell_, tantek, myles, melanierichards, emilio, bradk
Present: dael Rossen_ rachelandrew dauwhe plinss florian AmeliaBR svoisen antonp smfr gregwhitworth jensimmons oriol TabAtkins dbaron bkardell_ tantek myles melanierichards emilio bradk
Found ScribeNick: dael
Inferring Scribes: dael

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

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