[CSSWG] Minutes Telecon 2020-02-12 [css-device-adapt] [css-viewport] [css-contain] [css-pseudo] [css-sizing] [css-color-4] [css-color-adjust]

  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 Device Adaptation & CSS Viewport

  - RESOLVED: Remove @viewport, retire the spec, move the meta tag to
              a new spec (CSS Viewport) (Issue #4766: Remove @viewport)
  - RESOLVED: Move layout/visual viewport spec into CSS Viewport spec
      - smfr will be added as an editor to the new CSS Viewport spec

CSS Contain

  - RESOLVED: Accept proposal as phrased in comment from florian [When
              calculating the size of the containing box, including
              when computing its intrinsic size, it must be treated as
              having no contents.] (Issue #4741: It should be clearer
              that size containment inhibits effects of contents on
              intrinsic sizes)

CSS Pseudo Elements

  - fantasai will draft up proposed text for issue #4720 (Clarify
      ::selection background-color in presence of fill/stroke)
      creating a keyword so that the UA can set that keyword and it's
      only used if both color and background-color compute to the

CSS Sizing

  - RESOLVED: Syntax order is physical for intrinsic-size (Issue
              #4531: intrinsic-size lost the thread)
  - RESOLVED: Switch initial keyword [of intrinsic-size] from 'none'
              to 'auto'

CSS Color

  - RESOLVED: Add clarifying text that all system values are
              reflecting the browser settings (Issue #4533: Clarify to
              what extent new system color are about system settings
              versus browser settings)

CSS Color Adjust

  - RESOLVED: Accept proposed definition [do not apply forced colors
              to SVG <text>, and only apply forced-color-adjust: auto;
              to <foreignObject> SVG elements.] (Issue #3855: Define
              what happens to SVG in forced colors mode)


Agenda: https://lists.w3.org/Archives/Public/www-style/2020Feb/0004.html

  Rossen Atanassov
  Tab Atkins
  David Baron
  Amelia Bellamy-Royds
  Christian Biesinger
  Oriol Brufau
  Tantek Çelik
  Emilio Cobos Álvarez
  Elika Etemad
  Simon Fraser
  Megan Gardner
  Chris Harrelson
  Daniel Holbert
  Dael Jackson
  Brian Kardell
  Daniel Libby
  Chris Lilley
  Peter Linss
  Florian Rivoal
  Christopher Schmitt
  Jen Simmons

Scribe: dael

CSS Device Adaptation

Remove @viewport
  github: https://github.com/w3c/csswg-drafts/issues/4766

  smfr: Since @viewport hasn't traction on shipping browsers I propose
        we remove and just specify the metatag which has wide support
  TabAtkins: Support
  florian: Yeah, I'm editor. I like @viewport but I can't disagree. It
           doesn't have traction

  florian: Related; we resolved to define the viewports and CSSOM View
           as the host. If device adaptation doesn't contain @viewport
           this is a good host for them. Should we move?
  smfr: Don't agree because spec of layout and visual viewports is
        about layout, not about adapting to devices. That's why I
        think I would like it elsewhere. This is right for tap
        highlight color or things only for devices.
  florian: Why I'm not happy with them in CSSOM View is not all things
           care about viewports have OM. Where else it should live,
           this felt okay. I can live with elsewhere. I don't feel OM
           view is a better home
  smfr: I think OM View is a bad name for a spec.
  fantasai: I agree with them in device adaptation. Less convinced
            with things that are touch specific. It's fundamental to a
            lot of devices and I think it goes in UI. But I agree with
            dropping @viewport and shifting meta viewport into device
  florian: If device adaptation name is the problem we can retire as a
           note and have a new spec called viewports
  smfr: That would be fine. If layout and viewport is moved to another
        spec I should be editor on that.
  smfr: Layout and visual viewport will tie into scrolling and
        coordinate system for getBoundingClientRect. That's why I
        think more closely with OM View
  florian: A bunch need to refer to them but that's not defining what
           they are

  Rossen: We are moving away from original topic. Given that we don't
          have layout and viewports spec yet we can decide where to
          host once we have spec text closer.
  Rossen: Back to original proposal to remove @viewport. I didn't hear
          any challenges and I hear support.
  Rossen: Objections to removing @viewport?
  florian: Don't object. Suggest we retire spec
  smfr: Need live spec for meta viewport
  florian: Yeah, call it viewport spec

  tantek: Drop is from lack of implementor interest?
  many: Yes
  florian: Proposed by Opera, adopted by MS, and then both companies
           switched to engines that lack that feature and Google had
  Rossen: And we didn't have any use of it. Adding it didn't add to
          capabilities we had. No one has asked for it after we
          decided to move on to Blink platform
  <tantek> Gecko BTW: https://bugzilla.mozilla.org/show_bug.cgi?id=747754
  tantek: Checking Mozilla bug ^
  Rossen: tantek are you trying to push back on resolution?
  tantek: I read the GitHub and hearing reasoning from absence of
          evidence. I wanted to site relevant Gecko bugs and I guess
  florian: Google has objected to it
  tantek: I didn't see that in the bug. It wasn't linked. That's a
          strong claim so I'd like a link
  <smfr> https://github.com/w3c/csswg-drafts/issues/258
  smfr: There's a link to ^ from Google saying @viewport is loader
  florian: That's the one
  tantek: They think it's bad idea
  smfr: And WebKit agrees
  tantek: So it's bad design not neglect?
  florian: Both.
  tantek: Can't be both.
  Rossen: Let's try to resolve on this. tantek do you object to the
          resolution? If you object let's record it and move on.
  tantek: I can't find a reason to object

  <dbaron> I'm not sure what I think about the objection of being
           preloader-hostile -- I think many good features may not fit
           nicely with preloading but that doesn't mean we shouldn't
           do them for other reasons.

  RESOLVED: Remove @viewport, retire the spec, move the meta tag to a
            new spec (CSS Viewport)

  florian: And make smfr an editor of that
  smfr: Okay with that
  smfr: Also okay with layout and visual viewports being in this new
  Rossen: Proposal: Move layout visual viewport spec into CSS Viewport

  RESOLVED: Move layout visual viewport spec into CSS Viewport spec

  smfr: Should it be Viewport or Viewports?
  <smfr> “viewport” or “viewports”?
  TabAtkins: Prefer singular. Maybe only have one plural in backgrounds
  smfr: Fine
  <fantasai> +1 to css-viewport
  Rossen: Let's stick singular for now

CSS Contain

It should be clearer that size containment inhibits effects of
    contents on intrinsic sizes
  github: https://github.com/w3c/csswg-drafts/issues/4741

  dbaron: I don't think this is controversial but it seemed to me it
          should be implied by size containment it doesn't impact
          intrinsic size in addition to final computed size
  dbaron: Ran into this while writing something that referenced size
  florian: Agree it was the intent. Proposed rephrasing is in the
           issue to clarify. dbaron said he was fine.
  florian: [reads original sentence]
  florian: Would insert including when computed as intrinsic size.
           Suggest we add to L2. Clarification so I'll probably edit
           it into L1 too.
  Rossen: Proposed resolution?
  florian: Accept propose as phrased in comment
  Rossen: Objections?

  RESOLVED: Accept proposal as phrased in comment from florian

  fantasai: Republish a REC?
  florian: Rather not, not worth process hassle
  florian: Happy to update ED so if we do need to update REC it's
           folded in
  Rossen: fantasai do you feel strong to republish?
  fantasai: Not super strong. Want to keep things in sync but this is
  fantasai: I do want us...if something doesn't effect sizing it
            should mean any type of sizing. I don't think
            clarification is a problem but I think problem if "Size"
            doesn't include "intrinsic size"

CSS Pseudo Elements

Clarify ::selection background-color in presence of fill/stroke
  github: https://github.com/w3c/csswg-drafts/issues/4720

  fantasai: I don't have proposed change, it's a question. Special
            rule that says if either color or background-color is set
            on selection then UA default colors for both are not used
            and we use initial value for not set property
  fantasai: What if author sets fill or stroke, should that remove the
            UA default color and background-color or is that part of
            properties that nulls UA rule or applied in addition to UA
  dbaron: Why do we have that behavior in the first place?
  dbaron: We remove the UA rules?
  fantasai: Yes and I'm pretty sure that's required for web compat.
            Haven't tested, but implemented in all browsers that way
  tantek: Don't know how to evaluate without tests
  fantasai: No one implements fill or stroke right now
  tantek: Test for existing behavior so we can understand effect and
          what desired/undesired would be
  fantasai: Will make a test case
  <fantasai> http://software.hixie.ch/utilities/js/live-dom-viewer/?%3C!DOCTYPE%20html%3E%0A%3Cstyle%3E%0Aspan%3A%3Aselection%20%7B%20color%3A%20blue%3B%20%7D%0A%3C%2Fstyle%3E%0A%0A%3Cp%3ETest%20%3Cspan%3Ethis%3C%2Fspan%3E
  <fantasai> testcase ^
  <fantasai> demonstrates that setting 'color' removes background-color
  <emilio> fantasai: I'm pretty sure browser behavior is _any_
           property removes background-color
  <fantasai> emilio, yes, but I don't think that's a web-compat
             requirement, and I think it's reasonable that e.g. adding
             text-decoration doesn't remove colors

  dbaron: Seems like this behavior is kind of silly and removes
          possibility of using one of the colors. Maybe not silly.
          What's trade off between preventing things authors would
          like to do but can't so with this rule vs the fact that spec
          one color but not the other will break when defaults aren't
  florian: More that case

  Rossen: Clarifying question- if what you're proposing is adopted if
          I set a stroke or fill are you suggesting selection
          background will be discontinuous?
  fantasai: Transparent, yes
  Rossen: That on its own is questionable
  florian: If you set stroke and color and color-background you get
           intended. If only set stroke you expect the rest to be set
           to something

  emilio: I'm pretty sure browser behavior is as soon as have a
          selection pseudo element then you apply UA colors. You put
          anything in and browser suppresses default colors
  fantasai: I don't think that's good
  emilio: But it's current. Agree not great. May not be great
  Megan: Do we know why this is there in the first place?
  emilio: Once you get to rendering you only have computed style.
          Gecko can in theory do it, but it's easier saying does
          pseudo match any rule vs saying did the author specifically
          set this color which could be same as UA color
  <Rossen> What about the use case for

  <AmeliaBR> Test case for SVG:
  AmeliaBR: There was statement earlier that we can't test browser
            because they don't impl fill and stroke. Not true with
            SVG. We have existing use. Made a quick test. In Chrome if
            you set a fill color in a selection for SVG text it
            doesn't draw default selection background. Have to look at
            other browsers to see if consistent
  florian: True in FF
  ??: Have looked in Safari
  AmeliaBR: If we want to keep it's another question. In SVG have no
            way for author to define background-color for selection.
            Don't have a property that's span background-color.
  AmeliaBR: Either way selection styling is limited in SVG. It's
            something to think of.
  smfr: These examples show what emilio stated. UA assumes author
        knows what they're doing and provides style to make selection
        look okay.

  florian: We can keep spec as is and increase scope. Or we say if you
           have a selection pseudo things change
  emilio: I'm pretty sure it's consistent behavior except blink and
          webkit don't handle empty decoration blocks.
  florian: Empty because syntax or just empty
  emilio: Just empty. Discarded with unknown property. If declaration
          top line is 0. I think it's styling optimization doing
  florian: If it discards unknown syntax that's annoying
  emilio: I think that's a bug.
  Rossen: Implementation issues aside. I think a guiding principle
          should be whatever behavior we land on can't break user
          expected behavior of visual selection
  Rossen: I think one of the challenges is if I accidentally create an
          empty selector I'm breaking the user expected behavior. That
          sounds like a counter-argument to have the behavior
          currently proposed.
  Rossen: From there if this is obviously not the case main question
          is how smart should this rule behave and how are these
          interdependent properties are supposed to behave. One is put
          it in the hands of the author and trust or provide safe
          defaults in browser to guaranteed expected behavior. That's
          the top level fork

  fantasai: For as long as selection only accepted background-color
            and color it made sense if you choose one or the other you
            drop UA selection color because it could be any random
            color and you want to know the contrast. That does have
            utility in that author can't assume and if they set color
            can't predict background-color
  fantasai: As we extend selection to allow for more properties should
            I add a text decoration in that rule some browser it will
            have effect and in some it won't because not impl. but it
            will blow out existing color so browser without support
            will have no indication of what's happening.
  fantasai: That's bad for the user and we don't get benefit from
            dropping colors when adding text decoration
  <AmeliaBR> What fantasai is describing is exactly what happens with
             my SVG test in Firefox: you don't get the
             author-specified selection fill color, but you also don't
             get the browser default selection styles.
  fantasai: From PoV that we're adding more properties any property
            blowing out the colors is a problem for transition
            especially as transition could be continuous as we add
            more properties. Indefinite period of transition and any
            property will blow out color in browsers that don't
            support it.
  fantasai: Would be best for us to not have any property blow out all
            the colors behavior. I don't think it's good. Given
            current behavior and contrast concerns having that
            behavior for background-color and color we can't and
            shouldn't change.
  fantasai: fill and stroke have same contrast concerns so should fall
            in same bucket. If you set any of those 4 you drop, any
            other property does not
  <florian> +1
  emilio: I kinda agree with Rossen that current is sometimes
          undecided. These 4 properties disable and rest do not seems
          weird to me. Can we add a note to spec say UA should ensure
          selection has visible effect?
  emilio: Not sure. 4 properties that disable not sure it's the best.
          Maybe it is.
  fantasai: There's 2 reasons why background-color and color reset
            should be kept. One is that if author sets
            background-color they make assumptions about text color of
            selection and that might be incorrect on another platform.
            If you're not testing all platforms you can get bad
  fantasai: Second is this is current behavior so if people are
            setting it's with background-color and color. not sure if
            anyone is depending on not setting these. If they are
            might be depending on fact that setting background-color
            causes reset
  emilio: Setting background-color should retain inherited color. Not
          sure that contradicts my proposal to ensure there's enough
          contrast. I think some UA restrict transparency.
  emilio: I agree we can't break that case of just changing background

  plinss: Opportunity to instead of magic where one property blows out
          another can we have a value UA can set that has that
  plinss: That way UA can set magic value for color and
          background-color and then setting values acts normally.
  AmeliaBR: Logic would be UA says `color: selection-style;
            background-color: selection-style` but rule is you only
            use them if both values compute to the keyword and
            otherwise go back to inherit. Is that what?
  plinss: Something like that. not exact mechanics. I want not having
          magic behavior, just magic in value of property
  florian: Have similar in text decor. Value of text-decoration-line
           that's supposed to be used on ::spelling-error has a value
           of spelling-error.
  plinss: The UA stylesheet says selection color something like
          selection color. Behavior is normal as far as web property
          is defined. Make sense?
  fantasai: Yes.

  Rossen: Should we put this back to issue and work out details later?
  Rossen: Once proposed magic is baked enough we bring it back for
  fantasai: I think that works. I'll try and draft plinss suggestion
            as AmeliaBR described and see if that's acceptable
  Rossen: Sounds great. Adding guiding principles of expected behavior
          would be good.

  [agenda wrangling]

CSS Sizing

intrinsic-size lost the thread
  github: https://github.com/w3c/csswg-drafts/issues/4531

  TabAtkins: Whether intrinsic-size should order sizes in logical or
             physical. I objected to physical ordering on idea that
             we've been doing logical lately. fantasai leaned
             physical. I went through list of css properties that take
             2 lengths and categorized
  <TabAtkins> https://github.com/w3c/csswg-drafts/issues/4531#issuecomment-585321048
  TabAtkins: List ^
  TabAtkins: Pattern is clear. There are 4 properties that are logical
             and they're all specs fantasai and I have done in last
             few years. All others are physical. More physical then
  TabAtkins: Unhappy about overall split but if fantasai is thinking
             we should stick with physical I think data agrees and we
             should switch to physical where we can
  fantasai: Agree with conclusion, though not all details leading to
            it. Useful to switch to logical for layout. Block first
            was a mistake. I think size property close align to
            properties that background size that are physical. All box
            sizing is physical. So this should fall into that category
  TabAtkins: List is split between offset and sizes. Properties that
             are background like agree so let's do it. Size is
  Rossen: Last time we called for objections you were the only one.
          Objections now?
  AmeliaBR: What's the resolution?
  TabAtkins: Syntax order is physical for intrinsic size
  Rossen: width and height

  RESOLVED: Syntax order is physical for intrinsic-size

  cbiesinger: One other thing, I think we need initial value as a
              keyword that is auto. Thoughts on that?
  florian: Agree
  fantasai: Why need?
  cbiesinger: Because 0 isn't always the default. If have flexbox with
              gaps initial value would take gaps into account so 0
              can't be initial
  fantasai: How if don't know number of items?
  florian: Hard coded quantity of columns
  TabAtkins: To clarify, initial value that's a keyword is decided
             with examples. Question is if keyword name should be
             'auto' or 'none'. I think spec is 'none' but fine to
             switch to 'auto'
  AmeliaBR: Agree 'auto' is better because 'none' is easy to confuse
            with 0
  cbiesinger: Agree
  <fantasai> +1 to Amelia's reasoning
  Rossen: Objections to switching initial keyword from 'none' to

  RESOLVED: Switch initial keyword from 'none' to 'auto'

CSS Color

Clarify to what extent new system color are about system settings
    versus browser settings
  github: https://github.com/w3c/csswg-drafts/issues/4533

  dbaron: To some degree a question. Might help to get it sorted out
          for us to implement. A bunch of new system color keywords in
          Colors 4. One thing unusual is they're both and OS and a
          browser setting and may be different
  dbaron: Are these about getting browser or OS setting?
  fantasai: Browser setting
  TabAtkins: Agree
  fantasai: It should default to match OS but if user sets different
            we should honor
  AmeliaBR: Should always be about respecting user preference. If set
            something specific in browser it should override the OS.
  Rossen: From tooling you should be able to allow the dev tools to
          change and override system colors and they see fit so
          authors can play.
  Rossen: Browser has the right to override the system color. Author
          running code should never see system except through lens of
  Rossen: Back to issue; dbaron does that answer your question?
  dbaron: It does. That was my preference.
  dbaron: Good to get it written so can land patches
  Rossen: Do you propose clarify in spec?
  dbaron: I think it should yes
  Rossen: Objections to adding clarifying text that all system values
          are reflecting the browser settings

  RESOLVED: Add clarifying text that all system values are reflecting
            the browser settings

CSS Color Adjust

Define what happens to SVG in forced colors mode
  github: https://github.com/w3c/csswg-drafts/issues/3855

  Rossen: I can introduce this
  Rossen: This issue defined how forced colors are supposed to effect
          SVG. Previous resolution was that forced colors should apply
          to text element and foreign object element. Foreign object
          makes sense because switching to HTML and all forced color
          rules apply
  Rossen: Additional complication and proposed change is what seemed
          reasonable to expect text element effected by force colors
          but in effect when text gets forced color applied in
          addition a background plate should be rendered so overall
          contrast ratio is as defined through system. This proved to
          be ineffective and counter intuitive for SVG
  Rossen: A few cases where this might make sense but in general since
          no SVG elements except these are effected by forced colors
          overall effect becomes incongruent. Proposing to revert
          including font
  Rossen: Computing backplate on a path is hard to define and
          detrimental. You either get bounding box is is more then
          necessary or you do per glyph which is bad
  Rossen: Proposal: exclude text elements of svg from being effected
          by force colors
  chris: Agree, makes most sense
  AmeliaBR: sgtm

  AmeliaBR: Example in spec may be useful about using MQ to make SVG
            work with high contrast. Default it's best not to try and
            do too much
  AmeliaBR: Do we need to call out foreign object or do colors
            naturally apply to content inside? Do we need to add
            colors to the foreign object itself or enough content
            inside has the rules if it's html
  fantasai: We should set force color adjust none on SVG root and
            switch to auto on foreign object
  <AmeliaBR> +1 to fantasai's solution
  <fantasai> which is what's posted in the issue at
  chris: agree [missed]
  chris: You don't want color value set outside inheriting in. Need to
         be explicitly set on foreign object
  Rossen: That's the impl we landed on. +1 to fantasai
  Rossen: Other suggestions or objections for that resolution?

  RESOLVED: Accept proposed definition

  Rossen: Please engage on GH with remaining issues. We'll prioritize
          these items for next call

Received on Thursday, 13 February 2020 00:31:04 UTC