Wednesday, February 01, 2006
by Nik Kalyani
Wednesday, February 01, 2006 11:25:26 AM (Pacific Standard Time, UTC-08:00)

Sometimes, it is necessary to override stylesheets defined on a page or to add additional stylesheets, perhaps for different media. The script below defines a JS object that allows you to define stylesheets for screen/print for IE/Other browsers. It then adds them to the page dynamically.

In the code below, you can ignore the portion from //BEGIN to //END. The snippet at the end is all that needs to be changed. Se the desired values for “picker.ieScreen,” “picker.iePrint,” “picker.otherScreen,” and “picker.otherPrint” and the code will take care of the rest.

<script language="javascript">

// BEGIN: styleSheetPicker object definition
function styleSheetPicker()
{
   this.ieScreen = this.iePrint = this.otherScreen = this.otherPrint = "";
}

styleSheetPicker.prototype.render = function()
{
   if (document.createStyleSheet)
   {
    if (this.ieScreen)
     document.createStyleSheet(this.ieScreen);

    if (this.iePrint)
        {
     var ieP = document.createStyleSheet(this.iePrint);
            ieP.media = "print";
        }
   }
   else
   {
        var head = document.getElementsByTagName("head")[0];
    if (this.otherScreen != "")
            head.innerHTML += "<link rel=\"stylesheet\" href=\"" + this.otherScreen + "\">";

    if (this.otherPrint != "")
            head.innerHTML += "<link rel=\"stylesheet\" media=\"print\" href=\"" + this.otherPrint + "\">";

   }
}
// END: styleSheetPicker object definition


var picker = new styleSheetPicker();

// IE stylesheets
picker.ieScreen = "ie.css";
picker.iePrint = "other.css";

// Other browser stylesheets
picker.otherScreen = "default.css";
picker.otherPrint = "other.css";

picker.render();

</script>

 

#    Comments [1] - Trackback    

CSS | Javascript

 Thursday, August 04, 2005
by Nik Kalyani
Thursday, August 04, 2005 9:04:11 PM (Pacific Standard Time, UTC-08:00)

CSS gives you the ability to control HTML presentation with a fair amount of granularity. However, if you take a peek at stylesheets from random websites, you will see that a vast majority of them define styles using Type, Class and ID selectors. This is fine, but only barely scratches the surface when exploring the capabilities of CSS. I'll try and shed some light on the different CSS selectors and hope it will help you create cleaner, more-compliant HTML.

Let's start with Type Selectors. These are the most basic of selectors as they require nothing more than an HTML element.

p { background-color: blue; } will change the background of all <p> elements on the page unless it's overridden with a local style definition or a nested element's style definition.

You can define the style attributes for multiple type selectors by separating them with commas, like this:

p, span, div { font-family: Verdana, Helvetica, Sans Serif; }

Take special note of the comma separator as it is often a hard to debug problem. In CSS, the comma is a separator for multiple selectors to which the style definition should apply, while the space character indicates a descendant selector which we'll examine in a moment. So the following two are completely different:

p, span { font-size: 11pt; }

p span { font-size: 11pt; }

Class Selectors allow you to define style attributes based on the value of the "class" attribute. The most common use of the class selector is like this:

.BorderedBox { border: 1px solid black; }

This would make all elements with a class="BorderedBox" attribute inherit this style. For example:

<div class="BorderedBox">Some text</div>

You can make this more interesting by keeping the class name the same, but varying the elements to which it applies. This gives you the ability to granularly define a style class based on the element to which it is being applied, like this:

p.Highlight { background-color: yellow; }
div.Highlight { background-color: yellow; border: 2px solid black; }

<p class="Highlight">Some text</p>

<div class="Highlight">Some text</div>

Although it is rarely used, CSS does have the capability to define hierarchical class selectors. I suspect it's not used a whole lot because it is not very well-known. In the example below, although there is no style definition for the class "NewHighlight," this class is used in a hierarchical class selector to define the appearance of a headline and body text.

.NewHighlight.Headline { background-color: yellow; font-size: 14pt; }
.NewHighlight.BodyText { background-color: #efefef; font-size: 10pt; }

<p class="NewHighlight">
<span class="Content">

<div class="Kicker">this is a kicker</div>
<div class="Headline">This is the headline</div>
<div class="BodyText">This is the body text</div>
</span>
</p>

This hierarchical class selector technique is very useful for defining zones within your page. You can have a series of standard class definitions used in your markup and completely change their appearance simply by changing the class label of the outermost wrapper element ("NewHighlight" in the example above).

While on the subject of hierarchical selectors, let's tackle the three selectors reserved for applying styles based on an item's position. The selectors are Descendant Selector, Child Selector and Adjacent Sibling Selector.

A descendant selector allows you to apply a style attributes to an item based on its order in a hierarchy. "Descendant" is often incorrectly interpreted to mean "direct descendant." In CSS, this is not the case. An item is selected as long as it is a descendant of the item before it, regardless of whether the relationship is child, grandchild, great grandchild etc. But, I'm getting ahead of myself. Let's first see an example of a descendant selector style definition:

.DescendantExample div a { background-color: red; }
.DescendantExample div span a { background-color: yellow; }

[Note: The DescendantExample class in the hierarchy exists merely to facilitate displaying examples in this blog. If I did not use it, all instances of the hierarchy on the page would be displayed in the style I have picked for the example. This would make the page look quite ugly.]

Recollect that earlier I cautioned against using a space where a comma was intended (i.e. for multiple items). As you can see from the above example, the space character is used for defining a hierarchical relationship. Using a comma would have completely changed the intended definition.

Here's how the above appears in practice:

<div class="DescendantExample">
<div>This is a <a href="#">link</a></div>
<div><span>This is another <a href="#">link</a></span></div>
<div><span><p>This is another <a href="#">link</a></p></span></div></div>

The overall definition is controlled by the wrapper <div> element with a class of "DescendantExample" which is the first in the hierarchy. Then a match is made based on the order of descendant element. For the first <div>, the match is <div> <a>; for the second it's <div> <span> <a> and it's the same for the third. Alert readers might notice that the <div> <a> hierarchy also applies for the second and third examples, however it is ignored in favor of the <div> <span> <a> hierarchy. This is because of how CSS computes specificity. The rules for this, although not very complex, are not simple to understand, so I'll leave it as the topic of a future blog post.

Child selectors are a specialized form of descendant selector. While descendant selectors could care less about what a descendant items level is in the hierarchy and how many intermediate items appeared before the descendant item, child selectors are pickier. In order to match a child selector, the items in the hierarchy must have a direct parent-child relationship without any intervening elements. Child selector hierarchy items are separated by the > symbol.

div.ChildExample  > a { background-color: red; }
div.ChildExample  > div > span { background-color: yellow; }

Here's how it appears:

<div class="ChildExample"><a href="#">This works</a></div>
<div class="ChildExample"><span><a href="#">This does not work because <a> is not a child of <div></a></span></div>
<div class="ChildExample"><div><span>
This works, too
</span></div></div>

(Note: Your mileage with the above example will vary since not all browsers implement this correctly.)

That's it for Part I. In Part II I will explore the remaining selectors: Adajcent Sibling Selector, Universal Selector, ID Selector, Simple Attribute Selector, Exact Attribute Selector, Partial Attribute Selector and Language Attribute Selector. In Part III I will explore pseudo-classes and pseudo-elements. Stay tuned.

 

 

#    Comments [0] - Trackback    

CSS

 Wednesday, March 02, 2005
by Nik Kalyani
Wednesday, March 02, 2005 9:56:49 PM (Pacific Standard Time, UTC-08:00)

I have had it with designing cross-browser web pages without tables.

OK, I get it. An HTML table was never intended to be used for pixel-perfect design layouts. For that matter, HTML was never intended to be used for pixel-perfect design layouts, period.

But, I have tried to go with the flow. The design gurus say, don’t use tables…use CSS. But from a productivity standpoint, that stinks. I have spent countless hours trying to get CSS-based <div> elements to do my bidding. And you know what. I am done. I will try and use CSS-based layouts when possible, but if I have to spend more than a few minutes trying to get things to position properly, I am back to using tables.

Now, I am no designer, but then I am not completely clueless about CSS either. I tell you, with the number of workarounds/hacks that you have to use to get cross-browser layouts to work using CSS only, I am surprised that people still continue to pursue this type of design. Doesn’t productivity matter more than “View source…”?

There is nothing inherently wrong with tables in HTML unless your overall page is one giant table. Then the user is going to wait until the browser can figure out how to lay the table out. For intermediate content, I don’t see how using tables is a big problem if my targeted browsers are IE and Firefox and I use them for layout of elements within the page. (Yes…I am aware that there are other browsers, but just as people have a choice of browser, I have a choice of the browsers I will support.)

I develop web applications. If my app enables the user to complete the task it was intended for quickly and easily, then as far as I am concerned, tables or no tables, my app is a success. So until all the browser developers get their act together, I am going to keep my tables.

 

 

#    Comments [0] - Trackback    

CSS

 Tuesday, February 22, 2005
by Nik Kalyani
Tuesday, February 22, 2005 5:24:30 PM (Pacific Standard Time, UTC-08:00)

There is a lively discussion on the DotNetNuke Core Team forums about DNN stylesheets. If there is one area of DNN that I don't care much for, it would be in how DNN handles stylesheets. It's a bit messy and leaves even the most CSS-savvy designer scratching their head about how/where/why a particular style was inherited by a particular element.

Personally, I don't think there is a need for host, portal, skin, container and module stylesheets. There should be one stylesheet used on the page and that is the skin stylesheet. All classes required by a page where the skin is applied should be defined in this stylesheet. While this may require a bit more work, it is definitive and portable.

 

#    Comments [5] - Trackback    

DotNetNuke | CSS

RSS feed
Search and Links
Bling

View Nik Kalyani's profile on LinkedIn

TechBubble
www.flickr.com
This is a Flickr badge showing public photos from techbubble. Make your own badge here.
Statistics
Total Posts: 216
This Year: 19
This Month: 0
This Week: 0
Comments: 226
About the author/Disclaimer

Disclaimer
The opinions expressed herein are my own personal opinions and do not represent my employer's view in anyway.

© Copyright 2008
Nik Kalyani
Sign In
All Content © 2008, Nik Kalyani