CSS

You are currently browsing articles tagged CSS.

Understanding HTML5 and CSS3

June 20, 2011 in Design, Marketing & Advertising, Technology by Roger | No comments

For the past year or so, companies that use the internet for sales, products, or services are aglow with conversations of HTML5 and CSS3 and how it will save the world! Well, it will certainly help your browsing experience be more useful and be a little less work for coders, but it takes content to save the world.

HTML5 is still going through standardization as there are so many browsers and devices, the W3C (World Wide Web Consortium – the group who helps make standard for the internet) is still tweaking HTML5 definitions. For now, HTML4 remains the current standard of internet pages, standardized in 1997. HTML5 has been in the works since 2004, and the W3C hopes to have it released in 2012. There is a lot to this to be sure!

The goal for HTML5 is to pull current web technologies into one standard, including HTML4, XHTML1 (HTML with XML), DOM2HTML (document object model HTML), and some JavaScript. Just don’t forget that most users don’t have HTML5-ready browsers, so there is a very good chance that you’ll have to make your content work for both (doubling your work) if HTML5 is what you want.

First, let’s look at some of the key benefits of HTML5 compared to HTML4. Since most of the inner-workings of HTML code is just Greek to most folks, we won’t delve into the specifics of each of the new elements added to HTML5, but here is the list some of them:

article, aside, audio, bdo, canvas, command, datalist, details, embed, figcaption, figure, footer, header, hgroup, keygen, mark, meter, nav, output, progress, rp, rt, ruby, section, source, summary, time, video, and wbr

If you have ever worked with a blog such as WordPress or Blogger, you may recognize some of the page elements above that you are familiar with.

Of all the new elements that are listed above, some of the most talked about are these:

  • article – an independent piece of content in a document
  • audio and video are less dependent, sometimes not dependent, on plug-ins to play multi-media content in HTML5
  • canvas – probably one of the most talked-about element in HTML5, it is used to render dynamic bitmap graphics on the fly in graphs or games through the use of JavaScript and other dynamic content tools
  • footer, header, and nav – all the regions of a page typically coded in most sites, but especially in blog sites

There are also many new APIs for HTML5 that were not part of HTML4 making using, playing, watching, and interacting with web content a little easier for web servers, computers, and users alike.

Many new mobile devices such as the Apple iPad are using HTML5, as are other desktop browsers, but none fully utilize HTML5 – yet. Currently the top contenders for the use of HTML5 according to HTML 5 Test website are the following (scores indicated out of a possible of 400 points each):

  1. Google Chrome v10.0.648 – 288 points
  2. Opera v11.10 – 258 points
  3. Mozilla Firefox v4.0 – 255 points
  4. Apple Safari v5.0.3 – 228 points
  5. Microsoft Internet Explorer v9 – 130 points

Browsers are working hard to adopt these new standards, and often standards change as challenges for global implementation arise.

While HTML5 offers some great ways to use JavaScript and built-in processes to provide content a bit faster and with less reliance on plug-ins and add-ons, the changes to CSS3 are substantial too! While changes to how a page displays has been controlled by CSS (cascading style sheets) for over a decade, the slow adoption in consistent support of CSS styles has made it tough on users and developers alike.

While you have been able to add rounded corners, drop-shadows, and gradients to pages with CSS for some time, some of the most prominent browsers (cough, cough, IE) have not provided support for many ‘standard’ CSS rules. So developers often have to write separate style rules for specific browsers. Been there, done that, don’t want more of it!

In addition to rounded corners on an HTML page, CSS can now rotate content, it can change the opacity of a page element with RGBA (RGB for colors: RED, GREEN, and BLUE, and A for “alpha” or transparency). So you don’t have to use a semi-opaque PNG file to fill a DIV, but you can just say ‘make this DIV 50% transparent’. SO much easier!

Below is a screen capture from CSS3PIE. They offer tools to allow Internet Explorer to support standards-based applications of CSS. Normally getting IE to render CSS consistent with other browsers is a wash.

The sample below shows some cool CSS3 style examples you might like using on your own site! Note the redundancies in the CSS code below the sample. You’ll see how browsers ‘see’ the styles are NOT the same (click image for a larger view)…

CSS3 Sample Pie Tool Example

  • BORDER-RADIUS: is the new CSS3 definition for HTML5 documents to display rounded corners on DIVs.
  • WEBKIT-BORDER-RADIUS: is now Apple’s Safari browser and Google Chrome recognize rounded corners.
  • MOZ-BORDER-RADIUS: tells Mozilla and Gecko how to display rounded corners

So as you see, making all browsers play the same game with HTML and CSS styles could really improve our lives, both in time saved making pages online, and time reduced viewing content. But it may not save the world…

Tags: , , , , , , , , , ,

Auntie em, auntie em!

July 2, 2009 in Design, Web & Social Media by Roger | No comments

Web technology has come a long way in a few short years. I’ve been surfing the wave of these new developments as they have come along.

To see just how far we’ve come online, check-out the Internet Archive for a history lesson.

In the 90s, not much was possible unless you used a lot of imagery to make a page look ‘designed’. Today with the use of CSS, pages have finally begun to shape-up and mirror their paper-clad cousins in print media. You can add fonts, colors, graphics, positioning to page elements, and if done well, they will look pretty much the same on any browser (yes even IE).

Over the past few years, I’ve preferred to build my pages using ‘pixels‘ versus ‘points‘ or ‘%’. Why? For me, it was due to consistency. I could define an <h1> tag for a page headline as “16pt” and it might look fine for me, but on a Windows computer, the page might get horsey (and huge!).

On the other hand, if I said that an <h1> tag should be “16px“, I could almost always guarantee that regardless of computer or platform, the font and page would be pretty consistent.

Over the past few years using “em” has been the size designation of choice.

Web developers know that an “em” is a percentage of the body font size. So if you have a headline (<h1>) defined as “2.5em” that means the headline will be 250% larger than your body copy. Or if you have a caption and you want it to be tiny, you might define it as “.3em” (or 30% of the body size). So if you had body copy defined as “12px” as a rule, your caption would be just “4px” tall, and your headlines would be “30px” tall. Make sense?

But like all good things, there are potential problems. I recently noted that if I define my browser font settings so that all my fonts use a specific font and size in Firefox (which I tend to do), pages that show content based on a combination of “em” and “%” without a fixed “px” size, can really get small.

The CSS for BINGenuity.com uses “76%” as the designated size for body copy. For most folks this works fine. But for me, since I have designated specific fonts sizes for my page, this CSS style takes my 12pt font size, and then takes it down to 76% through the page’s cascading style sheet (CSS). So I get a rather small standard body copy size of about 8px.

Thankfully my eyes are pretty good (for now) and I can read things much smaller, but it is tough.

The point being made is that we need to consider users, like me, who like to define their own fonts and sizes. If we are using CSS that is based on “em” and “%” for fonts without a defacto size in pixels, we might end up with some strained user eyes.

But we can’t always be safe defining a page based on pixels either. If a user has a screen resolution set very high, a base font of “12px” might still be tiny.

So test and compare before deciding on what works best for you.

Tags: , , , , , , , , , , , , , , , , ,

« Older entries