[CSSWG] Minutes Telecon 2020-07-01 [css-images-3] [css-color-5] [form controls] [css-sizing-4]

  These are the official CSSWG minutes.
  Unless you're correcting the minutes,
 Please respond by starting a new thread
   with an appropriate subject line.

CSS Images

  - RESOLVED: Make from-image's none value apply to background and any
              other images (Issue #5245: Clarify which images
              image-orientation applies to)

CSS Color

  - RESOLVED: Publish a version with all keywords but 'longer' (Issue
              #4735: When mixing hue, there are two ways round the hue

Form Controls

  - There was wide interest in trying to specify a color for the
      accent color of form controls (Issue #5187: Allow specifying the
      "accent color" of a form control element) however there were
      some concerns about if it's possible
      - Specifying form controls is being looked at by several people
          and this was a small step toward that which needs to be
          compatible with larger efforts.
      - Maintaining appropriate contrast may be hard if the accent
          color is sometimes against background and sometimes against
          foreground or text.
      - The solution needed to work with all existing browser/OS
          combinations and also support OSs that don't have accent
          colors so it is important to do more research before
          proceeding with moving into spec text.

CSS Sizing

  - RESOLVED: Accept proposal [
             (Issue #5151: Should aspect-ratio be used for abspos
             `top: 0; bottom: 0;`?)


Agenda: https://lists.w3.org/Archives/Public/www-style/2020Jul/0000.html

  Rossen Atanassov
  David Baron
  Christian Biesinger
  Mike Bremford
  Tantek Çelik
  Elika Etemad
  Simon Fraser
  Chris Harrelson
  Daniel Holbert
  Dael Jackson
  Dean Jackson
  Brian Kardell
  Chris Lilley
  Peter Linss
  Alison Maher
  Myles Maxfield
  Cameron McCormack
  Tess O'Connor
  Florian Rivoal
  Devin Rousso
  Jen Simmons
  Alan Stearns
  Miriam Suzanne
  Lea Verou

Scribe: dael

  Rossen: I wanted to ask for any last minute agenda items or changes
  Rossen: I'm aware of 3 changes; items to skip because already
          discussed or will be covered further in GH. Issue #4, #8,
          and #9
  Rossen: Besides skipping 4, 8, and 9 other changes?
  Rossen: I'll take that as a no

CSS Images

Clarify which images image-orientation applies to
  github: https://github.com/w3c/csswg-drafts/issues/5245

  heycam: We have image orientation property that allows us turn off
  heycam: Some discussion about widening to all images a few months
          ago. Resolution from there was orientation meta data should
          be honored for decorative images. Makes sense.
  heycam: Wasn't discussed if properties should be extended. As Mike
          noticed we have contradictory WPTs. Should image-orientation
          apply to decorative images?
  heycam: My feeling is it should because real purpose of property is
          let authors opt-out and it doesn't make sense to limit that
          to a subset of images

  dino: My question is what would you do if want decorative to do one
        thing and non-decorative do another
  heycam: You would need to introduce some other way of override
          orientation, maybe with image value syntax, or correct images
  dino: Sort of leading question. In many cases will have to fix image
        or change content. Is it worth having this apply everywhere? I
        don't know
  heycam: From experience of bug reports they were all content images.
          jpegs with image data rotated but tool didn't update meta
          data so new image-orientation made them wrong. Didn't get
          cases on decorative

  fantasai: We had this discussion before and I believe resolution was
            only to apply to content. Idea was if we needed to apply
            to other we would introduce image notation syntax. This
            discussion was before auto EXIF but that was original
            discussion and conclusion
  Rossen: Is that 4165?
  fantasai: Older
  fantasai: Let me check DoC
  Rossen: Where does this leave the current issue?
  <fantasai> https://lists.w3.org/Archives/Public/www-style/2012Mar/0412.html
  fantasai: Here's the issue. #50 in DoC. Conclusion was replaced
            elements and generated content but not background image
  fantasai: Or any other images in CSS
  fantasai: Images which are considered part of content are effected
            but no other
  faceless2: If purpose is undo EXIF makes sense to apply, but it's
             not weird to not. As long as it's documented.
  <fantasai> "It applies only to content images (e.g. replaced
             elements and generated content), not decorative images
             (such as background-image)."
  fantasai: Spec says ^.
  <fantasai> https://drafts.csswg.org/css-images-3/#the-image-orientation
  fantasai: Anything that's a replaced element in css model it applies
            to that. Everything else is not effected.
  <fantasai> This was issue 50 in the 2012 LC Disposition of Comments

  heycam: Seems like notion of this property has changed over time.
          Originally I want to set an orientation on an image. Now
          property is for I have a problem caused by change in
          browsers default and this gets me the old way back so I
          don't have to fix images I'm serving. In that PoV makes
          sense to apply as broadly as possible. Lets author set one
          property which goes to all images
  chrishtr: I agree with heycam reasoning and that's what Chrome impl.
            There were cases where it was useful behavior for site
  <smfr> webkit agrees with cameron too

  fantasai: If we make this change it should only effect none value
            and others shouldn't apply to decorative
  heycam: I think we have resolution to remove other values.
  fantasai: It's deprecated but has been impl and shipped in multiple
            implementations, just not browsers. We can remove from
            next spec level, but there needs to be a spec with those.
  chrishtr: Who implements?
  fantasai: Some printer based technology shipped with onboard layout
            in printer chipset.
  chrishtr: Okay so we say rotate ones won't apply to style images
  fantasai: And support for that is marked as optional so browsers
            don't need to impl. But there needs to be spec for it
  Rossen: Any changes to L3 images?
  fantasai: Yes if we want to make from-image none value apply to
            background and other images we need to change spec to say
            it's all images associated with element
  Rossen: Is this going to be still valid for printer or are they okay
          because L2?
  fantasai: They don't impl from-image I believe
  Rossen: Sorry, confused by statement that there were implementations
  fantasai: If we make change for other values than yes. That's why
            I'm saying it shouldn't apply to the other values
  Rossen: Would that solution work for everybody?
  heycam: sgtm

  Rossen: Proposal: Make from-image and none value apply to background
          and any other images?
  fantasai: Angle only applies to content
  Rossen: Sorry, I meant none value on from-image
  Rossen: Additional comments?

  smfr: Can we resolve on cursor behavior and linked meta that are in
        GH issue?
  Rossen: Would this be the exception on cursor?
  smfr: Makes sense for cursor to have same. Link and meta I don't
        know since usually don't apply CSS to them
  fantasai: Not sure what a link or meta element would do
  heycam: Some cases about favicons and similar images
  smfr: First comment in issues has list of interesting items like
        embed object. We need to be explicit which of these we include
  chrishtr: Canvas is an imperative API
  smfr: Not sure about canvas I think right is API to expose EXIF to
        JS or extend draw image API
  <tantek> presumably you can put images on link or meta via
           background-image or ::before and content property etc.
  fantasai: Rest it should apply, every image associated to the
            element is effected as far as CSS is concerned. If it's a
            replaced element it's applied. Decorative elements would
            include background image and cursor
  smfr: Source graphic in SVG
  fantasai: Replaced element, isn't it?
  smfr: I think it's paint source or whatever it's called
  heycam: I think that's rendered content of some sub-element on dom
  fantasai: Do you do image orientation of source, using, or neither
  heycam: Similar to canvas-draw-image because can reference another
          image element. Have minor incompat on where to look already.
          I think those cases can be handled in specs that define what
          it's referencing
  smfr: Agree. We can resolve on what we discussed and say SVG may
        need refining
  heycam: I'm happy to make cursor effected.
  Rossen: Should we try to resolve on this and heycam or someone can
          open an issue on SVG to makes sure there's no additional
          items to associate to this decision?
  heycam: sgtm
  Rossen: Still previous resolution. Objections?

  RESOLVED: Make from-image's none value apply to background and any
            other images

CSS Color

When mixing hue, there are two ways round the hue range
  github: https://github.com/w3c/csswg-drafts/issues/4735

  leaverou: When interpolating between hues usually you don't want
            interpolate in same way. If going between hue 0 and hue
            400 you don't want a whole rainbow
  leaverou: What we put in spec is by default use shortest arc which
            does expected in common. Have keywords for longest arc etc
            and also as-specified keyword to allow raw interpolation
  leaverou: Wasn't sure if all keywords needed. Especially the
            specified one. If impl want to store value as normalized
            keyword doesn't allow
  leaverou: I put algorithm in spec which tweaked by dbaron. Good to
            get sanity check.
  <smfr> https://drafts.csswg.org/css-color-5/#hue-interpolation

  fantasai: Can you summarize?
  leaverou: Do we need all 5 keywords?
  leaverou: We need shorter because that's what you expect in most
            cases. Do we need specified which is interpolate as
            specified so if you go between 0 and 720 you get 2
            rainbows. Need increasing, decreasing, longest or is that
  fantasai: Are there use cases? We can add keywords. If there's not a
            use case might want to note possibility for future
            reference in case we need to add later. If not a use case
            don't need to add.
  fantasai: I think it's useful to think of all and make sure keywords
            are a set that make sense even if we only include 1 or 2
            in spec
  dbaron: Intent is these would eventually apply to all gradients,
          animations, and color mix functions or only some?
  leaverou: Good to design with that in mind. Not sure how to write
            text for animations and gradients but if we have a syntax
            making sense it would be good to have the option
  <astearns> for gradients and animations the workaround would be to
             add more steps/stops to mimic the non-short behavior?

  fantasai: My suggestion is draft all in spec, put an issue in saying
            we're not sure if we need all and we might limit to a
            subset with the subset that makes sense to you and also
            note might expand to gradients. Encourage people to think
            what that would look like
  <tantek> +1 to publishing at least one draft with more keywords to
           get the ideas published
  fantasai: Early stage WD so makes sense to put ideas and poke at
            them with people like Una and Adam to make cases

  <leaverou> https://drafts.csswg.org/css-color-5/#hue-interpolation
  leaverou: Does math make sense? This is the section ^

  miriam: Thinking of specified I'd have use cases when comes to
          gradient. As pointed out in chat that could be do with extra
  miriam: Can't think of cases when mixing colors. I don't know if
          that's separate but might be. Math makes sense. Shorter and
          longer fall apart at 180 which maybe implies need to
          determine direction without them
  florian: I haven't reviewed math for correctness, but intuitive
           seems right. Longer seems least useful. Wanting longer for
           being longer seems odd. Might pick if gives right thing.
  <miriam> +1 to longer being less useful than increase/decrease
  florian: Approach about putting in spec now with note for use cases
           sounds good

  dbaron: On math have a PR to tweak. I think set notation doesn't
          match pseudo code and I think pseudo code is right. I have
          some tweaks for 180 case but it's not clear that's what we
  leaverou: 180 case chris said we can pick one as long as it's well
            defined. Doesn't matter increasing or decreasing
  florian: Makes sense. If you have a preference you can say it.

  fantasai: We use 'closest' in radial gradients so maybe that instead
            of 'shorter'?
  leaverou: Than what longer?
  fantasai: 'farthest'?
  florian: I don't think longer is needed so I don't mind not having a
           good replacement
  <tantek> near and far, close and distant, short and long ?
  fantasai: We have farthest and closest side
  leaverou: That's differ than angles

  Rossen: Apart from bikeshedding I hear 2 proposals. 1) let's push a
          version of the spec with all the keywords initially or as
          many as we want so we encourage more incubation.
  Rossen: 2) I hear agreement that longer doesn't seem useful. I
          didn't hear a use case to prove otherwise.
  Rossen: I don't want to bikeshed.
  Rossen: Should we resolve to keep the keywords besides longer and
  leaverou: I'd rather hear from Una and Adam before we resolve.
  fantasai: This isn't final. We're drafting for discussion to
            encourage participation. I think it's fine to put it all
            in the draft, explain the thoughts, and encourage
            feedback. We can publish often.
  <fantasai> "Publish early, publish often"

  Rossen: Objections to publish a version with all keywords but longer?
  <tantek> +1

  RESOLVED: Publish a version with all keywords but 'longer'

CSS Values

Fallback value of ex height
  github: https://github.com/w3c/csswg-drafts/issues/5243

  fantasai: There's been discussion since I did agenda+ so might want
            to kick to GH to see if there's changes to spec text. Does
            seem like point 8 is not what's implemented
  Rossen: Sure. Chatter on issue started after posted agenda. Let's
          give it more time.

Form Controls

Allow specifying the "accent color" of a form control element
  github: https://github.com/w3c/csswg-drafts/issues/5187

  chrishtr: Form controls are styled and painted in UA specific way in
            all browsers
  chrishtr: There tends to be a concept of an accent color used to
            indicate checked or marked state of form controls.
  chrishtr: UAs pick a default color for that that's consistent in
            page. There are also OS settings on some OSs to change
            accent color which is respected by some browsers.
  chrishtr: Color might conflict with brand of site, like site with
            orange theme but checkboxes are blue
  chrishtr: Proposal is to have css property which says form controls
            should use this color as basis of accent color when
            painting form control
  Rossen: Opinions on this?
  <tantek> the other big use-case is for sites that want to make
           "darker" versions of form controls that match their site
           styling, similar to scrollbar colors
  <fantasai> tantek, that use case is handled by the 'color-scheme'
             property fwiw
  <fantasai> tantek, https://www.w3.org/TR/css-color-adjust-1/#preferred
  <tantek> fantasai, not talking about not dark mode. hence I said
           darker deliberately

  fantasai: Main concern is it's not clear what accent color is used
            for. Because that it's not clear what's expected contrast
            between that, text, and background.
  <tantek> +1 agree with fantasai, needs to be predictably specified
           so it makes sense across OSs and devices
  fantasai: Concern people will choose colors that are good on some OS
            but won't contrast with background enough in other rows.
            For example a select multiple it needs to contrast with
            text. But on a selected checkmark it's background
  fantasai: Understand what you're trying to do but concerned we won't
            get something robust across browsers
  <tantek> needs to be sufficiently predictable across browsers
  florian: Can we split into foreground and background or does that
           not generalize well?

  myles: We had internal discussion and general feeling is good for
         web in general. Not sure mechanism to expose. We have a
         general idea good to style lots of form control aspects. Good
         to do in general not just one piece. In general feel this has
         value for web.
  <tantek> +1 myles that's a good summary
  chrishtr: Re: general styling point. Agree that there are other
            things devs wish to style and hopefully can. This one
            seems to be simple and common and immediately solves a
            specific concern. That's why I think do it as a one-off
            for the moment and general in future
  florian: General will take time. Seems most of time accent color is
           related to background but not always. If it's background or
           foreground matters. Having the pair would be a step which
           could make sense. There can be many aspects of form control
           we can do later. Knowing if you're in foreground or
           background matters.
  heycam: Ignoring select multiple issue which might not be accent
          color all other colors are contrasting separately. For
          checkbox and radio you'd got icon inside which authors can't
          control. I think for most cases where accent color can be
          changed any contrasting color can be painted by UA.

  jensimmons: Has anyone working on open UI on the call? I know a lot
              of work has gone into form controls and what it means to
              style them

  myles: On iOS there's no concept of the accent colors. Whatever is
         in spec needs affordances for OS where it doesn't apply
  florian: If we look at range of historical OS to get diversity the
           buttons were a shade of blue. If that was still the fashion
           accent color wold be there and it's very background-y
  <florian> https://66.media.tumblr.com/e0c02215356306ee52298451ac25685e/tumblr_o5a0h4UIDN1v0jfsto2_1280.png
  <florian> http://pcdesktops.emuunlim.com/pictures/skins/wb/macosx-aqua-bjb.gif

  chrishtr: Answering jensimmons, I'm working with gregwhitworth and
            others on longer term project for form controls. I don't
            know if enough to discuss here. In general I think compat.
            I don't think there's enough to say about OpenUI to clarify

  Rossen: Is there a resolution you're looking for?
  chrishtr: I'm hoping to get to agreement on name and set of text
            what's it's supposed to be for UA and says UA should make
            sure sufficient contrast and only where it makes sense
  fantasai: Fine to try and draft language. Requires more review to
            make so it works on a variety of OSs. I'm a little
            skeptical this will work but understand we want it. I'm
            concerned about having it work for all OSs.
  fantasai: If we can show that would be the case across current and
            past OSs and there's a reasonable interpretation for all
            the OS/browser combos I would feel more comfortable moving
  <jensimmons> +1 to what fantasai said
  chrishtr: Hearing general support but need more research to
            understand compat as well as foreground/background comments
  fantasai: I think we should do that evaluation in GH. Might be right
            design, but might be diversity of form controls requires
            something different.
  <tantek> we're also looking preliminarily at a more longer term
           project for form controls as well, if existing work is
           happening in the open, please share that in CSSWG! Thanks!
  chrishtr: We'll come back with more concrete proposal
  florian: What I'd like to see in research is wide variety of form
           control and show form controls is always background or
           neither. If it's in foreground sometimes we need to split
           it up.

  <tantek> just going to note that existing OS UI use of color is
           insufficient to determine feature flexibility, new OS's may
           and will do new things with colors etc.

CSS Sizing

Should aspect-ratio be used for abspos `top: 0; bottom: 0;`?
  github: https://github.com/w3c/csswg-drafts/issues/5151

  <astearns> PR:
  fantasai: Issue raised was if you have abspos element with top,
            bottom, left set non-auto but right is auto should that
            use aspect-ratio in sizing width. TabAtkins and I thought
            it made sense so drafted spec of that.
  fantasai: If width and height are both auto we ignore aspect-ratio
            for width and use it for height. In this case it's easy to
            determine height. Width has only one constraint so it's
            variable and makes sense to use height for deterministic
  fantasai: Drafted wording into positioning spec. Wanted to check
            with WG if it's acceptable

  Rossen: Would align-stretch work the same or have same behavior in
          this case?
  fantasai: Don't remember which align-stretch does
  Rossen: My understanding is align-stretch should behave same as if
          fixed height which should then have the same expected
          behavior for aspect-ratio, wouldn't it?
  Rossen: Not sure if this is related to position spec
  fantasai: align-stretch takes precedence over aspect-ratio. If
            neither is stretch, width and height auto, but can stretch
            because top:0 bottom:0. Take that as a definite height
            where we can calculate the width

  Rossen: Back to top and bottom 0. Other opinions or reasons why the
          aspect-ratio shouldn't behave this way?
  cbiesinger: On behalf of Chrome I support
  Rossen: This isn't just about top:0 bottom:0 it would be same with
  fantasai: Right. It's non-auto

  dholbert: This is any element with an aspect ratio?
  fantasai: Problem is we have compat requirements for images. For a
            replaced element it's slightly different. Replaced
            elements don't stretch between constrained insets and we
            can't change due to compat. aspect-ratio on non-replaced
            we figured we can do the thing that makes most sense.
  fantasai: Question is do we use it to resolve height or width in
            this case since height can come from size of containing
  Rossen: Objections or other comments?

  RESOLVED: Accept proposal [

  Rossen: Let's call it for today and we'll chat again next week.
          Thank you everyone and we'll chat on the 8th

Received on Thursday, 2 July 2020 10:23:57 UTC