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

[CSSWG] Minutes Telecon 2019-08-07 [css-images] [css-text-decor]

From: Dael Jackson <daelcss@gmail.com>
Date: Thu, 8 Aug 2019 05:11:16 -0400
Message-ID: <CADhPm3tELNm41_HcKUhWREBwQfc28KpBfztCG1CsUYTp2eR96Q@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.

Charter Update

  - The new charter ( https://w3c.github.io/charter-drafts/css-2019.html )
      will go before W3C management next week. Anyone who would like
      to review should do so soon and open any issues on github:

CSS Images

  - RESOLVED: Default behavior for all images to respect EXIF
              orientation (Issue #4165: Should CSS decorative images
              respect EXIF-orientation by default)
  - The last few edits will go into the spec next week with the plan
      of requesting publication next call.

Text Decoration

  - RESOLVED: If multiple layers exist with text-shadows we draw them
              all (Issue #3932: Need for clarification on how
              ::selection text-shadows work)
  - RESOLVED: Background on a highlight layer paints over shadows on
              layers below (Issue #3932)
      - There was concern with the background overpainting leading to
          ugly results when the background is smaller then the
          text-shadows below it. If there is more information that
          this will be a real problem the group will revisit the
  - The group agreed not to use 'weight' for issue #4138 (Rename
      `text-decoration-thickness` to `text-decoration-weight`?)
      however there wasn't agreement between 'thickness' and 'width'.
      There is one shipped implementation using 'thickness' however
      'width' is more consistent with other CSS properties. An on call
      straw poll had a slight majority leaning no change/'thickness'
      however before resolving the question will be asked again with
      more people on the call.
  - fantasai will draft proposed text for issue #4134 (What happens to
      the wavy & double lines when `text-decoration-thickness` is
      applied?) that will give general guidelines that wavy and double
      lines must scale, but not giving specific sizes.


Agenda: https://lists.w3.org/Archives/Public/www-style/2019Aug/0000.html

  Rossen Atanassov
  Tab Atkins (IRC Only)
  David Baron
  Amelia Bellamy-Royds
  Brian Birtles
  Tantek Çelik
  Benjamin De Cock
  Elika Etemad
  Simon Fraser
  Dael Jackson
  Brain Kardell
  Myles Maxfield
  Cameron McCormack
  Melanie Richards
  Devin Rousso
  Alan Stearns
  Fuqiao Xue

  Rachel Andrew
  Christian Biesinger
  Manuel Rego Casasnovas
  Christopher Schmitt
  Jen Simmons
  Greg Whitworth

Scribe: dael

Charter Update

  astearns: xfq any update or anything you need from me or Rossen?
  <xfq> https://w3c.github.io/charter-drafts/css-2019.html
  xfq: Link to current draft^
  <xfq> https://github.com/w3c/charter-drafts/issues?utf8=✓&q=is%3Aissue+is%3Aopen+csswg
  xfq: Nothing needed from chairs. Here ^ is open issues from florian
  xfq: Agree with testing policy change. Haven't done it yet
  xfq: Delays of horizontal review haven't made the change because
       likely to get objections from horizontal groups. Not a blocker
       of W3C management review.
  xfq: W3C doesn't have management meeting this week. I will request
       review next week. If it gets approved will start AC review soon

  <xfq> https://github.com/w3c/strategy/issues/188
  xfq: Had a comment ^ from Richard that it would be good to group
       deliverables into WD & CRs. I don't object. If no objections I
       can do that
  astearns: I like Richard's suggestion. I would put CRs at the top so
            stuff furthest along is at the top.
  xfq: Looks good to me

  astearns: For horizontal review might be good to go with template
            and open florian issue on template itself to get wider
            discussion on how things should get processed
  astearns: Sounds great to get review started next week
  astearns: Any other issues on the charter please open on the repo
  astearns: Anything anyone would like to add or amend to the agenda?

Agenda Setting

  fantasai: I've only got 20 minutes
  * fantasai looking
  <fantasai> images stuff and text-decor
  astearns: fantasai anything you want to get to in your 20 minutes?
  astearns: Everyone else please look at issues and if an issue is
            fantasai related move it up
  fantasai: Images, text-decor, Lists 3 on counter
  astearns: So follow first 4 items
  astearns: Other re-ordering?
  fantasai: Let's pull #13 above text-decor
  fantasai: I think after that can repub images

CSS Images

Specify fallback behavior when replaced or background image content
    not available
  github: https://github.com/w3c/csswg-drafts/issues/1984

  astearns: TabAtkins added but he's IRC only
  fantasai: Have some discussion from last week
  fantasai: Wanted to get WG review I believe. Then we were supposed
            to make edits
  astearns: Needs edits tag was removed
  fantasai: I'll fix that
  astearns: Maybe were edits...There is a PR
  <astearns> https://github.com/w3c/csswg-drafts/commit/73d7635574d54f5afb154b5bcf24a2fc086e2093
  AmeliaBR: There were edits 3 weeks ago discussed last week. Nothing
            since last week

Should CSS decorative images respect EXIF-orientation by default
  github: https://github.com/w3c/csswg-drafts/issues/4165

  astearns: Added by smfr
  smfr: Cleaning up issues for if images respect EXIF. Question came
        up if decorative ones should respect EXIF. Should we allow
        authors to control orientation in decorative images?
  smfr: Simple question is do decorative images respect EXIF by default
  AmeliaBR: I think default behavior should be to respect it,
            especially if that's the default for content images. We
            should be consistent unless there is webcompat reasons
  AmeliaBR: Like having extra parameter that can change things. Adding
            the extra shouldn't delay spec default
  fantasai: Default behavior will have to go in L3, image function is
            in L4 so it would go there

  smfr: One data point I don't think we have web compat data because
        no platform has respected EXIF for decorative images by default

  astearns: Distinction between content and decorative is background?
  smfr: Yeah. Content images are images in replaced elements
  AmeliaBR: Instead of decorative we should say css images. Images
            spec through css property. Exception is content property.
            New image-orientation property would effect images
            embedded using content
  fantasai: Yeah. Early defined replaced to work using content
            property. Definitely interchangeable. List markers and
            background images and stuff are not replace in box tree.
            Content images are
  smfr: Images in SVG too which we haven't talked about

  astearns: Concern was on compat for spec default to honor EXIF. Do
            you have any idea of what % images used on web have EXIF
  smfr: TabAtkins had data. It's less common to use thing with EXIF
        data as decorative. I'm not as concerned as I was with content
        images. We can try and see what happens
  astearns: I know people use background image for content data. I
            think it would be surprising to take a URL that's an
            image, but it in background and it flips
  <TabAtkins> Yeah agree.
  fantasai: Agree with AmeliaBR default should be consistent between
            all the images
  smfr: Happy to resolve now and come back if compat
  <TabAtkins> Should agree unless there's compelling compat data.

  astearns: Proposal: default behavior for all images to respect EXIF
  astearns: Additional concerns?
  astearns: Objections?

  RESOLVED: default behavior for all images to respect EXIF orientation

  astearns: My understanding is we do not yet have param in image
            function to override in next module
  fantasai: No. Inclination is not to add unless authors say they want
            this. We've historically had problems getting image() impl
            so I'd rather not add without demand
  AmeliaBR: Have vague resolutions to add params to control image for
            things like lazy-load. Once we get all that ecosystem of
            params maybe this gets added in if there is demand
  astearns: Seems fine place to leave it. Anyone want to fight to put
            in a param now?
  smfr: I think it's fine. Agree with fantasai to wait

  smfr: It is odd we have image-resolution apply to all aster but
        image-orientation is content images. Should think in the future
  AmeliaBR: Re-access image resolution?
  smfr: I would go in other where image-orientation should effect all
  astearns: Since we're consistent in orientation data, consistent in
            orientation property makes sense
  fantasai: Reason why not is that images typically come from
            different sources. Might have a bunch of SVG used for
            background or border. Not going to want to have that
            rotate but might correct rotation so a photograph.
            Discussed this in the past and decided does not effect
            anything other then content and images
  fantasai: Makes sense to be consistent on EXIF. I don't think
            explicit values need to be everywhere. I don't think
            orientation wants to effect decorative and content
  smfr: from-image is the only one you'd care about for css images
  AmeliaBR: Only you can assume applies to many images. If you had
            content and bg images wouldn't necessary align. Probably
            try for image-resolution property. Might be worth
            considering finer grain control there. I don't know if
            there are impl of that to get author feedback
  fantasai: Idea was for css images that we would address use case to
            override explicit orientation through image()
  astearns: Sounds like we're toward no change for rest of questions
            in issue. Correct?
  fantasai: Open to adding image orientation overrides in image() if
            there's demand. Default is respect EXIF
  astearns: Then let's close this issue.


  fantasai: Just need to make edits for first 2 issues so next week
  astearns: And for this issue as well.
  astearns: Please take a look at images 3 and likely will call for
            republication next week.
  <fantasai> For reference, DoC is at

Text Decoration

Need for clarification on how ::selection text-shadows work
  github: https://github.com/w3c/csswg-drafts/issues/3932

  fantasai: I was going over what we want for text-shadows. Came up
            with a bunch of questions for ::selection text-shadows
  fantasai: Last time we discussed only thought about ::selection but
            have multiple highlight pseudos that can layer. Models
            discussed don't make too much sense.
  <fantasai> https://github.com/w3c/csswg-drafts/issues/3932#issuecomment-510220043
  fantasai: Summary ^
  fantasai: Default case selection with a background suppresses
            text-shadows because otherwise might not get enough
            contrast. Spelling and grammar do not suppress
            text-shadows. Need to make it that having a highlight
            there shouldn't suppress text-shadow below
  fantasai: 2 models. Any non-transparent background disables shadows
            on layers below. Background on any paints over layers
  fantasai: Highlight pseudos might want to change order and paint
            background in between
  fantasai: There are questions on multi-layers with text-shadows and
            they all spec text shadow do we draw top most non-none?
  fantasai: I don't have a clear answer to these questions so I want
            feedback from WG

  AmeliaBR: I don't think have any other way in CSS where you can
            composite together text-shadow from different declarations
  fantasai: Right, because shadows inherit. Parent inherits to child
            so shadow takes effect on child unless you do something.
            Here is a bunch of layers without parent/child so no clear
            inheritence. But we don't want something like
            spelling-error to prevent a shadow just because it now
  AmeliaBR: As with everything on selection highlight classes I wish
            we could make sense of this in normal cascade way. I think
            trying to draw 2 text shadows on same text is strange.
  AmeliaBR: For background layering multiple backgrounds seems to make
            sense. Question of if it's performant to draw shadows that
            will be obscured.
  fantasai: I don't care if we draw background over or don't draw
            because the background will obscure. Either gets
            reasonable behavior
  astearns: Main thing is pick easily impl and can be consistent.
            Seems edge case because selection happens on editable text.
  fantasai: Could select to copy out. That's frequent
  smfr: Some add funky text shadow to change anti-aliasing
  astearns: ooh, fun.

  smfr: I'm confused about how things are supposed to work. Understand
        text-shadow style gets cascade into text-shadow on element and
        paint result. fantasai sounds like saying selection has own
        text-shadow style hence the layers
  fantasai: Didn't quite follow. In this case you have a word and it
            is a spelling error and a grammar error and it's selected.
  fantasai: Properties on each pseudo element cascades in and
            inherited through...trying to remember because
            changed...[reads spec]
  fantasai: You aren't going to have the text-shadow value inherit
            from base document element. Properties are inherited from
            parent. Each element has own ::selection and the
            ::selection of span inherits from ::selection of p which
            inherits from ::selection of body. Text-shadow around that
            word's text-shadow property won't have that value on it.
  fantasai: If going to draw text we would see text-shadow:none and
            that's not okay for spelling error. You don't expect a
            spelling error to suppress shadows. Even though spelling
            errors don't have text-shadow you want to draw the shadow
  <fantasai> https://drafts.csswg.org/css-pseudo-4/#highlight-cascade
  smfr: It's about the decoration style clobbering the text-shadow of
        unselected version
  fantasai: Could do it for selection, but not for spelling and
            grammar. Making it disappear with only difference is
            underline doesn't make sense and could make text unreadable

  smfr: Implementation no problem paining multi shadow. Prefer to
        avoid complex logic if things are transparent
  fantasai: 2 related questions. 1: How do we deal with suppressing
            shadows when drawing background because selection has
            background. Can do that by saying if background in
            non-transparent we don't paint shadows below. Or paint
            shadows first and then paint background
  smfr: background may not be opaque
  fantasai: Right. Or smaller then text-shadow
  fantasai: You could distinguish between two, but difference isn't
            that important question of what's easier to implement
  smfr: Want to look at native platform to see if those make sense and
        should be matched
  fantasai: Second question is if we have multi-layers spec
            text-shadow. So author decides spelling error creates a
            blurred red text-shadow and grammar is green shadow and
            selection is orange shadow, do we draw all or only top
            most non-none?
  smfr: I think draw all. Draw what author asked for
  smfr: Mac native does paint text shadow under selection, I think.
        You do get combination
  fantasai: Prop: If multiple layers with text-shadows we draw them all
  fantasai: Resolve on that?
  astearns: Objections?

  RESOLVED: If multiple layers with text-shadows we draw them all

  fantasai: Background either suppress or paint over lower level, I
            think smfr suggests we paint over?
  smfr: Yes
  fantasai: Background on a highlight layer paints over shadows on
            layers below
  astearns: Obj?

  RESOLVED: Background on a highlight layer paints over shadows on
            layers below

  astearns: Is that enough to spec interop?
  fantasai: That's enough to spec. Interop depends on impl.
  astearns: There are test cases I expect will need to be amended to
  fantasai: Yeah

  <dbaron> I'm not crazy about the background painting over thing.
  <dbaron> seems like the shadows may well peek out at the edges.
  astearns: dbaron you mentioned you're not crazy about peaking out? I
            believe that is the case and shadows will show if larger
            then background
  fantasai: I don't care which way it goes between the 2
  <fantasai> as long as we have an answer
  astearns: Let's go with that option. dbaron if you have a change or
            objections please update the issue
  <dbaron> yeah, I don't feel that strongly, but the behavior seems a
           bit ugly
  <fantasai> Also OK if we want to make it a UA choice between the two
  <fantasai> just so long as it's only those two options and not "do
             anything" :)
  astearns: Anything else on this?

Rename `text-decoration-thickness` to `text-decoration-weight`?
  github: https://github.com/w3c/csswg-drafts/issues/4138

  astearns: Jen suggested weight because typographic term. We have
            width, thickness, and weight as possibilities for the
            property that determines how wide/thick a text underline is
  astearns: Opinions on what we should do?
  myles: We shipped thickness. Prefer no change
  astearns: Anyone else?
  <TabAtkins> I prefer no change
  <TabAtkins> (I prefer we'd kept it as 'width', but oh well.)
  fantasai: I personally favor width because every other line
            thickness in css is width and that's helpful to authors
  <fantasai> https://github.com/w3c/csswg-drafts/issues/4138#issuecomment-517121344
  fantasai: bradk said same ^
  <tantek> +1 fantasai
  heycam: Prefer not to change here. I'd like to stick with [missed]
  astearns: I believe heycam wanted preference for width
  AmeliaBR: Would have leaned width, but not worth changing shipped
  <tantek> seriously how did we all screw this up?
  * tantek wants the history / blame on the resolution for thickness
  <tantek> outline-width etc.

  astearns: Jen suggested weight because it's typographic. Somewhat
            against because we don't use it for line thickness
            elsewhere. Font has more then line thickness
  myles: Also 400 is reasonable weight
  astearns: Should reject weight. Have people on both sides of width
            and thickness
  fantasai: Sympathetic that we impl and shipped. Inconsistency will
            effect authors going forward and will have to remember
            this is only one that has a different name for what it's
            doing. That's an ongoing cost
  drusso: Would argue it's different. Thickness of line under text I
          don't think is a width. border-width is how wide is it.
          Underline people think thick or heavy
  fantasai: Majority of people don't speak English, they're looking
            for patterns. It's just another line.
  <tantek> agreed with fantasai, for non-native English speakers, it
           makes no sense to appeal some minute difference of meaning
           between thickness and width
  myles: Value in css matching colloquial talk
  fantasai: Yes. But higher value in css matching itself

  astearns: tantek asked for where we resolved on thickness
  <astearns> tantek:
  myles: At f2f, forget location. Did twitter poll asking people what
         width means, horizontal distance or vertical distance of
         line. 60/40 split with 60% being wrong answer
  <tantek> wow those linked minutes do not have any reasoning for
  <tantek> that's really bad
  <fantasai> https://lists.w3.org/Archives/Public/www-style/2018Dec/0004.html

  astearns: I'm torn. Like consistency, but things are shipped. I'm
            inclined to leave things as they are with thickness. It's
            poss a mistake and we need to create line-weight alias
  <tantek> "shipped" is not good enough
  <tantek> webcompat would be
  fantasai: We won't make an alias. We'll either get this right now or
            we live with this
  myles: Agree. If we didn't do font-stretch we won't do this
  astearns: tantek in IRC says shipped isn't enough, should only
            consider web compat. Do we have content using this?
  fantasai: Hardly any I think, shipped recently
  myles: We did resolve before we shipped
  tantek: There's no reasoning in that resolution, not even a straw
          poll. I think we should throw that resolution out. I don't
          trust it.
  myles: You were in the room tantek
  tantek: I don't remember it.
  astearns: I remember more discussion then captured in minutes, but
            it was short.
  tantek: Well, it was scribed more now then it was then

  tantek: We had resolution on some discussion. I see a non-trivial
          amount of folks uncomfortable after the fact. I'd request a
          straw poll to see if it's a few of us uncomfortable or if
          it's wider questions of the resolution
  astearns: Can straw poll
  Rossen: We don't have as many people as compared to other calls. If
          this is problematic resolution let's push to next week with
          more people and give a week to think
  tantek: I don't disagree, but doesn't conflict with my straw poll

  astearns: For people on call to get tone of room. Please type 0 if
            don't care. 1 if prefer width. 2 if you prefer thickness
  <bkardell_> 14
  <fantasai> fantasai: 1
  <astearns> 0
  <fantasai> bradk: 1
  <myles> 2
  <smfr> 2
  <dbaron> 2
  <Rossen> 2
  <bkardell_> 0
  <heycam> 2 (because I prefer not changing)
  <AmeliaBR> 1
  <drousso> 2 (because i'd rather not change)
  <xfq> 0
  <birtles> 0
  <melanierichards> 0
  <tantek> 1 / 0 (weak preference)
  astearns: People on call slight preference for no change

  astearns: Let's set this to go over next week with more people on
            call. Decision will be keep thickness or change it back to
  <tantek> I'm not seeing fantasai or tab on the poll who previously
           said 'width' in the above
  <bkardell_> slight/weak preference prob, but I said 0 because i
              think it is weak
  * fantasai is in the poll above
  * fantasai also noted bradk's preference, which he asked to have
             noted in the meeting

What happens to the wavy & double lines when
    `text-decoration-thickness` is applied?
  github: https://github.com/w3c/csswg-drafts/issues/4134

  astearns: Should we spec how wavy lines should be drawn?
  heycam: More control over these things, more authors will expect
          specific effects. Presence of thickness will make people
          aware of difference in render for wavy lines
  AmeliaBR: Agree something should be specified. No strong opinion of
            what. Clear rendering definition is worthwhile
  Rossen: Any expectation that this property will be different then
  fantasai: Yes because when scaling stroke thickness you're not
            changing path. Here you expect thickness of line and size
            of wave will scale

  Rossen: Suggestion is both the control points and stroke change?
  fantasai: Yeah because if you don't change control points you just
            get a thick line. It is spec as wavy line
  <tantek> more thickness = lower frequency?
  <astearns> tantek: more thickness = more amplitude
  <tantek> text-decoration-radius?
  <fantasai> :(
  AmeliaBR: Better compare at least for double line is double borders
            where as you scale up the total width of border is divided
            between two strokes and space between. I'd expect that for
            double line. Wavy I'd expect waves to take full width. If
            the waves stretch to keep proportional curve that's
            unspecified since we don't define what it is to start with.
  Rossen: I'd be interested to hear behavior on different platforms.
          Desktop word when scaling overall text the thickness and
          waviness of underlines does not change. Consistent across
          office products. Curious if different
  <fantasai> rossen, the issue here is that the thickness of the
             underline is specified to change, in that case we can't
             be consistent with the platform if the platform isn't
             changing the thickness

  myles: Couple points. Straight double underlines we've got platform
         conventions for position. Shouldn't spec gap. Wavy underlines
         a use case is spelling market or cjk names/titles as an
         honorific. The shape of those might intend to be different.
         Shouldn't give amplitude and frequency controls. If give
         controls should be for semantic.
  myles: I don't see authors asking for high level of control on
         shaping underline
  astearns: I don't think talking adding properties. Just specifying
            something so get slightly more consistent rendering across
            browsers and platforms

  fantasai: Might need to just spec that for wavy lines that thickness
            of line as well as amplitude and frequency are meant to
            scale up. UA can adjust and it doesn't have to be a linear
            curve. If you're increasing thickness of line then
            amplitude and frequency needs to scale up
  fantasai: Can say something similar for doubling. Thickness of 2
            underlines and space between should scale. Should look
            good in large font sizes.
  astearns: We're past time. We should close this.
  astearns: fantasai can you come up with a proposal for what to do?
  fantasai: If people are happy with the general guidelines I can draft
  astearns: Draft it, put in issues, and then we'll agenda+ for
            specific text
  fantasai: Agree with myles shouldn't spec exact curves and amplitude.

  astearns: Thanks everyone for calling in and letting me go a bit
            over. We'll talk next week.
Received on Thursday, 8 August 2019 09:12:42 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 22:53:15 UTC