Mysticpixels

Living life…the cool way !

Archive for February 2008

Zzzzzzz !

leave a comment »

Good Morning !

Yet another day of fights and challenged awaits me…Still diggin deep into my keyboard and staring into my monitor, im just minutes away from breaking my record of latest office stay ever in my career…

Developing CSS for an application, im still enjoying it to the last second. Never have i thought that CSSing would be this much fun. I wants to hear my mind saying to go bit more far into the process, but my fellow organs are just not allowing me to stay any longer…im feeling the tiresness now, have to sleep now, and have to rush to bed 🙂

HAPPY CSSing to ALLLLLLLLLLLL !!!!!!!!!!!!!

Advertisements

Written by Ranjith

February 28, 2008 at 4:06 am

Posted in Professional Life

Not yet another video sharing tool !

leave a comment »

This video sharing app, is not yet another video sharing app on the web. Check out for its usability and the cool UX. Ofcourse, the videos rocks too 😉

http://www.vimeo.com/ 

Written by Ranjith

February 24, 2008 at 8:16 pm

Posted in Techie, UI

Tagged with

Inspirations, inspirations…this video rocks !!

leave a comment »

Hie,

Just slipped into a video on the web and felt that im wrong by not sharing it…this guy just rocks in his creative skill. Watch the video

Episode Seven: 64 Days – Part 2 from mike ambs on Vimeo.

Written by Ranjith

February 24, 2008 at 8:11 pm

Posted in Creativity

Building CSS – Naming conventions and Nomenclature

leave a comment »

Building a CSS from scratch can be an inevitable task for budding UI designers. Since i belong to that genre of the profession, and am already starting to build a brand new css from scratch…and already digging my head deep into the fathoms of web to find out the perfect article that equips me with the best way of naming my IDs and Classes.

The primary point that all those articles are trying to convey is that, naming ids and classes whold be done in a structural point of view with respect to the layout and not in a Visual perspective. ie, giving names that reveal the position, and the scope of the element in the visual mindset. For eg, a ‘leftnav’ could be replaced with a ‘subnav’, which is more structural and helps flexibility. Find inspiration from the following links and get your naming skills sharpened up 😉

  1. http://www.stuffandnonsense.co.uk/archives/naming_conventions_table.html
  2. http://www.stuffandnonsense.co.uk/archives/whats_in_a_name.html
  3. http://meyerweb.com/eric/thoughts/2004/06/18/elemental-nomenclature/
  4. http://www.stuffandnonsense.co.uk/archives/whats_in_a_name_pt2.html

Wishing you all happy css-ing ahead…

Written by Ranjith

February 22, 2008 at 4:25 pm

Posted in UI

Tagged with , ,

Writing browser specific CSS – Conditional Comments !

with one comment

Working around with cross browser compatibility needs you to be equipped with techniques which enables you to write seperate css for various browsers.

Due to its relatively poor level of standards support, Internet Explorer tends to be the subject of most CSS hacks. Luckily, as of version 5, it deliberately supports a rather safe-to-use hack called “conditional comments”. Conditional comments are specially constructed HTML comments that Internet Explorer on Windows may treat differently from other browsers, optionally based on IE’s version number. They can cause Internet Explorer to ignore the markup between comments or to include part of a comment as if it was regular markup. Conditional comments apply specifically to browsers using Internet Explorer’s Trident layout engine, meaning IE-based browsers like Maxthon and Avant handle them like Internet Explorer does while browsers using other layout engines see them simply as regular comments. Internet Explorer on the Mac uses a different layout engine and doesn’t support conditional comments.

The syntax for conditional comments is as follows:

Positive
<!--[if condition]> HTML <![endif]-->
Negative
<!--[if !condition]><![IGNORE[--><![IGNORE[]]> HTML <!--<![endif]-->

condition is one of the following:

IE
Any version of IE
lt IE version
Versions less than version
lte IE version
Versions less than or equal to version
IE version
Only version version
gte IE version
Versions greater than or equal to version
gt IE version
Versions greater than version

version is the version of Internet Explorer, typically 5, 5.5, 6, or 7

HTML is the HTML to be included if the condition does or doesn’t match, depending on the type of conditional comment. When included, the HTML is placed right where the conditional comment is in the source.

For negative conditions, <![IGNORE[--><![IGNORE[]]> can be replaced with --> if the condition is simply IE. The longer version is only needed when Internet Explorer might parse the contents.

The <![IGNORE[ ... ]]> directive is not available in XML, so it is illegal to use it in XHTML. A solution would be to split it up into two special conditional comments: <!--[if !condition]> XHTML <![endif]--> <!--[if !IE]>--> XHTML <!--<![endif]--> where XHTML is the same both places. Note that Internet Explorer 7 and below don’t yet recognize XHTML as a form of XML, so this is merely forward-looking.

Written by Ranjith

February 19, 2008 at 6:00 pm

Posted in UI

Specificity of selectors – The decision makers !!

with one comment

Courtesy: HTMLDOG

If you have two (or more) conflicting CSS rules that point to the same element, there are some basic rules that a browser follows to determine which one is most specific and therefore wins out.

It may not seem like something that important, and in most cases you won’t come across any conflicts at all, but the larger and more complex your CSS files become, or the more CSS files you start to juggle with, the greater likelihood there is of conflicts turning up.

If the selectors are the same then the latest one will always take precedence. For example, if you had:

p { color: red; }
p { color: blue; }

p elements would be coloured blue because that rule came last.

However, you won’t usually have identical selectors with conflicting declarations on purpose (because there’s not much point). Conflicts quite legitimately come up, however, when you have nested selectors. In the following example:

div p { color: red; }
p { color: blue; }

It might seem that p elements within a div element would be coloured blue, seeing as a rule to colour p elements blue comes last, but they would actually be coloured red due to the specificity of the first selector. Basically, the more specific a selector, the more preference it will be given when it comes to conflicting styles.

The actual specificity of a group of nested selectors takes some calculating. Basically, you give every id selector (“#whatever”) a value of 100, every class selector (“.whatever”) a value of 10 and every HTML selector (“whatever”) a value of 1. Then you add them all up and hey presto, you have the specificity value.

  • p has a specificity of 1 (1 HTML selector)
  • div p has a specificity of 2 (2 HTML selectors; 1+1)
  • .tree has a specificity of 10 (1 class selector)
  • div p.tree has a specificity of 12 (2 HTML selectors and a class selector; 1+1+10)
  • #baobab has a specificity of 100 (1 id selector)
  • body #content .alternative p has a specificity of 112 (HTML selector, id selector, class selector, HTML selector; 1+100+10+1)

So if all of these examples were used, div p.tree (with a specificity of 12) would win out over div p (with a specificity of 2) and body #content .alternative p would win out over all of them, regardless of the order.



	

Written by Ranjith

February 19, 2008 at 4:43 pm

Posted in UI

Expanding Box Problem – A frequent showstopper !

with 2 comments

Working around with IE and FF, there are quite a lot of issues that may surface too often and among them is the expanding box problem, wherein a block/container just expands out of its specified width and due to the content within, which may be an unbreakable text or a bigger image that needs more width to contain itself. Similar is the problem with the height also. Following are the solutions for these bugs in a comprehensive mode….these are not exactly a complete solution but still we can live with these… (Courtesy – http://www.positioniseverything.net)

It’s an unfortunate fact that Internet Explorer will always incorrectly expand any dimensionally restricted block element so that oversize content is unable to overflow, as the specs require that content to do. I will be comparing IE/win’s way with the correct behavior as seen in Firefox. The W3C says a rigidly sized block box should allow oversize content to protrude or overflow beyond the edges of the sized box.

There is no real “fix” for IE/win’s incorrect behavior, except to work around or avoid it. Several possible workarounds will be detailed as I discuss the issue.

Setting Up the Problem

Have you ever tried to do a two-column float layout like in the graphic below?

And after some content changes, it turns out like this when viewed in IE?


Screen shot in IEwin

It’s a “float drop”, and it’s caused by having oversized content in a fixed-width floated div that must fit into a particular spot in the layout. In this case, the oversized content is the URL string in the green float.

To understand what is happening, first consider our HTML structure:

<div id=”wrap”>
<div id=”masthead”>My header</div>
<div id=”leftnav”>Typical Left Nav</div>
<div id=”main”>My main text here…</div>
<div id=”footer”>My footer</div>
</div>

This is a common two-column structure, where we have a <div id=”masthead”> (colored blue), followed by two floated columns: <div id=”leftnav”> (colored green) and <div id=”main”> (colored red). The two columns are made to sit side-by-side because they both get the CSS float: left;.

#masthead {background-color: #006699;}
#leftnav {background-color: #99CC00;
float: left;
width: 50px; }
#main { background-color: #D54500;
float: left;
width: 340px; }
#footer { background-color: #CCCCCC;
clear: both;}

Finally we have the <div id=”footer”> (colored dark gray) where we clear the float — forcing the footer to clear itself to a position below the earlier floated columns.

All the page elements are enclosed in a wrapper div: <div id=”wrap”>. This wrapper is set to a width of 390px, enforcing a rigid pixel with on the layout.

#wrap {
width: 390px;
}

We want our green left column to take up exactly 50px of the available wrapper width, and the main column will occupy the remaining 340px, so we have specifically set these widths in the CSS:

#leftnav {background-color: #99CC00;
float: left;
width: 50px; }
#main { background-color: #D54500;
float: left;
width: 340px; }

And if you look at the code in both Firefox and IE/win, things looks as expected.

view live code


Screen shot in Firefox and IE/win

So far so good, but real web pages are messy, and sometimes they receive content that the designer did not test in advance. When that happens, suprising things can happen.

The Cause Of The Problem

One common cause of box expansion in IE/win is when you have oversized content such as a long “unbreakable” URL, with no spaces where word wrapping may take place. What if our <div id=”leftnav”> consists of this content:

<div id=”leftnav”>
http://AnUnbreakableURL.com
Left Nav
</div>

view live code
View live demo in IE/win to see incorrect behavior. View in Firefox for correct behavior.

The graphic below shows what you will see if you view it in Internet Explorer for Windows (IE/win):


Screen shot in IE

Note how IE/win has expanded the width of div#leftnav (green box) to accommodate the unbreakable URL string. div#leftnav is no longer 50px wide, as specified by its given CSS width value. After this expansion, div#main (red box) does not have room to fit inside our fixed-width layout next to div#leftnav, and is forced to go below. Since we did not specify an overflow property value for div#leftnav, its overflow property value defaults to visible. The expansion of div#leftnav is a clear violation of the W3C specification for the overflow property, which covers the default value “visible” this way:

Visible (the default or “initial” value for the overflow property )
“This value indicates that content is not clipped, i.e.,
it may be rendered outside the block box”.

Note that it does not say that the box should be enlarged when content is too big to fit. IE/win should respect the assigned width, and should not expand the div. The URL should be allowed to overflow outside the green box.

Notice how the text “Left” and “Nav” are on separate lines? Why don’t they just appear on one single line, since the green box is clearly wide enough to hold them? That is because IE/win seems to not know when it has expanded a box!

I will demonstrate with an oversized image followed by a paragraph, both inside the green #leftnav box:

<div id=”masthead”>My header</div>
<div id=”leftnav”>
<img src=”masthead.jpg” width=”267″ height=”50″>
<p>An image followed by a paragraph of text</p>

</div>
<div id=”main”>My main text here. … </div>
<div id=”footer”>My footer</div>


Screen shot in IE

view live code

The paragraph following the image is colored a darker shade of green so that you can see what is going on.

Note how the image has expanded the lighter green #leftnav div in IE/win. However, nested block elements (such as our paragraph) do not expand to fill the newly available area in the expanded container div! You would think that the dark green paragraph would fill the entire width of its light green container as usual, but it doesn’t. Apparently the paragraph does not “know” that the light green container has been expanded by the large image in the same container, so the paragraph below stays the same width and doesn’t expand to fill the available space.

This effect can cause coders to think the problem is in the paragraph, when really it’s the image and container that are causing the IE/win problem. Suspicious right side spaces like this should be a warning that expansion has occured somewhere.

The Way It’s Supposed To Be

Now let’s look at that “long URL” layout code in Firefox.

view live code
View in Firefox (shown below) to see correct behavior. View in IE/win for incorrect behavior.


Screen shot in Firefox

Firefox respects the specified width on the paragraph, but what has happened to the text? Is it clipped, in violation of the specs? Not to worry, the text actually does overflow correctly. We just cannot see it because the red background on the adjacent red float is covering it up. Let’s remove the background from div#main and see if it’s hiding back there.

#main {
float: left;
width: 340px;
/* background removed */
}

view live code


Screen shot in Firefox showing correct overflow

Clearly Firefox does exactly what the specification requires, letting the long URL go beyond the edge of the surrounding green box. This does cause that URL to go behind the text in the red box, but at least the floated layout structure is not damaged. Float dropping in such cases is a lot more harmful to a web page than text overlapping, in the opinion of most people.

Some Possible Workarounds

Let’s examine some workarounds that might keep IE/win from wrecking our layout.

Using “word-wrap: break-word”

Try adding the word-wrap property with the value break-word.

#leftnav {
background-color: #99CC00;
float: left;
width: 50px;
word-wrap: break-word;
}

view live code


Screen shot in IE/win

Although this has no effect on Firefox, it does force IE/win to break up “unbreakable” text so that it no longer expands the width of the box containing the text.

Be aware that word-wrap is a proprietary Microsoft CSS rule. It is not part of the W3C specification at this time, and will invalidate the page unless that code is hidden inside a Conditional Comment, like this:

<!–[if IE]>
<style type=”text/css”>
body {word-wrap: break-word;}
</style>
<![endif]–>
That style block is contained in the CC, which can go in the head section of the web page. Only IE/win will look inside the CC, while all other browsers and the W3C validator see only an ordinary HTML comment, and ignore everything inside. It’s not a pure solution, but it does work safely on potientially damaging long text strings, and does validate too. Notice that this rule inherits to all page elements from the body element, providing page-wide protection.

Using overflow: hidden

According to the spec, another possible value for the overflow property is hidden. Let’s see what happens when we apply it.

#leftnav {
background-color: #99CC00;
float: left;
width: 50px;
overflow: hidden;
}

view live code


Screen shot in Firefox and IE/win

The overflowed text is hidden, or clipped. By doing so, IE/win no longer “needs” to expand the column width. That’s good, but some content can never be seen now, and some browsers have been known to show odd bugs when overflow is changed from the default value “visible” for complex CSS layouts, so this fix is less than ideal.

Another drawback of the “hidden” method is that IE/win demands that the boxes having this overflow fix must have widths applied to them. So for example, consider a nested paragraph in one of those floated columns above. The floats do have widths but the nested paragraph will normally be left widthless. If the overflow: hidden; trick is used on the paragraph, it will fail in IE/Win. But, if it’s used on the surrounding float it will then work properly, because the element with the overflow rule also has a width applied to it.

More Oversized Content

Keep in mind that oversized content does not only mean very long URLs. You might also have an image that is too big for the width allowed for it in the container. Below is a demo graphic showing an image that’s just a bit too wide to let the red box fit next to it:

Or a user might enlarge the browser text size, making a normal word too wide to fit, just like the long URL:

Word-wrap only works on text, not on images, but both these problems can be handled by overflow: hidden as you can see here.

So overflow: hidden can protect against oversize text, images, and even oversize tables, but may clip off some content. Using word-wrap preserves the text but doesn’t affect oversize images or tables. As always, web design means making hard choices.

Expansion in the Vertical Direction

Just as IE/win can incorrectly expand an element’s width, it can also incorrectly expand an element’s height. Take the following example where we have <div id=”cornerbox”> inside <div id=”masthead”>.

view live code

HTML:

<div id=”masthead”>
<div id=”cornerbox”>
Lorem ipsum dolor …
</div>
</div>

CSS:

#cornerbox {
width: 150px;
height: 50px;
background-color: #99CC00;
}

We now specify the height of the green div#cornerbox to be 50px. Since our text is too tall to be accomodated within this height, the text should overflow the green box. The correct behavior looks like the following graphic, as shown in Firefox. Similarly, all other modern non-IE/win browsers such as Opera and Safari will behave in the same manner.

However, when we take a look at this same code in IE/win, it looks like the following:

IE/win has incorrectly expanded the height of the green div#cornerbox to accommodate the excess text, and that in turn has expanded the height of the blue div#masthead! Neither div remains at the 50px height specified on #cornerbox after IE/win gets a look at that tall text. Both expansions are incorrect behavior, and are violations of the overflow specification.

Unlike IE/win, the IE/mac browser will not expand the green corner div (good), but it will for some reason incorrectly expand the blue masthead anyway! (not good)

This kind of inconsistency can play havoc with height controlled layouts. Suppose that you have a background image attached to your masthead and the image is only 50px high. After expansion you won’t have enough image to fill the expanded masthead.

Non-IE/win browsers will overlap some content, yes, but having two different apparent problems is very hard on newbies when trying to debug a design across browsers.

view live code
View in IE/win (shown above) to see incorrect behavior. View in Firefox for correct behavior.

HTML:

<div id=”masthead”>
<div id=”cornerbox”>
Lorem ipsum dolor …
</div>
</div>
<div id=”bodytext”>
This is the main content of my web page.
</div>

CSS:

body { margin: 0; padding: 0; }
#masthead {
background-color: #006699;
background-image: url(masthead.jpg);
background-position: 150px 0px;
background-repeat: no-repeat;
}
#cornerbox {
width: 150px;
height: 50px;
background-color: #99CC00;
}

Using word-wrap: break-word won’t help us here. However, we can set the overflow property to hidden to put our layout back in place.

#cornerbox {
width: 150px;
height: 50px;
background-color: #99CC00;
overflow: hidden;
}

view live code


Screen shot in IE/win and Firefox

Now IE/win no longer expands the element. And best of all, it behaves consistently between both IE/win and Firefox.

Clearly there are options available, but the best and most common option employed for web pages is to not use height at all. Letting height be the default auto will let content determine the height and avoid the IE box expansion problem. Unless the content’s displayed height can be rigidly controlled, applying a height to the container box will only cause trouble.

Summary

In summary, both word-wrap: break-word and overflow: hidden are possible workarounds that will make Internet Explorer respect our specified dimensions. The method of overflow: hidden works in more situations — such as oversized images and vertical expansions, but at the cost of possibly clipped content. The word-wrap: break-word; method won’t clip content, but is useless on anything but text. Now that you have seen the effects of both, their possible employment will depend on specific situations and preferences.

Written by Ranjith

February 19, 2008 at 4:18 pm

Posted in UI