XHTML: banner (embedded divs) - html

I want to do the following:
------------------------------------------------
width: 100%;
height: 60px
image center
image bottom/right
-------------------------------------------------
I used to do it with table:
<table border="0">
<tr>
<td width="25%"></td>
<td width="50%"><center>image center</center></td>
<td width="25%" valing bottom><div align="right">image bottom/right</div></td>
</tr>
</table>
but they say using tables for formatting is bad (Dunno why)
So is there any idea how to do the following banner? I heard there is absolute position, so mightbe the 2 images could be embedded to 2 divs

First off before I do any explaining I think you could use some visuals of just how powerful CSS can be...
CSS Zen Garden shows how using a different CSS style sheet can completely change the entire way a site looks (use theme links on the right side)...
http://www.csszengarden.com/
My own site supports multiple themes which you can instantly change without even reloading the page...
http://www.jabcreations.com/blog/?prompt=themes-official
1.) Tables are intended for tabular data only, think the nutrition panels on food labels if you're not sure where to start. Tables are great for tabular data because it removes the formatting issues however you should never put non-tabular content in to tables as it disrupts the context of the content to search engines and you should instead use division elements instead since non-tabular data tends to do anything except for be presented in a tabular fashion.
2.) The context of using either CSS background-images or (X)HTML img (image) elements comes down to what you're trying to do.
2.A.) CSS3 allows the use of multiple background-images however browser support isn't yet universal when considering browser market shares...
http://www.caniuse.com/#search=css3%20multiple%20backgrounds
...as time passes however IE8 and other older browsers that do not support this modification to the CSS background-image property will slowly disappear so it will only become an increasingly viable option.
2.B.) You can combine an img element and a CSS background-image together to get two images to display inside of a single element.
2.C.) You can use two division elements with the same styling (or lack thereof) and then give them each a CSS background-image.
Here is the generally relevant CSS code...
background-image: url(kittens.png);
/* Choose one or the other below */
background-position: right bottom;
background-position: center center;
I'll reiterate that tables for on-tabular data is exceptionally bad for styling. Once you begin to grasp how CSS works (cascading means rules on lower lines override earlier lines, so the same rule on line 10 will override the same rule on line 9, if they are the same rule).
By using CSS you're going to have so much more power to quickly implement changes across your entire site and you'll be able to implement changes quicker and move on to more important things.

Related

Div width incorrect in Office Outlook Client

I am trying to send an email with html content but I am observing displaying issues.
The following does not get displayed properly in width by Microsoft Office Outlook, any hint?
<div style="width: 650px; border: 1px solid blue">hello</div>
use tables, and on <td> use width="" propery and also style="width:" ... for some clients are reading the width property and others reads the style property
You must reconsider to change the email template to be tables within table and with inline styling
here is a sub link to problem which you may encounter
How to align several tables in td in center
HTML divs and spans don't work particuarly well in office outlook. You are better off using tables for this display.
Reference: "...The best way to combat these issues would be to use a table-based layout." https://litmus.com/blog/a-guide-to-rendering-differences-in-microsoft-outlook-clients
Here is some further information taken from another answer:
"- JavaScript - completely off limits. If you try, you'll probably go straight to email hell (a.k.a. spam folder). This means that LESS is also out of bounds, although you can obviously use the resulting CSS styles if you want to.
- Inline CSS is much safer to use than any other type of CSS (embedded is possible, linked is a definite no). Media queries are possible, so you can have some kind of responsive design. However, there is a long list of CSS attributes that don't work - essentially, the box model is largely unsupported in email clients. You need to structure everything with tables.
There are loads of answers on SO, and lots of other links on the internet at large.
http://www.emailology.org/
http://www.email-standards.org/
http://www.campaignmonitor.com/css/
http://www.getfractal.com/ [DISCLOSURE - I used to work at Fractal.]"
Reference:
Has anyone gotten HTML emails working with Twitter Bootstrap?

Header/content page with content div filling available space

So I'm trying to create a simple header/content layout where the content part extends to the bottom of the window.
Doing it with CSS looks impossible, at without introducing too much complexity considering how simple is this layout.
Please tell me a SINGLE reason why I shouldn't do this
body, html { height: 100%; padding: 0; margin: 0; }
#h{ height: 150px; }
#tbl { height: 100%; }
<table id="tbl" cellpadding="0" cellspacing="0">
<tr>
<td id="h">header</td>
</tr>
<tr>
<td>content</td>
</tr>
</table>
And don't tell me about semantics and how tables weren't made for layout.
It seems most web designers today are masochists who spend hours everyday trying to build simple layouts in very complex ways because they like to torture themselves with things that don't matter.
I can hear you already saying "But... but... john using divs instead of tables is the latest hip thing to do, you don't want us to be mocked by the other web designers do you?"
We do not use table layout anymore because they are not semantic. Bots and screenreaders can not identify what the content is good for. Secondly you will want to separate your content from code for layout (distribution of duties).
Having an external CSS file will make your page much more easy to maintain. If you have 20+ pages which all have a table to keep content in, you will pretty likly have to edit all this documents for a redesign. If you use CSS and have a good document layout width identifiers you will only have to change one .css file to alter all your layout for good.
You have a question. You want to have a content area under your header item. That ok and indeed can be solved with more complex CSS if you want to, but not have to be.
Firstly you will begin width your header. You can use <div> for that or use the headings (h1-h6) items. Like that every bot will know > "Oh! a headline. Thats important!"
Lets structure your document:
<body>
<h1>Header</h1>
<div class="static-content">
<p>Content</p>
</div>
</body>
We have a headline and a div width the classname "static-content" for layout reasons. You can change this name to what ever you want (no whitespace and start width a alphabetic char) you can also add multiple classes, separated by white spaces.
here is some CSS
html, body {
height: 100%;
margin:0;
background-color: gray;
padding: 0;
}
h1
{
display: block;
padding: 20px 10px;
background-color: blue;
margin: 0px 0px 0px 0px;
}
.static-content
{
background-color: red;
padding: 10px;
margin: 0;
}
So. Like you can see in the fiddle here: http://jsfiddle.net/NicoO/rC66e/2/
Your content area can be red (like it is). But you also see the gray background. The element in the background is the body you can work with the body like nearly any div.
So you see, you already have stretched your content area to the bottom of the browser. If you want the red area to be on the bottom also, you have multiple options to realsise that.
See the fiddle here: http://jsfiddle.net/NicoO/rC66e/3/
There are also other ways to realise that.
Update. If you really want that red area to be big, you could try something like this:
http://jsfiddle.net/NicoO/rC66e/5/
This is not a really good solution because I don't know what you want to use it for. You just could style the body element and you are good to go. If you want more complex layout, you will have to addapt your CSS. The soltion in this fiddle is not generic as it should be. But it shows, that you can do a lot of things width CSS. Even if you don't really showed us your use case.
Edit:
You keep saying "why don't i just juse a two row table?". But on the other hand you try to alter this rule for the answer here. Why don't you just a heading and a paragraph? like <h1>Title</h1><p>content</p> You can add a background-color to the body element and be done. There is no reason to do anything else here.
Final Edit:
You have a valid point #John. sometimes CSS can be a pain. But it is far superior to table layout. For most common problems there are Tools like grown grid systems, that get the most of the problems out of the way. W3C is working on making CSS more powerfull and easy to use. For example with thew new display:grid; property.
If you really give css a chance and try to addapt a new pattern of thinking about the box model, it will help you a lot. With HTML and CSS you can just write what you reall need without having to have a clumsy table all the time.
I'am sorry if I offended you. But i'd recommend you to weight the pros and cons of table vs css layout. There is pretty nice stuff around like responsive layouts, that you will not be able to fully use width these old techniques
My personal view:
Using tables for layout is like using coffee to stay awake. Don't do it too often. Maybe once in a while.
And certainly we shouldn't hassle people who use table-based layouts, especially when there's no sound, cross-browser way to do a particular layout in CSS.
That said...
1. Tables make it harder to design for multiple screen sizes at once
Responsive layout is important these days. Having different CSS rules for different viewport sizes, applied to the same HTML code, is a good way to adapt a site to all screens.
For very simple designs, though, a table-based layout may work at any screen size.
2. Tables can interfere with search engine indexes, screen readers, and other automatic web page parsing
In other words, not so good for SEO and accessibility.
However, it's worth pointing out that Google has recently been optimizing its search algorithm to distinguish between layout tables and data tables.
And there are some techniques like <table role="presentation"> to help screen readers handle tables, although those hacks can get complicated.
3. Table-based layouts require changing the HTML markup when you want to change the layout
Again, it's nicer and more conceptually pure -- and often more maintainable -- to use HTML for content/semantics only, so you can leave the markup alone when you make design changes. But practically speaking, in a substantial redesign you'd often need to make changes to the HTML anyway.
In sum, I believe that guidelines and best practices are more useful than hard-and-fast rules regarding tables for layout. It's a balancing act, and there are situations where tables can be, overall, a better choice.

What is wrong with using tables in responsive utilities?

Bootstrap's page about responsive design says this:
Responsive utilities should not be used with tables, and as such are
not supported.
Being new to web development, I am not familiar with what this is talking about. It seems that there is a general aversion to using <table>. Is this true?
Also, the quote as phrased doesn't make sense to me. Shouldn't it read like this?
Tables should not be used in responsive utilities, and as such are
not supported.
Tables are very structured elements. A <td> can only ever be a column. You couldn't change it to suddenly appear like a row or float it somewhere, etc., etc.
HTML, in responsive design, shouldn't define what something should look like (or where it should appear to a degree) that's CSSs job. the HTML should simply group text and other elements. So a HTML <table> and all it's associated tags breaks this paradigm.
CSS display now contains table like elements: How is a CSS “display: table-column” supposed to work? so this removes the need to embed <table> tags and allows you to use the more generic <div> tags and their like, thus now it's a <div> that looks like a <table>, there is nothing to stop you making this appear as something completely different simply by updating the CSS. You could even make it look different for different audiences, etc.
hope this helps a little.
It's not really true in the latest browsers, but traditionally it's been hard to unstyle a table in CSS to not have a table layout.
So while a table might be the correct semantic element for your tabular data, pragmatics meant that if, in some responsive design profiles, you want the data to be displayed in a linear format, it just couldn't be done, except by using JavaScript to rip the table markup out and replace it.
Try table, tbody, tr, td {display:block; } - (JsFiddle http://jsfiddle.net/Z26GF/) in various browser (e.g. compare IE10 with IE9 behaviour) to see what I mean.
(The more I learn about Bootstrap, the less I like it. It seems to encourage a number of bad HTML practices. This is one of them)

What can't be done using CSS

I've seen quite a few answers on this site which advocate using tables for a design because it can't be done using CSS and Divs... when in actual fact it can be done with a bit of ingenuity.
What are examples of things that genuinely can't be done?
The only one I've ever come across is vertically aligning a box within another box.
*edit: I suppose I'm mostly interested in unachievable layouts using CSS2
Vertical alignment of blocks or text.
Having elastic containers that stretch to the width of their content.
Having several "rows" with the same structure where "cells" are synchronized in width throughout all rows.
Having several "columns" synchronize their height (up to the length of the longest text block).
These are quite basic designer needs that appear in even basic design concepts.
Cells/columns issues can possibly be solved with CSS if you take IE8 into account, but it will be many years until its wide spread (even IE7 in 2-3 years hasn't reached the desired market share).
As for "ingenuity", it is not that good thing in software development. Tricks that your colleagues and you yourself after a couple of months will not be able to understand usually build up that code base that everyone either is scared to touch or determined to refactor/rewrite completely.
Remember the KISS principle. The simpliest way you do this, the more reliably it will work.
The answer to this question depends on a number of things:
How backwards compatible do you need to be? Including IE6 will decrease the capacity of pure CSS; and
How much of your site is fixed-width and/or fixed-height. There are certain things in CSS that become hard if not impossible in variable width and/or height situations.
Side-by-side content is a problem for CSS. You can use floats for this but if the sum of widths exceeds the width of the container, the tail end floats will fall down below. Tables are more capable in this regard as they will squeeze columns where possible to make things fit and cells will never be split onto new rows.
Vertical centering you mentioned. Its trivial with tables and hard or impossible (depending on compatibility and fixed or variable heights of the container and the item) in pure CSS.
You may also be referring to hover content. IE6 only supports the :hover pseudo element on anchors. Javascript is required for that browser for :hover-like behaviour.
Basically if what you need to do can be done fairly trivially with pure CSS then do it. If not, don't feel bad if you have to use tables despite all the anti-table fanatics (and they are fanatics) jumping up and down in horror.
If you want a relatively simple exmaple of this check out Can you do this HTML layout without using tables?. This is a conceptually simple layout problem that is trivial with tables and noone has yet posted a solution meeting the requirements with pure CSS.
"... when in actual fact it can be done
with a bit of ingenuity."
How about 'avoiding the need for ingenuity' as a thing that's hard to do in CSS.
;)
tables should be used for tabular data! We should always try to use the correct HTML for the given content in which to markup. So not just div's (span, ul, li, dl, strong, em ... etc) This ensures that the content is not just looking right but is right (for SEO and accesibile reasons)
By not using tables it allows us to transform the content from one look and feel to the next without having to change the HTML, see Zen Garden
For now though with current browsers CSS table like layouts can be done but are tricky. there are techniques to get round many of the issues, weather they are done though global wrappers with background images, or positioning fixes... where both articles also refer to using Javascript to progressively enhance a page to get those additional classes you may require.
or of course you could use some XSL as a middle ware to help do formating if processing from a CMS.
Alternate row colors in a table without manually (or with the aid of a script) assigning alternate styles to each row.
Determine one element's position relative to another. For example you can't use CSS to determine which position one box is in a bunch of floated boxes using the same class. Would be nice to for example know if one box is the first box floated, or the second, or the last.
Handle widows. A widow is a word that dangles off the end of a paragraph, that is a single word starts the last line on a paragraph. It's a big nono on print design, but in the world of web it's hard to control.
Floating elements in multiple columns, where text in each cell can expand the height of the element, but the entire row below must be pushed down if this happens.
--- --- ---
|AAA| |BBB| |CCC|
--- --- ---
--- --- ---
|AAA| |BBB| |CCC|
| | |BBB| | |
--- --- ---
--- --- ---
|AAA| |BBB| |CCC|
--- --- ---
An image cannot placed in exact center of a cell with align attribute.It can be done with some brute force .
Sounds obvious but you can't change content with CSS, it can only be used for styling.
Rory, I think you're absolutely right. Vertical alignment can be done with line-height, and creating lay-outs in CSS really isn't that hard. In fact, it's far more flexible when using absolute/relative positioning and floats.
People still using tables for design should really brush up with the current standards.
Going on topic, with CSS3 coming up it's hard to think of stuff CSS can't do. Image manipulation, content manipulation, advanced selectors, it's all going to be possible. But if I had to name one thing, it's that with CSS you can't (and won't) be able to rotate elements.
I was unable to use a transparency to create a variable-height text area across all pages. I believe it's impossible. I ultimately just wrote a quick javascript function to reset the height after the page load, to get the layout to work. See http://peterchristopher.com to see what I mean by transparency for the text area.
There is absolutely nothing tables can do that CSS can't.
There seems to be a common misconception that HTML & CSS should be easy. It isn't. If you find yourself wanting to use tables then its your CSS skills that need improving not the technology (although the technology does obviously have plenty of holes that could do with improving).

What's the best way to go from a Photoshop mockup to semantic HTML and CSS?

I generally use a manual process:
Look at the page, figure out the semantic elements, and build the HTML
Slice up the images I think I'll need
Start writing CSS
Tweak and repeat different steps as necessary
Got a better approach, or a tool?
I have a fairly natural way of coding. The key is to treat the page like a document or an article. If you think of it like this the following becomes logically clear:
The page title is a top level heading
Whether you make the site title or actual page title the h1 is up to you - personally I'd make About Us the h1 rather than Stack Overflow.
The navigation is a table of contents, and thus an ordered list - you may as well use an ol over a ul.
Section headers are h2, sections within those sections are h3s etc. Stack them up.
Use blockquotes and quotes where possible. Don't just surround it with ".
Don't use b and i. Use strong and em. This is because HTML is structural rather than presentational markup. Strong and emphasis tags should be used where you'd put emphasis on the word.
<label> your form elements.
Use <acronym>s and <abbr>s where possible, but only in the first instance.
The easiest: always, always give your images some alternate text.
There's lots of HTML tags you could use that you probably haven't - address for postal addresses, screen code output. Have a look at HTML Dog for some, it's my favourite reference.
That's just a few pointers, I'm sure I could think of more.
Oh, and if you want a challenge write your XHTML first, then write the CSS. When CSS-ing you aren't allowed to touch the HTML. It's actually harder than you think (but I've found it's made me quicker).
Well, when I build a website I tend to try and forget about the design completely while writing the HTML. I do this so I won't end up with any design-specific markup and so I can focus on the semantic meaning of the elements.
Some pointers how to markup things:
menu - use the UL (unordered list) element, since that's exactly what a menu is. an unordered list of choices. example:
<ul id="menu">
<li id="home">Home</li>
<li id="about">About</li>
</ul>
if you'd like an horizontal menu you could do this:
#menu li {
display: block;
float: left;
}
Logo - use a H1 (heading) element for the logo instead of an image.Example:
<div id="header">
<h1>My website</h1>
</div>
And the CSS (same technique can be applied to the menu above if you would like a menu with graphical items):
#header h1 {
display: block;
text-indent: -9999em;
width: 200px;
height: 100px;
background: transparent url(images/logo.png) no-repeat;
}
IDs and classes - use IDs to identify elements that you only have one instance of. Use class for identifying elements that you got several instances of.
Use a textual browser (for instance, lynx). If it makes sense to navigate in this way, you've done good when it comes to accessibility.
I hope this helps :)
I essentially do the same thing Jon does, but here are a few other ideas:
Use Guides in Photoshop (and lock to them). Figure out all of your dimensions for each box/ region ahead of time.
Collect all of your dimensions and color hex values into an info file (I use a txt file) that you can easily reference. This will reduce your alt-tab tax and selecting colors in Photoshop multiple times.
After all my Guides are in place, I slice out the entire website into my images folder, starting with photos and grouped elements, and ending with the various background tiles/images, should they exist. (Tip: Use ctrl-click on the layer preview to select that layer's content).
Notes on using Photoshop:
Use Guides or the Grid.
Use the Notes feature for any pertinent information
Always use Layer Groups for similar elements. We need to be able to turn entire regions off in one click. Put all 'header' content in one Layer Group.
Always name your layers.
You can put each page template in one PSD file and use nested Layer Groups to organize them. This way we don't have to setup all of our guides and notes for each page template on a site.
No shortcuts :) but everybody works slightly differently.
This tutorial that popped up in my feedreader yesterday shows the process from start to finish and might help people who have never done it before but as you are an old hand it's just about streamlining your own methods.
EDIT:
The listapart link certainly is more automated for 'flat' designs where both imageready and fireworks have had pretty good support from day one and it's got better and more semantic with every release but if you have a more complex design it's the twiddly bits that make the design what it is and these have to be done by hand.
I just thought it was worth pointing out that in addition to the excellent advice you've had so far I'd recommend getting a printed version of the design, using a red pen to mark up all the block elements on the design you think you can spot and sitting down with the designer for half an hour and talking through how they envisioned their design working for the use cases that don't fit the static design.
What happens when more text is put in the navigation?
Is this width fixed or fluid?
Is this content pane to the right fixed height or fluid? If it's fluid why did you put a background on it that can't be repeated?
You have a border extending down the page that breaks two otherwise connected elements. Visually it makes sense, but semantically I not can't just use an li to house both those elements. What do you think is more important?
It'll also help you spot potential problems that you might otherwise not have realised were going to be issues until your elbow deep in css.
Not only does it make your job easier after a few times doing it your designer will get a much stronger sense of what is involved in marking up their work - some designers have real trouble comprehending why something they think looks visually very simple will take a few days of css tweaking to make work.
Some of the designers i know, usually uses Illustrator to make the design elements.
This page shows how to do it a little more automated.
Also, get to know the "Layer Comps" feature. I use this for changing button states.
Create layer comps for normal, hover, and active.
In each of these, set up the effects/color overlays and visible layers which belong with that state.
Save for web: go to a different folder for each state, unless it's easier to rename each slice (otherwise your hover button slices will overwrite your regular slices).