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.
Related
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.
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.
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.
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.
I'm wondering, why this double border on table TDs won't show in Chrome but only in FF? Any ideas what could be the work around? Thanks!
http://jsfiddle.net/yQQLk/1/
Not sure why you're using box-shadow to produce a double border, when the border property itself already supports a double border on its own. Just use the following CSS instead of what you've got:
td {
border-bottom: 3px double red;
}
Note you'll need to increase the size of the border to 3px so that both of the lines show up (with 1px, it sometimes doesn't show up at all when you specify double).
The other advantage is that this will work in all browsers, including older ones which don't support box-shadow.
Increase your border thickness to to see a more obvious demonstration of the rendering differences between the two browsers. It seems that in FF, the box-shadow is overlaid on top of the border, in Chrome it hides underneath.
You could use another approach - perhaps use a border-bottom combined with a text-decoration: underline.
Try this, it works in both the browsers:
td {
-moz-box-shadow: 0 1px 0 #000;
-webkit-box-shadow: 0 1px 0 #000;
border-bottom: 1px solid red;
box-shadow: 0 2px 0 #000;
}
I guess, this is the problem: box-shadow: 0 1px 0 #000;