15:55:31 <RRSAgent> RRSAgent has joined #css
15:55:31 <RRSAgent> logging to https://www.w3.org/2019/07/10-css-irc
15:55:33 <trackbot> RRSAgent, make logs public
15:55:33 <Zakim> Zakim has joined #css
15:55:35 <trackbot> Meeting: Cascading Style Sheets (CSS) Working Group Teleconference
15:55:35 <trackbot> Date: 10 July 2019
15:56:02 <Rossen_> Rossen_ has changed the topic to: Agenda for July 10 at: https://lists.w3.org/Archives/Public/www-style/2019Jul/0010.html
15:56:07 <fremy> fremy has joined #css
15:57:05 <dael> present+
15:57:10 <dael> ScribeNick: dael
15:57:32 <AmeliaBR> AmeliaBR has joined #css
15:59:43 <Rossen_> present+
15:59:59 <IanPouncey> IanPouncey has joined #css
16:00:53 <dael> Rossen_: We'll start at 9:02 PT.
16:00:58 <rachelandrew> present+
16:00:58 <dauwhe> present+
16:00:59 <plinss> present+
16:01:01 <skk> skk has joined #css
16:01:04 <florian> present+
16:01:09 <AmeliaBR> present+
16:01:26 <svoisen> present+
16:01:55 <smfr> smfr has joined #css
16:02:23 <dael> Rossen_: It's a couple minutes past, let's get going
16:02:24 <antonp> Present+ antonp
16:02:35 <dael> Rossen_: Wanted to call if there are extra items for the agenda
16:02:47 <smfr> present+
16:02:50 <dael> Topic: How to interpolate min/max/clamp?
16:02:55 <dael> github: https://github.com/w3c/csswg-drafts/issues/4082
16:03:23 <dael> AmeliaBR: I agenda+ it, though thinking of it for next week.
16:03:38 <dael> AmeliaBR: We're starting to get consensus, at least TabAtkins and I and Alan C agree
16:04:10 <jensimmons> jensimmons has joined #css
16:04:17 <gregwhitworth> present+
16:04:18 <dael> AmeliaBR: We have new mask 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
16:04:32 <jensimmons> present+
16:04:36 <smfr> s/mask/math/
16:04:42 <oriol> present+
16:05:15 <dael> AmeliaBR: 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
16:05:50 <dael> AmeliaBR: 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
16:05:51 <TabAtkins> present+
16:06:26 <dael> AmeliaBR: 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
16:06:42 <dael> Rossen_: Other comments or thoughts?
16:06:51 <dbaron> Present+
16:07:27 <dael> 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
16:07:34 <dbaron> weighted sum, I hope :-)
16:07:40 <dael> Rossen_: Okay. Any objections?
16:07:47 <myles> myles has joined #css
16:07:52 <fremy> LGTM
16:07:56 <dael> AmeliaBR: Yes, weighted sub by the interpolation factor
16:08:03 <dael> s/sub.sum
16:08:05 <dael> s/sub/sum
16:08:08 <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)
16:08:11 <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
16:08:15 <dael> RESOLVED: For interpolation math functions are treated as atomic algebraic terms. You interpolate a calc expression that is the weighted sum of all the terms
16:08:23 <dael> Topic:  Substitution of invalid variables into other variables
16:08:31 <dael> github: https://github.com/w3c/csswg-drafts/issues/4075
16:08:58 <dael> Rossen_: I'm not sure who the commentor is
16:09:07 <dael> TabAtkins: One of our implementors.
16:09:33 <dael> TabAtkins: This isn't appropriate for agenda + though. Still discussing in issue.
16:09:46 <dael> AmeliaBR: I tagged b/c looked like a conclusion, but still something not resolved.
16:09:48 <dael> github: none
16:09:58 <dael> Topic: Computed gradient colors
16:10:03 <bkardell_> bkardell_ has joined #css
16:10:06 <dael> github: https://github.com/w3c/csswg-drafts/issues/4042
16:10:18 <tantek> tantek has joined #css
16:10:22 <bkardell_> present+
16:11:00 <dael> 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.
16:11:43 <tantek> present+
16:11:49 <dael> TabAtkins: 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
16:11:50 <myles> present+ myles
16:12:18 <dael> 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
16:12:23 <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
16:12:30 <melanierichards> present+
16:12:40 <dael> AmeliaBR: Second is having one definition os what should happen to make consistency. I think that goes in replaced images and everywhere references it.
16:12:43 <dbaron> I don't know of them off the top of my head -- though that doesn't mean we haven't.
16:13:20 <dael> 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?
16:13:34 <dael> dbaron: I don't know of any. We could search but I haven't heard of any escallated
16:13:41 <dael> gregwhitworth: That's good enough for me. Thanks.
16:13:54 <dael> dbaron: Is this mostly a gradient thing?
16:14:23 <dael> 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.
16:14:37 <dael> AmeliaBR: Also filter image function with I think is in Safari. Will need to be defined.
16:14:59 <dael> dbaron: Only compat bugs I find with gradients is 0 vs 0deg and a graphics bug. Doesn't seem relevant here
16:15:02 <dael> Rossen_: Okay
16:15:37 <dael> Rossen_: Additional thoughts? Sounds like we have consensus on expected behavior and what clarifications to spec are needed. Don't see pushback
16:15:43 <fantasai> +1 to the change
16:15:45 <dael> Rossen_: Objections?
16:16:46 <dael> 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
16:16:59 <dael> TabAtkins: and fix specs referring to images to make sure use correct language
16:17:17 <dael> RESOLVED: 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
16:17:26 <dael> Topic: svg interaction
16:17:34 <dael> github: https://github.com/w3c/csswg-drafts/issues/4032
16:18:15 <dael> 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.
16:18:18 <emilio> present+
16:18:20 <dael> Rossen_: Can you summerize?
16:18:33 <dael> bkardell_: Resize observer observes a box. First take was content and expanded to border.
16:19:25 <dael> bkardell_: 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.
16:19:38 <dael> bkardell_: Difference between element inside svg or svg itself is easiest example
16:20:19 <dael> 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.
16:20:44 <dael> AmeliaBR: 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.
16:20:53 <dael> AmeliaBR: THis is a spec change that requires impl change to match.
16:21:20 <dael> AmeliaBR: 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
16:21:41 <fantasai> https://github.com/w3c/csswg-drafts/issues/857 is relevant here
16:22:19 <dael> 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.
16:22:29 <dael> gregwhitworth: Maybe other svg folks can think about it as well
16:22:45 <emilio> q+
16:22:48 <fantasai> See e.g. https://drafts.fxtf.org/fill-stroke/#fill-origin
16:23:02 <dael> 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.
16:23:36 <dael> 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.
16:23:57 <dael> Rossen_: I'm leaning toward agreeing with bkardell_ and stick to defining the behavior on css box
16:24:19 <dael> gregwhitworth: Sounds like based on your and AmeliaBR expertese there isnt value for bounding box. Could remove svg special case
16:24:27 <bradk> bradk has joined #css
16:24:46 <Rossen_> ack emilio
16:25:13 <dael> 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.
16:25:15 <bradk> present+
16:25:22 <Rossen_> ack fantasai
16:26:04 <dael> 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
16:26:14 <dael> AmeliaBR: Not sure we got that adoped beyond one spec.
16:26:54 <dael> 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
16:27:36 <AmeliaBR> q+
16:27:39 <dael> 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
16:27:41 <gregwhitworth> Proposed Resolution: Remove special case for SVG which will allow SVG elements to be observed rather than using the svg bounding box
16:27:50 <dael> bkardell_: If my svg resizes I should be able to observe that
16:28:10 <dael> bkardell_: According to spec and impl you can't. At a minimum we'd like that resolved.
16:28:50 <dael> 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.
16:29:45 <dael> Rossen_: 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
16:30:13 <AmeliaBR> `svg:root, *:not(svg|*) > svg, svg|foreignObject > svg { /* SVG elements with CSS layout box */}`
16:30:16 <dael> 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.
16:30:28 <Rossen_> ack AmeliaBR
16:30:52 <dael> AmeliaBR: We have clear agreement svg elements with css layout boxes should be able to observer the css layout boxes from resize observer.
16:31:13 <dael> AmeliaBR: Pasted in IRC the definition of those elements as a css selector.
16:31:27 <dael> AmeliaBR: Those svg elements have a css layout box and you should be able to observe it
16:31:36 <dael> Rossen_: fantasai will this contradict anything you said?
16:31:38 <dael> fantasai: no
16:32:12 <dael> 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.
16:32:14 <fantasai> https://github.com/w3c/csswg-drafts/issues/857 is the issue where we resolved the box correspondance
16:32:18 <dael> Rossen_: Is that going to be the case?
16:32:22 <fantasai> See definitions at https://drafts.fxtf.org/fill-stroke/#fill-origin
16:32:55 <dael> 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
16:33:19 <dael> 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.
16:34:06 <bkardell_> can we punt the things specifically inside of svg to a level 2,  is that what emelio was asking for ?
16:34:12 <dael> 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
16:34:33 <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
16:34:36 <dael> AmeliaBR: THe bounding boxes in general, browsers have rough and dirty calc and precise calc. Rough is for dirty paint
16:34:59 <bkardell_> fantasai, I think this is the important part - can we resolve on that?
16:35:05 <dael> 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
16:35:41 <bkardell_> +1
16:35:45 <dael> Rossen_: prop: svg elements generating css layout boxes are included as part of resize observer and resize observer rectangles
16:35:48 <dael> Rossen_: Obj?
16:36:10 <dael> Rossen_: With definition of layout box is `svg:root, *:not(svg|*) > svg, svg|foreignObject > svg { /* SVG elements with CSS layout box */}
16:36:19 <bkardell_> rossen - is there a second resolution necessary for punting some of what is in the spec currently to v2
16:36:35 <dael> RESOLVED: 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 */}
16:37:21 <dael> 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
16:37:53 <dael> 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
16:38:03 <dael> Rossen_: I would agree. I don't think ready for second resolution
16:38:09 <dael> Topic: Limits on text-underline-offset to preserve semantic meaning
16:38:23 <dael> github: https://github.com/w3c/csswg-drafts/issues/4059
16:38:59 <dael> jensimmons: txt-underline-offset lets authors move up and down, speaking in latin. negative is up, positive is down, 0 is baseline.
16:40:12 <florian> q+
16:40:33 <dael> jensimmons: 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.
16:40:42 <jensimmons> https://codepen.io/jensimmons/pen/wLrjGG?editors=1100
16:40:45 <dael> jensimmons: You can style strikethroughs, though you can't move upa nd down.
16:40:54 <dael> jensimmons: Codepen in irc if people want to look at this
16:41:09 <AmeliaBR> q+
16:41:10 <myles> q+
16:41:12 <Rossen_> ack florian
16:41:42 <dauwhe> q+
16:41:48 <dael> 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.
16:42:01 <dael> fantasai: We have a shorthand that lets you set both.
16:42:13 <bradk> +1 no clamping at all
16:42:17 <dael> Rossen_: Making properties depend on each other is not great.
16:42:33 <Rossen_> ack AmeliaBR
16:42:38 <fantasai> +1 to Rossen
16:42:46 <dael> AmeliaBR: I agree these are neat effects. Important to recognize different text decor have different semantic meanings. strikethrough is different then underline.
16:43:18 <bradk> Underlines are behind the text and strikethroughs are in front of the text right?
16:43:21 <jensimmons> AmeliaBR that's why I explained how strikethroughs can be styled.
16:43:27 <astearns> bradk: yes
16:43:30 <dael> 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
16:43:42 <dael> AmeliaBR: As far as outcomes for clamping, I don't nec. mean need to clamp
16:43:53 <jensimmons> bradk — yes. Underlines are behind. Strikethroughs are in front.
16:44:12 <bradk> Text decorations are not semantic
16:44:35 <dael> 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.
16:44:38 <dauwhe> q?
16:44:46 <dael> myles: Suggesting add same controls on strikethrough?
16:44:50 <dael> AmeliaBR: Might be nec.
16:44:54 <bkardell_> q+
16:44:56 <Rossen_> ack myles
16:45:37 <dael> 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
16:45:47 <jensimmons> q+
16:46:23 <dael> myles: 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
16:46:36 <Rossen_> ack dauwhe
16:46:48 <dael> Rossen_: We're not hearing dauwhe
16:47:17 <Rossen_> ack dbaron
16:47:23 <dauwhe> q-
16:47:55 <Rossen_> dauwhe: can you perhaps summarize over IRC at least?
16:48:07 <dael> 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
16:48:36 <bradk> +1 Offset overline and strike-though offsetting.
16:48:51 <dael> 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
16:49:35 <dael> 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.
16:49:55 <dael> myles: We've heard plenty of authors asking for underline control. I know of 0 for strike through and overline.
16:50:14 <bradk> Why not text-decoration-offset?
16:50:16 <bkardell_> q-
16:50:17 <jensimmons> q
16:50:24 <dael> 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
16:50:31 <dael> dbaron: Poss want single property to move all
16:50:42 <dael> fantasai: I don't think so. If you have 2 or 3 might not want up by same amount
16:50:43 <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
16:50:52 <dael> dbaron: But 2 or 3 is rare so not clear worth another property
16:51:06 <fantasai> dbaron, text-undelrine-offset inherits
16:51:21 <fantasai> dbaron, so that you can set it once and forget about it
16:51:27 <Rossen_> adk jensimmons
16:51:30 <Rossen_> ack jensimmons
16:51:35 <fantasai> dbaron, so making it apply to all the lines wouldn't be very usable
16:51:52 <dael> 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.
16:52:17 <astearns> +1 to interop - I don't see a big need to allow UA inconsistency here
16:52:27 <fantasai> +1 to astearns and jensimmons
16:52:43 <bkardell_> q+
16:52:48 <dael> 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.
16:53:08 <dael> jensimmons: I would be fine with a clamp if it's a magical mid-line. Maybe at x height?
16:53:14 <bradk> +1 to dbaron and jensimmons
16:53:26 <Rossen_> q?
16:53:35 <AmeliaBR> +100 to clamping (if it is used) being clamping the offset, not making the underline disappear
16:53:50 <dael> 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.
16:54:23 <dael> 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.
16:54:31 <dael> jensimmons: Makes sense to have a clamp to the line box.
16:54:41 <dael> dbaron: I think underlines are visual but not scrollable overflow
16:54:52 <dael> myles: Yes, but if page is 3 viewports tall might be at bottom
16:55:02 <dael> Rossen_: Yeah, I'm with dbaron .
16:55:05 <dbaron> s/visual/ink/
16:55:41 <dael> Rossen_: 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
16:56:01 <Rossen_> q?
16:56:02 <dael> myles: Skipping in our impl only considers text the underline is on. It won't skip next line of paragraph
16:56:14 <Rossen_> Zakim, close queue
16:56:14 <Zakim> ok, Rossen_, the speaker queue is closed
16:56:33 <Rossen_> ack fantasai
16:56:48 <Rossen_> dauwhe, can you talk yet?
16:56:59 <dael> 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
16:56:59 <jensimmons> +1 for allowing past the line box — yeah, maybe can't be two lines boxes away or something
16:57:11 <dael> fantasai: I think jensimmons case of using central baseline is fine.
16:57:35 <jensimmons> right now, btw, Safari allows any distance down — will go very far. There's not a clamp yet
16:57:45 <dael> 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.
16:58:02 <dael> Rossen_: bkardell_ you're next
16:58:16 <dael> bkardell_: My questions are big so will ask in another forum
16:58:31 <dael> Rossen_: I don't think we'll resolve. Meta idea of if we want any kind of clamping.
16:58:32 <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)
16:59:13 <dael> 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.
16:59:20 <tantek> could it be clamped to the linebox?
16:59:35 <dael> fantasai: I think need to decide if clamping to enforce underline-ness or if we're looking for reasonable distance of text
16:59:36 <fantasai> tantek, no, because line box can be smaller than the text
16:59:40 <dael> Rossen_: Both require clamping.
16:59:41 <tantek> to resolve the "underline down to page 5" problem
16:59:52 <fantasai> tantek, see my comment to myles above
16:59:54 <tantek> fantasai is there some box that contains the text?
17:00:16 <dael> 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
17:00:42 <dael> 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
17:00:47 <florian> I want clamping for one, not the other, so I'm not sure what to do about a resolution to clamp for either...
17:00:54 <dael> fantasai: We all agree clamping withing reasonable distance of text is something UA can do
17:01:10 <dauwhe> https://github.com/w3c/csswg-drafts/issues/4059#issuecomment-510145258
17:01:16 <dael> AmeliaBR: If we allow visual effects, we allow them. I don't see a reason to clamp in either direction.
17:01:21 <tantek> I'm (a little) worried about the effect on printing, e.g. do text decorations count as part of widows and orphans computations?
17:01:23 <astearns> box-shadow not clamping is a good argument against not clamping here
17:01:27 <dael> Rossen_: Let's continue that in the issue.
17:01:34 <bradk> -/+ 1em clamp
17:01:36 <dael> fantasai: Can we resolve on being able to clamp within range of text?
17:01:42 <dael> Rossen_: That's what I was pushing for.
17:01:50 <dbaron> I'd note *normal* underlines often extend outside the font's bounding box at the bottom
17:01:50 <bkardell_> I'm fine with that much
17:01:53 <dael> fantasai: Just resolving a clamp to keep line in reasonable range of the text
17:01:56 <tantek> would prefer more discussion before a resolution on this - that seems too wishy washy
17:02:02 <dbaron> (especially if they're wavy, etc.)
17:02:11 <dael> AmeliaBR: I have an objection. I don't see that as a strong argument. Paint can be all over page from box shadow.
17:02:15 <tantek> defer resolution please
17:02:20 <dael> jensimmons: It's after the hour, I think need to do another time.
17:02:26 <dael> Rossen_: We'll do that next week.
17:02:36 <dael> Rossen_: Thank you everyone, we'll continue next week.
17:02:38 <dael> topic: end
17:03:04 <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.
17:03:04 <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?
17:04:54 <Rossen_> trackbot, end meeting
17:04:54 <trackbot> Zakim, list attendees
17:04:54 <Zakim> As of this point the attendees have been dael, Rossen_, rachelandrew, dauwhe, plinss, florian, AmeliaBR, svoisen, antonp, smfr, gregwhitworth, jensimmons, oriol, TabAtkins, dbaron,
17:04:57 <Zakim> ... bkardell_, tantek, myles, melanierichards, emilio, bradk
17:05:02 <trackbot> RRSAgent, please draft minutes
17:05:02 <RRSAgent> I have made the request to generate https://www.w3.org/2019/07/10-css-minutes.html trackbot