If you are familiar with color spaces (ICC profiles), you probably know, that there are "absolute units" of representing the color (XYZ, L*a*b*) and device-specific units (RGB, CMYK ...) which could mean any real color (unless it is specified using the ICC profile).
But on the web, we usually use RGB units (e.g. in CSS or when drawing onto a Canvas) without specifying any color profile. Is it somewhere defined, that the whole web uses the sRGB or some other color space?
Your question is a bit broad, and it's not possible to give a one sentence answer to it.
So let's go to the specs :
All RGB colors are specified in the sRGB color space (see [SRGB]). User agents may vary in the fidelity with which they represent these colors, but using sRGB provides a unambiguous and objectively measurable definition of what the color should be
So this tells that sRGB for CSS <color> is expected, with some variants.
What variants ?
Well e.g in Safari, the browser has access to the currently used monitor's color-profile, and it will use it to adapt the authored values to match the sRGB output, through this user-set color-profile.
Firefox has some flags to do the same.
Note that there is a feature request to add a color-profile CSS rule, in order to allow authors to define the color-profile to be used on the page. Note that this feature-request [has been dropped] in current specs, but may still appear in future versions.
This was for CSS <color>, but this is not the only place where colors are defined in a web page.
Most browser nowadays do read the color-profiles embedded in images, when displayed in an <img> element.
But since you tagged your question with canvas, one should note that this color-profile info is currently being dropped by the browser when it paints it on the canvas.
Once again, there is a pending feature request to add more options to the 2DContext. One of these options being the color-profile.
Currently, only Chrome is in the process of implementing it, so it's hard to tell what it will be exactly, if any.
Also, since we're at it, it should be noted that svg does have a <color-profile> element, and a #color-profile CSS rule, which also have been proposed for CSS specs, but got dropped in the final edition.
And there might probably also be a note about color-management in videos, but for this, I have no idea who does support it (IIRC it's quite rare, and only allowed in mp4 container).
The Microsoft and HP sets out the in the 1990's to define the colour space for the web as sRGB. Since then it seems to have stuck with but minor modification and clarification.
More can be found at W3C CSS3 color
Related
I've been working on a few websites that have beautiful color palettes but do not provide high enough contrast between text and background for accessibility. I love to make sites usable for everyone, but as a designer, I feel bummed that so many awesome color combinations are totally off the table. Would providing an obvious way to toggle into a high contrast mode be an acceptable alternative?
Lots of users would benefit from a high-contrast color scheme, including many who don't regard themselves as disabled. You can certainly let yourself off-the-hook, legally speaking by providing a WCAG compliant color scheme alongside whatever awesome swatch you prefer. I would advise starting with the WCAG-compliant one first, and make it the default, so you always have that as a base to fall back on.
You could even use the forced-colors media query, although this is not yet standard. There are a few other related media queries offered by Microsoft, as mentioned here
https://blogs.windows.com/msedgedev/2020/09/17/styling-for-windows-high-contrast-with-new-standards-for-forced-colors/
But before you start working on a new color scheme, it will be more worth checking how your 'regular' site looks like with some of the system-level contrast mode settings enabled. These are available on most platforms, and there are a number of browser extensions which also manipulate color/contrast (each works slightly differently).
Please note that it's perfectly possible to make the UI unusable using system level "high contrast" features with 'extreme' settings. Mac OS's contrast slider can almost bleach out the entire screen if pushed to the edge! I can't help wondering who this is supposed to benefit.
WCAG does not require that content should be perceivable within the broad limits of every single high contrast gadget on the market, so in general, if these kinds of problem only occur when the gadget is enabled, they are not (strictly) WCAG violations.
However, given that the success criteria "Focus Visible", "Text Contrast" and "Non-Text Contrast" are already met, any contrast "failures" which only occur when High Contrast gadgets are enabled are usually best understood as possible violations of SC 1.3.1 Info and Relationships, because they do not "ensure that information and relationships that are implied by visual formatting are preserved when the presentation format changes". You might also have some violations of SC 1.4.1 Use of Color if any distinctions are made by color alone. (e.g. if all headings are the same font and size as body text, but in red).
Therefore the important thing is to try your content with some of the default schemes in (say) Windows High Contrast Mode. Check that everything is still distinguishable, especially including focus indicators and UI states (e.g. text labels, disabled controls, checkboxes and radiobuttons, thumbs on sliders and scrollbars, data views etc.). It will probably not be very beautiful, but that's not the point. Again, it's not a WCAG violation if you don't offer perfection in Windows High Contrast Mode, although you should probably mention any howlers in any Accessibility Conformance Report or VPAT.
As a small tip, I will mention that Windows High Contrast Mode will try to color-code UI borders to reflect certain states. (e.g. a button with a disabled attribute might be drawn with a green border). Therefore: Make sure your UI controls have borders of at least 1px. If you don't want a visible border in the regular scheme, use a transparent color. Similarly, make sure any non-decorative SVG content uses some kind of stroke to be distinguishable in Windows HCM.
That way, if someone enables HCM, the boundaries of content, and also the state of the controls will still be perceivable.
I am working on a project where we have designers that work in Adobe RGB and are used to seeing the more vibrant colors from that spectrum in Illustrator. However we have been building an application that will allow them to do their work in a web browser using a THREE JS 3D workspace.
Because we have been creating the color swatches using CSS background color and applying RGBA to the meshes in THREE we have been displaying everything in sRGB, and now the designers are complaining the colors don't seem right in the browser.
I know that current versions of Chrome support color management for images but I can't find any information about CSS or Three JS. Does anyone know if it's even possible to control the color profiles for these areas, or are we just going to have to live with sRGB?
We have the very same problem, i found no way to control the CSS Colors. I think this will maybe change with the mediaQuery keyword, but I did also not found out if it will affect CSS colors.
http://furbo.org/color/ResponsiveColor/
We only need a special set of colors so now we store them in a texture and make a lookup, but I guess this is no solution for you.
Is your destination the web? Then Adobe RGB is not presently supported, and is not recommended.
The Standard for the Web is sRGB
The W3 defined the standard for web content as sRGB. In the future, CSS4 will support other colorspaces. Right now? Stick with sRGB.
Chrome, and most browsers do not support any color management for CSS. Safari is the only one I know that does, at least without tweaking some internal experimental options on the others.
When possible, I suggest working in the destination space (though possibly working at a higher bit depth) then there will not be these kinds of "surprises". In the interim, you might try converting the existing work from AdobeRGB to sRGB using "perceptual intent" or "relative colorimetric".
Also, you can find the docs for CSS here:
https://www.w3.org/TR/css3-roadmap/
It is not possible now, but it will be possible in the future when draft specification from W3C will come into browsers... (https://drafts.csswg.org/css-color/)
It is now already possible in latest Safari of MacOS BigSur. There is even a special test here.
Console in Safari also has Color managed color picker.
I'm trying to create a game that uses buttons (and text areas) that are semi-transparent (Alpha of about 60%). I can do almost everything I want in XHTML and CSS, except for these semi-transparent items. So I'm looking for the easiest way of creating semi-transparent images on my web pages.
Ideas so far:
Create PNGs with semi-transparent pixels. This is supposed to be possible, and there are well-defined interfaces for defining an Alpha channel using PHP and the GD package. Problem: I tried this, but the images were opaque in all the browsers I tried (Chrome, IE8, FF).
Do it in Flash. I know how to use Flash(*) from some work I did before I retired. Problem: Flash is priced for the professional developer, not the hobbyist.
(*) Well, Flash 8. But as I understand it, even with newer versions I can continue to create movie clips the old way, they just get translated into a bunch of AS. And it's supposedly possible to continue using AS2, although you can't mix AS2 and AS3.
Do it in Flex. Problem: interfaces best described as arcane. Even using suggestions from experienced Flex developers, trying to include code from another mxml file (other than as a class) was a PITA.
Use SVG. This looked promising. The SVG syntax is basically XML, the element tags are reasonably obvious, and the interaction of attributes only slightly arcane, and there are plenty of examples in the tutorial. But... about half of current browsers will not support using SVG in an <img> tag. You have to use <embed> That means you can't put it inside an <a> or <button>. Even using embed, I got what look like "broken image" icons in IE8.
As I'm writing this, I notice several items under "similar questions" that look promising. But when I look at them, they use attributes that are not mentioned in the CSS spec: opacity, filter:alpha, and rgba. When working in a complex language, I really prefer to have the complete language spec open in another window, or to have the equivalent dead-trees version (e.g., the O'Reilly salmon book Cascading Style Sheets, The Definitive Guide, which sits on a bookshelf next to my desk.
So I'm asking for recommendations. If the consensus is to use SVG, I'll post my code and see if people can tell me what I'm doing wrong.
The CSS "opacity" property is perfectly valid. It is part of CSS3, and is supported in all browsers (*).
http://caniuse.com/css-opacity
Or you can use semi-transparent PNGs, as Alvaro demonstrated. They should work just fine. Not sure what happened with your attempts, but you must have done something wrong.
Note for versions of IE <= 8, you need to use the "filter" property instead.
https://developer.mozilla.org/en-US/docs/Web/CSS/opacity
I don't know what problem you have with PNG's. Imo the best and easiest option by far. And they look as they should in all browsers from my own experience.
check this out: http://jsfiddle.net/BDLYG/
(and here a code I need to add)
If you have most users with the 'modern' browsers, I would say go with SVG. If you do, post here, and I'll be glad to help.
Many thanks for all the useful answers. I'm currently using a combination of CSS and PNGs (generated via PHP). I could have gotten along with just CSS, but I decided I wanted to change the opacity of the background when the user hovers over the button -- but keep the text opaque. It's easy to change the opacity of the whole thing, but (as far as I can tell) not of just the background.
I also experimented with SVG, and it also works fine, but it requires extra computation so I chose the simpler (for me) approach of CSS and PHP. I'm already comfortable with those two languages, just needed to be introduced to the newer stuff in CSS3 and the one extra function call needed to make alpha work in PNGs generated by the PHP GD package.
The vertical position of text rendered in Helvetica and the size of its content area differ between Firefox and Chrome for Mac. For example, in Chrome, the descenders are clipped if the line-height is identical to font-size.
(I’ve adjusted the position of the block elements in this picture—keeping the baseline consistent—to illustrate the difference in size and text positioning). If you have a Mac, you can see what I’m talking about in this JS Bin.
Now, I'm not directly interested in how to fix this specific discrepancy. I realize there are hand-tuned reset stylesheets that attempt to eliminate or paper-over the differences, but I'm specifically interested in the factors that caused these browsers to render differently in the first place.
I'm making some assumptions here:
Standards exist for both the rendering of fonts and the sizing and positioning of glyphs within the standard box model, but may be unspecified in terms of how they interact.
Bugs exist in browser-makers interpretations of the aforementioned standards, which may influence how text is sized, positioned and rendered.
For these specific browsers, much of the design discussion and actual implementation is public in some form. Therefore, it is possible to learn the source of such discrepancies, if one knows where to look.
Both browsers start in the same place - the markup, styles and font definitions are consistent between them. At some point, they diverge in how they use these to produce the final output.
Therefore, my specific question is: where in the process does this divergence occur, and what causes it to occur?
I feel that, armed with this knowledge, I can better understand how to correct for such discrepancies. Both in this case specifically, and in similar situations that I may encounter in the future.
Unfortunately, re: rendering of the content area based on the font, CSS2.1 does not say much at all:
The height of the content area should be based on the font, but this specification does not specify how. A UA may, e.g., use the em-box or the maximum ascender and descender of the font. (The latter would ensure that glyphs with parts above or below the em-box still fall within the content area, but leads to differently sized boxes for different fonts; the former would ensure authors can control background styling relative to the 'line-height', but leads to glyphs painting outside their content area.)
In other words, typesetting, and how exactly to draw and position the content area of a line box, is left up to the browser's own implementation, at least in CSS2.1. This may however be better defined in a future specification (likely the Fonts module, if not a separate module1).
Section 10.8.1 contains some details on how the line-height property affects the rendering of the content area around text that flows inline, but again it depends on the height of the content area itself, which as stated above is undefined in CSS2.1.
Note that auto is not a valid value for line-height; you probably meant to use normal, which incidentally is also its initial value (but not necessarily the browser default). Also, this is what the spec says about the value normal:
normal
Tells user agents to set the used value to a "reasonable" value based on the font of the element. The value has the same meaning as . We recommend a used value for 'normal' between 1.0 to 1.2. The computed value is 'normal'.
As you can see, there's not much to go on, even with regards to comparing line-height: normal and line-height: 1 (or 1em or 100%), because what constitutes a "normal" line height is up to the browser to decide as well. However, it looks like Chrome and Firefox do a good job of keeping glyphs within reasonable boundaries when asked to use a normal line height.
By the way, Chrome does not clip the descenders. It does render them outside of the content box, but it should never clip them to the bounds of the box unless you set overflow: hidden.
1 A CSS3 definition of the line-height property currently resides in this module, but it's immediately obvious that it's been long abandoned, or at least pending a rewrite. The module in its current state is extremely detailed, but suffice it to say that it's been largely ignored by both browser vendors and the working group.
'Line height is auto' => the browser gets to choose.
'Line height = font size' => user error: the text will be illegible, and again it is reasonable, indeed essential, for the browser to make some adjustment.
You must use some leading. Books for example may be set 10pt on 12pt line spacing.
So I'm looking at a specific application for a web browser which requires me to express color as a straight alpha channel with a black and white alpha channel as a separate element. (an example of both types
I know many moons ago, IE supported some perverse filter options, but since I'm doing css3 transforms, I need this to work in a modern browser, preferably Chrome.
Basically what I'd like to do is have an element with CSS transforms applied, specifically rotation most likely, then I'd like to take that and copy it to another equivalently sized element which has the black / white transformation applied. An additional bonus would be setting the original element to use straight alpha, but I can live without that for now.
I haven't been able to find any routes with which to start investigating. If you have one, I'd be super grateful. My last resort is to start doing things in WebGL or Canvas and modifying the output there.
Two or three different elements stacked on top of each other using absolute positioning and z-index? This would require you to save two different images which I'm guessing you're trying to avoid.
You can do CSS 3D transforms. Browser support is basically there in newer IE, Chrome, Firefox, iOS and Android.
where can you use them
how to use them
MDN
I've actually figured out the answer... it's CSS Shaders.
https://dvcs.w3.org/hg/FXTF/raw-file/tip/custom/index.html
Not yet available, but soon.
The reason not to use Canvas is for simplicity in authoring. (Long story.)