- From: CSS Meeting Bot via GitHub <sysbot+gh@w3.org>
- Date: Wed, 17 Jul 2019 17:01:39 +0000
- To: public-css-archive@w3.org
The CSS Working Group just discussed `Limits on text-underline-offset to preserve semantic meaning`, and agreed to the following: * `RESOLVED: always draw the underline even if it's spec to be outside a limit we choose` <details><summary>The full IRC log of that discussion</summary> <dael> Topic: Limits on text-underline-offset to preserve semantic meaning<br> <dael> github: https://github.com/w3c/csswg-drafts/issues/4059#issuecomment-510148922<br> <dael> astearns: Discussed this, what, last week? Been more discussion in GH. jensimmons gave 3 options<br> <dael> astearns: 1. Don't do any clamping. 2. Wide clamp 3. Narrow clamp<br> <dael> astearns: Any additional information to add?<br> <dael> astearns: From my pov we shouldn't have a clamp at all. Whatever clamp we choose might be difficult to come at an interop consensus as to what it should be. I am not concerned with semantic implications of moving an underline.<br> <dael> astearns: Agree we should have these offsets for strikethrough and overline as well<br> <florian> +1 to astearns<br> <TabAtkins> 1<br> <dael> astearns: I think that's an arguement to add more offset properties and not clamping any<br> <dael> ??: I agree<br> <TabAtkins> +1, rather<br> <bradk> s/??/bradk<br> <fantasai> I'm against the narrow clamping definition.<br> <dael> florian: One nuance. If there are impl difficulties having an allowance for clamping for the reason of not painint many pages away I would accept that. Not go any further then that.<br> <dael> smfr: If you don't clamp do you allow underline to be clipped out? So UA must paint howeevr far or is it okay to not paint if it's "too far away". If you don't clamp need to say if can do clipping<br> <bradk> Ink overflow only.<br> <dael> florian: Do we expect impl to be more difficult to put underline 3000 px away?<br> <dael> smfr: More difficult for text decor<br> <dael> myles_: Performance hit where any part of page changes have to redraw entire paragragh<br> <dael> AmeliaBR: True for things like box shadows<br> <dael> myles_: Unfortunate there too<br> <dael> AmeliaBR: Shouldn't have special rules for this. SHould have general rule for at point you can reasonably clip<br> <dael> myles_: Have webcompat for others. THis is new so can change<br> <dael> jensimmons: Sounds to me this is an argument for a wide clamp. TO smfr point I meant any obstruction of author ability to put underline where they thought. A clip or a clamp is a level of sophestication we haven't reached.<br> <dael> florian: If you're going to limit it should be clamp rather then clipping.<br> <dael> florian: I would go for wide clamp or no clamp<br> <dael> Rossen_: Sounds like discussing merit of feature again. There was good consensus last time we wanted clamping<br> <dael> florian: no<br> <florian> I don't think there was emerging consensus<br> <dael> Rossen_: And also of the opinion that if we don't have clampping of offset then any other impl that do underline-offset will have fairly different semantic meanings as to where they'll draw underline or one that looks like a strikethrough.<br> <dael> Rossen_: For a new feature we have control over we have a chance to make it right.<br> <dael> Rossen_: If there are use cases to pay around with a background in the middle of the line box, use the striketrhough. If that's not good enough use a background. CHanging underline and allowing it to escape to be a strikethrough is bad from many PoV. Esp. for impl that don't have it. Having poor fallback is not a good idea<br> <jensimmons> q+<br> <dael> florian: I disagree it's poor. If you design an underline in such a way that it's thick and shifted up it's reasonable for the fallabck to be a normal underline. Argues for no local clamping. Wide is different.<br> <bradk> Strike though cannot be a background because it is in front of the text<br> <tantek> Why are *under*lines not drawn *under* the text (layerwise), so they can't actually strike-through? (they could strike-under?)<br> <dael> jensimmons: What I'm hearing Rossen_ is an argument for narrow clamp. I don't htink we've had consensus. After call esp hearing more and more no clamp. We can keep trying to articulate reasons, btu I haven't heard lack of consensus of the reasons for each. I've hear arguments as to why each is a good idea. I don't think there is consensus<br> <fantasai> tantek, they are drawn under the text<br> <florian> tantek: they are<br> <fantasai> tantek, and strike-throughs are drawn over<br> <florian> s/tantek:/tantek,/<br> <dael> jensimmons: Personally I prefer no clamp. Okay with wide clamp if it's for performance. narrow is much harder and we don't have to prevent authors from doing dumb things. We should pick which of the 3 and discuss details<br> <dael> myles_: Maybe comprimise is wide clamp. b/c wide spec can just recommend a general idea of where to put it.<br> <jensimmons> +1 for what Myels jsut said<br> <jensimmons> *Myles just<br> <fantasai> s/Myels/Myles/<br> <dael> astearns: Another way of casting narrow vs wide is narrow is for semantic argument to keep underline and underline and not mistaken for anything else. Wide is for perfromance reasons but not semantic. Is that correct?<br> <dael> fantasai: yes<br> <dael> florian: That's how I understan<br> <tantek> thanks fantasai, then I'm not as worried about underline abuse, cosmetically, semantically or otherwise<br> <bradk> <u> is semantic. *-decoration is not<br> <florian> +1 to tantek and to bradk<br> <fantasai> Specific proposal for wide clamp: within the larger of 2 x max(line-box-height, font-height)<br> <dael> Rossen_: I think first is characterized well. Second is a little unfair. Impl will become more complex for unknown reasons. Performance will be potentially impacted. Having to go in and validate and keep validation out of current bounds for overflowing underlines is not great. I would say both impl and performance<br> <dael> astearns: To move discussion, can we resolve not to add a clamp to this property for mearly semantic reasons. Would anyone like to argue for narrow clamp to satisfy semantic concerns?<br> <fantasai> +1 to bradk<br> <dbaron> Implementations already need to keep track of underlines for overflow.<br> <tantek> I wonder if there are some math related display hacks we could do with underlines far from their text<br> <dael> Rossen_: I would be willing to continue to argue this. I would want to hear from other groups on this issue, including a11y<br> <dael> astearns: I wonder if makes sens eto break issue into 2 concerns. There are separate arguments for each.<br> <dael> astearns: Is there anyone besides Rossen_ who is up to argue for semantic concerns?<br> <tantek> this is still WD right? why not put the issue in the text as a question linking to the issue and leave the presence/absence of clamping open til we have more implementations?<br> <astearns> tantek: we are getting a second implementation now, so we can't punt<br> <fantasai> tantek, we have implementations<br> <dael> myles_: Our original purpose was this. THere's a diff between existing prop and this new property. You could never draw a text shadow and not move it. But you can draw an underline and not move it. Semantic is a11y but also if you view new website in old browser it will look totally different. I don't think that's a concern for existing css properties<br> <tantek> I feel like we can punt a bit longer until Chrome intents to implement, or have we seen that already?<br> <dael> fantasai: If you as an author want fallback for this underline to be no underline you can do that. If you want fallback to look regular you can do that. Both are possible<br> <dael> myles_: Authors have to think about that and add code<br> <dael> florian: To disappear yes<br> <dael> bradk: Have to think about that for any new<br> <dael> jensimmons: Fallback is natural and makes sense. If you're doing fancy in a new browser your fallback is a normal browser. I don't see it as complex, it seems natural from author PoV<br> <bradk> +1 jensimmons<br> <fantasai> s/browser/underline/ ?<br> <dael> astearns: On wide clamp side I'm a bit concerns about doing it right for new prop means we have a set that behave one way and a set behaving a different way.<br> <dael> astearns: That's a difficult story to tell<br> <dael> astearns: As we introduce more properties you have to keep in mind which do you clip and which do not<br> <dael> florian: A valid use case was brought up for not wide clamp. Since they're animatibe you can shift overline from way for to right position with the offset. I would expect people to try and do that. Yes perf implications and complexity but if you go for it you go for it. There's no good taste design law that says we should ban this<br> <dael> myles_: Seen websites that do that effect. All those have underline in a reasonable position through any point in animation. I think all 3 options would work on those sites. Sites I've seen move underline rfom 5 px below natural position to its natural position<br> <dael> florian: Not from outside screen?<br> <dael> myles_: Never seen a website that did that<br> <dael> jensimmons: I agree with myles. Don't have to worry about underline flying in from off page. Small move from hover is use case<br> <dael> jensimmons: I wonder if one thing to agree one is question of if we were to have a clamp are there people that want to clip and have it disappear or can we agree with will never clip. We'll clamp and it won't move anymore. You hit a limit and it no longer moves<br> <bradk> -1 to any clipping at all<br> <dael> AmeliaBR: I think it's important that if we allow clipping we have to be consistent where it happens so you don't have accidently disappearing. Clamping is easier to leave to UA discretion b/c will never have content disappear<br> <dael> myles_: Underline 700px away is effectively lost<br> <jensimmons> I disagree with what AmeliaBR just said. But she also changed the subject<br> <dael> AmeliaBR: Are we clipping at 700px or at 2em. We've been throwing a lot of things around.<br> <dael> myles_: 700px is the no clamp situation<br> <dael> astearns: jensimmons question is if we do agree on a limit do we agree underline will be drawn at that limit if author spec something outside limit.<br> <dael> astearns: I'm for resolving on always drawing underline<br> <dael> myles_: fine with that<br> <fantasai> I think if we resolve on always drawing the underline, whatever clamping limit we choose should be relatively close to the line<br> <dael> florian: Along lines AmeliaBR said we can make argument it's less important with strong interop. But I think it's better to always draw<br> <dael> bradk: can all agree on that<br> <dbaron> +1 to always drawing<br> <dael> astearns: And fantasai point that if we do decide to always draw limit will need to be fairly close. If we say always draw helps to define limit<br> <fantasai> because if the limit is ~ 700px, then the author might want to draw the underline off-screen but it'll only be off-screen on some UAs/some screen sizs<br> <dael> astearns: Obj to always draw the underline?<br> <dael> RESOLVED: always draw the underline even if it's spec to be outside a limit we choose<br> <dael> astearns: Remaining issue is do we have a limit. If we do what is it<br> <dael> astearns: I heard from some people they wanted to talk to other groups like a11y<br> <dael> fantasai: If clamping and not clipping we need to clamp relatively close. WIthin a couple of lines. If we allow anywhere on screen and UA limit is 1000px author will try for 9000px and on some monitors it's visible which is not intended.<br> <dael> fantasai: If we're clamping rather then clipping underline needs to show up in most cases<br> <dael> florian: You're aruging no clamp or mid-range clamp but not wide<br> <dael> jensimmons: I think she's arguing narrow or wide but not no clamp<br> <jensimmons> The problem fantasai just described already exists for authors.<br> <dael> fantasai: I'm against narrow; I agre with jensimmons and bradk arguments<br> <jensimmons> Authors putting things off-screen, thinking they are gone, when in fact they are on-screen for some people<br> <dael> bradk: If you're going to clamp position need to clamp thickness too. If top of underline is 3em away it can be 6em width<br> <dael> fantasai: It'll be visible enough for author to notice it's there. Interensting point if we want to allow underlines that are 500x width of line.<br> <dael> bradk: I'm for not restraining creative uses. It's a decoration. If there's a great reason to cover height of page, fine. If it's performance hit it's author's responsibility to deal<br> <tantek> +1 bradk<br> <florian> agree with bradk<br> <dael> astearns: I'm not hearing consensus. Some people interested in a limit for semantic, some people want a limit for impl difficulty or perf, and others not up for a limit at all.<br> <dael> fantasai: Straw poll?<br> <tantek> priorities: authoer > implementation > semantic purity<br> <dael> astearns: I suppose we can.<br> <dael> myles_: Fourth is allow impl to decide<br> <tantek> so I think we should lean towards bradk & jensimmons opinions here<br> <dael> fantasai: I think we need some interop. If one does semantic and the other does none it'll be bad for everybody<br> <bradk> Does it help to agree that it is an ink effect only, which doesn’t break to other pages and columns?<br> <florian> agreed with jen<br> <dael> jensimmons: If we land on narrow needs to be very specific. If we land on wide it can be more like the allowed zone needs to be something specific but beyond browsers can do what they want. Then you're out of author impact zone and into engineering impact zone.<br> <fantasai> bradk, we're already agreed on that, but good to remind<br> <dael> jensimmons: If it's about effecting authors need tight interop<br> <dael> Rossen_: Currently all browser clamp at semantic place. If you say differences are bad for everyone not having clamping close to semantic puts in that effect for everyone<br> <dael> AmeliaBR: Do we have more than one impl?<br> <dael> jensimmons: FF nightly and it has no clamp<br> <dael> Rossen_: All browsers that don't support offset draw underline at semantic height<br> <dael> astearns: Not relevent b/c discussing new property<br> <dael> Rossen_: Is based on amount of difference we impose on users without that property<br> <jensimmons> straw poll??<br> <dael> florian: THat's progress of enhancing. They do a sensible fallback<br> <dael> Rossen_: that's what I'm arguing about<br> <fantasai> s/progress of enhancing/called progressive enhancement/<br> <dael> astearns: I agree with myles_ and jensimmons there is a 4th optino of we have a wide clamp and we spec you must allow this much and where you decide liit is impl dependent<br> <myles_> **9:18<br> <dael> jensimmons: Can I suggest we don't do details in straw poll. It's no clamp, wide clamp, narrow clamp. We realize those might need to be refined and need allowance. THis is about what is important to people<br> <bradk> A<br> <dael> astearns: IRC straw poll. a. No clamp. b. Narrow Clamp. c. Wide clamp<br> <astearns> A<br> <florian> +1 to A, -1 to B, 0 to C<br> <jensimmons> A or C — no clamp or wide clamp<br> <dael> astearns: Please put in IRC, can vote for >1<br> <Rossen_> B, C<br> <tantek> A<br> <myles_> B C<br> <fantasai> C, A<br> <drousso> B C<br> <emilio> A<br> <dbaron> A or C<br> <nigel> +1 to A, 0 to B, -1 to C<br> <dael> astearns: About half of people on call have voted<br> <AmeliaBR> A<br> <smfr> A<br> <bradk> C would be OK if it is 1 meeeelion ems<br> <rachelandrew> A<br> <cbiesinger> A<br> <dael> florian: Surprised by nigel vote<br> <gregwhitworth> B, C<br> <dael> nigel: It seem slike underline is the thing that belongs near text. having a wide clamp doesn't seem helpful. If you're saying it can be 5 lines away from text but not 6 it seems arbitrary. Either the underline is associated to text and we enforce or we don't clamp it.<br> <melanierichards> B, C<br> <dael> florian: Narrow version of clamping tries to prevent overlapping underline with text so you can't mistake for a striketrhough<br> <fantasai> "Narrow clamp" forces the underline below the descenders and above the next line of text<br> <dael> nigel: May have misunderstood<br> <fantasai> "Wide clamp" has varying interpretations, but is not trying to make such a restriction.<br> <dael> florian: So you're for wide but not too wide?<br> <dael> nigel: Authors need to be able to overlapunderline with text. If it's a different color they can put text on top of it.<br> <dael> florian: So that means you disagree with what has been called narrow clamp.<br> <dael> nigel: Okay, I guess I should refine my vote.<br> <nigel> Revised vote: +1 to A, -1 to B, 0 to C<br> <dael> astearns: Looks like no clamp wins the straw poll, but wouldn't resolve on<br> <emilio> yes<br> <smfr> can live with C<br> <dael> fantasai: Question for people that voted a. Can you live with c?<br> <dael> florian: can<br> <dael> bradk: Can if it's sufficiently far<br> <dael> AmeliaBR: For every css prop we allow impl to have reasonable limits<br> <dael> bradk: 1mil em away doesn't matter<br> <tantek> yes the dr. evil option!<br> <rachelandrew> yes can live with C<br> <fantasai> Q - Limit is super-far, based on how big can you draw a box and things like that<br> <dael> fantasai: 3 ranges of clamping we could have. q: limit is super far based on how big can you draw a box.<br> <fantasai> R - Medium-range, like 6-10 lines - enough for author to notice that there's clamping, but not particularly restrictive<br> <dael> fantasai: r- medium range, like fixed to10 lines. lets author notice clampping, but not particularly restricted<br> <dael> Rossen_: Define in terms of line box?<br> <dael> Rossen_: I think that's more concrete<br> <dael> fantasai: That's what I'm talking about.<br> <fantasai> S - Short-range, 1-2 line boxes, tries to keep the line with the next, not overlapping the adjacent lines<br> <dael> fantasai: s- short range keeps line wiht text<br> <dael> Rossen_: q means no limits.<br> <dael> fantasai: I would equate q with basically no clampping. We've got medium and short range. Medium you can put it around but you can notice there's clamping. On screen most devices. Short is within range that gives author freedom within line box and slightly outside, but stay within range and avoid overlapping next text<br> <dael> fantasai: r and s are variations of [missed] clamp<br> <dael> fantasai: For people that voted a and can't live with r or s it means you can't live with c<br> <dael> jensimmons: Can you use medium and far words?<br> <bradk> -1 to R, -10 to S<br> <florian> voted for A, can live with all versions of C (but prefer further)<br> <dael> fantasai: Far is basically same as no clamp b/c based on memory usage. Equate with a. Wide clamping there's 2 approaches. One is a lot of room but clamp it close enough you can see there's a clamp. Or we pull tighter and say our goal is within range of line box and not too far down<br> <dael> astearns: For people that voted b and c is there anyone that could not live with a?<br> <dael> myles_: Totally confused with all the letters<br> <dael> a. No clamp. b. Narrow Clamp. c. Wide clamp<br> <dael> AmeliaBR: Everyone that said narrow also said wide. Maybe enough consensus with wide and then we get to what is wide clamp really mean.<br> <dael> s/ AmeliaBR / jensimmons<br> <bradk> A good compromise is when everyone is a little unhappy<br> <dael> jensimmons: I was thinking with a few line boxes away, I couldn't fine use cases to go any more then the line above it. I'm fine with it being +/- 1 line box. Doesn't get into not allowed above x height. It's much more forgiving, but it's like you don't want 2 line boxes away.<br> <dael> florian: I think bradk dislikes this.<br> <dael> astearns: I think it does improve discoverability of limit if we stop moving within a linebox of original position<br> <dael> myles_: Have we thought about moving other direction? We did clamp to not do striketrhough. Clamping moving toward text?<br> <dael> fantasai: This is all directions. This is in scope<br> <tantek> I'd like to allow authors to animate text-decorations into view from outside the viewing area<br> <dael> florian: That's option b<br> <tantek> that's my no-clamp use-case<br> <dael> astearns: We are at time. We'll come back to this again<br> </details> -- GitHub Notification of comment by css-meeting-bot Please view or discuss this issue at https://github.com/w3c/csswg-drafts/issues/4059#issuecomment-512378640 using your GitHub account
Received on Wednesday, 17 July 2019 17:01:42 UTC