W3C home > Mailing lists > Public > www-style@w3.org > July 2019

[CSSWG] Minutes Telecon 2019-07-17 [css-text-decor] [css-text]

From: Dael Jackson <daelcss@gmail.com>
Date: Wed, 17 Jul 2019 19:09:27 -0400
Message-ID: <CADhPm3vh3ff+AAJ_W-NprgzpZDyeKovf13Y859N2JH0b9mVeqg@mail.gmail.com>
To: www-style@w3.org
  These are the official CSSWG minutes.
  Unless you're correcting the minutes,
 Please respond by starting a new thread
   with an appropriate subject line.

Text Decoration

  - Issue #3993 (text-decoration-width claims to be a sub-property of
      text-decoration, but text-decoration disagrees) should be
      addressed once the text-decor-3 text is edited into L4

  - RESOLVED: Always draw the underline even if it's specified to be
              outside a limit we choose [meaning that even if we clamp
              the underline we won't clip it] (Issue #4059)
  - The discussion on if there should be a clamp on
      text-underline-offset (and by extension strikethrough and
      overline offset) continued without resolution. There were three
      options to pick from:
      A) No clamping
      B) Wide clamping
      C) Narrow clamping
  - The argument for no clamping is that there shouldn't be
      restrictions on the designs people produced.
  - The argument for wide clamping is to avoid design restrictions but
      also limit performance and implementation difficulties.
  - The argument for narrow clamping to avoid the underline being used
      to replace a strikethrough or overline.
      - There's a desire to hear from the a11y working group on their
          views about this concern
  - A straw poll was taken of the three options, but there was no
      clear winner between the three options.
  - As the meeting drew to a close there was discussion to
      understanding more specifics about the limits intended when the
      group spoke of wide vs narrow clamping. The offered more
      specific details were:
      Q) Limit is super-far, based on how big can you draw a box and
         things like that
      R) Medium-range, like 6-10 lines - enough for author to notice
         that there's clamping, but not particularly restrictive
      S) Short-range, 1-2 line boxes, tries to keep the line with the
         next, not overlapping the adjacent lines

CSS Text

  - RESOLVED: Tabs do not hang and you can break between for
              white-space: break-spaces (Issue #3869: pre-wrap and
              tabs at the end of the line)
  - RESOLVED: For white-space:pre-wrap tabs hang like spaces do (Issue


Agenda: https://lists.w3.org/Archives/Public/www-style/2019Jul/0023.html

  Rachel Andrew
  Rossen Atanassov
  Tab Atkins (IRC Only)
  David Baron
  Amelia Bellamy-Royds
  Christian Biesinger
  Tantek Çelik
  Emilio Cobos Álvarez
  Elika Etemad
  Simon Fraser
  Dael Jackson
  Brad Kemper
  Peter Linss
  Nigel Megitt
  Anton Prowse
  Jen Simmons
  Alan Stearns
  Melanie Richards
  Greg Whitworth

  Dave Cramer

Scribe: dael

  astearns: We should get started
  astearns: Anything to add or change about the agenda?
  astearns: Do we have the people to discuss
  astearns: Particularly is myles on?
  astearns: Let's skip until we get myles

Text Decoration

text-decoration-width claims to be a sub-property of text-decoration,
    but text-decoration disagrees
  github: https://github.com/w3c/csswg-drafts/issues/3993

  astearns: emilio added this and fantasai commented.
  astearns: Anything we need to do?
  fantasai: Not unless someone disagrees with making it a sub property

  astearns: I have not read through the text. Is there a spec change?
  <emilio> astearns: I'm fine with fantasai's comment, updating the
           spec would be nice
  fantasai: Hang up is text-decor-3 text isn't folded into L4. I need
            to cross check before I copy over and merge in. L4 is
            basically a diff spec atm
  astearns: So we'll close this as soon as you cross check and
            possible update spec
  fantasai: Yeah
  astearns: Any disagreement with that course of action?
  ??: nope
  astearns: Let's leave it at that.

CSS Text

pre-wrap and tabs at the end of the line
  github: https://github.com/w3c/csswg-drafts/issues/3869#issuecomment-509811620

  astearns: florian added an example
  florian: 2 parts to the discussion. One is hardly discussed and
           non-controversial. Other was controversial and needed an
  florian: The hardly discussed is just like spaces tabs do not hang
           and you can break between. Mentioned in issue and no one
           pushed back.
  florian: I'd like to resolve on that before going to
  astearns: Treat tabs the same as issues for this?
  <fantasai> for break-spaces, right?
  florian: They can't hang and you can wrap between two consecutive
  astearns: Tabs do not hang and you can break between for
            white-space: break-spaces
  astearns: Objections?

  RESOLVED: Tabs do not hang and you can break between for
            white-space: break-spaces

  florian: Now what happens with tabs at end of line with
  florian: Example in document with line empty with tabs at end. What
           happens if line is too short?
  florian: First example is when line is long enough, second is when
           tab hangs.
  florian: If you disallow hanging and disallow breaking between tabs
           you get second rendering. 3rd is disallow hanging but allow
           breaking between tabs. No one does 3rd, browsers are split
           between first 2.
  florian: I don't have a strong preference. Weak for option 3 which
           no one does. But we should try and align on something.
           Would want to hear if anyone has preference.

  florian: Questions on example? Thoughts on why one is preferable?
  astearns: I don't have much of a preference. Not sure the 3rd is
            preferable either
  astearns: I don't know why you have weak preference for that

  dbaron: Drawing in example assumes tab stop lines up with end of
  florian: It could be a different length, that's correct. I have a
           line length of 16 in this example. If you did 17 for
           example line breaking position wouldn't change in any
           example but you'd have empty space at end of it.
  fantasai: Only difference visually is container is slight wider, but
            otherwise render same
  dbaron: Complexity with not line up is you would also have to decide
          if can break in middle of tab
  florian: I assumed you could not, but fair enough. It renders as a
           shift not a character.
  dbaron: You'd have to decide if you have tab stop at beginning/end
          of line. If you don't you can break in middle of tab. If you
          don't have tab stop and your next position is early in next
          line but not start; I guess it doesn't matter if tab is on
          first line or part on each line
  fantasai: Tab stop is at beginning of line, but not end of line
            unless lines up with a multiple of 8 spaces from start of
            the line

  florian: If we don't have a use case driven preference we can ask
           the web author folks to fish for one. We have split between
           browsers now. We can ask who is easier to change.
  florian: Going by use case would be better. Haven't ID'ed any.
           Should we draw in rachelandrew or jensimmons to do a
           Twitter poll?
  dbaron: This feel obscure to me.
  florian: It does

  astearns: Could resolve on behavior 1 since we have 2 engines
            doing it
  florian: Yeah...no particular reason to think behavior 1 is terrible
           so I'm okay with that. It is similar to what happens to
           spaces in white-space:pre-wrap. That implies FF has to
  dbaron: I think consistency with spaces is reasonable thing. I don't
          have strong opinions.
  <tantek> is there any way to apply the principle of least surprise
  <tantek> all other things being equal?

  florian: Suspect any impl difficulty?
  dbaron: Hard to say
  astearns: Main difficulty is reason to make the change. I could just
            be a bug in FF forever
  myles: Engines have special case for tabs. It'll be a slightly
         smaller or larger special case then it would have been.
         Picking an option is more important then which
  florian: And as to the point about no rush to fix I think this will
           be low in priority, but there will eventually be a lump of
           bugs to fix and this will be in.

  astearns: tantek asked in IRC: [reads]. One of the problems is no
            one has strong opinion on actual expectation
  florian: Being consistent with spaces goes slightly to least
           surprise. If you know one you know the other
  astearns: Sounds like we are driving toward a preference for the
            first option since consistent with spaces
  florian: Right, the tabs hang

  astearns: Proposal: for white-space:pre-wrap tabs hang like spaces do
  astearns: Objections?
  <tantek> that seems reasonable and less noisy (random tabs/ws at end
           of line won't change layout)

  RESOLVED: For white-space:pre-wrap tabs hang like spaces do

Text Decoration

Limits on text-underline-offset to preserve semantic meaning
  github: https://github.com/w3c/csswg-drafts/issues/4059#issuecomment-510148922

  astearns: Discussed this, what, last week? Been more discussion in
            GitHub. jensimmons gave 3 options
  astearns: 1. Don't do any clamping. 2. Wide clamp 3. Narrow clamp
  astearns: Any additional information to add?
  <florian> opinions yes, but nothing new

  astearns: From my pov we shouldn't have a clamp at all. Whatever
            clamp we choose might be difficult to come at an
            interoperable consensus as to what it should be. I am not
            concerned with semantic implications of moving an
  astearns: Agree we should have these offsets for strikethrough and
            overline as well
  <florian> +1 to astearns
  <TabAtkins> +1
  astearns: I think that's an argument to add more offset properties
            and not clamping any
  bradk: I agree
  <fantasai> I'm against the narrow clamping definition.
  florian: One nuance. If there are implementation difficulties having
           an allowance for clamping for the reason of not paining
           many pages away I would accept that. Not go any further
           then that.

  smfr: If you don't clamp do you allow underline to be clipped out?
        So UA must paint however 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
  <bradk> Ink overflow only.
  florian: Do we expect impl to be more difficult to put underline
           3000 px away?
  smfr: More difficult for text decor
  myles: Performance hit where any part of page changes have to redraw
         entire paragraph
  AmeliaBR: True for things like box shadows
  myles: Unfortunate there too
  AmeliaBR: Shouldn't have special rules for this. Should have general
            rule for at point you can reasonably clip
  myles: Have webcompat for others. This is new so can change
  jensimmons: Sounds to me this is an argument for a wide clamp. To
              smfr's point I meant any obstruction of author ability
              to put underline where they thought. A clip or a clamp
              is a level of sophistication we haven't reached.
  florian: If you're going to limit it should be clamp rather then
  florian: I would go for wide clamp or no clamp

  Rossen: Sounds like discussing merit of feature again. There was
          good consensus last time we wanted clamping
  florian: no
  <florian> I don't think there was emerging consensus
  Rossen: And also of the opinion that if we don't have clamping of
          offset then any other implementations that do
          underline-offset will have fairly different semantic
          meanings as to where they'll draw underline or one that
          looks like a strikethrough.
  Rossen: For a new feature we have control over we have a chance to
          make it right.
  Rossen: If there are use cases to pay around with a background in
          the middle of the line box, use the strikethrough. 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. Especially for implementations that don't have it.
          Having poor fallback is not a good idea
  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.
  <bradk> Strike though cannot be a background because it is in front
          of the text
  jensimmons: What I'm hearing from Rossen is an argument for narrow
              clamp. I don't think we've had consensus. After call
              especially hearing more and more no clamp. We can keep
              trying to articulate reasons, but 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

  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
  myles: Maybe compromise is wide clamp. Because wide spec can just
         recommend a general idea of where to put it.
  <jensimmons> +1 for what Myles just said
  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 performance
            reasons but not semantic. Is that correct?
  fantasai: Yes
  florian: That's how I understand
  <tantek> Why are *under*lines not drawn *under* the text
           (layerwise), so they can't actually strike-through? (they
           could strike-under?)
  <fantasai> tantek, they are drawn under the text
  <florian> tantek, they are
  <fantasai> tantek, and strike-throughs are drawn over
  <tantek> thanks fantasai, then I'm not as worried about underline
           abuse, cosmetically, semantically or otherwise
  <bradk> <u> is semantic. *-decoration is not
  <fantasai> +1 to bradk
  <florian> +1 to tantek and to bradk
  <fantasai> Specific proposal for wide clamp: within the larger of 2
             x max(line-box-height, font-height)
  Rossen: I think first [narrow] is characterized well. Second is a
          little unfair. Implementations 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 implementation and performance
  <dbaron> Implementations already need to keep track of underlines
           for overflow.
  <tantek> I wonder if there are some math related display hacks we
           could do with underlines far from their text

  <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?
  <astearns> tantek: we are getting a second implementation now, so we
             can't punt
  <fantasai> tantek, we have implementations
  <tantek> I feel like we can punt a bit longer until Chrome intents
           to implement, or have we seen that already?

  astearns: To move discussion along, can we resolve not to add a
            clamp to this property for merely semantic reasons. Would
            anyone like to argue for narrow clamp to satisfy semantic
  * fantasai suggests a straw poll
  Rossen: I would be willing to continue to argue this. I would want
          to hear from other groups on this issue, including a11y
  astearns: I wonder if it makes sense to break issue into 2 concerns.
            There are separate arguments for each.
  astearns: Is there anyone besides Rossen who is up to argue for
            semantic concerns?
  myles: Our original purpose was this. There's a difference between
         existing properties 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
  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
  myles: Authors have to think about that and add code
  florian: To disappear yes
  bradk: Have to think about that for any new
  jensimmons: Fallback is natural and makes sense. If you're doing
              fancy in a new browser your fallback is a normal
              underline. I don't see it as complex, it seems natural
              from author PoV
  <bradk> +1 jensimmons

  astearns: On wide clamp side I'm a bit concerned about doing it
            right for new property means we have a set that behave one
            way and a set behaving a different way.
  astearns: That's a difficult story to tell
  astearns: As we introduce more properties you have to keep in mind
            which do you clip and which do not
  florian: A valid use case was brought up for not doing wide clamp.
           Since they're animatable you can shift overline from way
           far to the side to the right position with the offset. I
           would expect people to try and do that. Yes performance
           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
  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 from 5 px below natural position to its
         natural position
  florian: Not from outside screen?
  myles: Never seen a website that did that
  jensimmons: I agree with myles. Don't have to worry about underline
              flying in from off page. Small move from hover is use

  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
  <bradk> -1 to any clipping at all
  AmeliaBR: I think it's important that if we allow clipping we have
            to be consistent where it happens so you don't have
            accidentally disappearing. Clamping is easier to leave to
            UA discretion because will never have content disappear
  <jensimmons> I disagree with what AmeliaBR just said. But she also
               changed the subject
  myles: Underline 700px away is effectively lost
  AmeliaBR: Are we clipping at 700px or at 2em. We've been throwing a
            lot of things around.
  myles: 700px is the no clamp situation
  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.
  astearns: I'm for resolving on always drawing underline
  myles: fine with that
  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
  bradk: Can all agree on that
  <dbaron> +1 to always drawing
  <fantasai> I think if we resolve on always drawing the underline,
             whatever clamping limit we choose should be relatively
             close to the line
  astearns: And fantasai's 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
  <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 sizes
  astearns: Objections to always draw the underline?

  RESOLVED: Always draw the underline even if it's specified to be
            outside a limit we choose

  astearns: Remaining issue is do we have a limit. If we do what is it
  astearns: I heard from some people they wanted to talk to other
            groups like a11y
  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.
  fantasai: If we're clamping rather then clipping underline needs to
            show up in most cases
  florian: You're arguing no clamp or mid-range clamp but not wide
  jensimmons: I think she's arguing narrow or wide but not no clamp
  <jensimmons> The problem fantasai just described already exists for
  <jensimmons> Authors putting things off-screen, thinking they are
               gone, when in fact they are on-screen for some people
  fantasai: I'm against narrow; I agree with jensimmons' and bradk's

  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
  fantasai: It'll be visible enough for author to notice it's there.
            Interesting point if we want to allow underlines that are
            500x width of line.
  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
  <tantek> +1 bradk
  <florian> agree with bradk

  astearns: I'm not hearing consensus. Some people interested in a
            limit for semantic, some people want a limit for impl
            difficulty or performance, and others not up for a limit
            at all.
  fantasai: Straw poll?
  <tantek> priorities: author > implementation > semantic purity
  <tantek> so I think we should lean towards bradk & jensimmons
           opinions here
  astearns: I suppose we can.

  <bradk> Does it help to agree that it is an ink effect only, which
          doesn’t break to other pages and columns?
  <fantasai> bradk, we're already agreed on that, but good to remind

  myles: Fourth option is allow impl to decide
  fantasai: I think we need some interop. If one does semantic and the
            other does none it'll be bad for everybody

  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.
  <florian> agreed with jen
  jensimmons: If it's about effecting authors need tight interop
  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
  AmeliaBR: Do we have more than one impl?
  jensimmons: FF nightly has it and it has no clamp
  Rossen: All browsers that don't support offset draw underline at
          semantic height
  astearns: Not relevant because discussing new property
  Rossen: Is based on amount of difference we impose on users without
          that property
  florian: That's called progressive enhancement. They do a sensible
  Rossen: That's what I'm arguing about
  <jensimmons> straw poll??
  astearns: I agree with myles and jensimmons there is a 4th option of
            we have a wide clamp and we spec you must allow this much
            and where you decide it beyond that much is impl dependent

  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
  astearns: IRC straw poll. a. No clamp. b. Narrow Clamp. c. Wide clamp
  astearns: Please put in IRC, can vote for >1
  <bradk> A
  <astearns> A
  <florian> +1 to A, -1 to B, 0 to C
  <jensimmons> A or C — no clamp or wide clamp
  <Rossen> B, C
  <tantek> A
  <myles> B C
  <fantasai> C, A
  <drousso> B C
  <emilio> A
  <dbaron> A or C
  <nigel> +1 to A, 0 to B, -1 to C
  astearns: About half of people on call have voted
  <AmeliaBR> A
  <smfr> A
  <rachelandrew> A
  <cbiesinger> A
  <gregwhitworth> B, C
  <melanierichards> B, C

  florian: Surprised by nigel's vote
  nigel: It seems like 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.
  florian: Narrow version of clamping tries to prevent overlapping
           underline with text so you can't mistake for a strikethrough
  <fantasai> "Narrow clamp" forces the underline below the descenders
             and above the next line of text
  <fantasai> "Wide clamp" has varying interpretations, but is not
             trying to make such a restriction.
  nigel: May have misunderstood
  florian: So you're for wide but not too wide?
  nigel: Authors need to be able to overlap underline with text. If
         it's a different color they can put text on top of it.
  florian: So that means you disagree with what has been called narrow
  nigel: Okay, I guess I should refine my vote.
  <nigel> Revised vote: +1 to A, -1 to B, 0 to C

  astearns: Looks like no clamp wins the straw poll, but wouldn't
            resolve on
  fantasai: Question for people that voted a. Can you live with c?
  <emilio> yes
  <smfr> can live with C
  florian: I can
  * cbiesinger can live with C
  bradk: Can if it's sufficiently far
  <rachelandrew> yes can live with C
  AmeliaBR: For every css property we allow impl to have reasonable
  bradk: 1mil em away doesn't matter

  fantasai: 3 ranges of clamping we could have.
  <fantasai> Q - Limit is super-far, based on how big can you draw a
             box and things like that
  <fantasai> R - Medium-range, like 6-10 lines - enough for author to
             notice that there's clamping, but not particularly
  <fantasai> S - Short-range, 1-2 line boxes, tries to keep the line
             with the next, not overlapping the adjacent lines
  Rossen: Define in terms of line box?
  Rossen: I think that's more concrete
  fantasai: That's what I'm talking about.
  Rossen: Q means no limits.
  fantasai: I would equate Q with basically no clamping. 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
  fantasai: R and S are variations of [missed] clamp
  fantasai: For people that voted A and can't live with R or S it
            means you can't live with C
  <bradk> -1 to R, -10 to S
  <florian> voted for A, can live with all versions of C (but prefer
  jensimmons: Can you use medium and far words?
  fantasai: Far is basically same as no clamp because it's 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

  astearns: For people that voted b and c is there anyone that could
            not live with a?
  myles: Totally confused with all the letters
  [a. No clamp. b. Narrow Clamp. c. Wide clamp]
  jensimmons: Everyone that said narrow also said wide. Maybe enough
              consensus with wide and then we get to what is wide
              clamp really means.
  <bradk> A good compromise is when everyone is a little unhappy
  jensimmons: I was thinking with a few line boxes away, I couldn't
              find 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.
  florian: I think bradk dislikes this.
  astearns: I think it does improve discoverability of limit if we
            stop moving within a linebox of original position

  myles: Have we thought about moving other direction? We did clamp to
         not do strikethrough. Clamping moving toward text?
  fantasai: This is all directions. This is in scope
  florian: That's option b
  <tantek> I'd like to allow authors to animate text-decorations into
           view from outside the viewing area
  <tantek> that's my no-clamp use-case

  astearns: We are at time. We'll come back to this again

  <florian> https://github.com/w3c/csswg-drafts/issues/3440#issuecomment-509638587
  florian: I'd like to encourage anyone who cares about how lines wrap
           to look at issue #3440. That was next on agenda. Good to
  astearns: Thanks everyone for calling in

Post Call IRC
- - - - - - -
  <fantasai> I wonder if we were almost at consensus on Jen's last
  <florian> I think we were
  <florian> It seems that bradk strongly dislikes it, but everyone
            else either likes it or can live with it
  <tantek> I'd rather allow authors the option
  <tantek> so I'd lean towards bradk's position
  * fantasai wonders if tantek would object?
  * fantasai also wonders if Rossen can live with
  <fantasai> Rossen?
  <florian> I'd rather allow the authors the option too, but I can
            live with that if that's the only place we can find
  <tantek> I'd rather ask if folks can live with A / no-clamp
  <jensimmons> I don't think limiting the underline to +/- one or two
               line boxes is a creative limit at all
  <florian> also, we didn't get into whether we meant "must clamp
            there" or "may clamp, must not clamp closer than that"

  <tantek> do we limit text-shadow?
  <florian> we don't
  <tantek> ok that seems obvious then. they'
  <tantek> they're both decorative
  <tantek> principles of least surprise, don't limit text-decoration
           positioning if we don't limit text-shadow

  <jensimmons> I do think it helps discoverability of "WTF I moved the
               underline where?" and if browser engineers are saying
               they want to do this for performance sake, I'm like
               cool. It won't impact Authors.
  <bradk> I think authors would be confused by why the change in value
          stopped having any effect on the line
  <bradk> Confounded even
  <AmeliaBR> I'm at the point where I strongly dislike ALL the options
             because we've been debating too long. But I'd be happier
             with one of the other extremes: either no clamp & leave
             it up to authors, or clamp to a semantically meaningful
             definition of "underline" (e.g., midline in between
             x-height and 1em below the baseline). I don't like
             arbitrary restrictions.
  <bradk> And the line thickness would still cause the same
          performance issues
  <tantek> I think strawpoll demonstrated far more A than other options
  <tantek> so I'd really like us to find a way to get consensus on A,
           rather than begrudgingly picking a far less preferred option
  <bradk> If text shadow doesn’t have a limit, then neither should
  <tantek> boom
  <tantek> that's what authors are going to think
  <tantek> limitless text-shadow is already out of the box (so to
  <florian> myles said he considered the lack of limit on text shadow
            to be a historical mistake that we cannot fix there for
            compat reasons, but can fix here because it's new. I
            disagree, but that was the claim.
  <tantek> limitless text-shadow is excellent for retro 1980s style
  <bradk> Exactly. A cool creative effect that wasn’t necessarily
          anticipated by spec authors
  <tantek> yes
  <bradk> I also have used box shadow with giant spread values for
          backdrops for dialogs
  <florian> I think it'd go with: "UAs may limit how far the underline
            may be placed. If they do so, the limit must be enforced
            by clamping the numerical value of the offset, not by
            visual clipping. The limit must not be less than ...." and
            we pick the largest ... that gets no objection.
  <florian> that way, UAs that want to allow authors creativity can do
            so, and those who want to enforce a limit are at least
            forced to keep the underline visible
  <fantasai> That gets into the interop problem again
  <fantasai> Someone tries to put an underline off-screen
  <fantasai> it works in one browser
  <fantasai> it ends up on-screen in another browser
  <florian> true
  <florian> but you can do that with shadows, outlines, etc.
  <fantasai> they clip, they don't clamp
  <florian> sure, but if you have your shadow offset by 500px, it will
            be off screen on my phone, and on screen on my desktop. no
            need to invoke clamping for that problem to occur
  <florian> So I don't get why this is a problem now and not before.
  <fantasai> That's fine because you designed for desktop, and some
             things you have to scroll to on a phone, it's OK
  <fantasai> the problem is you *try* to put something off-screen
  <fantasai> and then it's visible on someone else's computer
  <florian> maybe you designed for phone, and it bugs out on desktop
  <fantasai> really?

  <bradk> 2vmax
  <fantasai> bradk, I don't think implementations want to use viewport
             units in their clamping limits
  <fantasai> they require recalculation every time the window size
  <bradk> If you could have viewport units, it would solve that part
  <florian> I put my shadow 500px away to make it off screen, so that
            I can animate it into view when $foo happens, but I failed
            and it shows on big phones and desktop.
  <florian> same problem with the underline
  <bradk> Sort of
  <florian> but while I agree it's a problem in theory, I don't recall
            ever running into that
  <fantasai> If the limit is going to be as far away as 2vmax or
             thereabouts, then I'd like to reresolve on clipping

  <florian> "may clamp, but not closer than X" has the same problem,
            which I think is theoretical, not real life
  <fantasai> which is why I am disagreeing with it
  <florian> good. At least we know what we disagree about :)
  <fantasai> If we're going with "no clamping, effectively, because
             the limit is huge" then we should have "and you clip if
             it's too far"
  <bradk> fantasai: Why clip?
  <fantasai> If we're going with "clamping within reasonably visible
             range" then "clamp, don't clip"
  <fantasai> bradk, results are less arbitrary, and if it's a
             UA-defined limit, you don't get an underline overlapping
             some random other content on the page in one browser but
             not on another
  <bradk> Offset 1vh, thickness 1vh
  <fantasai> draw a box, not an underline
  <bradk> Sorry I keep thinking we are offsetting the center of the
  <florian> or maybe we leave the clip vs clamp question open in the
            "may clamp, but no closer than X" version, and browsers
            who limit to nearby clamp, and those who limit to 65536px

  <jensimmons> https://github.com/w3c/csswg-drafts/issues/4059#issuecomment-512421819
  <jensimmons> I drew a drawing.
  <bradk> Offset -1vh, thickness 1vh
  <florian> Jen, do you mean "must clamp there" or "may clamp, but no
            closer than there".
  <fantasai> Florian, our job is to create interop.
  <florian> I take that as a vote for "must clamp there" :)
  <fantasai> Thanks jensimmons :)
  <florian> :)
Received on Wednesday, 17 July 2019 23:10:27 UTC

This archive was generated by hypermail 2.4.0 : Monday, 23 January 2023 02:15:11 UTC