Quick Tips On Html And Css

[mik1405241541 0]

Here are just some general tips, helpers and time-savers for HTML and CSS.

 

HTML

Ideally, you should be working under the XHTML 1.1 doctype specification. Some reasons:

Improved semanticism - make use of the elements available appropriately to convey the information as it was intended.

Improved understanding - because of an increase in semanticism, it's easier for your audience to understand what your trying to convey.

Cleaner code - due to the deprecation of some elements and the strict requirements of nesting, closing and structure, your code becomes much cleaner and hopefully more readable.

Faster - cleaner code = faster generation; the browser doesn't have to do as much work to render your site.

It's not difficult to work under XHTML as apposed to HTML. Infact, to clients it shows that you are with the times and that your truly care about your audience, not just your own design.

 

You'll often find people saying "I want a CSS, not a table site". This is an inaccurate conception. HTML and CSS are two different modules connected by a rule or link. HTML is used to present the data where as CSS is used to style the data. Tables are part of HTML and should be used when tabular data is being displayed. CSS should be used to style your site, from structure to typography and forms to colour. The use of tables to create layouts are long-gone. You shouldn't depend on divisions (<div>) or span (<span>) neither. Only use the div and span elements when you are absolutely sure that your need them and your site layout will suffer without them. It is possible to create layouts without using divs or spans.

 

When creating forms, leave nothing out - fieldset, legends and labels are all part of a form (and inputs) so use them. They'll make your form look better when the styles are off (and can make your form spectacular when the styles are on).

 

Remember your block-level elements from your inline-level elements and their rules:

Inline-level elements must reside within block-level elements.

Inline-level elements are the height and width of the contents - the more there is in the contents, the greater the size of the element. Inline-level elements do not expand into the white-space (unless told otherwise by the CSS)

Inline-level elements should not occur within inline-level elements.

Block-level elements can reside in other block-level elements, but should not be in inline-level elements

Block-level elements usually occupy the whitespace around them to set height and width. However, you'll find that most block-level elements further expand the height and/or width like inline-level elements.

CSS

When working with floats, ensure you use

display: inline

to all elements which float. This is to help IE out with it's little issue of not being able to do mathematics, whereby it will display floats incorrectly (and causes some funny looking layouts).

 

To save time in making your CSS, use

*{padding: 0; margin:0}

then

ol, ul, select{margin-left: 1.5em;}

to quickly remove the padding and margins of all elements. I find this a great time-saver especially as I don't end up repeating on almost every selector the same padding / margin properties. The ol, ul, select fixes the margin being put out of alignment by the global selector (*).

 

Hiding an element from the screen is achieved one of two ways:

display: none

or

visibility: hidden

. The first simple removes the element when styles are enabled. The effects of this element are negated. This makes it highly useful when you need additional informatio on your site to tell disabled styles or text-browsers something that the visual browser (CSS enabled) would understand already from the design. The second is more useful (hidden visibility) when you want to hide an element but you want the effects of its existence to occur on the document structure. For example, say you wanted to split two images with a 2em gap using a horizontal ruler (hr) but your didn't want to see the ruler. You can simply use

hr.splitter{visibility: hidden; width: 2em;

and hey presto! The images are split with a 2em gap and no sign of the hr unless you view it without the styles.

 

Avoid absolute positioning at all costs. It is a terrible CSS feature that will hopefully be deprecated as soon as posssible - either that make it more usable. Seeing as though the latter won't happen, AVOID IT. Seriously, there is no need for absolute positioning. You can achieve the same effects by using floats and taking your time when making the layout.

 

Don't descriminate browsers. If you create your layout properly, there will be very little or no need to throw in a billion of bugswats for IE. I hardly ever run into a bug, and when I do, it's been down to my own arrogance. The lessons I have learnt is that time and patience are required. Additionally, don't rely on advanced selectors like

a[rel^="external"]

. They don't work in most browsers (only the really compliant ones) and using class selectors

a.external-link

allow for much nicer reading and cross-browser friendliness. Only use the advanced selector if you want to give a treat to the compliant browsers or if you want to tell them something that you don't want non-compliant (like IE) browsers to read.

 

NEW CONTENT:

 

Attribute selectors (e.g. the above rel^="external) are not-so-common simply because of their lack of support in a lot of browsers. However, they can be really cool to use AND when they are more widely supported will more-than-likely see the end of ID and CLASS selectors. Why? Because unlike these two monsters, you can do string query for type matching through the CSS. Sound baffling? Well, it's not! For the sake of sakeness, imagine all browsers supported attribute selectors in the following examples.

 

Let's say we want all <a> elements with the attribute title="homepage" to show with a little icon of a home. We could use a class to define this, but what would be the point in extending our code needlessly? Through pure CSS (and a little magic) we can make all these show a home icon without even touching the class or id selectors. Here's your 'code':

a[title="homepage"]{padding-right: 20px; background: url(images/icons/home.gif) center right no-repeat;}

The a[title=homepage] is where our magic lies. Attribute selectors are encased in the square brackets. They can be tied to anything that can have an attribute and depending on your browser, there are no set attributes (although consideration of the standards should be taken).

 

What happens if we have more than one relation to the document linked to? Because of the nature of the attribute selector and it's available properties, we can do more magic to query the string. Say we had two, space seperated relatives in the link to the home page.

<a href="/" title="Homepage" rel="index start">Home</a>

And say we only wanted to pick out the "start", because index occurs in other places. We could use the absolute reference as shown in the previous example. Or we could use one of three other matches (or all at the same time with group selectors): wildcard (*), space-seperated (~) or end-of-string ($). Examples:

a[rel*="start"]

This will search the entire string for the word "start". Be careful, as a rel attribute with "starting" will be matched as well.

a[rel~="start"]

This will match the string start when in a space-seperated list.

a[rel$="start"]

Finally, this will match "start" where it occurs at the end of the list.

 

I know of only 5 match criteria (~|$^*) however, there may be more. Note that the ^ does the opposite of $, in that it gets the string from the beginning. Like $, * will find the word within other words (e.g. will locate start in starting and apply the style to it).

 

Personally, I would prefer this method of selection than through the use of ID and CLASSes, it would make things pretty much easier. Descendants would still exist, e.g.

p > a[rel*="external"]:hover acronym{color: #bbcc66;}

Would still work, just the same as if <a> had the class attribute of "external":

p > a.external:hover acronym{color: #bbcc66;}

Whilst it may look shorted (the class selection), it doesn't provide as many opportunities. Edited March 12, 2007 by mik (see edit history)

[Arbitrary 0]

While I agree that ideally one should be working with XHTML 1.1 Strict, I still believe that it's best to adapt to the situation. Not every one of your visitors have browsers that support the XHTML standards (say strict). Therefore, it's better to figure out what the majority of the visitors want and do that instead.

And there are some changes to XHTML that I just don't get. Like how does changing the bold tag from <b></b> to <strong></strong> make the code "cleaner" or "faster"? It seems to me that <strong></strong> is obviously longer than <b></b>, so how could it possibly be faster? Although I believe sticking to the standard is a good thing, I fail to see how the current coding methods are improvements from before.

You'll often find people saying "I want a CSS, not a table site". This is an inaccurate conception. HTML and CSS are two different modules connected by a rule or link. HTML is used to present the data where as CSS is used to style the data. Tables are part of HTML and should be used when tabular data is being displayed. CSS should be used to style your site, from structure to typography and forms to colour. The use of tables to create layouts are long-gone. You shouldn't depend on divisions (<div>) or span (<span>) neither. Only use the div and span elements when you are absolutely sure that your need them and your site layout will suffer without them. It is possible to create layouts without using divs or spans.

Agreed. You can have a table for the layout an CSS all-in-one. I remember I did something like that for my first website. CSS for layouts is quite helpful--all the styles in one compact file. There's no need to repeat styles over and over again for every tag; it's a bit like writing functions to reuse the code instead of copying and pasting it. Nonetheless, I don't see what's wrong with using <div>'s or <span>'s in a site. Many well-coded CSS-heavy sites that I've seen almost always use them. There really aren't that many other tags to latch a style onto besides <div>, <p> etc. So use what you have when you want. Neither of those two tags are "bad".

When creating forms, leave nothing out - fieldset, legends and labels are all part of a form (and inputs) so use them. They'll make your form look better when the styles are off (and can make your form spectacular when the styles are on).

This I do not agree on. While it's nice and dandy to use fieldsets and legends (they do make the form a lot clearer), it's not recommended since numerous browsers don't support it (and, from what I've heard, make a mess of it). You'll have to decide what browser the majority of your audience uses--if the majority uses Firefox, then depending heavily on fieldsets and legends can be very useful. But if they use IE6, forget it. They won't see anything and you should depend on something else to highlight sections of your forms. (Say <div>'s or something)
Ahhh...the horrors of cross-browser compliance. Ugh. I hate how there's so many different browsers; it makes it insanely difficult to cater to everyone's tastes. Why can't everyone just be a bit more...compliant and change their browser as needed?

[TavoxPeru 0]

Wow, thanks for the tips, some of them i already knew but the related with images with gap dont .

 

Arbitrary i think that the benefits of changing the bold tag from <b></b> to <strong></strong> is more related with the Accesibilty fact and not with make the code "cleaner" or "faster".

 

Best regards,

[Quatrux 4]

Well, I read about it some time ago and I think I found the same explanation, that the <b></b> tag is a style, which needs to be done with CSS, font-weight: bold; When I think of it, I don't use b tag, only sometimes ;D But strong tag was there long before xhtml and the effect was almost the same as with b tag.

A quick explanation, but hopefully understandable. "Bold" is a style. HTML was never meant to be about styles. Do some searches for "Tim Berners Lee"
and "the semantic web". <strong> is semantic - it describes the text it
surrounds ("this text should be stronger than the rest of the text you've
displayed") as opposed to describing HOW the text it surrounds SHOULD BE
DISPLAYED ("this text should be bold").

[closed 0]

and also used <em></em> instead of <i></i>, additional points in semantic as stated above.

[mik1405241541 0]

While I agree that ideally one should be working with XHTML 1.1 Strict, I still believe that it's best to adapt to the situation. Not every one of your visitors have browsers that support the XHTML standards (say strict). Therefore, it's better to figure out what the majority of the visitors want and do that instead.

If a browser doesn't support the standard then it will fall back into quirks mode, therefore displaying the site in it's basic form anyway. So support for doctypes is not enitrely necessary. Additionally, XHTML 1.1 does not come in any flavours other than itself, so unlike 1.0, there are no Frames, Traditional, Loose, Strict, etc.

And there are some changes to XHTML that I just don't get. Like how does changing the bold tag from <b></b> to <strong></strong> make the code "cleaner" or "faster"? It seems to me that <strong></strong> is obviously longer than <b></b>, so how could it possibly be faster? Although I believe sticking to the standard is a good thing, I fail to see how the current coding methods are improvements from before.

As Quatrux quite rightly said, the <b> and <i> are style formatting - something HTML wasn't developed to do. <strong> and <em> however tell it to make it a point which needs consideration from the rest of the information. It doesn't make it faster or cleaner, but it does give your site greater semanticism.

Nonetheless, I don't see what's wrong with using <div>'s or <span>'s in a site. Many well-coded CSS-heavy sites that I've seen almost always use them. There really aren't that many other tags to latch a style onto besides <div>, <p> etc. So use what you have when you want. Neither of those two tags are "bad".

The W3C and many other webmasters don't find anything wrong with using divs or spans, and neither do I. The point I was trying to make is don't rely on them heavily. For example:

<div id="heade"><p>Website Title</p></div><div id="body"><p>Some text some text some text</p></div><div id="footer"><p>Copyright me 2007.</p></div>

Is totally wasteful as your using the divs for no reason other than to say in the code that this is a section. The following makes more semantic sense:

<h1>Website Title</h1><p>Some text some text some text</p><p id="footer">Copyright me 2007.</p>

See, it is much nicer and won't take as much styling. I know it's not very common to come across, but it does happen (well variations of the above).

But if they use IE6, forget it. They won't see anything and you should depend on something else to highlight sections of your forms. (Say <div>'s or something)

Actually, IE5+ is fine with forms and the fieldset / legends / labels. I've just being designing on IE6 and also tested on an older machine's IE5.5 and it appears to be fine.

Ahhh...the horrors of cross-browser compliance. Ugh. I hate how there's so many different browsers; it makes it insanely difficult to cater to everyone's tastes. Why can't everyone just be a bit more...compliant and change their browser as needed?

And where would the fun be in that?
Thanks for your comments Arbitrary, Quatrux, TavoxPeru and closed.

[closed 0]

...Is totally wasteful as your using the divs for no reason other than to say in the code that this is a section. The following makes more semantic sense:

<h1>Website Title</h1><p>Some text some text some text</p><p id="footer">Copyright me 2007.</p>

See, it is much nicer and won't take as much styling. I know it's not very common to come across, but it does happen (well variations of the above).
...

the advantages of your approach is that the code is cleaner and neater, more points in semantic web, it seems that your are focused on the contents rather than the design which means good web site *cheer*

btw for the hobbyist like me, and for the sake of my heavy gfx and design styling an additional divs make sense, like drop shadow here, gradient their, rounded on that corner, marker to the side and soon... and i don't hesitate to use more divs if needed.

it seems that different people/designer have different approach in coding xhtml. love your approach

[Quatrux 4]

If a browser doesn't support the standard then it will fall back into quirks mode, therefore displaying the site in it's basic form anyway. So support for doctypes is not enitrely necessary. Additionally, XHTML 1.1 does not come in any flavours other than itself, so unlike 1.0, there are no Frames, Traditional, Loose, Strict, etc.

In addition, it is a bad practice to not declare a doctype for your site or any site and only use html head /head body /body /html due to some things by the browser may be displayed differently, for example when you don't declare a doctype, on IE7 browser, the css :hover only works with anchor links and not on other elements.

[FirefoxRocks 0]

HTMLIdeally, you should be working under the XHTML 1.1 doctype specification. Some reasons:

* Improved semanticism - make use of the elements available appropriately to convey the information as it was intended.
* Improved understanding - because of an increase in semanticism, it's easier for your audience to understand what your trying to convey.
* Cleaner code - due to the deprecation of some elements and the strict requirements of nesting, closing and structure, your code becomes much cleaner and hopefully more readable.
* Faster - cleaner code = faster generation; the browser doesn't have to do as much work to render your site.

First of all, XHTML 1.1 MUST be served with application/xhtml+xml MIME type, which can be tricky. Internet Explorer doesn't support this MIME type (it requests a File Download ) so you will miss many visitors. If you serve XHTML 1.1 over text/html (usually), the document is TRULY XHTML 1.1. I recommend using XHTML 1.0 Strict (almost same) instead, otherwise deal with some server-side content negotiation scripts!

You'll often find people saying "I want a CSS, not a table site". This is an inaccurate conception. HTML and CSS are two different modules connected by a rule or link. HTML is used to present the data where as CSS is used to style the data. Tables are part of HTML and should be used when tabular data is being displayed. CSS should be used to style your site, from structure to typography and forms to colour. The use of tables to create layouts are long-gone.

I agree, CSS is the way to go. However I still use tables for 1 of my sites because I want to retain utmost compatibility with all browsers and IE positions things funny (tried many, many tips). In my XHTML tutorial, I have informed that Tables for layout is NOT the way to go.

You shouldn't depend on divisions (<div>) or span (<span>) neither. Only use the div and span elements when you are absolutely sure that your need them and your site layout will suffer without them. It is possible to create layouts without using divs or spans.

If you use <div> or <span>, make sure you have a good use for them and that you probably use heavy CSS coding on them. <div> with an id attribute is not very useful because it is a one-time use thing, use it only if you are covering a large area.

When creating forms, leave nothing out - fieldset, legends and labels are all part of a form (and inputs) so use them. They'll make your form look better when the styles are off (and can make your form spectacular when the styles are on).

I love using <fieldset> as well as <legend>, not to forget <label>. They are part of the Section 508/Web Accessibility Initiative guidelines so that my audience is larger for disabled people and/or screen readers. I don't know how you can make the forms look "spectacular" though.

Those CSS tips are great! I have never even seen such an advanced selector The part explaining browsers was really helpful.

Thanks for the great info!

[TavoxPeru 0]

If you use <div> or <span>, make sure you have a good use for them and that you probably use heavy CSS coding on them. <div> with an id attribute is not very useful because it is a one-time use thing, use it only if you are covering a large area.

I love using <fieldset> as well as <legend>, not to forget <label>. They are part of the Section 508/Web Accessibility Initiative guidelines so that my audience is larger for disabled people and/or screen readers. I don't know how you can make the forms look "spectacular" though.

 

Those CSS tips are great! I have never even seen such an advanced selector The part explaining browsers was really helpful.

You can get "spectacular" results for your forms if you apply the advanced selectors :hover and :focus in your fieldset, input and textarea tags, but, as usual, you don't see it in IE -¿IE7+?- only in FF.

 

I'm just redesigning a client's website -it's almost done - in which i use these selectors with my forms, take a look to these pages:

Contact Us Form

Reccomend Us Form

Stu Nicholls | CSSplay | CSS styling of forms

BTW, from the last website is where i found the use of these selectors.

 

Best regards,

[mik1405241541 0]

First of all, XHTML 1.1 MUST be served with application/xhtml+xml MIME type, which can be tricky. Internet Explorer doesn't support this MIME type (it requests a File Download ) so you will miss many visitors. If you serve XHTML 1.1 over text/html (usually), the document is TRULY XHTML 1.1. I recommend using XHTML 1.0 Strict (almost same) instead, otherwise deal with some server-side content negotiation scripts!
Those CSS tips are great! I have never even seen such an advanced selector The part explaining browsers was really helpful.

Thanks for the great info!

I've not come across any problems with the XHTML 1.1 with application/xhtml+xml MIM type, it works perfectly in my IE6, IE5.5, Opera 9x and FF2.x can you please provide a link to the article proving this please?

The advanced selectors (also known as attribute selectors) are quite handy if you're willing to make styles that are solely based on a specific element (or elements). Thank you for pointing it out that you've never seen such, as I have now added to it.

Thanks for all the feedback guys (and gals?).

[TavoxPeru 0]

I've not come across any problems with the XHTML 1.1 with application/xhtml+xml MIM type, it works perfectly in my IE6, IE5.5, Opera 9x and FF2.x can you please provide a link to the article proving this please?

 

The advanced selectors (also known as attribute selectors) are quite handy if you're willing to make styles that are solely based on a specific element (or elements). Thank you for pointing it out that you've never seen such, as I have now added to it.

 

Thanks for all the feedback guys (and gals?).

Yes please provide a link to the article proving this because i don't have also any problems with the application/xhtml+xml MIME type with IE6 and FF2.x.

 

BTW, i read a couple of articles related with this but when i test it i don't have any problems as i say, in both ways i get the same result:

Serving XHTML As HTML

Serving XHTML As XML

Now, i have a little problem when i use big images and try to load the webpage containing it more faster, so, I remember a technique that do it and works perfectly with HTML 4.x, it consists to split this big image into a group of several smaller images and then assembly this group of images with a table to show the big image, but when i try to use this technique with XHTML 1.1 i dont get the same result, does anybody knows how to do this????

 

Best regards,