From: Andy Dingley on
On 29 Mar, 03:50, "A. Deguza" <deg...(a)hotmail.com> wrote:

> I have been learning about the use style sheets to build web pages for
> the past month or so.

> The page refers to an div ID of "scores". On the style sheet I see a
> div#scores section.

> Why have a "div" before "#name"?


It's hard to answer this without knowing just how much you know about
CSS selectors. The precise meaning of the question could be either
obvious or subtle.

In the simple case, this means that the selector only applies to
elements that match _BOTH_ conditions, i.e. they're not just elements
with an id of "name", they're also <div> elements.

In the more subtle case, they have a "div" before "#name" simply
because they can (i.e. it works, it's not wrong to). However (as you
might have realised) ids must be unique in a compliant document, so
div#name can't match to anything that wasn't matched by #name anyway.
Nor should div#name exclude anything that #name would have matched,
assuming that this HTML document only placed that id on that element
type anyway.



In common practice, this is often a bad practice and should be avoided
- but only when you take a broad and rather complex view of HTML+CSS
design. It's used when some pages match div#name and others match
span#name or form#name instead. Remember that ids must be unique on a
page, but sites often share one CSS stylesheet across many pages.

Imagine a web site of many pages, and a somewhat consistent menu
across these pages. Sometimes this menau is coded as <ul>, sometimes
as <div><ul> As <ul> is used for other tasks too, the menu is always
identified by an id "menu".

So on some simple pages, HTML and a CSS selector of <ul id="menu" >
and #menu { } are sufficient. ul#menu {} could be used too, but would
be pointless (as above).

On other pages, <div id="menu" ><ul> are used instead (e.g. these
menus require some extra border or whitespace around them). The
selector here can be div#menu {} or div#menu ul {} to style either the
menu list itself or its container (they're going to need different
styling: obvious content, discrete spacer).

#menu no longer works. The selector "couldn't tell" if it was matching
the ul or the div (and they need different styling) on different
pages. Placing the id="menu" always on the <ul> (i.e. <div><ul
id="menu" >) doesn't work, as there's no way to write a selector for
the <div> with a predicate that only matches those <div>s that contain
the <ul>s.

The problem is the temptation to write "sophisticated" CSS that
"works" for both pages. Selectors like this:

div#menu {
background-color: bland;
}

div#menu ul,
ul#menu {
background-color: striking;
}
div#menu ul {
margin: smaller; /* No needed so much, we've got a big border
from the <div> anyway */
}

work for all of these pages, in either structure, and apply the right
styling to each combination.

This is a bad approach and should be avoided (yes, really). It looks
tempting, but it soon grows to be unworkable. Sites collect vast
stylesheets that are applied across every page, but only a fraction of
each stylesheet is ever applied on the same page. The idea is good,
"one magic stylesheet makes everything work" but in practice it's too
complicated to make workable for anything big and complicated
enough.

It's a lot better to instead keep the structure consistent across
pages within a site, certainly across the scope of the stylesheets
(many sites use multiple stylesheets, perhaps one for "lists of
articles" and another for "article bodytexts"). Even if most menus
didn't require that extra <div>, if you make it a rule that all pages
on that site will code their menus as <div id="menu" ><ul> and that
some pages will simply CSS hide the unwanted extra capacity, you'll
find yourself with far simpler CSS overall on a complex site.