Prev: Italic fonts vs. Slanted letters
Next: Style sheet question: difference between div#score vs. #score
From: Andy Dingley on 29 Mar 2010 06:30 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.
First
|
Prev
|
Pages: 1 2 Prev: Italic fonts vs. Slanted letters Next: Style sheet question: difference between div#score vs. #score |