Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

[css-color][css-color-adjust] We should add sufficient system colors to fully implement the HTML UA stylesheet #4924

Closed
tabatkins opened this issue Apr 6, 2020 · 6 comments

Comments

@tabatkins
Copy link
Member

See whatwg/html#5426 for some more context. In that thread, @tomayac pointed out that link colors, because they're explictly defined to be blue and purple in the UA stylesheet, aren't being inverted when the UA is in a dark color scheme, making them very hard to read.

Obviously, we have linktext and visitedtext system colors, so that particular issue should just be a matter of switching the UA stylesheet to using the system colors rather than explicitly naming them.

However, further discussion suggests that there are some colors in the UA stylesheet that aren't adequately addressed by system colors yet. If the UA stylesheet for plain HTML can't be done with system colors, we're probably missing some useful semantics, so we should make sure that the HTML stylesheet can be done purely in system colors.

@tabatkins tabatkins added css-color-4 Current Work css-color-adjust-1 Current Work labels Apr 6, 2020
@AmeliaBR
Copy link
Contributor

AmeliaBR commented Apr 6, 2020

Reviewing the other colors found in @zcorpan's review of the suggested stylesheet…

  • Standard foreground/background colors for a dialog should use the CanvasText/Canvas pair. Similarly, the default table border color should be CanvasText if there's a compat reason not to make it currentColor.

  • Colors for <mark> would need to be defined. First instinct is to use highlight/highlightText, but that's incorrect — those are for dynamic user selections, not for highlighted phrases in the document. (They could still map to the same colors in WHCM if necessary, but they're definitely not the same in the default UA stylesheets.)

  • The default color of an <hr> should probably be the same default as a button border, but even in the deprecated system colors that isn't a single color, since that set of keywords defined separate colors for all the 3D lighting effects instead of defining a single color that then gets modified by the 3D border-style. So that would also need to be a new keyword.

So new keywords would be (something like):

  • Mark
  • MarkText
  • ButtonBorder

(Alternatively, it may be acceptable to just use ButtonFace for ButtonBorder, and let the raised/inset border styles do all the adjustments.)

Related issue: #4883.

@tabatkins
Copy link
Member Author

(This comment was started before @AmeliaBR posted theirs, so by the end I'm mostly just agreeing with them.)

The full list of colors used in the UA stylesheet:

dialog { color: black; background: white; }
dialog::backdrop { background: rgba(0,0,0,0.1); }
:link { color: #0000EE; }
:visited { color: #551A8B; }
:link:active, :visited:active { color: #FF0000; }
mark { background: yellow; color: black; }
table /* lots of variations */ { border-color: black; }
hr { color: gray; }
  • dialog { color: black; background: white; }: Since these are just repeating the assumption of what the main page is already doing, those should be replaceable with canvas and canvastext.
  • dialog::backdrop { background: rgba(0,0,0,0.1); }: This one's harder. I doubt we want to provide this color directly. Really, it's just color-adjust(canvastext alpha(.1)), so I suppose we can just pretend that exists already? The UA stylesheet already does some "doesn't really exist" stuff anyway.
  • :link, :visited, and :active: already done, via linktext, visitedtext, and activetext
  • mark { background: yellow; color: black; }: probably needs something new; at least a new background (accent?), probably a full pair (mark and marktext?)
  • table { border-color: black; }: should be doable with just canvastext
  • hr { color: gray; }: as @AmeliaBR says, could probably be aligned with button borders, which need their own singular color anyway.

So yeah I agree with @AmeliaBR: let's add mark, marktext, and buttonborder. Bikeshedding of mark and marktext appreciated.

@tomayac
Copy link
Contributor

tomayac commented Apr 7, 2020

Bikeshedding of mark and marktext appreciated.

+1 for Mark and MarkText.

@tabatkins
Copy link
Member Author

table { border-color: black; }: should be doable with just canvastext

Just to call this out specifically in answer to Amelia's question, this can't be currentcolor, as the default table borders don't respond to color today. So it has to be canvastext.

@tabatkins
Copy link
Member Author

Agenda+ to discuss the addition of mark and marktext colors, and whether we want to add a buttonborder or not.

@css-meeting-bot
Copy link
Member

The CSS Working Group just discussed [css-color][css-color-adjust] We should add sufficient system colors to fully implement the HTML UA stylesheet (Agenda+ to discuss the addition of mark and marktext colors, and whether we want to add a buttonborder or not.), and agreed to the following:

  • RESOLVED: Add mark, mark text, and button border colors to system colors
The full IRC log of that discussion <dael> Topic: [css-color][css-color-adjust] We should add sufficient system colors to fully implement the HTML UA stylesheet (Agenda+ to discuss the addition of mark and marktext colors, and whether we want to add a buttonborder or not.)
<dael> github: https://github.com//issues/4924#issuecomment-610662062
<fantasai> s/futue/future, as they're less likely to have been used and thus cause compat restrictions/
<dael> TabAtkins: Issue raised against HTML that UA stylesheet does not respond to dark mode. WHat we spec in CSS does this partially but it means that things like input colors don't switch
<dael> TabAtkins: Results in bad design where inputs don't switch
<dael> TabAtkins: In issue discussion brought up these colors are spec as literal colors and how should they be adapted
<dael> TabAtkins: Most straight forward is only use system colors.
<dael> TabAtkins: A few spots don't directly map to system colors. Argument if you can't write UA stylesheet in system colors they're not rich enough for web pages
<dael> TabAtkins: With this goal there's 3 missing colors
<dael> TabAtkins: The mark element needs text and bg color to distinguish from surrounding text. Right now it's yellow with black text.
<dael> TabAtkins: Adding mark and mark text color
<dael> TabAtkins: Border of buttons and button-like things. It's a gray between foreground and background. Could get around with 3d color things, but feel awk and weird. Good to have a color to offset from background. Button border color lets us hit that
<dbaron> I think the existing system color set has �two� complete sets of values for button border colors
<dael> TabAtkins: Every other literal color use is well handled. Add these 3 colors and UA stylesheet becomes color scheme friendly
<dael> TabAtkins: Prop add these and then we can proceed with HTML issue. better names welcome
<dael> AmeliaBR: Field as in text inputs also tend to have gray border in UA stylesheets. It's not explicitly set out in HTML as a color. Left to match OS conventions. MIght be another thing to add, field border. If field and button are same perhaps can collapse
<dael> TabAtkins: That's not expressed in stylesheet
<dael> AmeliaBR: Neither is button border. It's in prose that must look like button.
<dael> TabAtkins: Right
<dael> dbaron: Button thing. Is your assumption about how this color is used within inset or outset?
<astearns> we're talking about this list? https://drafts.csswg.org/css-color-4/#typedef-system-color
<dael> AmeliaBR: Yes. Right now system colors from css 2 have border0highlight and border-shadow but really impl as single color plus inset border style which modifies
<dael> dbaron: Problem with inset and outset is they have an algo which does not match system for button look. You won't be able to match
<dael> TabAtkins: I think I'm still fine with spec having escapse hatch of similar to match OS. But a well defined color that does the job is reasonable. Suggests you shouldn't have blinding bright buttons in a dark mode
<dael> astearns: Do we have consensus on adding border color? Or just resolve on mark and mark text?
<dael> TabAtkins: Not sure if dbaron is objecting or commenting
<dael> dbaron: Just commenting. If you're still okay I'm okay
<dael> astearns: Is border color for both buttons and fields?
<dael> TabAtkins: Definitely similar in HTML. For purpose of if you're using system colors to do your own stuff using same color is fine so I'd use one for both cases
<dael> astearns: Call it button color or different name?
<dael> astearns: button border
<dbaron> I'd note that the ButtonHighlight and ButtonShadow colors provide a one-color-on-a-side 3-D button effect, and the existing ThreeDDarkShadow, ThreeDHighlight, ThreeDLightShadow, ThreeDShadow colors provide a two-color-on-a-side 3-D button effect.
<dael> AmeliaBR: Resolve on button border and as people impl if they need different color for field they can say
<dael> fantasai: Why not using the button highlight, button shadow etc on the button?
<dael> AmeliaBR: THey fall apart with stylesheet that's not creating 3d. Which do you use. We don't want to preserve those.
<dael> fantasai: Wouldn't all resolve to same color?
<dael> TabAtkins: They're not implied to resolve to same. Implied to do inset 3d-ish
<astearns> ah, and also this list: https://drafts.csswg.org/css-color-4/#deprecated-system-colors
<dael> dbaron: I think both sets of colors came from windows 95 system colors.
<dael> dbaron: There was older set of windows where buttons had a single border with a color in the middle color on highlight side color on shadow. Newer went with two colors on each side and had a separate set of names.
<dael> dbaron: button-something were the old one color on a side. 5 color set that was 3d on newer windows and 3 of the 5 colors were the same thing.
<dael> astearns: Happy to have border color without that baggage.
<dael> astearns: Prop: Add mark, mark text,a nd button border colors to system colors
<dael> astearns: Obj?
<dael> fantasai: Happy to add mark and mark text. Not clear on button. Are we using button border in UA stylesheet or other stuff?
<dael> TabAtkins: UA stylesheet would say use button border for inputa nd buttons or match OS with similar intent. Neither 3 nor 5 color set matches OS conventions today. none of the browsers will do it. But having something reasonable if doing a generic system can be done with this one color
<dael> florian: Just because current design is flat or also true if we went back to the days of glowing candy?
<dael> AmeliaBR: True if we go back to browser that have ability to do lighter and darker versions
<dael> astearns: fantasai do you object to button border?
<dael> fantasai: Not objecting, concern about re-using it
<dael> astearns: Objections?
<dael> RESOLVED: Add mark, mark text, and button border colors to system colors
<fantasai> s/re-using it/re-using it for hr and input/

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

6 participants