mik1405241541

I would never employ you.

I'm surprised to see you still here yordan

Web designers should now be using techniques that are adaptable to devices. If you're not designing websites with the expectation that it will be viewed across a massive range of screen resolutions and devices, you're not doing your job properly.

Do you mean that you want 4 background images on the same element? E.g., a paragraph element (<p>) with four backgrounds?If so you can do it the fast way or the cluttered way. The fast method is relying upon CSS3 and your users using up-to-date browsers. The cluttered method is stacking the <p> element with spans or parenting with divisions.

BUMP!I'm back again! On Christmas Day of all days... Merry Christmas everyone.I didn't change my name, I have forgotten my old (twitch) email address and password.

Brilliant vujsa, I'd just like to add my two-bits.Before you start thinking of writing a tutorial, check out your visitors. I don't mean stare at their rear-ends, I mean track their behaviour on your site. Why write an endless tutorial when most of your visitors only come to your site to see the latest comic cartoon, catch up on a bit of gossip or just download your latest offering? The more information you have behind the average visitor, the better.There are plenty of tools out their to help you track the your visitors through your site.Additionally, to paraphrase Problogger, it's not the writing of your content, it's the editting. There are few writers out there capable of coming up with a captivating article first-time round. Make sure you spend at least an hour checking through your article, making adjustments and even get the opinion of someone else if you can.Anyway, I don't want to w.h.ore this topic anymore.Again, excellent advice on writing tutorials.P.S. The point about the design of tutorial, specifically the dark text on light background - you can use pure white and black as long as their is stark contrast in that area to the surrounding areas and that the content area in question is in good proportion to the rest of the layout.

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?).

That reads exactly how the email subjects from a worm mass-mailer I had been infected with.Care to tell us what this article is all about?

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. 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. 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). 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. And where would the fun be in that? Thanks for your comments Arbitrary, Quatrux, TavoxPeru and closed.

Heya guys I'm back (a bit obvious eh?). If you didn't know me before, I was twitch or mik. Whichever you remember me by. To tempt you all into letting me rejoin the community, here's a little something I find to tickle your design taste-buds: http://www.famfamfam.com/lab/icons/ The designer has made a few collections, but the Silk collection is by far the most complete and BEST. With 1,000 high-quality icons, you'll never need another icon. Be aware, these are a max of 16x16 px so not approrpriate for desktops (unless you have a mini lifestyle).

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. CSSWhen 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.

Why? The easiest solution is display: inline on all floating elements, because IE messes up with float sizes.Quatrux, can you please explain clearly in words what the issue was please?