Styling the html element
Styling the html element
|
|
In his article “HTML’s a Tag Too,” Bryan Veloso discusses the benefits of applying styles to the <html> element. He argues that by making more effective use of <html>, developers could eliminate the need for a wrapper div. Everything would effectively be “moved up” a level – apply global styles to <html> instead of <body>, and then <body> can serve the same purpose as the wrapper div would have. Bryan points out that this can be particularly handy in XHTML 1.1, in which the <body> no longer stretches the entire length of the page.
It’s a neat idea, but for many developers – particularly those of us who work on large, enterprise-level sites – it is simply impractical. On large sites, rarely would you want to declare a global background image, for example. Or, you may not be able to access certain elements of a page at all, due to CMS limitations or other restrictions. However, for a small-scale site, styling <html> could be a good way to reduce divitis, as long as you’re mindful of scalability issues.
Read | Permalink | Email this | Linking Blogs | Comments
Similar Posts
- Documents
- Client files
- Copy
- Proofs
- Staged/Development area (folder for a “clone of the site” where you can make changes and get sign off)
- Downloads
- reset.css
- main.css
- structure.css
- typography.css
- print.css
- helpers.css
- More consistant rendering due to reusing ideal CSS techniques
- Easier editing and maintenance as you can better recall what names mean
- The start of code that can be saved and reused every time
- A class that floats an image left / right and gives it some margin
- The structure for an unordered list navigation
- The structure for a form
- external link, pdf and download icons
- clearfix
- png fix
- Typeography baselines and hierarchies
- etc…
- Font sizing (all normal text is 12px, featured text is 14px bold)
- Margin’s (normal margin is 10px between elements, margin between two content blocks is 40px, etc…)
- All navigation tabs will have 15px height and 13px font
- etc…
Using Keywords – css-discuss
CSS font-size keywords: xx-small, x-small, small, medium, large, x-large and xx-large. Part of: UsingFontSize. In modern browsers rendering in Standards Mode, body {font-size …Fonts
Unlike most other CSS properties, values are … CSS absolute-size values. xx-small. x-small. small. medium. large. x-large. xx-large. HTML font sizes …CSS Background Styles.
HTML CSS JavaScript XHTML SSI Perl … to declare a WHITE background for the main page area using embedded CSS : … css”> body {background-color: #ffffff; …Conditional CSS – not just for IE
It’s true that IE is the most notorious browser for inconsistencies, incompatibilities, and bugs. But the fact remains that no two browsers are created equal, and while IE is the most likely to cause headaches in the course of development, other browsers can be culprits, as well.If you run into a major roadblock, Rafael Lima’s CSS Browser Selector could be your saving grace. A tiny bit of Javascript (less than 1kb!) determines the user’s browser and creates an accordingly-named class. From there, it’s simply a matter of applying the styles that were written for that particular browser. For example:
.ie .example {
background-color: yellow
}
.gecko .example {
background-color: gray
}
.opera .example {
background-color: green
}
.konqueror .example {
background-color: blue
}
.webkit .example {
background-color: black
}
.example {
width: 100px;
height: 100px;
background-color: brown;
} The colored box on the CSS Browser Selector page gets the point across better than anything else, though. Open the page in a few different browsers to see for yourself.
Read | Permalink | Email this | Linking Blogs | Comments
CSS: font-size
Jak vytvořit www stránku: CSS – font-size … font-size: xx-small | x-small | small | medium | large | x-large | xx-large | 10px | 10pt | 10% | 11em | 2cm | 5mm8 methods to bring your front end coding to rockstar levels
There are a lot of good front end developers out their right now. If you fancy yourself as a front end editor then you really should be looking at how you can differentiate yourself from the rest. Yes there are lots of “good” front end developers, but there are not a whole lot of excellent front end developers.
1. Improve Your Semantic Names
If you work in a team or ever revisit your code and need to update it then you should think about the quality of your class and ID names. It is not uncommon for developers to use class names like “box”, “wrapper”, or “container.” While you may think that these naming conventions or “semanitc enough” none of them describe the content that is inside them. Instead consider using HTML5 spec’s such as “content-sub”, “section”, “content-aside” or “content-sup.”
You and your team will have a much easier time sorting through code that describes the content than trying to remember the details of “box.”
Read more about semantic naming from Andy Clarke and A List Apart.
2. Improve the Organization of Your Files
I think it is reasonable safe to assume that most developers have at least started to organize their files by type (ie: a folder for images, css, javascript, etc…). You can go a step further and improve the organization even more, particularly any folder that is going to have a lot of files (such as Images in particular and CSS as a secondary.)
I find it best to create sub folders with in images and separate images based on design structure, buttons, headlines, photos, etc…
There are plenty of other folders you may want to create to keep the updating and growth of a site easy and efficient, including:
The Elements CSS Framework does a great job of organizing files based on the normal client/provider workflow.
3. Use Commenting in Your XHTML
Any time you end up developing complex layouts you are bound to use a lot of <div>s in your markup. This can be particularly confusing to go back and edit as it becomes hard to figure out which div is being closed where. You may see three </div>s all in a row.
To combat this simply add some coments at each </div> (or any other closing element if you find that it will be helpful) to let you know what element was just closed.
<div id="header" class="section">
<div id="header-logo">
<h1>HTMLiZER</h1>
</div><!--/#header-logo-->
</div><!--/#header-->
If you find it useful you can take it one step further and comment the primary area you would be editing (such as the main content area, sidebar, etc…)
4. Segment Your CSS
For small 4 – 5 page brochure sites your CSS will be pretty manageable even if you don’t spend the time and effort you should into organizing and commenting. Once you start developing web applications or large sites with a vast array of design “modules” you should make sure that you organize your CSS in way that is easy to manage.
I recommend splitting your css into logical different files for better organization, such as:
This way you don’t have to sort through all of the typography styling to find the area where you defined the size of the header. Likewise if you want to adjust the headings it is pretty simple to find it through a small typography.css file rather than a huge file that has everything.
5. Create a TOC With Comments in Your CSS
Every CSS file you plan on editing and extending over time should have a table of contents at the begining and a headline seperator at every section. This will allow you to easily jump to a section using “find” rather than scrolling for that one area that had the CSS you are hoping to modify.
EX
/***********
TOC:
=1: Header
=2: Content
=3: Footer
=4: Navigation
=5: Portfolio
****************/
/* ********* =1: HEADER *********** */
#header { … }
6. Compress and Combine Your CSS files
Even though it is easier to work on a site when you segment and organize your css into several different file names, it actually causes your site to load slower. The more calls the browser has to make to the server for additional files the slower it will load.
Before deploying your css files you should combine and compress them. Compressing them removes any uncessary whitespace, comments, etc… that is unnecissary when the site is live.
There are several handy tools to do this including this online version.
7. Create your own framework (or improve on another one)
As you get more experience under your belt you will find that you use the same methods and naming conventions over and over. This is helpful for several reasons and it should be encouraged. It has lots of benefits including:
Chances are that you end up rewriting the same type of code over and over again, simply because you don’t have it stored somewhere. Some examples may be:
Rather than reusing these bits of codes write modules into your own CSS framework (or you could imrpove on another one). This way you can streamline the development process so it takes less time and improve the consistancy of your work.
8. Develop your CSS to be modular or “object oriented”
You could assign every bit of code an unique ID or adjust the margins and padding per instance. Lots of coders do this to try and get the CSS as close to the designers comp as possible. However this is inefficient in development time and file size. Establish a set rule for differnt types of content and how they should be styled, this should include basic things such as:
This way you don’t have to rewrite the code for every new item added to the site. Additionally it will keep the site feeling consistant and well balanced visually. If all elements and every page follows the same rhythm it will feel more unified as a whole.
Some call this object oriented css, it is worth looking into for rockstar like front end coding.
Don’t forget about :active
Every once in a while I remember some functionality of CSS that we have had access too for ages yet is rarely taken advantage of in creative ways. The last time I really wrote about this is when I had discovered a way to make other menu items change when you hovered on just one of them, as you can see here in the Advanced CSS Menu Trick article.
Sometimes rediscovering these capabilities are valuable for creating new ways to add creative touches, such as the parallax scrolling effect. Other times they can greatly improve the usability and user experience of our sites. In some cases they do both.
I was recently reading through “The Elements of User Experience
,” which opens with a compelling story describing why things going wrong in your day could be the fault of poor design in regards to usability. Interestingly enough one of the points covered in this section is the use of feedback as a way to notify a user that something has occurred.
Most Web Designers Fail to Take Advantage of :active
In the case in the book they mention a coffee pot beeping so you know that it was switched on. This same principal of offering a user basic feedback applies to the web, yet we rarely see it used in all instances it can.
We have had the ability to style a links :active pseudo selector since CSS1, yet when was the last time you actually used it? I will admit that I am a grand offender as well, as I couldn’t tell you. However the value of such a subtle detail can have large benefits to a users experience of the site. Not to mention it does give another avenue to enrich the interactivity of our interfaces.
An Common Example
If you have ever done any usability studies you will have probably run into a situation where things that seem incredibly simple end up taking significant amount of time. One of the most basic of these situations is that of clicking on a simple link. I have many times in my “behavior observing” career seen a user who thinks they have click on a link, despite having missed it slightly.
What follows is a long pause while they wait for the page to change, before getting frustrated and either blaming the internet, the site, or swirling the mouse to ensure the computer hasn’t locked up.
This could all be solved by simply giving the user feedback when a button is clicked. Interestingly enough flash based websites have done a better job through out history of accomplishing this than most HTML sites, done so by adding a subtle “clicking” noise as a link is clicked.
Of course I am not advocating the use of sound (as it fails on several accessibility levels among other issues), however it wouldn’t be hard to give the user some feedback to let them know the link was successfully clicked on.
What We Can Do
By using the :active selector in CSS we can give the user some feedback that a link has in fact been clicked. This way if there is any sort of delay the user knows that it is successful loading and they don’t have to reclick the link. This will make the site more usable and as more developers and designers begin to adopt this process the web itself will become more usable.
Additionally it opens up a new area for us designers to work our creativity. We can now think about what subtle design elements we can give links and buttons to indicate to the user that they have been clicked. In my example, a beveled button appears to be pushed inward.
It Isn’t Perfect
Despite the fact that it is a dramatic improvement over not having any feedback and it does give us more room to express our creativity, the functionality isn’t perfect. You may notice in the demo that if you click on a button quickly it changes so fast you might not even notice. You may not realize that there is even an effect giving you feedback.
Regardless, using :active will still enhance the user experience. Even if only 10% of your users notice it is worth the time and effort put into it. Additionally users who are less familiar with computers and the internet will be more likely to hold the mouse button down longer and thus notice the effect.
Consider Adopting it as a Regular Practice
I really advocate the adoption of it as normal standards based markup. If it becomes a convention than users will expect some sort of notification that a link was clicked and even it happens to fast on the pages that load right away, they know to look for it.