How to validate CSS3 HSLA color values? - validation

I like checking CSS validity. It makes things work better. However, a stylesheet I'm using specifies some colors, like so..
border-right: 1px solid hsla( 0, 0%, 0%, 0.2 );
which results in an error when using the W3C validation services (even with level=css3 set), such as...
Value Error : border-right Too many values or values are not recognized : 1px solid hsla(0,0%,0%,0.2 )
I also tried...
border-left: 1px solid ; border-left-color: hsla( 0, 0%, 100%, 0.3 );
but that returns...
Value Error : border-left-color hsla(0,0%,100%,0.3 ) is not a border-color value : hsla(0,0%,100%,0.3 )
I guess this notation is simply a "candidate", according to this spec... Does that mean validating it, at this point, is simply not an option? It's the alpha that's tripping it up.. Can I "break that value out", somehow?

This is a known validator bug which has been reported. Your CSS declarations are all valid, and there's nothing you can or need to do about the validator failing to recognize them.
By the way, the spec you cite is out of date; the CSS3 Color Module is already a W3C Recommendation.

Related

Sass mistakenly converts rgba function to hex

I have the following SASS code in a SASS file which is imported to my Vue component in Nuxt 3:
.page {
background-color: rgba(0, 0, 0, 0.87);
}
I convert this to CSS using nuxt generate (with 3.0.0-rc.8), I get the following output:
.page {
background-color: #000000de;
}
This is wrong, because there is no opacity anymore. The output should be:
.page {
background-color: rgba(0, 0, 0, 0.87);
}
What causes this problem?
Side note: I could use opacity property instead of rgba, but it cannot always replace rgba, for example if I have box-shadow: 0 -0.1rem 0.4rem rgba(0, 0, 0, 0.5) inset;
Both the RGBA and hex values are the same.
Hex using 6 digits for regular RBG channels, the 2 last ones (if provided) are used for the alpha channel.
You can find an online converter here: https://rgbacolorpicker.com/rgba-to-hex
Otherwise, you can also try those directly into the browser.
I've used an alpha of 0.15 because 0.87 is quite hard to see (1 being totally opaque as a reminder), but it is totally equal for all the values as you can expect.
For that example, pick the sidebar on the right and apply both properties, toggle them back and forth and you'll notice no difference as expected.
Moreover, the devtools can provide you the convertion directly, click on the color icon (just on the right side of background-color and before the actual value), then click on the arrows on the bottom right of the popup.
So, if something is not working, it may come from somewhere else but both are totally equal from a CSS point of view.

Browser support for text-shadow spread value

Seen discussions here but it has been 2 years!
I don't know if I'm using this right but I have the following sass/compass code:
+text-shadow(red 0 3px 0 3px)
Generating the following css:
text-shadow: red 0 3px 3px, red 0 3px 0 3px;
text-shadow: red 0 3px 0 3px, red 0 3px 0 3px;
Which not works in neither Chrome/Safari/Firefox/Opera.
Is this something with the declaration or this spread feature was really removed from specs?
It's not ideal, but since text-shadow accepts a comma separated list of values, you can "stack" text-shadows on top of each other to get a more opaque outcome.
text-shadow: 0 0 1px white, 0 0 2px white, 0 0 3px white;
It says in the specs that,
This property accepts a comma-separated list of shadow effects to be
applied to the text of the element. Values are interpreted as for
‘box-shadow’ [CSS3BG]. (But note that spread values are not allowed.)
The shadow is applied to all of the element's text as well as any text
decorations it specifies.
Compass doesn't allow to set the spread value when using the mixin: text-shadow as they said in their documentation:
if any shadow has a spread parameter, this will cause the mixin to emit the shadow declaration twice, first without the spread, then with the spread included. This allows you to progressively enhance the browsers that do support the spread parameter.
Alternatively, you can use the mixin: single-text-shadow then pass all the values including the spread value separated with commas.
single-text-shadow(0, 3px, 0, 3px, red);
That will work as you expected.

line-height 2px lower in firefox vs webkit

I have the following css:
.btn_container {
cursor: pointer;
font-family: Tahoma,Verdana,Arial;
font-size: 11px;
padding: 0;
width: auto;
}
.btn_center {
background: blue;
color: #FFFFFF !important;
display: block;
float: left;
font-weight: bold;
height: 32px;
line-height: 32px;
padding: 0 10px;
}
line-height of 30 lines up center in firefox, but 32 in webkit.
I know browsers will render things differently, but i've never had a problem getting text to center properly.
In the following example you can see that it drops a couple px lower in firefox:
http://jsfiddle.net/mstefanko/EGzEB/5/
I've done heavy testing of this in the past. I call it text jiggle. It's not something you can control. All you can do to minimize it is apply an explicit line-height (especially one in px) to every text element.
The default line-height varies by a wide margin in different browsers, and for different font families at different font sizes. Setting an explicit line-height addresses that.
But within that, the exact placement of the text within the line-height space will vary slightly browser-to-browser no matter what you do. For some combinations of font-size and line-height, all browsers match up. For instance, Arial at font-size:11px and line-height:14px renders the same in FF, Webkit, and IE. But change the line-height to 13px or 15px, and it varies by 1px browser-to-browser.
There's no standard or defined behavior for it. It's the result of how that particular font-family, font-size, and line-height happens to be rendered by the browser on that operating system. Arial, for instance, is a relatively consistent font, generally not varying by more than 1px as long as an explicit line-height is defined, while Helvetica varies by as many as 4 to 6 pixels.
I had the opposite experience actually. I noted that some header elements were positioned higher in IE7/compatibility mode as well as Chrome/Safari. So after much trouble I inspected with chrome and saw -webkit-margin-before: 1.6em or something added to the headers. Adding that value and tweaking it didn't work because it effected the height of the header which pushed some elements down but the padding option worked well for me ...
I found that this worked for me:
H1, H2, H3, H4, H5, a.mainTab div {
-webkit-padding-before: 1px;
}
a.mainTab div had spans which wouldn't respond to the padding/margin so wrapped them in a div ... this may work for li span span headers as well.

Webkit vs. Firefox vs. Opera text-shadow issue

I seem to have an issue where Firefox is displaying a blurred text shadow of 0.75 opacity just fine on white background, but in Webkit and Opera it's too dark/crisp. Who is right? What gives? And how should I attempt to solve it? Thanks.
Notes:
Here's an example JSFiddle
Actually, it seems like the issue might be in the choice of image processing filter. The fire fox version seems the blurriest, followed then by Opera's and then Chrome/Safari (Webkit). It almost looks like the Webkit browsers are using some sort of box filter to do their blurring, whereas Firefox is using something smoother. The shadow seems just too crisp in Webkit.
If I understood your problem in order to fix that on chrome and opera you must set blur radius on a higher value in order to have same result on those three browsers. I know that because I use a box-shadow on Firefox and Chrome and I noticed that.
check this live example: http://css3generator.com/
firefox: text-shadow: 1px 10px 19px #050505;
chrome and opera: 1px 10px 29px #050505;
Looking at http://www.w3.org/TR/css3-text/#changes (W3C Working Draft 19 January 2012)
A number of less-stable features have been deferred to Level 4: ...
...
the spread radius on ‘text-shadow’
So the meaning hasn't been specified. Go figure.
In any case, I also (re)discovered that text-shadow accepts a comma delimited list, so I suppose if I wanted to manually blur it further, If I originally had
text-shadow: 5px 5px 5px rgba(0, 0, 0, 0.75);
I could maybe do something like
text-shadow: 4px 4px 5px rgba(0, 0, 0, 0.1875),
4px 6px 5px rgba(0, 0, 0, 0.1875),
6px 4px 5px rgba(0, 0, 0, 0.1875),
6px 6px 5px rgba(0, 0, 0, 0.1875);
adding shadows as necessary.

Transparent Background Image with a Gradient

Today I was designing a transparent PNG background that would only sit in the top left of a div, and the rest of the div would maintain a gradient background for all transparent areas of the PNG, and the rest of the div itself.
It might be better to explain through the code I thought might work:
#mydiv .isawesome {
/* Basic color for old browsers, and a small image that sits in the top left corner of the div */
background: #B1B8BD url('../images/sidebar_angle.png') 0 0 no-repeat;
/* The gradient I would like to have applied to the whole div, behind the PNG mentioned above */
background: -moz-linear-gradient(top, #ADB2B6 0%, #ABAEB3 100%);
background: -webkit-gradient(linear, left top, left bottom, color-stop(0%,#ADB2B6), color-stop(100%,#ABAEB3));
filter: progid:DXImageTransform.Microsoft.gradient( startColorstr='#ADB2B6', endColorstr='#ABAEB3',GradientType=0 );
}
What I've been finding is that most browsers pick one or the other - most choosing the gradient since its further down the CSS file.
I know some of the guys around here will say "just apply the gradient to the PNG you're making" - but thats not ideal because the div will maintain a dynamic height - sometimes being very short, sometimes being very tall. I know this gradient isn't essential but I thought it might be worth asking y'all what you thought.
Is it possible to have a background image, while keeping the rest of the background as a gradient?
Keep in mind that a CSS gradient is actually an image value, not a color value as some might expect. Therefore, it corresponds to background-image specifically, and not background-color, or the entire background shorthand.
Essentially, what you're really trying to do is layering two background images: a bitmap image over a gradient. To do this, you specify both of them in the same declaration, separating them using a comma. Specify the image first, followed by the gradient. If you specify a background color, that color will always be painted underneath the bottom-most image, which means a gradient will cover it just fine, and it will work even in the case of a fallback.
Because you're including vendor prefixes, you will need to do this once for every prefix, once for prefixless, and once for fallback (without the gradient). To avoid having to repeat the other values, use the longhand properties1 instead of the background shorthand:
#mydiv .isawesome {
background-color: #B1B8BD;
background-position: 0 0;
background-repeat: no-repeat;
/* Fallback */
background-image: url('../images/sidebar_angle.png');
/* CSS gradients */
background-image: url('../images/sidebar_angle.png'),
-moz-linear-gradient(top, #ADB2B6 0%, #ABAEB3 100%);
background-image: url('../images/sidebar_angle.png'),
-webkit-gradient(linear, left top, left bottom, color-stop(0%, #ADB2B6), color-stop(100%, #ABAEB3));
background-image: url('../images/sidebar_angle.png'),
linear-gradient(to bottom, #ADB2B6, #ABAEB3);
/* IE */
filter: progid:DXImageTransform.Microsoft.gradient(startColorstr='#ADB2B6', endColorstr='#ABAEB3', GradientType=0);
}
Unfortunately this doesn't work correctly in IE as it uses filter for the gradient, which it always paints over the background.
To work around IE's issue you can place the filter and the background image in separate elements. That would obviate the power of CSS3 multiple backgrounds, though, since you can just do layering for all browsers, but that's a trade-off you'll have to make. If you don't need to support versions of IE that don't implement standardized CSS gradients, you have nothing to worry about.
1 Technically, the background-position and background-repeat declarations apply to both layers here because the gaps are filled in by repeating the values instead of clamped, but since background-position is its initial value and background-repeat doesn't matter for a gradient covering the entire element, it doesn't matter too much. The details of how layered background declarations are handled can be found here.
You can use Transparency and gradients. Gradients support transparency. You can use this, for example, when stacking multiple backgrounds, to create fading effects on background images.
background: linear-gradient(to right, rgba(255,255,255,0) 20%,
rgba(255,255,255,1)), url(http://foo.com/image.jpg);
The order of the image and gradient is very KEY here, i want to make that clear. The gradient/image combo works best like this...
background: -webkit-gradient(linear, top, rgba(0,0,0,0.5), rgba(200,20,200,0.5)), url('../images/plus.png');
background-image will also work...
background-image: -webkit-gradient(linear, top, rgba(0,0,0,0.5), rgba(200,20,200,0.5)), url('../images/plus.png');
the gradient needs to come first... to go on top. The absolute key here though is that the gradient uses at least 1 RGBA color... the color(s) need to be transparent to let the image come through. (rgba(20,20,20,***0.5***)). putting the gradient first in you css places the gradient on top of the image, so the lower the alpha setting on you RGBAs the more you see the image.
Now on the other hand if you use the reverse order the PNG needs to have transparent properties, just like the gradient, to let the gradient shine through. The image goes on top so your PNG needs to be saved as a 24 bit in photoshop with alpha areas... or a 32 bit in fireworks with alpha areas (or a gif i guess... barf), so you can see the gradient underneath. In this case the gradient can use HEX RGB or RGBA.
The key difference here is the look. The image will be much more vibrant when on top. When underneath you have the ability to tune the RGBA values in the browser to get the desired effect... instead of editing and saving back and forth from your image editing software.
Hope this helps, excuse my over simplification.
This is possible using multiple background syntax:
.example3 {
background-image: url(../images/plus.png), -moz-linear-gradient(top, #cbe3ba, #a6cc8b);
background-image: url(../images/plus.png), -webkit-gradient(linear, left top, left bottom, from(#cbe3ba), to(#a6cc8b));
}
I read about this at Here's One Solution.
UPDATED
* {
margin: 0;
padding: 0;
}
html,
body {
width: 100%;
height: 100%;
}
.hero {
width: 100%;
height: 100%;
min-width: 100%;
min-height: 100%;
position: relative;
}
.hero::before {
background-image: url(https://images.unsplash.com/photo-1566640269407-436c75fc9495?ixlib=rb-1.2.1&ixid=eyJhcHBfaWQiOjEyMDd9&auto=format&fit=crop&w=750&q=80);
background-size: cover;
content: "";
display: block;
position: absolute;
top: 0;
left: 0;
width: 100%;
height: 100%;
z-index: -2;
opacity: 0.4;
}
<div class="hero flex-center">
<div class="hero-message">
<h1 class="hero-title">Your text</h1>
<h1 class="hero-sub-title">Your text2</h1>
</div>
</div>
<div class="not-hero flex-center bg-info">
<div class="not-hero-message">
<h1 class="hero-title">Your text</h1>
</div>
</div>
** It's working**
Transparent images are not yet a CSS standard, yet they are supported by most modern browsers. However, this is part of the W3C CSS3 recommendation. Implementation varies from one client to another, so you will have to use more than one syntax for cross-browser compatibility.
http://www.handycss.com/effects/transparent-image-in-css/

Resources