h1 slogan dilemma

Yes, a good formulation: legitimate tag. But this is a CSS job, not a markup job. And <br> is hardly a legitimate tag here. The three lines are for presentation, so a CSS solution is best: em width, or a HTML + CSS solution, second best: <span> + display:block.

<br> is to be used when no CSS is expected. It’s the easiest way, when CSS is no game. But it wouldn’t make sense then, to have a three lines h1. The rest of the required presentation can’t be done with tags alone. And when author CSS come into play, <br> should get display:none.

For this case, there is no need to make h1 appear on three lines when author CSS is not applied, no matter what those cases are, or their use procentage.

As a solution for CSS aplied cases, <span> is a straightforward sollution.

There is though a pure CSS solution, em width, which I still think is the best. It may require changes, if font size is changed also, but zooming will not break it.

Like this case…

Legitimate question though – I generally assume NOT…

Though as mentioned, I lean towards using the extra spans for OTHER reasons. Even if I were to use BR, which I don’t entirely see something wrong with, my markup would still end up:

<h1><span>ΜΑΚΕΔΟΝΙΚΗ<br />ΕΣΤΙΑ<br />ΑΘΗΝΩΝ</span></h1>

Since the outer span I’d be using to apply the second header image, which is presentational and as such has no place in the markup as a IMG tag…

Which is to say, I’d be replacing ALL of this:



			<h1 id="content_slogan">&#924;&#913;&#922;&#917;&#916;&#927;&#925;&#921;&#922;&#919;<br />&#917;&#931;&#932;&#921;&#913;<br />&#913;&#920;&#919;&#925;&#937;&#925;<br />
			<img class="bust1" src="http://www.makedonikiestia.gr/images/makest/alexander_the_great_marble_bust_222px.jpg" alt="alexander_the_great_marble_bust" width="222" height="222" />
			<img class="bust2" src="http://www.makedonikiestia.gr/images/makest/philipos_2_of_vergina_macedonia-222px.jpg" alt="philipos_2_of_vergina_macedonia" width="222" height="222" />
			</h1>
			<div class="clear"></div>

from the original, with just “h1, a span and two BR”, or “h1 and two span”.

Basically, I’d be ok with it either way.

Ok, didn’t get to work on this last night, but I just belted this out over the past few minutes:

Which the HTML got a bit of a rewrite since the post above, mostly to remove further redundancies and as part of throwing the accuweather javascript in the trash. As with all my examples the directory:

Index of /for_others/peterb

is wide open for easy access to the gooey bits – which given I re-optimized all the images…

Valid XHTML 1.0 Strict, Valid CSS 2.1, Same functionality without one shred of javascript to be found anywhere. (That accuweather one was particularly horrid – 27k of “For WHAT?!?”). Gracefully degrades images off, CSS off images on, both technologies off, handles most narrow screen display modes (like Opera’s “Small Screen” rendering) perfectly… and tested working IE 6, 7, 8, 9, FF 3.5 and 4, and the latest flavors each of Saffy, Chrome and Opera… Though IE6/lower will get a degraded page that shows the content of the hovers instead of the effect – something I’m increasingly doing on pages instead of throwing a script fix at it.

… and takes the page down from ~300k in 25 files to 75k in 16 files. Partly from reducing the HTML file from 27 down to 12, MOSTLY from throwing all the “javascript for NOTHING” in the trash.

I’ll write up a line-by-line how/what/why of the choices made, pointing out the problems I saw in the original code.

Ok, so starting from the top of the original’s markup and comparing it to the new one.

First up, the original uses a transitional doctype – which is to say it’s HTML 3.2 slapped up there any old way with some new functionality on it; the pinnacle of 1998 coding. Tranny is for old/outdated markup, not for building new sites.

That it uses a XML prolog (the “<?xml version=” bit) automatically throws IE into quirks mode – broken box model and unreliable/different jscript rules abound – so that line should be deleted outright if you care about supporting IE.

There are a whole slew of pointless meta tags I didn’t bother copying over… generator for example is a pointless waste of bandwidth, setting robots to the DEFAULT BEHAVIOR seems a bit silly, etc, etc…

The inlined CSS has NO PLACE IN THE MARKUP – so swing the giant ogre axe at that. This is ESPECIALLY true of your “IE fixes” – which appear to not only be completely pointless/unnecessary settings, it completely shtups any chance of making IE behave. The body tag settings ALONE are a serious whiskey tango foxtrot.

So we finally get down to body, and this thing is knee deep in unnecessary elements, stuff that doesn’t belong in the markup, and just outdated methodologies like clearing DIV. Where you open three div before you even get to the h1, I use a single DIV for fixing the width. Since there should only ever be one H1 on a page, the H1 doesn’t need a ID or class on it! Both of the image tags as I mentioned before are for presentational images, so I get rid of those completely and apply them via CSS. Not sure what this “headright” div is for, so lumberjack that too.

Moving on to the menu, AGAIN multiple POINTLESS DIV wrapping it! The UL is a perfectly good block level container, let it do the work… and this is where the really silly bits of markup showed up.

You see, if every anchor inside a container is getting the same class, THEY SHOULDN’T HAVE A CLASS. Classes and ID’s are for marking things that are DIFFERENT, not the same! As such, if you have a perfectly good ID around them like say:

<ul id=“mainMenu”>

Then the anchors inside that menu can be accessed as:

#mainMenu a

in the CSS… A lot better than saying class=“mainlevel-nav” on every single one. Kind of the POINT of CSS, saying it once, instead of multiple times.

Likewise there’s the use of the title attribute – Title only has two situations where it should be used – when the content of the tag doesn’t convey it’s full meaning, or when customizing accesskeys menus for blazer/opera and other browsers that support them properly. Since I’m not seeing any accesskeys defined, and since the content of the title attributes is IDENTICAL to the content inside the anchor – Why is it wasting the bandwidth on title attributes? That’s just bloat.

THEN there’s the telltale of the garbage CMS – absolute url’s on EVERYTHING. Waste of bandwidth, makes no difference on access, I have no clue where ANYONE got the idea that’s necessary or even a good idea… so axe those too, and suddenly your 510 bytes of menu code is chopped down to 186 bytes.

Next we have ten or so div that the names are all vague/meaningless and I can’t even figure out what they are for, so I tossed them and started over. I use two wrapping DIV to apply faux-columns left and right meaning if you wanted to open the layout up to being semi-fluid you can. I use the content-first double wrapping DIV for the same purpose.

The heading order on the page made no sense – you had a second h1, and then dropped down to lower level headings when they were NOT subsections of the heading preceding it. That makes no sense. The second H1? Should be a h2. The H3? Should be H2… many of your STRONG tags? Should be H3 or H4… etc, etc… (some other strong tags should be B, since you do not want to apply more emphasis to them!)

On the IMG, you have ANOTHER pointless title tag. In this case, the “content” is either the alt tag or the image itself, so don’t waste the bandwidth saying the EXACT SAME THING over again.

Oh, you’ll notice some horizontal rules laced into it – I use those to break up sections for users who have CSS off or are on devices that don’t use the entire “screen,projection,tv” declarations… For screen I just hide them with display:none;

The sidebar has multiple lists – I’m not sure why you had one set of them as flat anchors – though again with the ENDLESS POINTLESS REDUNDANT classes, full URL’s for no good reason, and the redundant title tags were just chewing bandwidth for NOTHING. Wrap them in a classed list, and poof you have ALL the hooks you need to apply your CSS. I suspect this is also a contributing factor to the 41k of CSS doing about 10k’s job… MAYBE 15k for the entire site.

Headings, paragraphs, lists, the two sidebars code-wise are simple – KEEP them simple.

Close out the sidebars and faux-column wrappers, and we get to what I’m calling the “infoSection” – you’ll notice I use meaningful names and don’t waste my time commenting the “starts” – or saying “end” on my closing content… this is because I take the “No REALLY?!? Opening a tag is the start of something and closing the tag ends it?” approach to comments. I only add the ending comment to say WHAT is being closed when it’s not clear, and I put it BEFORE the tag or tags being closed so as to avoid the double render and/or disappearing content bugs that comments can trip in IE, and the “width chopping bug” in some versions of FF.

Infosection gets a single wrapping div, mostly just to contain the floats and add some spacing around them.

Each subsection, which I named “.subSection” gets a third the width minus the 10px or so padding you seemed to like to use around things. A secondary class can be used to target each one for unique values, like done on calendar.

Calendar has the obvious H2, and the subsections that are H3’s. The first H3 gets a class so we can target it for that top notepad effect, and I put a span inside it along with a bold tag to apply the breaking of it into multiple lines and the number that’s styled different.

The rest of the content does require a good number of elements to work, but slapping each and every single one into a DIV seemed a bit wasteful, especially when some of them are obviously headings. Using different semantic tags around some elements and a few <br /> makes it easier to target for the desired appearance while reducing the amount of code needed.

The middle subsection I was trying to figure out what the DIV was even for, since if you were using outdated markup you could have simply used align – though for my rewrite I scrap both entirely and just set a class on it – PLATE.

I usually have leadingPlate, trailingPlate and Plate classes to describe my plate images – using the typesetting terminology for it. Float left, float right, center, with the appropriate paddings/margins applied to them. This is a plate image, let’s call it a plate image.

the final section is the Accuweather part – which is just a train wreck of redundant/pointless/broken code tied to a giant bloated PERFECT EXAMPLE of what I mean when I say “javascript for NOTHING”. Removing all the times it says the exact same thing over and over, using a class with a nested div for the hover effect not only reduces the amount of code needed to next to nothing by comparison, it also means CSS off the content still makes sense, and we can just send IE6/earlier a non-behavioral version of the page. Heading tags, wrapping div, nested div contains the hover content with it’s own heading. All the strong are changed to B since you are not trying to put more emphasis on the field name than you are the actual content, right?

Close out all that, and we have the footer – In your original you not only had several odd/unneccesary elements, you had code that didn’t even make sense like align=“footer” – there is no such alignment… NOT that the align attribute has ANY business being used in HTML after about 2001ish, and this used it three times. Same goes for the Target attribute – don’t force a new window on the user, let them CHOOSE to do it using their browsers built in ability to do so… and of course, I stripped out all the pointless/redundant title attributes again.

… and that’s the how/why of the new markup. I’m out the door in a few, but if I have time later (I say that a lot) I’ll toss together a breakdown of the CSS explaining how it works.

… and to breakdown the CSS. Mine is sufficiently different from the original (a single 6k “for screen only” vs. 41k in five files without media types) there’s no common ground to even compare them, so I’ll just explain what I did.

I always start out with a reset – there are smaller resets and larger resets; the smaller ones tend to break form elements, the larger ones have NOTHING to do with actually resetting anything and are more CSS frameworks than anything else. The POINT of a reset is to set up the elements different browsers display different default behaviors on – and that’s IT. That means margin and padding on a handful of block-level elements, border on TWO elements, and that’s IT!

Next I hide those horizontal rules – again those are only in the code for people who won’t see screen/tv/projection CSS.

body - I just use text-align to center #pagewrapper in legacy IE which only have “quirks mode”. I set up the default font size I want across the entire page, which is a nice simple 85% giving 14px for 96dpi users and 17px for 120dpi users. Personally, I like a nice tall line-height too. I position the background “top center” so that regardless of screen width you don’t get ‘partial’ bits of the background revealed.

#pagewrapper - width, centering, background, and set the alignment back to normal after our IE 5.x centering method. Because of the techniques used to build the rest of the page, it is possible to make the layout semi-fluid or fully-fluid here if desired.

h1 - center the text, margin the bottom to push the menu away, font, color, background. Nothign too fancy. We don’t need to state width or height as it will expand to fit what we put in it. The background-image is one of the two busts – I put them in a single file to save a handshake and to make better use of the image encoding possibilites… for the H1 we just show the top-half by setting it to “top left”.

h1 span - the outermost span gets set to display:block so it will expand in height to fit it’s content. A “holly hack” to trip haslayout fixes a scrolling issue in IE, and we just pad the sides to make sure the text will never overlap the images, and pad the top and bottom to make room. Three line-heights of 54px plus two 30px paddings equals that 222px, letting us avoid stating a fixed height which would break when combined with padding to make the text look centered…

h1 span span - on this one we just undo the padding and background we set on the outermost span. This leaves it as a normal display:block element splitting the text into three lines.

#mainMenu - killing the list-style is the norm for a menu list, and I use overflow:hidden and a fixed height to wrap floats. I like to set the font-size on the outermost container, which I used px metric fonts because of the background image interaction… thankfully few if any people will complain about 16px being ‘too small’. The tiled background-image is the same file used on the anchors – though I ALSO combined it with the hover state; more on that in a moment. I also declare a background-color so images off users aren’t stuck up the creek with invisible white on white text.

#mainMenu li – unless you are going to add dropdowns later, I try to avoid putting ANY styling on LI as cross-browser they are an unpredictable mess. Setting display:inline pretty much strips them of all formatting cross-browser letting us use the anchor for our real style.

#mainMenu a – the anchors get floated to stack without any extra gaps and to allow top/bottom padding to be applied in all browsers. Again we have the background-image for the gradient. Again I declare the background-color.

#mainMenu a:pseudos – the hover states get the color changes, but also I slide the background image up 30px to reveal it’s bottom half. Simple effect to let you use one image for all your hover states instead of using multiple images that may not even load into memory until used, leaving a “delay” on first hover. It also reduces the number of separate files speeding up the page load.

.firstFauxColumn – the two wrappers to make the fake full-height columns is pretty simple. Margin to space it away from the edges like the original, and the background image repeating on the left.

.secondFauxColumn – I set up some float wrapping, and then the other image repeating on the right.

#contentWrapper – the outer wrapper for a fluid center column content first layout. I generally use this method whether the page is fluid or not just because it’s reliable, predictable and not prone to float drop.

Content – side margins to push away from where the columns would be, padding to make it pretty. Using both lets me mix px metric column space with EM padding for content… very nice when the content gets larger.

Content h2 – just centering and fonts, nothing fancy.

#firstSideBar – a float with a negative margin equal to it’s width has zero width for figuring out it’s “positioning”, which lets it fit next to the 100% width floated #contentWRapper. The first one gets the margin on the right which puts it’s content off the right side of the page, which we can then slide left with relative positioning putting the column in place. Sounds complicated, but it’s a slick way to build a center column code-order first layout.

#secondSideBar – the second one is simpler, since doing the margin on the left will put the whole column precisely where we want it.

#firstSideBar h2,
#secondSideBar h2,
.infoSection h2
– these all share the same appearance for mine, so I declare them together. Simple padding, font, color, background. Yawn.

#firstSideBar p,
#secondSideBar p
– ooh, padding. I prefer padding instead of margins since it prevents overlap issues.

.sideMenu,
.newsList
– these just get list-style stripped. From here out a number of ‘like’ values are declared together for these two menu types.

.sideMenu li,
.newsList li
- as before, just strip styling off them with display:inline, and let the anchors do the grunt-work.

.sideMenu a.
.newsList a
– – display:block lets them accept vertical padding and puts them on their own lines, and they both lose text-decoration.

.sideMenu a padding and color, nothing fancy.

.sideMenu a:active,
.sideMenu a:focus,
.sideMenu a:hover
– colors… ooh… colors.

.sideMenu .current a - just style that one indicating the current page differently. At least, I assume that’s what you were doing on the original.

.newList a - padding and margins combine not only to space them apart, but to make room for that star image applied as a background.

.newsList a:active,
.newsList a:focus,
.newsList a:hover
– color, text decoration… again, no real surprises.

#firstSideBar .controls I don’t speak greek so I was kind of guessing, but I assumed this elemetn was some sort of admin login controls.

.infoSection – I use width:100% and float:left to handle the float wrapping as the popups from the accuweather thing would get cut off otherwise. padding the bottom spaces us off from the footer without worrying about margins.

.infoSection h2 – all the h2 get the same alignment, and I use border instead of padding so that the background color applied to .calendar is overwritten back to our normal background. We already set up the rest of their appearance up top.

.infoSection .subSection – floating all three of them 300px width and 10px left margin makes them fit. The display:inline prevents IE from turning that 10px margin into 20px which it has the nasty habit of doing on floats. Floats are inherently display:block and NOTHING you set for “display” can change that behavior, but for some weird reason it trips a rendering quirk in IE that makes it behave properly.

.calendar – I just set the gray background here along with our text alignment.

.calendar h3 – each of the subheadings get the same fonts and colors.

.calendar.date – except for this one, which also gets a background-image and padding on the top.

.calendar .date span – the nested span uses the narrow container method noonnope suggested earlier to break it into multiple lines. The alignment isn’t always perfect, but it’s “good enough”.

.calendar .date span b – the nested bold tag also gets a bigger font, and it’s so narrow that the narrow width multi-line break doesn’t work, but display:block fixes that.

Depending on the content for those, you MAY be better off getting rid of the SPAN and using BR instead just for reliability.

.calendar .sunriseSunset - half the width, float, margin, border. Pretty simple.
Is this the little girl I carried?
Is this the little boy at play?
I don’t remember growing older
When did they?

.calendar .moon - rather than float this one too, I just use a margin to push it over so the centering is always correct. Simple, fast, effective.

.calendar p – the parts I put in P are debatable as to whether those are really paragraphs or not, but it also gave me a separate tag to target for padding without resorting to any extra classes.

.informative – wasn’t quite certain what to even call the elements this is applied to since your page is all Greek to me.

.toolTip – the outer wrapper for the various accuweather elements. Position:relative and some z-index games let me be sure that on hover our content will show. IE will screw up the positioning without a haslayout trigger, so the holly hack is good as any allowing us to avoid declaring a fixed width or height; something that’s always a disaster when you want to use padding or border at the same time.

.toolTip img – the images basically get the same formatting as a ‘leading plate’.

.toolTip h3 – each one’s heading just gets some extra padding. I really didn’t feel the need to play with the font size on them.

.toolTip h3 a – the anchors inside get green and text-dec stripped. I used a darker green because the one you had was insufficient contrast making it not meet accessibility norms.

.toolTip div – the nested div is APO’d off screen at the start. The width should be sufficient for any content, and the large border makes it attractive with our simple CSS hover replacing that train wreck of javascript.

* html .toolTip div – using the * HTML hack to target IE6- we just kill the hover effect to ‘gracefully degrade’ for legacy IE users. Rather than waste scripting on people stuck on the old browser, let’s just show them the content normally. Simple, small, and all you need for supporting legacy users.

.toolTip:hover – background-color so we see it’s hovered, z-index change to make sure it depth sorts not only over everything other section on the page, but also it’s own kin.

.toolTip:hover div – just slide it into place.

.toolTip h4 – just some alignment, font and colors.

.toolTip h4 small – just making sure the size is the same everywhere.

.toolTip b – I add padding to the B instead of the outer wrapper. It MAY be worth resorting to a second div to apply the padding, but this seems to work for now.

#footer – the clear SHOULDN’T be neccessary given all our floats are wrapped, but IE can be a bit of a re-re in that department… likewise it needs a haslayout trigger so it doesn’t screw up the preceeding margin. (by applying it before and inside the element and doubling BOTH!). Rest of it is just color, paddings, borders… yawn.

#footer a and pals – just colors and decoration.

From this point on it’s just some standard elements I use a lot on my sites:

.offset – some elements are ‘offset’ from their kin, like your placeholder image on that page. (REALLY hope that’s not a REAL page on the site)… simple class that says it’s an offset, but not what that offset would actually appear like.

.plate – standard image plate… block level, centered.

.leadingPlate – a lead-in image. float it, pad it enough to push any content away from it.

.trailingPlate – the opposite. Float the other way, pad the other way.

… and that’s it, the how/why/what of the CSS for my approach to coding your page. I realize you’re probably somewhat neutered in what you can change by the CMS you are in and the various mods/plugins (like the accuweather thing) in how much of it you can actually apply – but I’m hoping you will at least be able to come away with SOMETHING useful out of all this…

… and that it shows how bad some off the shelf solutions are coded.

Again, hope this helps, or at least gets you thinking in different directions.