EzPortal - Portal Software for Forums

EzPortal - Made to Fit Your SMF Forum - Glad You Found Us!
+- +-

UserBox

Welcome, Guest.
Please login or register.
 
 
 
Forgot your password?

+- Recent Posts

Re: ezPortal 4.0 Released! by EzPortal
September 07, 2018, 02:44:21 pm

Re: ezPortal 4.0 Released! by JorgeAVM
September 07, 2018, 02:28:46 pm

Re: ezPortal 4.0 Released! by JorgeAVM
September 07, 2018, 02:04:13 pm

Re: ezPortal 4.0 Released! by EzPortal
September 07, 2018, 01:56:41 pm

Re: ezPortal 4.0 Released! by JorgeAVM
September 07, 2018, 01:48:49 pm

ezPortal 4.0 Released! by EzPortal
August 13, 2018, 02:27:14 pm

Re: How to add pictures on recent post ezportal front page by Botango23
June 30, 2018, 03:38:18 am

Re: How to add pictures on recent post ezportal front page by EzPortal
June 29, 2018, 06:21:42 pm

+- HTML Menu


Sample HTML Block Usage - You May Custom Code it, as needed!

Author Topic: CSS Lists: Part 2  (Read 7280 times)

0 Members and 1 Guest are viewing this topic.

Offline Maxx

  • VN Vet E4
  • Hero Member
  • *****
  • Posts: 560
  • Karma: 8
  • Gender: Male
  • Web Designer
    • SurfaceThemes - Web Design Ideas Classic Rock
CSS Lists: Part 2
« on: May 08, 2010, 02:36:29 pm »
CSS Lists: Part 2

In CSS Lists: Part 1, we took a plain HTML list, encased it in a DIV, and used CSS to style the list by accessing it through the DIV's decendant-elements. Here was how the list looked like when we finished styling it (before re-adding the markers):


    * List Item 1
    * List Item 2
    * List Item 3

It's now clearly a navigational element, with mouse-over reactions to boot. Let's look at a few variations we can achieve simply by playing around with the CSS, while leaving the HTML as it is. Needless to say, if we were to add HTML elements, there would be more for us to style, but for now, we'll stick to the original structure.

We'll start with a version that intentionally seeks to maximize the graphical detail that we can attain, by styling every element in the HTML. This is also where we'll encounter the first CSS-standards browser issue:


.list_container li {
width: 200px;
border: 1px solid #000;
margin-bottom: 4px;
}
.list_container a {
display: block;
padding: 2px;
padding-left: 10px;
background-color: #A74B4B;
border: 2px solid;
border-color: #C98787 #6C3131 #6C3131 #C98787;
}
.list_container a:link, .list_container a:visited {
color: #FFF;
text-decoration: none;
}
.list_container a:hover {
border: 2px solid;
border-color: #6C3131 #C98787 #C98787 #6C3131;
}


    We left the UL element unchanged, since it mainly styled font properties which will stay the way they are for now. Something may draw curious attention in the code above: The width property was moved from the a element to the LI element -- I'll explain this in a moment. The LI element was also added a 1px black border, and a margin of 4px in order to space the list items out. The main graphic element that was added was the button-like border to the a element. I used the short-hand definition of border-color, defining the four colors clock-wise. Here's what we got:

    * List Item 1
    * List Item 2
    * List Item 3

Considering how little HTML code makes up this list, this is quite remarkable. If you tried doing that using tables, you'd probably have to use about 10 times the code. Now, why was the width property moved from the a element to the LI? Didn't I write in CSS Lists: Part 1 that you're supposed to keep the width property to the a element and the DIV? I did, and for good reason: this specific list will function one way in Explorer 6, and another in Firefox and Explorer 7. This is because Explorer 6 does not implement CSS to exact standards. Let's first go over how the CSS standard browser "sees" things: Think about it like boxes within boxes. If you define the inner box to a certain size, you dictate the outer box to at least that size. Remember that since the a elements have the property of display: block, that they will take up however much horizontal space that they can. Now consider that the a element is the one which dictates the width, and the LI elements wrap around it -- that would mean that the LI elements would have to take into consideration all of the a element's margins and borders, something that not all browsers do well. Instead, we define the LI element's width, and let the a element "flow" within it, taking up however much space it needs, like pouring liquid into a specific-size container. This is easier for the browser to calculate and render. This, again, has to do with the Box Model, as was mentioned in the previous article.

Internet Explorer 6 doesn't support CSS standards fully, and renders things differently: Even though the a's property of display was set to block, the link's active area will only react when the cursor touches the text itself, not the entire list item. In fact, the oddity goes further -- if you've assigned border reactions to the a:hover (and we did), they will indeed take effect, but only if you trigger them by moving the cursor over the link text itself.

Quite a few of you reading this are probably thinking to yourselves: "if this is some experimental future-standards thing that isn't applicable today, why didn't you say so earlier?"... Well, because it isn't. The the above "mix" of properties is already implemented on many sites, for 3 main reasons:
 

    * Even though it does not render exactly the same on the two latest versions of Explorer, both versions render it acceptably. Even if you have no conditioning for alternate CSS when a different browser is encountered, it won't "break" the page (and you could condition different style sheets for the two different browser versions, if you really wanted to, in which you'd use the stricter set of rules).
    * You can always condition to have the browser load a different CSS file if a completely non-supporting browser is encountered. In the meantime, why deny supporting browsers the most effective manner of achieving the goal, using standard CSS?
    * Generally, when you code for the web, you code for the most commonly supported standards, slightly biased upwards, and then make sure that your design 'downgrades' gracefully. This way, you're giving users of modern browsers a better user experience, without hindering users of older browsers. This does not, mind you, take into account mobile browsers, at least not the nonconforming ones. The Opera browser, on the other hand, used on many non-PC devices, is highly standards compliant, and is usually easier to code for than Internet Explorer versions.

Now let's design a list that's close in terms of outcome, but is more lenient on CSS standards. What would we have to do in order for it to render exactly the same in all major browsers? Well, first, we'd use the rule mentioned in CSS Lists: Part 1 -- assign a pixel width property to the DIV, and the a elements. Since we're not going to be assigning anything to the LI's width property, there's no point in adding a border to it, because its width will be dictated by the a elements, which will cause problems if we try to outline it (remember the boxes within boxes problem?). So how close can we get, if we have to change so much? This close:
 

    * List Item 1
    * List Item 2
    * List Item 3

Well, as you can see, one "layer" of detail had to be removed. Of course, we're still using the original HTML code -- we could add HTML in order to achieve the goal, but then, we could just as well use tables and burden the browser further. We're trying to maximize our gain from lists and CSS, so for now, we'll stick with the original HTML. Before moving on to additional functions, let's see a couple of additional design options. First:

 

    * List Item 1
    * List Item 2
    * List Item 3

Two new tricks were employed for this list. The first was to apply a different margin-left for the hover mode, in order for the items to indent when they're touched by the cursor. The second was to add a border-left of a different thickness under the same condition. This adds a strong sense of selecting links, since it appears like pulling tabs. This list won't have any problems with Explorer 6, since it styles the a element, and leaves the LI element alone. Here's the complete CSS of the above list:

 

.list_container ul {
margin-left: 0;
padding-left: 0;
list-style-type: none;
font-size: 12px;
line-height: 14px; f
ont-family: Trebuchet MS, sans-serif, Arial, Helvetica;
}
.list_container a {
display: block;
width: 200px;
padding: 1px;
padding-left: 10px;
background-color: #55F;
border: 1px solid #005;
margin-bottom: 2px; margin-left: 0px; margin-right: 24px;
}
.list_container a:link, .list_container a:visited {
color: #FFF;
text-decoration: none;
}
.list_container a:hover {
border: 2px solid;
color: #00A;
background-color: #FFF;
border: 1px solid #080;
border-left: 15px solid #080;
margin-left: 10px;
margin-right: 0px;
}


    A few things to note: When assigning specific margin values, or specific border values, make sure you have a constant sum of values for the top/bottom, and for the left/right. If you don't, the overall object will actually change size. So why does the a element start with a margin-right of 24px? Because of the potential margin plus the potential border. It starts off with just a 1px uniform border, so the object moved 1 pixel to the right (because it is left-aligned). If you were to move your cursor over it, it would increase its border-left to 15px, and its margin-left to 10px, a total of 25. So again, why 24 instead of 25? Because of the initial 1 pixel border -- it's counted in as part of the left/right sum. When the link is in hover state, the margin-right is reduced to 0.

    And now for something completely different:

    * List Item 1
    * List Item 2
    * List Item 3

Images were expected at some point, weren't they? This is the exact same HTML as the rest of the lists, the only thing that's changed is the use of images. In fact, this is a mild implementation of them -- you can achieve all sorts of effects using filters. Also there's no position change, which, when using images, can be used to create effects like pushing buttons or flipping switches. Here's the CSS:

 
.list_container_f {
}
.list_container_f ul {
width: 140px;
padding: 5px;
margin-left: 0; padding-left: 5px;
padding-right: 5px;
padding-top: 15px;
padding-bottom: 15px;
list-style-type: none;
font-size: 12px;
line-height: 15px;
font-family: Trebuchet MS, sans-serif, Arial, Helvetica;
border: 1px solid #000;
background: url('wall4.jpg') no-repeat;
}
.list_container_f a {
display: block; font-weight: bold;
width: 130px;
padding: 1px;
border: 1px solid #000;
margin-bottom: 3px;
background: url('wall2.jpg') no-repeat; text-indent: 50px;
}
.list_container_f a:link, .list_container_f a:visited {
color: #FFF;
text-decoration: none;
}
.list_container_f a:hover {
color: #FC0;
border: 1px solid #FC0;
}

As you can see, the UL element was heavily styled this time. It was given a background of its own, and a 1px black border. Notice that its padding properties were addressed individually, giving the UL area 5px horizontal padding, and 15px vertical padding. This padding had to be accounted for in the width property, however -- you'll notice a 10px gap between the LI and the UL elements. Also notice that the text-indent property was used to push the text to the right. This is very convenient, since it leaves the padding and margin properties alone, which means you don't have to deal with the implications of setting them. What implications? Well, add margin-left: 30px; to the a element. Then load the page in both Explorer 7, and Firefox. Explorer will assume that you want the a elements to remain within the LI elements, which you'd like to keep within the UL element. Firefox, on the other hand, assumes no such thing. It will simply shift the a elements 30 pixels to the right, and the UL and LI elements will stay right where they were prior to the change. This is just one of many disagreements between the browsers, but don't worry, if you find a disagreement between Explorer 7 and Firefox, there's usually a straight-forward way of mending the problem (unlike, for example, a rendering difference between Explorer 6 and Firefox). Though these problems will crop up every now and then, they're worth the extra work of finding solutions for them: the reward is very little code that defines a lot of details, and renders very easily (and quickly) in the viewer's browser.

In future documents, I'll expand on how additional HTML elements can be styled within lists while maintaining the same course of containing the entire navigational area within one selector class. I'll give examples of horizontal lists, which are very useful, and have a special affinity for background images and buffers due to their fixed height (you can guess where I'm going with this, since the line-height doesn't change...).
If you find this Portal System useful, please consider supporting us with a small Donation!
Check out the How to Section!!
Please remember to keep your back ups, up to date, before you try anything new!

 

Related Topics

  Subject / Started by Replies Last post
0 Replies
5409 Views
Last post May 08, 2010, 02:26:15 pm
by Maxx
2 Replies
17263 Views
Last post April 04, 2012, 02:40:57 pm
by Maxx
0 Replies
2349 Views
Last post January 29, 2013, 04:20:17 am
by skadamo
4 Replies
4016 Views
Last post March 10, 2015, 05:40:19 am
by Maxx
0 Replies
2725 Views
Last post March 10, 2015, 06:48:01 am
by Maxx

+-SMF Gallery

Quick Menu








Members Online

10 Guests, 0 Users
Powered by EzPortal