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

[CSSWG] Minutes Telecon 2019-07-10 [css-values-4] [css-images] [resize-observer] [css-text-decor]

From: Dael Jackson <daelcss@gmail.com>
Date: Wed, 10 Jul 2019 19:42:56 -0400
Message-ID: <CADhPm3twHzXQMSfOLU0Lunz0zhjpLjzNdON7dqPSpmP10AudqA@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.
=========================================


Values & Units 4
----------------

  - 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. (Issue #4082: How
              to interpolate min/max/clamp?)

CSS Images
----------

  - 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. (Issue #4042: Computed gradient
              colors)

Resize Observer
---------------

  - RESOLVED: SVG elements generating CSS layout boxes are included as
              part of resize observer and resize observer rectangles
              with a definition [for layout box] of `svg:root, *:not(
              svg|*) > SVG, SVG|foreignObject > SVG { /* SVG elements
              with CSS layout box */} (Issue #4032: SVG Interaction)

Text Decor
----------

  - Much of the on call discussion on issue #4032 (Limits on
      text-underline-offset to preserve semantic meaning) was about
      where a clamp should be.
  - There continued to be concern about text-underline-offset being
      used in place of a strikethrough. This could lead to problems in
      styling with browsers that have not fully implemented the
      property as well as discrepancies between what is visually
      presented and what's in the a11y tree.
      - One possible way to prevent the strikethrough case is to
          ensure that authors have just as much style control on
          overlines and strikethroughs so that there is no incentive
          to misuse an underline.
      - The other option presented was to clamp at a mid-point in the
          text so that it can't get to the point where it looks like a
          strikethrough.
  - The other argument for clamping was to ensure that the underline
      was visually presented in near proximity to the text it is
      underlining.
      - This lead to an argument that clamping shouldn't be done at
          all since box-shadows can end up anywhere in the document,
          not just in close proximity to the box, and therefore
          limiting the text-underline-offset will limit flexibility in
          design. Changing a value and not having it change on screen
          is often a bad authoring experience.
  - Since there were several different opinions on where to clamp as
      well as some arguments that we shouldn't be clamping at all,
      discussion will continue on github.

===== FULL MINUTES BELOW ======

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

Present:
  Rachel Andrew
  Rossen Atanassov
  Tab Atkins
  David Baron
  Amelia Bellamy-Royds
  Oriol Brufau
  Tantek Çelik
  Emilio Cobos Álvarez
  Dave Cramer
  Elika Etemad
  Simon Fraser
  Dael Jackson
  Brian Kardell
  Brad Kemper
  Peter Linss
  Myles Maxfield
  Anton Prowse
  Melanie Richards
  Florian Rivoal
  Jen Simmons
  Sean Voisen
  Greg Whitworth

Regrets:
  Christian Biesinger
  Manuel Rego Casasnovas
  Stanton Marcum

Scribe: dael

Values & Units 4
================

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.
  AmeliaBR: We're starting to get consensus, at least TabAtkins and I
            and Alan C agree
  AmeliaBR: 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
  AmeliaBR: Proposal is that interpolation would be a linear
            interpolation of the terms where the functions on the
            initial side of interpolation are scaled and multiplied by
            0 and on the result side the scaled up from 0 to 1.
            Intermediary result is the sum of those terms
  AmeliaBR: Important benefits of the approach is you can define the
            intermediary value as a computed value without needing to
            substitute in values from layout. And you can do
            mathematical simplification and it won't change result
  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
            property rather then final mathematical expression
  Rossen: Other comments or thoughts?

  AmeliaBR: Proposal: 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 sum by the interpolation factor
  <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)

  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

Variables
=========

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.
  TabAtkins: This isn't appropriate for agenda + though. Still
             discussing in issue.
  AmeliaBR: I tagged because looked like a conclusion, but still
            something not resolved.

CSS Images
==========

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
             absolutizing colors and links. Because it's boiler plate,
             things like gradient colors don't turn into consistent
             versions per spec.
  TabAtkins: But we don't want copy/paste from boiler plate to mean
             something wrong. 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 inside gradient should
            behave like colors everywhere and links like links. We
            don't have cross browser so need impl to update
  AmeliaBR: Second is having one definition is what should happen to
            make consistency. I think that goes in replaced images and
            everywhere references it.

  <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
  <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 escalated
  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

  Rossen: 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?
  <AmeliaBR> Proposal: 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

  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

Resize Observer
===============

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 summarize?
  bkardell: Resize observer observes a box. First take was content and
            then it expanded to border.
  bkardell: In SVG terms means things line 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.
  bkardell: Difference between element inside SVG or SVG itself is
            easiest example
  AmeliaBR: Current spec has special rules for SVG elements. As
            specified and implemented those special rules are used for
            all SVG elements, even those with CSS box so you can't use
            resize observer to see if your SVG has been resized.
  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.
  AmeliaBR: This is a spec change that requires implementations to
            change to match.
  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
  <fantasai> https://github.com/w3c/csswg-drafts/issues/857 is
             relevant here
  <fantasai> See e.g. https://drafts.fxtf.org/fill-stroke/#fill-origin
  gregwhitworth: AmeliaBR I think what you said is fine. I don'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.
  gregwhitworth: Maybe other SVG folks can think about it as well

  bkardell: I don't know 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.
  Rossen: I'm leaning toward agreeing with bkardell and stick to
          defining the behavior on CSS box
  gregwhitworth: Sounds like based on your and AmeliaBR expertise
                 there isn't 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 discussion on resize observer v2 about
          different types of boxes. Weird 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 doesn't 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 adopted 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 shouldn'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 of resize observer is
            at least that
  bkardell: If my SVG resizes I should be able to observe that
  bkardell: According to spec and impl you can't. At a minimum we'd
            like that resolved.
  <gregwhitworth> Proposed Resolution: Remove special case for SVG
                  which will allow SVG elements to be observed rather
                  than using the SVG bounding box
  Rossen: I think that's where everyone is leaning. We spent some time
          in the past defining top level viewport. as far as I
          remember we defined as viewport that is generated by SVG/svg
          element. That's the outermost element that creates a box.
  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
  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> `svg:root, *:not(svg|*) > SVG, SVG|foreignObject > SVG {
             /* SVG elements with CSS layout box */}`
  AmeliaBR: We have clear agreement SVG elements with CSS layout boxes
            should be able to observer the CSS layout boxes from
            resize observer.
  AmeliaBR: Pasted in IRC the definition of those elements as a CSS
            selector.
  AmeliaBR: 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.
  Rossen: Is that going to be the case?
  <fantasai> https://github.com/w3c/csswg-drafts/issues/857 is the
             issue where we resolved the box correspondence
  <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
  <bkardell> can we punt the things specifically inside of SVG to a
             level 2, is that what emelio was asking for ?
  <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
  <bkardell> fantasai, I think this is the important part - can we
             resolve on that?

  AmeliaBR: Important thing is when we have the correspondence they
            don't override actual boxes. If you have a padding box we
            don't defer to stroke bounding box.
  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 correspondence to CSS bounding box. My
            concern is could be difficult to compute for a fast api
  AmeliaBR: The bounding boxes in general, browsers have rough and
            dirty calc and precise calc. Rough is for dirty paint
  Rossen: Let's take this with SVG WG. If SVG WG has rec for how
          resize observer should be defined on non-css boxes let's
          discuss later. Want to close those topic
  <bkardell> +1
  Rossen: proposal: SVG elements generating CSS layout boxes are
          included as part of resize observer and resize observer
          rectangles
  Rossen: Objections?
  Rossen: 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

  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 */}

  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 what 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 publication 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

Text Decor
==========

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

  jensimmons: text-underline-offset lets authors move up and down,
              speaking in Latin. Negative is up, positive is down, 0
              is baseline.
  jensimmons: Implementation 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. Implemented in FF behind a flag. When I've
              been looking at this the last image in the issue 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: You can style strikethroughs, though you can't move up
              and down.
  <jensimmons> https://codepen.io/jensimmons/pen/wLrjGG?editors=1100
  jensimmons: 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.
  <bradk> +1 no clamping at all
  fantasai: We have a shorthand that lets you set both.
  Rossen: Making properties depend on each other is not great.
  <fantasai> +1 to Rossen

  <bradk> Underlines are behind the text and strikethroughs are in
          front of the text right?
  <astearns> bradk: yes
  <jensimmons> bradk — yes. Underlines are behind. Strikethroughs are
               in front.

  AmeliaBR: I agree these are neat effects. Important to recognize
            different text decor have different semantic meanings.
            Strikethrough is different then underline.
  <bradk> Text decorations are not semantic
  <jensimmons> AmeliaBR that's why I explained how strikethroughs can
               be styled.
  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
  AmeliaBR: As far as outcomes for clamping, I don't necessarily mean
            need to clamp
  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 necessary.

  myles: Thanks for all these examples jensimmons. I think you've
         shown where we draw the boundary 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
  myles: Would be bad if in one browser look struck through and other
         looks emphasized. I would prefer a 'should' try and
         distinguish between strike through text and underlined text.
         Once those limits are agreed can spec

  [audio problems trying to get dauwhe's comment. He put his feedback
      in GitHub:
https://github.com/w3c/csswg-drafts/issues/4059#issuecomment-510145258
]

  dbaron: I was on queue to suggest that given problems we may want
          text strikethrough offset 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 property. It defaults
            to alphabetic-ish. If we get specific offset we snap to
            alphabetic offset so you have 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 strikethrough and overline. Especially strike
          through. I recognize 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.
  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
  <bradk> Why not text-decoration-offset?
  dbaron: Possibly 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
  dbaron: But 2 or 3 is rare so not clear worth another property
  <fantasai> dbaron, text-underline-offset inherits
  <fantasai> dbaron, so that you can set it once and forget about it
  <fantasai> dbaron, so making it apply to all the lines wouldn't be
             very usable
  <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

  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 should have interop. I don't want too
              loose 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.
  jensimmons: 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.
  Rossen: Are we considering underlines that are visually...missing
          the term but the ones that break underline when something
          else is around. Or is this just solid line segments
  myles: Skipping in our implementation only considers text the
         underline is on. It won't skip next line of paragraph

  fantasai: I wanted to agree with jensimmons. Making argument about
            if underline should allowed to be higher because we think
            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
  <jensimmons> right now, btw, Safari allows any distance down — will
               go very far. There's not a clamp yet
  fantasai: I think jensimmons case of using central baseline is fine.
  myles: For small text it's hard to get underline, like 5px text,
         hard to get it in the linebox. Has to have case outside line
         box. Some general same clamping is important. Probably not
         where our impl does it today.
  <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: 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.
  Rossen: I remember 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.
  fantasai: I think need to decide if clamping to enforce
            underline-ness or if we're looking for reasonable distance
            of text
  Rossen: Both require clamping.
  <tantek> could it be clamped to the linebox?
  <fantasai> tantek, no, because line box can be smaller than the text
  <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
  AmeliaBR: If we allow visual effects, we allow them. I don't see a
            reason to clamp in either direction.
  <astearns> box-shadow not clamping is a good argument against not
             clamping here
  <tantek> I'm (a little) worried about the effect on printing, e.g.
           do text decorations count as part of widows and orphans
           computations?
  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
  <dbaron> (especially if they're wavy, etc.)
  fantasai: Just resolving a clamp to keep line in reasonable range of
            the text
  <bkardell> I'm fine with that much
  <tantek> would prefer more discussion before a resolution on this -
           that seems too wishy washy
  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.

  <florian> I would like to encourage people who care about
           white-space:pre-wrap and its end of line effects to look at
           https://github.com/w3c/csswg-drafts/issues/3869 and
           https://github.com/w3c/csswg-drafts/issues/3440 (myles,
           koji)

  Rossen: Thank you everyone, we'll continue next week.

Post Meeting IRC Conversation
-----------------------------

  <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?
  <bradk> jensimmons: I agree with you.
  <bradk> After wavering just a bit
  <tantek> jensimmons, I can see clamping of text decoration related
           stuff being useful for implementations being able to do
           more sane things with pagination
  <tantek> e.g. trying to keep text and its decorations "together" and
           not broken across page breaks
  <jensimmons> You should write these comments in the issue, everyone:
               https://github.com/w3c/csswg-drafts/issues/4059
  <jensimmons> and to be clear, I was quoting dauwhe above ^^ (in the
               very last comment)

  <fantasai> tantek, I AmeliaBR was the one arguing that there
             shouldn't be any clamping
  <tantek> I wrote it as part of the chat during the topic in the
           call, so it should make it into that log
  <fantasai> tantek, no your point about page breaks isn't in the
             log... I think it's a good one though :)
  <tantek> I said "I'm (a little) worried about the effect on
           printing, e.g. do text decorations count as part of widows
           and orphans computations?"
  <tantek> as a specific example of pagination concerns. that's enough
           of a hook IMO
  <tantek> also wondering if there is a need for a new term besides
           linebox that actually encloses all the text (ink?)
           generated by that line box
  <bradk> clamping for performance and memory management should be OK.
          For example, not allowing an underline to be a thousand
          miles from the text.
  <tantek> since per fantasai, text can go outside its linebox
  <fantasai> tantek, maybe. Hasn't been needed so far, but we haven't
             defined line layout that closely yet
  <tantek> bradk, beyond performance, just trying to keep an underline
           with its text like on the same page
  <fantasai> tantek, it is clear that line boxes and their contents
             can't fragment, though
  <bradk> Yes, I didn’t think ink overflow got paginated

  <tantek> fantasai what happens when contents of a linebox exceed the
           page box?
  <fantasai> tantek, gets clipped
  <fantasai> tantek, or sliced, if the UA prefers
  <fantasai> https://www.w3.org/TR/css-break-3/#possible-breaks

  <AmeliaBR> I think so far we just talk about this as ink overflow of
             the box. Doesn't affect breaks or pagination as far as I
             know. But, I can tell you that at least some browsers do
             ugly things where they let the paint from one box get
             sliced across a column break and show up at the top of
             the next column, and that should definitely be something
             we discourage!
  <bradk> text-decoration-break: clone|slice ?
  <fantasai> Seems like we should specify that ink overflow doesn't
             get paginated. I don't think that's been made explicit
             anywhere
  <fantasai> files https://github.com/w3c/csswg-drafts/issues/4099

  <jensimmons> tantek There are definitely places in
https://codepen.io/jensimmons/pen/wLrjGG?editors=1100
               where allowing the underline to go beyond the "ink
               area" of a line box — and into the inked area of the
               next line box, would be fine. I would want to allow
               such things.
  <fantasai> jensimmons: So maybe the clamp should be max(line box
             height, font height) + font height?
  <fantasai> jensimmons: alternately 2*max(line box height, font
             height)
  <jensimmons> How about (2 * max(line box height, font height) + font
               height) ?
  <fantasai> which is slightly looser
  <jensimmons> jinks!
  <jensimmons> or 3*
  <fantasai> jensimmons: that's three times the height of the text?
  <jensimmons> I can't imagine any reason to beyond 3x
  * fantasai can't imagine any reason beyond 2x
  <jensimmons> maybe 2* does it
  <fantasai> once you're one full line height below the bottom of the
             line box...
  <fantasai> I think you've lost any visual association with the text
  <bradk> Is the thickness of the line clamped?
  <jensimmons> oh yeah, playing with my demo, I can't see a reason to
               go beyond 2x
  <fantasai> no, it can be zero. Hence the max against font height
  <bradk> If the line thickness is 4em, then don’t clamp the offset to
          less than that
  <fantasai> oh
  <fantasai> I thought you meant the line of text :)
  <fantasai> Yeah
  <bradk> Reasons we can’t imagine are not necessarily bad reasons
  <fantasai> you're right, we need to account for that.

  <jensimmons> fantasai Are you formulating a specific proposal in
               your mind? To drop into the issue? I think that'd be
               good.
  <bradk> Wavy lines are also thicker than straight lines
  <bradk> I mean, they take up more vertical space
  <jensimmons> WAVY
  <fantasai> Spec says “The line is aligned to the outside of the
             specified position.”
  <fantasai> So, clamping the offset wouldn't clamp the outer edge
  <AmeliaBR> Reason to have an extreme offset underline: Fancy heading
             with mildly obnoxious hover effect that causes an
             underline to appear, but it doesn't just appear it slides
             into place from offscreen. I'm not saying it's good
             design, I'm just saying that once you allow animated
             underline offset distances, some designer is going to
             want to take it to the extreme.
  <jensimmons> also, we haven't articulated whether the clamp measures
               from the outside or inside edge of an underline line.
               Potentially very thick line. Maybe it's obvious to
               folks, but I'm not clear.
  <fantasai> AmeliaBR: That's a case where the designer might equally
             want it to slide in from the left or the right
  <fantasai> AmeliaBR: And that's not even possible here
  <fantasai> AmeliaBR: That's a use case for some different way to
             create the line, I think
  <fantasai> jensimmons, see spec quote above
  <jensimmons> an underline that slides in is just wrong. people
               aren't going to try to do that
  <jensimmons> people *are* going to animate this line
  <jensimmons> they are already asking me about it
  <jensimmons> like a very slight movement up or down on hover
  <bradk> People can be very creative, and I don’t want to stifle the
          creativity with artificial limits
  <jensimmons> could start at 0.5em offset, and move to 1em offset on
               hover
  <tantek> web designers will use overlines and underlines as
           alternative borders
  <tantek> or alternative to outline-top and outline-bottom
  <bradk> Could be used as an offset solid background too
  <tantek> graphical effects you can position without affecting layout

  <jensimmons> gotta go. meeting. bye
  <bradk> Bye
Received on Wednesday, 10 July 2019 23:43:54 UTC

This archive was generated by hypermail 2.3.1 : Wednesday, 10 July 2019 23:43:55 UTC