browsers – Stéphane Caron – No Margin For Errors http://www.no-margin-for-errors.com Thu, 07 May 2015 00:40:40 +0000 en-US hourly 1 https://wordpress.org/?v=4.9.7 CSS3: rgba color values! http://www.no-margin-for-errors.com/blog/2010/01/14/css3-rgba-color-values/ http://www.no-margin-for-errors.com/blog/2010/01/14/css3-rgba-color-values/#comments Thu, 14 Jan 2010 16:11:35 +0000 http://www.no-margin-for-errors.com/?p=363

Related Posts

If what you were reading interested you, those might too! Check them out! ]]>
RGBA actually stands for (R)ed (G)reen (B)lue (A)lpha and is used to define colors in your CSS. As you must already know, colors are composed of various amounts of red, green and blue to form the final color. In CSS you can now specify the opacity of the desired color, that’s what the alpha channel is for.

What does that mean?

Up until now, the only way we had to add opacity to an element was to use the opacity CSS property. While it’s working totally fine, the opacity is also applied to all the children of that element, so this solution is not really appropriate if you just want a transparent background on a container.

Take a look at the following demo page to see how RGBA and opacity reacts differently.

Another way would be to use transparent PNGs and use them as background images to achieve the desired effect, but then again it’s not the clean way of doing this and PNG support in IE6 is far from being good.

Now you can simply add opacity to the color of your background by defining the background color like so:

#container {
  background: rgba(255,0,0,0.2);
}

The values are the following:

  1. Red color value
  2. Green color value
  3. Blue color value
  4. Alpha value, from 0 (transparent) to 1 (opaque).

Real world usage

As always with CSS3, you need to be careful on how you use it. If opacity on an element is not a major aspect of your design but a nice to have, you can consider RGBA. If your design rely on opacity to look nice, then you’ll have to look at other solutions.

What about degradation?

As you might expect, RGBA is not supported in any current version of Internet Explorer but it’s working as intended in the lastests versions of Chrome, Firefox, Safari, Opera, etc. To ensure at least everyone is able to see a solid background color, you must declare the properties as follow:

#container {
 background: rgb(255,0,0); /* For IE and older browsers */
 background: rgba(255,0,0,0.2);
 }

So when a browser sees the first value, it’ll apply it to the element, if it supports RGBA, it’ll override the first declaration with the second one. This way you’re sure everyone will at least see a solid background.

]]>
http://www.no-margin-for-errors.com/blog/2010/01/14/css3-rgba-color-values/feed/ 13
CSS3 properties: shadows! http://www.no-margin-for-errors.com/blog/2010/01/07/css3-properties-shadows/ http://www.no-margin-for-errors.com/blog/2010/01/07/css3-properties-shadows/#comments Thu, 07 Jan 2010 19:17:41 +0000 http://www.no-margin-for-errors.com/?p=302

Related Posts

If what you were reading interested you, those might too! Check them out! ]]>
Here’s a new series of post in which I’ll introduce you to new CSS3 properties. You might already know about them but have you tried them? Or know how to use them? Stay tuned and be ready when we can widely use them or start right now as it degrade gracefully.

In this article, I’ll cover text-shadow and box-shadow. Both are very similar and quite easy to use. To be able to view the example, you need to use a CSS3 compatible browser.

Text-shadow

This property will put a shadow under your text… Used wisely it can give the subtle touch that makes a design stand out. The CSS declaration should be as follow:

h1 {
text-shadow: #999 1px 1px 0px;
}

The four value are:

  1. Color of the shadow. Accepeted values are hex, rgb, rgba. I’ll discuss RGBA in the next article.
  2. X-Coordinate of the shadow relative to the text. A positive value will push it down, a negative value will pull it up.
  3. Y-Coordinate of the shadow relative to the text. A positive value will push it right, a negative value will pull it left.
  4. Blur of the shadow. The higher the value, the more blury the shadow. Don’t make it too high as it can make the text difficult to read. 0px or 1px is usually perfect!

Check out an example here. It should work in Firefox, Opera, Safari, WebKit, Chrome, you get it!

Box-Shadow

This property is very similar to text-shadow. It takes the same values, the only difference is that for now, you need to define it with browser specific prefix. The CSS declaration should be as follow:

#content {
  box-shadow: #000 2px 2px 15px;
  -moz-box-shadow: #000 2px 2px 15px;
  -webkit-box-shadow: #000 2px 2px 15px;
}

You see “-moz” and “-webkit”, those are the browser specific prefixes I was talking about. According to Michael Ventnor, the prefixes are not needed with text-shadow because they were part of CSS2.0 and got dropped in CSS2.1. Box-shadow needs the prefixes because it is part of CSS3.

Once CSS3 support will be final in the browsers the prefixes should be dropped. That’s also why I include a “box-shadow” without any prefix, for future support, this way you ensure your style will still be visible properly once the browsers drop the prefix.

Check out an example here. It should work in Firefox, Safari, WebKit, Chrome, you get it!

Bottom line

You can start using those properties right now, but make sure your design doesn’t rely on them as the properties are not widely supported yet. A browser that doesn’t support them won’t display any shadow, so it degrades gracefully.

It can be nice to start using this right now as it can make your life significantly easier, not having to play with PNGs to have shadows is a big plus and you can save some kilobytes on page sizes.

Just be careful if you start using this on clients website, I personally wouldn’t recommend it as clients often expect websites to be the same across all browsers. If your clients are open enough to let you play with this, then you’re in luck!

]]>
http://www.no-margin-for-errors.com/blog/2010/01/07/css3-properties-shadows/feed/ 9
pointer-events, a property I wish we had now. http://www.no-margin-for-errors.com/blog/2009/12/01/pointer-events-a-property-i-wish-we-had-now/ http://www.no-margin-for-errors.com/blog/2009/12/01/pointer-events-a-property-i-wish-we-had-now/#comments Tue, 01 Dec 2009 22:10:31 +0000 http://www.no-margin-for-errors.com/?p=234

Related Posts

If what you were reading interested you, those might too! Check them out! ]]>
Mozilla announced it’d support pointer-events in Firefox 3.6. While the specification has apparently been part of SVG for a while, I never really heard of it before today.

The pointer-events CSS property basically specifies if the mouse event should be sent to the current element, or the element underneath it. Might not look very useful at first, but it makes a whole lot of sense when you’re working with “complicated” designs.


Real world example

Lets say you have that fairly simple design, a content area and a sidebar. The content area has a drop shadow that goes over the sidebar area. Something that look like the following.

design_drop_shadow

The problem with the design is that in order to display the shadow over the sidebar, you have to bring it’s z-index up and since it goes a bit over the sidebar, there’s a small part of the content area that goes over the link and blocks the click. See below outlines in yellow.

design_drop_shadow_sizes

Up until now, you really didn’t have much choices. In order to enable the click on the link, you’d have to include the shadow as a background image in the sidebar. The content area wouldn’t go over the sidebar anymore, but the drop shadow would’nt be over the content as the designer intended it to be.

Well with the pointer-events, you just have to see the value to “none” in the CSS and that means any click event sent on that element will automatically go to the element underneath it, in that case, the link in the sidebar.

.content {
  pointer-events: none;
}

What now?

Unfortunately, this isn’t part of any CSS specification (yet). Mozilla decided to implement it in Firefox 3.6 and they are the only one right now. However, that’s a nice step forward and I really do hope others starts implementing it, because it’s really small, but can save quite some time in the long term.

]]>
http://www.no-margin-for-errors.com/blog/2009/12/01/pointer-events-a-property-i-wish-we-had-now/feed/ 2
This tweet got me thinking. http://www.no-margin-for-errors.com/blog/2009/11/16/this-tweet-got-me-thinking/ http://www.no-margin-for-errors.com/blog/2009/11/16/this-tweet-got-me-thinking/#comments Mon, 16 Nov 2009 20:48:29 +0000 http://www.no-margin-for-errors.com/?p=48

Related Posts

No related posts. ]]>
Today James Padolsey posted something quite interesting on his Twitter account that got me thinking:

Wondering what the client-side would be like if there were multiple languages, not just JavaScript…

Not only it got me thinking, but it also scared me. The way it works now is, you download a browser, you deal with what technologies comes bundled with it. It may be CSS3, ECMAScript 5, HTML5, every browser support the standards they want to a certain extent. Some does it well, some suck at it (don’t think I need to drop names!).

If you take a look at the “back-end” side. Depending on the technologies you want to use, you just need to install the proper libraries on your server in order to feed it properly to the web browser. YOU decided what you feed and how you feed it. Every time a new programming language emerge, you can start using it and be sure that everyone coming to your website will be able to see it as long as your webserver is setup properly.

And that’s what so “complicated” with front-end. You just don’t know who will come on your website and what they’ll be using. You totally depend on browser penetration.

Why I got scared?

Remember netscape 4, the <layer> tag, IE6 just to name a few?

In the current state of things I don’t think it’d be a good thing to add another language.

In the past, and even today, we’ve often been held back by older browser. Not because they suck, I think they were perfectly fine for their time, but because people were slow to upgrade. It can be the IT department that don’t want to go through the pain of updating all the employees computers or the users that are not aware enough, the end result is still the same, we need to support them until they die.

However, I think that sometime soon browser vendors AND users will be saavy enough to understand it is important to keep their browser up-to-date. Then we’d be able to take advantage of a new emerging client-side programming language since the adoption would be fast and widespread enough for us to use it.

But until then…I’ll be scared

What’s your view on the subject?

]]>
http://www.no-margin-for-errors.com/blog/2009/11/16/this-tweet-got-me-thinking/feed/ 4