- From: Dael Jackson <daelcss@gmail.com>
- Date: Thu, 4 Apr 2019 19:08:08 -0400
- 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
===== FULL MINUTES BELOW ======
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
container
<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
scrolling
<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
Publications
------------
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
interest
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
useful
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
https://wicg.github.io/spatial-navigation/tests/ux/result.html
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
CSS UI
======
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
itself
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
darkening
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
back
fremy: Today the light controls have this fallback today
fremy: if you have a button border-radius:3px, you get the fallback
rendering
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
field
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
everything
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
supports"
fantasai: You're only doing this for white or black -- is this a big
problem?
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
something?
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
environment
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
one
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
controls
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
light
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
prefs
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
theme
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
environment
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
black
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
irrelevant
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
not
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
selector
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
non-Windows
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
problem
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
liner
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
subtree
<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?
[giggles]
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
though?
fantasai: Yes, we already have this exact behavior, just on another
property
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