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

[CSSWG] Minutes San Francisco F2F 2019-02-26 Part V: CSS Navigation, CSS UI, CSS Text 3 [css-nav] [css-ui] [css-text-3]

From: Dael Jackson <daelcss@gmail.com>
Date: Thu, 4 Apr 2019 19:08:08 -0400
Message-ID: <CADhPm3s_5hmM2fmQqW3NBa_wdoMHeAbpf5hZV=kqW+WFQW2Mbw@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.

CSS Navigation

  - RESOLVED: Drop navbeforescroll and add `spatial-navigation-action`
              with at least two values (Issue #3401: changing the
              spatnav scroll controls from JS to declarative)
  - RESOLVED: Publish FPWD of css-nav
  - Feedback was requested on the proposal in issue #3384 (Improve the
      distance function)

CSS UI (continued)

  - The group discussed some of the possible permutations and future
      use cases centering around dark mode as a part of issue #3299
      (Add a way for authors to indicate that they want dark-mode form
      controls etc)
  - One proposal was a <meta> tag rather than a CSS mechanism,
      in order to avoid flashes of the wrong background color
      if painting is triggered before the relevant CSS loads;
      another proposal was a CSS property, which would allow
      control of dark mode at a subtree level. A possibility
      would be to combine both approaches, with the CSS property
      overriding the <meta> tag.
  - This raised the general issue of better controls for handling
      flash-of-unstyled-content problems in general.
  - There was some discussion about distinguishing "user requests
      dark mode" vs "user is forcing dark mode" and "website
      supports dark mode if requested" vs "website is always dark",
      and various combinations thereof.
      - There was skeptisism about forcing dark mode on sites
          that are unprepared. This type of forced change should be
          looked at in an a11y context.
      - There was some concern about compat if dark mode controls
          are used on sites expecting light mode, since sometimes
          they will set the foreground color but not the background
          or vice versa.
  - Rossen pointed out that dark mode is applied in layers--OS
      UI, application UI, application content. Whether to match
      the outer layer is chosen on a case-by-case basis, not
      always unilaterally imposed.
  - There was discussion about how dark mode would impact the UA
      style sheet, ::selection rules, and system colors. The spec
      for system colors may need revisiting to make sure relevant
      values exist and are specced appropriately.
  - Discussion is expected to continue on this topic.

CSS Text 3

  - RESOLVED: Add word-break:break-word to text level 3, with a note


Agenda: https://wiki.csswg.org/planning/sf-2019

Scribe: emilio

CSS Navigation

Drop navbeforescroll
  github: https://github.com/w3c/csswg-drafts/issues/3401

  jihye: We have three events, navbeforescroll triggers when there's
         no visible focusable element in the scroll container
  jihye: It has some perf issues so we want to drop it, but there are
         some use cases like moving the focus directly using arrow
         keys or focusing the non-visible content in the scroll
  <jihye> https://raw.githack.com/jihyerish/spatial-navigation/spatnav-behavior/demo/scroller/index.html
  jihye: So we'd like to propose a new CSS property,
         spatial-navigation-behavior, see ^ for demo
  jihye: This property is aimed to split scrolling and moving the
         focus behavior, to avoid scroll latency
  jihye: and it helps to implement the use-cases like infinite
  <jihye> https://raw.githack.com/jihyerish/spatial-navigation/spatnav-behavior/demo/infinite-scroller/index.html
  jihye: We have to decide exact naming and values, and I wanted to
         gather opinion about whether the new property is reasonable

  eae: I think it's a very good idea, and it helps to avoid preventing
       composited scrolling, so I'm very happy to see you're moving in
       this direction
  florian: Initially we wanted to go with events only rather than
           declarative syntax, so people could experiment
  florian: but given the only use-case for this event can be done
           declaratively, and it solves the perf issue that concerned
           google, it sounds like a good idea
  eae: Yeah, thanks for coming up with that proposal

  florian: We've iterated quite a bit on naming, last proposal is
           spatial-navigation-action: auto / focus / scroll
  florian: Normal behavior is a combination of focus and scroll
  florian: If you use focus, it'll just jumps across focusable elements
  florian: instead of scrolling step by step, like auto
  florian: Scroll is the opposite, it will just scroll it and skip
           focusable elements inside
  florian: So for example if you have a focusable scroller with
           focusable things in it, in which you're not strongly
           interested (like a twitter feed in the page), you could use
           the scroll value to avoid going into focusing the
           descendants until you focus one of them
  florian: We didn't feel strongly that we needed `scroll`, but having
           it now helps the bike-shedding for names and such
  astearns: Would it make sense to have three values with scroll noted
            like "maybe dropped"
  jihye: Maybe just add it later
  astearns: Since the value helped you, maybe better either leaving it
            out and noting that it might be added, or the opposite
  florian: If somebody finds a better name, then even better

  bkardell: So currently this demo works setting some DOM properties?
  jihye: I showed two demos, which one?
  bkardell: Let's take spatial-navigation-action? Is it just using a
            dom property in the demo?
  florian: The demo uses a polyfill
  bkardell: I was wondering how it was implemented, custom props?
  jihye: Yeah, it's a custom property

  RESOLVED: Drop navbeforescroll and add `spatial-navigation-action`
            with at least two values


  astearns: There are any other implementors interested in this spec?
  florian: Other than google?
  astearns: Yeah, we have google and polyfill, but no more implementor
  smfr: Webkit has an implementation but it's not maintained. It was
        contributed by an external contributor
  bkardell: So, when we met at TPAC, florian did mention that vivaldi
            wanted to ship the polyfill?
  florian: That's right, we've talked with them about replacing their
           implementation with jihye's polyfill
  bkardell: Yeah, I don't think it counts as an implementation but we
            can get feedback
  astearns: I think a shipping polyfill we can write tests against is
  emilio: But you can't test syntax or other implementation details
          with that
  bkardell: Yeah, didn't mean implementation for any official thing,
            but it's useful to have the feedback, so we're looking to
            get more good users and getting dev feedback
  <xfq> https://www.npmjs.com/package/spatial-navigation-polyfill
  jihye: This polyfill is in npm and I plan to keep maintaining it so
         we can get some feedback from devs
  myles: WebKit's implementation is fully incompatible with this spec,
         and it's pretty old. We are interested in updating it to match
         this spec, but it's pretty low priority

  astearns: comments? objections?

  RESOLVED: Publish FPWD of css-nav

  <xfq> \o/

Distance function
  github: https://github.com/w3c/csswg-drafts/issues/3384

  jihye: I've been working on improving the distance function to move
         focus to the correct next target.
  jihye: If you have any opinions it'd be useful, and I think it's the
         biggest issue
  florian: This is the heuristic part of the model, to guess which
           element is the right next target to move focus too
  florian: jihye has done a lot of great work on that, which is
           strictly better than what's on the spec
  florian: I think we could get some other round with UX and what not,
           but we should probably roll it in and try to get it into
           the spec
  <hyojin> you can see the result of the distance function experiment
           by Jihye at

  AmeliaBR: Does the geometric calculation really need to be specified?
  AmeliaBR: Do any other thing depend on the result of the function?
  florian: Not other properties, but we don't want a magical perfect
           heuristic, just a good enough heuristic where authors can
           take controls if the heuristic goes wrong
  florian: Which is what has happened in the TV world

  Scribe: heycam

Dark mode
  github: https://github.com/w3c/csswg-drafts/issues/3299

  futhark: Chrome is soon shipping dark mode for the UI of the browser
  futhark: respecting the dark mode setting of the OS
  futhark: but we also want to render the pages dark
  futhark: so the MQs 5 has prefers-color-scheme
  futhark: letting the authors follow the setting the user has
  futhark: But in order to render the content dark for all pages from
           day 1
  futhark: we're looking at a UA intervention that automatically
           darkens the web pages
  futhark: but giving the author the possibility to opt out of that
  futhark: and we have looked at a <meta> element that Apple has
           already implemented
  futhark: What it does is that you can specify which color schemes
           the page can respond to using MQs
  futhark: and apply a UA style sheet which renders form controls
           dark, having a lighter foreground color, using a black
           canvas backdrop
  futhark: This is basically what safari does
  futhark: The proposal here is that we do this with a <meta> element
  emilio: Also the CSS property?
  futhark: The CSS property I haven't mentioned yet
  futhark: There's the possibility for the page saying that parts of
           the page are styled itself, but also the possibility to do
           automatic darkening of other parts of the page
  futhark: We get this request for various Google products
  futhark: where they want to handle some UI parts themselves in dark
  futhark: but automatically darken some content

  smfr: We have to distinguish between auto darkening, which is
        clobbering what the author's done
  smfr: and this thing, which allows the author to tell us they've
        thought about dark mode
  smfr: For us this is just changing form controls, selection, ...
  smfr: An auto darkifying thing is maybe orthogonal to this

  futhark: What we've been thinking about is that the <meta> element
           at the same time it says it wants the dark UA style, it
           would also opt out of the auto darkening
  futhark: because it knows how to render dark pages
  futhark: When the author has a <meta> saying it knows how to render
           this page in a dark color scheme, please opt out of auto
  futhark: One of the reasons we've been thinking about <meta> is that
           we don't want any flash of white background
  futhark: so having it available early

  dbaron: I agree with a bunch of what Simon said
  dbaron: There's a long standing problem we've had which is that when
          we use native form controls and certain things like that, if
          the user has a dark theme, those don't work with some pages
  dbaron: e.g. text input is a common one. If the text input has a
          dark background with a light text color, and the author
          overrides only one of bg/fg, it's broken
  dbaron: as a result we've done work to prevent dark native themes to
          get through to web content
  dbaron: Some recent Gtk changes broke this
  dbaron: so I think there are a few separate problems here
  dbaron: One is the fact that because of these dark theme options in
          macOS, Windows 10, etc., more users have dark themes
  dbaron: and in a lot of web content that doesn't work, even if they
          want it to work
  dbaron: but we can't just go apply it to web content unless we know
          it will work with that
  futhark: That's why we want to rely on the meta element to have the
           page tell us it's ok
  dbaron: I think a meta that says "I the page author have thought
          about this and I know that my page will work with a dark
          theme" is a good thing
  dbaron: I think UAs could use it for different things
  dbaron: One could use it to say "the user has a dark theme, so I
          will let dark theme data theme, and use the user's preferred
          form controls for this page"
  dbaron: or the UA could say "for pages that haven't done this, do
          auto darkening"
  dbaron: and a meta that says "I support dark theme" serves both of
          those purposes but not completely
  dbaron: If the user wants the entire thing to be dark, working with
          dark form controls doesn't imply that their whole UI is dark
  dbaron: so they still might want the auto darkening in that case
  dbaron: Another thing in here I don't like. It also allows authors
          to say that their page doesn't work with light pages
  dbaron: and I'd rather not create this problem
  futhark: The only keyword?
  dbaron: You can say supported schemes "dark", and skip light
  dbaron: In the spirit of trying to do more of what the user wants,
          where right now users want to see things in dark mode, I'm
          hesitant to give authors an option to say this page doesn't
          work in light mode
  dbaron: For users who want that
  futhark: There's also the "only" keyword that Safari implements
  furthark: Don't you have to say "dark only"?
  smfr: [nods]
  futhark: If you have a light theme and say "dark only" in the meta
           tag, you get the authored dark page
  dholbert: And widgets are dark?
  smfr: Primarily widgets

  fremy: I am very curious about how you're going to enforce dark
         themes on pages that aren't prepared
  fremy: I'm skeptical people will like that
  fremy: You'll end up with images that look wrong etc.
  fremy: For a11y purposes it's a fair tradeoff
  fremy: but I am very unsure that people going to bing.com that
         doesn't support dark theme now the links aren't visible
  <fantasai> +1 to fremy
  futhark: Auto darkening is not something we'd like to spec
  fremy: On the other hand, replying to david, I don't see why you'd
         want dark only
  fremy: In VS Code, a web app, it has dark menus
  fremy: It makes sense for them to say "dark only"
  fremy: They want to control all their app UI
  fremy: If you're talking about wikipedia, they should probably not
         say "dark only", but I don't think they will do that
  fremy: Maybe for a powerpoint thing, if the author has thought about
         it, why prevent it?
  dbaron: One of my worries about this stuff is that not all browsers
          will be able to do all of these things
  dbaron: If we want web pages to be able to say "dark only", the
          browsers need a native set of light and dark controls
  dbaron: which on some platforms is not realistic
  fremy: You can always have a normal styled fallback for form controls

  florian: That's the difference between “I prefer dark” and “I support
           dark only”
  florian: If you don't have dark controls, and your OS doesn't have
           them -- that's different from saying "if you show light
           controls I will be broken"
  florian: We shouldn't have that
  florian: Why create that category?
  florian: There are some that would look better with dark controls
  fremy: VS Code only has dark controls
  fremy: Why do they custom style everything? because they can't get
         dark controls
  fremy: I think what you're saying exists today
  fremy: but the web page custom styles every single thing
  florian: If the OS doesn't support dark controls?
  fremy: You fall back, just like when you put borders on form controls
  florian: So VS Code will still need to hand code their dark
           controls, since they can't handle that some OSes will fall
  fremy: Today the light controls have this fallback today
  fremy: if you have a button border-radius:3px, you get the fallback
  fremy: and you can do this same fallback for the dark one

  dbaron: I think there is a tradeoff here. Some sites that want to
          own things so much they will replace the native controls
  dbaron: There's a tradeoff between that and having sites where the
          controls are more recognizable as such to users
  dbaron: and the users recognize the thing over there is an input
  dbaron: That's a tradeoff
  dbaron: There's an advantage to controls that look native
  dbaron: esp for less experienced users
  dbaron: If we offer more ability to change what the controls look
          like, we will pull some designers away from replacing
  dbaron: but we will also push some users into things that are less
          recognizable for them
  dbaron: There's no one answer is more correct 100%

  florian: afaict, the property here, whether it has a bunch of
           properties or auto vs i-support-dark, does the same thing
           at the meta tag? Just at a subtree granularity
  florian: Whether or not you support dark theme depends on the style
           sheet, so it belongs in the style sheet rather than meta tag
  florian: I know I will not get full agreement on that
  gregwhitworth: For end user experience reasons
  florian: But it could become wrong when you update the style sheet
           and forget to update the meta
  gregwhitworth: bad author
  <tantek> Why just meta tag? Why not an HTTP header?
  florian: If you have a page that claims to support dark mode, the
           author sheet does support dark mode, but user sheet doesn't
           -- how to tell the page?
  futhark: The property wins

  AmeliaBR: I'm a bit uncomfortable doing style theming in the meta
            tag because you might have all sorts of flexible themings
            based on user prefs based on your own thing
  AmeliaBR: but as long as the style property overrides the meta tag,
            that's ok
  AmeliaBR: but then I'm not sure why the meta tag is necessary
  AmeliaBR: If the style sheets don't load, I'm assuming the browser
            can apply whichever one
  futhark: If you parse the meta tag, you can apply the black canvas
           pretty early
  fremy: It's about flashing
  AmeliaBR: Is there any reason to do the flashing? If the style
            sheets haven't loaded can't you have a default bg that is
            according to the default theme?
  smfr: Every wikipedia page will flash
  AmeliaBR: ok that's the point of the meta tag, for the default
            backdrop before style sheets load
  fantasai: Use bgcolor on body? :)
  fantasai: I totally agree this is not something that belongs in the
            HTML layer if possible
  fantasai: if you want to put it there, we have bgcolor
  fantasai: The best thing there is you can solve that for any
            background color, not just black
  AmeliaBR: Not necessarily because what if the style sheet has a MQ
            switch based on user preference
  fantasai: Then it will override, but that's better
  AmeliaBR: You can indicate which themes you support
  fremy: bgcolor can only supply black, not "which theme the author
  fantasai: You're only doing this for white or black -- is this a big
  TabAtkins: If I'm looking at dark screens in bed, I don't want a big
             flash of white
  AmeliaBR: Why would wikipedia put a meta tag saying "dark only"?
  florian: They won't have the tag, so you know it's a light site, but
           you can still show dark until it shows up
  [wikipedia just as an example here]

  AmeliaBR: my other point, repeating some of fremy, if there's any
            discussion about auto applying styles without author opt
            in, that should be discussed in the context of accessible
            color schemes, high contrast mode, think of it that way
  AmeliaBR: When you're overriding author styles it's an a11y feature
  AmeliaBR: but that's separate from trying to match user preferences
  AmeliaBR: For matching user prefs, I like the idea of making it
            easier for authors to say this site supports a dark theme,
            draw default styles for select boxes, if you have one, or
            saying my styles work well whether you use light or dark
            whichever the user prefers
  AmeliaBR: There are sites that are dark that require custom styling
            for form controls now, so I like the easy way to opt in to
            native dark mode styles
  <fantasai> +1

  AmeliaBR: We kind of have multiple themes now in browsers
  AmeliaBR: The "legacy" widget themes, if you muck around with styles
  AmeliaBR: Then we have the modern native look buttons in light or
            dark theme
  AmeliaBR: I don't know how is the way the property is currently
           specced going to interact with that?
  AmeliaBR: When you revert to the legacy styles
  futhark: I don't have an answer for that

  AmeliaBR: If you use this property are you saying "use the native UI
            look no matter what other styles I put on the element?"
  smfr: Still has these fallback interactions
  AmeliaBR: So if I wanted styles that say use native dark mode, but
            if you don't support these new props, and if I want a
            custom styled dark inputs, you'll need @supports or
  AmeliaBR: Will @supports just look at syntax, don't say you support
            dark mode unless you have one to use
  AmeliaBR: but that would break an author request of dark or light
  AmeliaBR: so the keywords need to be recognized even if they don't
            have matching themes
  AmeliaBR: Can sites detect "do you have a native dark theme"?
  emilio: That's a fair request
  emilio: An author to see if the browser supports a native dark theme
          or not
  emilio: it feels to me that the auto darkening has a lot of
          potential to backfire
  <fantasai> +1 to emilio

  bdc: I think there are 2 different issues
  bdc: One is that it makes a lot of sense for a page to fit into its
  bdc: The other use case, which I disagree with, is fremy's example
       of "I'd prefer a dark theme for my app so I will just use theme
       by requesting dark controls"
  bdc: It's a design shortcut
  bdc: It's a different purpose IMO
  bdc: VS Code is not designing that because they don't have access to
       a dark mode
  bdc: They just design it that way
  bdc: To me it's a different use case
  bdc: to want to re-use a set of controls that are nicer to the
       designer's eye is different from fitting to the environment
  <florian> +1

  <fantasai> I would like to point out that Adobe Creative Suite uses
             dark mode for its UI, but the expectation is that content
             being edited is black-on-white, so it's not that you
             always want to match content to the OS "theme".
  <fantasai> Sometimes. Not always

  fremy: The #1 request we got for controls in Edge is sites wanted
         dark scrollbars
  fremy: We don't want to customize the scrollbar, we just want a dark
  fremy: When they do customize it, we get perf issues, etc.
  <smfr> https://drafts.csswg.org/css-scrollbars-1/#scrollbar-color
  <tantek> +1 same we get requests for dark scrollbars primarily
  fremy: That's the point of this prop, this area of the page is dark,
         it's a choice we made, but we want to play nice with native
  fremy: for better UX for users
  fremy: Also, let's say you have a blog engine, you want to support
         dark theme
  fremy: So you say the page supports light and dark
  fremy: An embedded component from another origin, it only supports
  fremy: you need to have a way to say this part of my webpage does
         not support dark theme, even though my site overall does
  fremy: This is the point of the property
  fremy: incorporating components from different sites, you might not
         want to give up your overall site dark theme
  fremy: The "dark only" value might not be useful...
  fremy: I have seen sites that just want a dark scrollbar
  fremy: And you need "light only" anyway

  AmeliaBR: Another example, you're concerned it's not respecting user
  AmeliaBR: for somethings I like a dark theme, but if I'm reading a
            lot, I can't read a lot of white text on black bg
  AmeliaBR: So I'm going to have different prefs for different sites
  AmeliaBR: Maybe browsers will one day allow me to set prefs on a per
            site basis
  AmeliaBR: but lots of sites have a way for the user to opt in to a
  AmeliaBR: so maybe when they're doing "light only" or "dark only",
            they're reflecting the user's preference in the site

  bdc: The way I would summarize is that letting the browser know that
       you are dark theme compatible is nice, a good citizen in this
  bdc: doing the opposite is being hostile to the env
  bdc: whatever you choose, I'm going to have dark, because I like it
  fremy: But you could have a theme inside the app
  AmeliaBR: We can encourage authors to make their sites theme flexible
  AmeliaBR: just like responsive sites
  AmeliaBR: but I don't think a dark only is any more hostile than
            saying background-color:black, etc.
  AmeliaBR: It's just one way for the author to opt in to a color
            scheme without setting everything themselves
  AmeliaBR: and making it a bit more native and familiar
  bdc: I see that, but it really depends on how many things in the UI
       that change
  bdc: e.g. at some point I think Edge had a title bar that matched
       the site header color
  bdc: Here you're forcing UI changes because use as an author prefer
  bdc: It might be pushy
  Rossen: We used to have a mode that when you pin a site to the
          taskbar or start menu and you want to use it exclusive in an
          app mode
  Rossen: We would do small things to match the page
  Rossen: That was the behavior we did
  bdc: This kind of thing can have an impact on the UI as a whole
  bdc: Who knows what the OS will do in the future
  bdc: so it could affect more things
  AmeliaBR: Good point but it sounds like it's outside the scope of CSS
  AmeliaBR: anything the browser/OS is doing to extract styles from
            the page and applying outside the page ...
  bdc: These properties and meta tags would do that no?
  florian: Just within the page
  AmeliaBR: The only thing outside what we can already style with CSS
            is styling the dark/light bg of the canvas
  bdc: The chrome of the browser could/should change based on that

  gregwhitworth: The way I would see this working in Edge, user turns
                 on dark mode, Edge would flip into dark mode,
                 devtools would too
  gregwhitworth: If you have the meta tag, it would flip to dark
                 controls too, if not, it wouldn't
  gregwhitworth: Is there an issue with that?
  bdc: Not with that
  bdc: but in the future making the assumption that if the site opts
       in that other UI is now dark, then I do
  dholbert: Alerts could be dark
  gregwhitworth: They're not controlled by you now anyway
  AmeliaBR: That's an issue on the browser team to decide whether to
            respond author or OS choices ...

  Rossen: The one thing to keep in mind is that at least in Windows,
          probably on macOS, we have three levels of where color
          schemes can apply
  Rossen: There's the shell, which is only controlled by the user
  Rossen: usually it doesn't propagate anywhere beside the shell
  Rossen: Then there are apps. Apps are going to depending on the UI
          framework they use, they may be either forced or opt in to a
          particular color theme
  Rossen: regardless of it it's dark or whatever
  Rossen: Then there's the content of these apps
  Rossen: Even besides browsers. Many other apps that have content
          that could benefit from theming
  Rossen: and there, it's the choice of the app on whether to
          propagate that information to the content
  Rossen: A quick survey of 1st party apps that ship with Windows or
          macOS, even there is some inconsistency
  Rossen: e.g. in Windows the shell is always dark, doesn't mean 1st
          party apps will always be dark
  Rossen: At the same time, in Edge, there's a user choice to change
          the UI to be dark mode only
  Rossen: Changing the UI of the browser alone doesn't fit with
          anything else if the shell is light
  Rossen: For these cases, to say that because I'm switching my app to
          be dark, I want everything else inside to be dark
  Rossen: Mail doesn't usually force content to be dark by default
  Rossen: Looking at macOS Mail, it seems this is only done for text
          only messages
  Rossen: Propagating this down to the site and allowing the site to
          say "yes I'm fine if you are going to change your UI,
          regardless where the change came from, I'm going to match it
          a bit better"
  Rossen: So I think the overall approach of this proposal doesn't
          seem crazy, it's just that how do we get to the point where
          the actual handshake between content and the app layer
          becomes as transparent/easy as possible
  Rossen: Most platforms today have these 3 tiers of color scheme
          propagation that, whether or not in this group agree, is

  futhark: One of the things I wanted to figure out is if a meta tag
           is the right way to do this
  futhark: The standardization of a meta tag typically doesn't happen
           in CSS
  Rossen: What are you optimizing for here? style sheet download, so
          that before you navigate you want the right theme applied
          without flashing?
  Rossen: If you're going from page to page on wikipedia, and let's
          say wikipedia had a dark mode, you don't each navigation
          flash to white
  Rossen: If we're ok with flashing, then meta tag or property or
          alternative style sheet would work
  smfr: We're not ok with flashing
  smfr: Asked one of our engineers about the meta tag proposal
  smfr: There are clients other than browsers, like mail client, it's
        useful for them to be able to parse the first part of the
        message without a css parser
  smfr: I think that's the primary reason
  <tantek> I'm curious if a <style> element would solve the flash or
  florian: I'm personally not enthusiastic about the meta tag, but I
           understand why you need it
  florian: and as long as you have the property, that's fine

  bdc: The only change you're contemplating is form controls, root
       viewport color
  futhark: foreground color, background color
  florian: Would this change the bg color of the selection?
  smfr: Yes
  florian: That's meant to be affected by a normal property on a
  smfr: Currently the selection color uses a system provided color
  smfr: but this will be overridden
  smfr: There's also spelling dots
  smfr: and the scrollbar color, even though we have a property for
        that now
  smfr: Links too
  jensimmons: Does it also include the colors in the UA sheet?
  hober: In practice we didn't have to, since it used named colors
  smfr: In KHTML there was a system color called "text"
  smfr: That value persisted to the present day
  smfr: Now we're using that in the UA sheet
  smfr: That becomes white when you use dark mode
  emilio: We should talk about, because all UAs probably use system
          colors for this
  emilio: Doesn't make sense to deprecate things that everyone is
          using them...

  dbaron: On system colors, I had a bunch of proposals
  dbaron: The current set is very Windows specific
  dbaron: You generally think there is a fg and bg pair
  dbaron: ButtonText / ButtonFace, HighlightText / Highlight
  dbaron: In that set, from the Windows API, seeing how the Windows UI
          used those, there were some non obvious pairs
  dbaron: There was a set of 4 colors, call them ABCD
  dbaron: it was confusing
  dbaron: In 2001..2003, I had a proposal for fixing this by adding
          another name for the other combinations
  dbaron: Rather than assuming this control always uses the fg color
          from this control and the bg color from that control
  dbaron: and Gecko implements a bunch of these behinds prefixes
  dbaron: Additional system colors so we can do sane things on
  dbaron: Dialog and Field
  dbaron: I would support working un-deprecating system colors given
          how much they're used, I had some proposals to fix them
  <dbaron> https://dbaron.org/css/test/sec1802 has some examples of
           how the system colors work -- part of the mess is that
           there are both single-border and double-border styles for
           raised buttons, which is why there are so many colors for
           the edges of buttons

  dbaron: I think it's possible that it might make sense to have 2
          different flags rather than 1
  dbaron: It might be that the aspect of what to do with native
          controls is different from what to do with default colors
  dbaron: So you may wish to say that my page supports either light or
          dark native controls, but I still want to leave the default
          colors light by default
  dbaron: Not fully thought through
  florian: I think that makes sense. Think of an existing dark today
           site, but was written dark with the assumption the UA sheet
           is light
  florian: and might rely on some things from there
  florian: even if they want to opt into dark controls
  emilio: But if you have no meta tag
  florian: You add the meta tag to use the dark controls
  emilio: Hopefully you then check the page!
  emilio: Presumably if you request dark theme, look at your page,
          notice that it has light text that looks broken ...
  florian: So don't ask for it and hack controls the old way?
  emilio: On one hand, I agree more configurability is nice. On the
          other hand, exploding the amount of combinations of themes
          and bits that you can tweak is also going to be a mess

  florian: The #1 statement before was dark form controls
  florian: not a dark UA style sheet
  florian: Why are we coupling the two?
  AmeliaBR: Is the disclosure on details a form control or just a
            style sheet thing? so many things
  florian: fremy earlier stated if you try auto darkening you will get
  florian: To me a dark UA sheet is a primitive form of that
  fremy: But if it's opt in they can fix it
  fremy: If they don't want to fix it that's up to them
  Rossen: Not having the foreground color matching form controls would
          be strange
  Rossen: let alone backgrounds

  AmeliaBR: I suspect in most cases the author is going to override
            most of the things that would be applied on non form
            controls, like on sites now
  AmeliaBR: but it seems nice to have the option to have a quick one
  AmeliaBR: Just write this web site in a light or dark whatever the
            user wants
  AmeliaBR: or write this section in a generic dark style because it's
            a chunk of text and we won't fuss on it too much
  florian: If the meta tag switches the UA sheet, does the property
           too? how do you switch the UA from light to dark on a
           subtree level?
  florian: If you have a meta dark, and this subtree light only, how
           do you apply things from the UA sheet in that subtree?
  Rossen: That's what we do for high contrast
  florian: You have selectors that depend on the value of a prop?
  fremy: The colors change
  florian: Change the UA sheet?
  fremy: We don't have a UA sheet for dark theme
  fremy: We switch a couple of colors
  AmeliaBR: But this would allow to opt in not just form controls, but
            also dark and the page will be light text on dark
            background, which is essentially the dark UA sheet
  AmeliaBR: Right now we just have appearance
  AmeliaBR: whether browser styles apply to that element
  AmeliaBR: but it's only for isolated replaced elements, not paras
  florian: If the only difference between light and dark UA sheets,
           and all differences are system colors, that's doable
  florian: if there is any difference, then you can't do that in a
  <dbaron> The other fun question is whether the system color keywords
           are computed values.

  astearns: I'm not hearing any objections
  astearns: some research into what the meta tag would actually do
  astearns: We need more details written down

  tantek: Other question this raises is that there is a hole in the
          CSS rendering model about initial / transitional paints
  tantek: and we're not addressing it
  tantek: and the jump to a specific solution like meta tag is a way
          of ducking that problem
  tantek: I believe this group owns this problem
  tantek: Not saying we're addressing it today, but we should admit
          it's a problem
  smfr: There are consumers of HTML/CSS like mail clients without the
        same navigational behavior as browsers
  smfr: when browsers paint during page load is in some cases a
        differentiator between browsers
  smfr: We try to paint not too late or early
  smfr: not sure specifying that is productively
  astearns: Not specifying first paint, but specifying some control
            over what happens in that first paint to avoid flashes
  astearns: seems like a good thing to work on
  fremy: First paint can happen before CSS
  tantek: I sense a hole
  tantek: I won't disagree with smfr that browsers are motivated at
          doing a good job at, just that it's a hole that authors have
          asked for control of it, but we haven't provided for
  tantek: We can do a better job too, but those two are not in conflict
  astearns: Can you raise an issue on that?
  astearns: For the meta tag, seems like we should do some more work
            and come back with a more concrete proposal

CSS Text 3
  scribe: fremy

word-break: break-word
  github: https://github.com/w3c/csswg-drafts/issues/2390

  <dbaron> https://bugzilla.mozilla.org/show_bug.cgi?id=1296042
  emilio: Blink cannot seem to be able to unship
  emilio: We considered the alternatives
  emilio: but the usage in Blink is very high so even if they also
          implemented the alternatives
  emilio: They would not unship
  emilio: I'm tired of getting new compat issues about this
  emilio: So, can we maybe as a group add this to a spec?
  emilio: Maybe even mark it as deprecated
  emilio: It's sad but realistic
  florian: I am annoyed that this means we will have to care about
           this forever
  florian: but I guess if this is required, I guess we will have to
           live with it
  florian: because both the name is bad, but also it's not on the
           right property
  florian: but well...
  florian: ...
  florian: Is anybody sad enough that they are willing to object?
  emilio: We could put it in a webcompat spec?
  florian: No, if we do it, let's do it properly
  florian: As in, the text spec

  astearns: So, all seem resigned to accept this at this point, is
            that right?
  astearns: Proposed resolution is thus to add it (back) to the spec
  fantasai: We have to decide if we put it in the same table as the
            other values
  fantasai: or in a prose section further down below
  astearns: I like the latter
  astearns: Level 3 or level 4?
  fantasai: Level 3 because it is not CR yet
  dholbert: Are we confident we can get this specced properly soon
  fantasai: Yes, we already have this exact behavior, just on another
  AmeliaBR: So we will have two values doing the same thing?
  fantasai: Yes
  AmeliaBR: How will they interact
  emilio: Either or both would trigger this behavior
  AmeliaBR: ok, seems reasonable
  emilio: Either must work on their own for compat
  astearns: So, any object to add this to text level 3? with the
            explanation that people should use the other property?

  RESOLVED: Add word-break:break-word to text level 3, with a note

Meeting Planning

  Non-minuted conversation about future meeting dates and locations.
  Firmed up dates for next F2F.
  Discussed proposed location and dates for early 2020 F2F.
Received on Thursday, 4 April 2019 23:09:05 UTC

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