I’m being confounded about an article I’ve read about your logo being an image (and not a background image). You would notice about the differences between the two wherein img puts your actual image on the page and h1 replaces the text with a background image of your logo.
You may be using one method over the other — and to calm your nerves down, Facebook and WordPress use h1 approach while Google and Firefox use img approach (and a whole lot of different combinations for other sites out there).
Now, I won’t go into details about both methods because I’m sure you’re already using one — even different from the two mentioned. What’s important is the answer to “why are we using what we use?”
The answer lies on your priorities.
You like the underlying text to be the document title of your webpage
You like the logo to be presented as is — an image of a logo
If you’ve answered the former, then most likely you’re using h1 approach and the latter, img approach.
Personally, the way I test if I’m writing a web document properly is I strip it off everything — images and CSS — and see if it still makes sense from having semantic HTML elements to its document outline. And one of the natural steps in this test is having a heading on top of your document — usually the title of the site — it could be a logo or an photograph with an inscription — but what it represents is more important.
There are lots of combinations in putting up a logo on your webpage — just be conscious of why you’re choosing one approach over the other.
Wrap the module and its elements in <div> tags. Use 4-spaces as standard for indentations.
For modules inside the content area, wrap the module in: <div class=”mod”> <div class=”mod-cr”> Your module in step 1 goes here… </div> </div>
For header, wrap the module in: <header> <div id=”header-cr”> Your module in step 1 goes here… </div> </header>
For footer, wrap the module in: <footer> <div id=”footer-cr”> Your module in step 1 goes here… </div> </footer>
This template model provides for the first container to have the display, positions, floats and the second container the width, padding, margin, border.
Apply box-sizing:border-box to the second container to fix the box model.
6 March 2013
So you’ve been developing the front-end all along but you’ve forgotten to setup a Google Analytics for the site. Not too bad, right?
But when you’ve taken for granted the IE browser version 8 and below, that’s when you should acknowledge a headache.
Checkout this list of things to account for when developing the front-end of a website.
This week, I’m conducting a workshop on basic HTML and CSS at Chikka. Participants come from the corporate communication, creatives, and content teams. For a martian to easily digest a complicated topic such as a webpage, I’ve used a human being as a metaphor for the three frontend layers of a webpage.
Frontend meaning the webpage not needing any database or server — it should launch and run even when all you’ve got are notepad, Internet Explorer 3.0, and zero prepaid load in your EDSA Mail internet dial-up connection account (no internet needed!).
HTML: the structure layer
Think about a simple human body; disregard the color of its skin or the length of its hair or whether it is male or female — god simply made it with a head, body, and legs. No complicated hiphop outfit nor nice slick pompadour; it doesn’t have any flavoring not even vanilla. It’s only a naked human being. That’s our HTML markup — purely focused on the very essence of the structure of the content.
The HTML markup is what you see when you view the source of a webpage or when you open an HTML document in a text editor.
That’s the structure of the content of your document. For example, your webpage is an article about cats, then most probably, the structure of your content is arranged according to this:
Header
Site name
Navigation
Content
Cat article
Footer
Copyright information
Of course, each item I enumerated has a corresponding HTML tag like for the header group it is <header>, etc.
It is best to forget about CSS when we’re laying out the structure layer. What all matters here is the structure of your content — don’t you ever write <header> at the bottom of the document because that’s not the correct structure. Header should be at the top, footer at the bottom.
Also, what we should give attention to in laying out the structure layer is semantics. Meaning, if you’ve got some important title or heading in your design, make it <h1> or <h2> depending on the hierarchy of your headings. Don’t use the heading tags for their font sizes; use them to show hierarchy in your headings. <h1> being the most important like the title of your site or the heading of your cat article. Likewise, if you have a list of anything, use <ul> or <ol>.
Open the HTML document in a browser, close your eyes and let someone read your HTML webpage per element from top to bottom, from left to right (or right to left in other cases) and say “next” if you want to proceed to the next element. If it makes sense to you, then most likely you’ve made the right structure.
To somehow test its semantics, you may want to use a screen reader. Everything should make sense to you while listening and “browsing” the content.
CSS: the presentation layer
Now, it’s time to present our naked human being to the world. It needs something to wear. Something like Sailor Moon’s costume.
That’s CSS, short for Cascading Style Sheets. A set of instructions that our HTML document takes to have a visual design like background color and many more.
CSS could also make HTML elements be positioned anywhere on the webpage whether at the left, right, top, or bottom.
JavaScript: the interaction layer
And lastly, whenever you want your vitruvian man to do some break-dancing, add some script.
A practical example is the validation of a form. Of course, we’ve got our content which is a form (HTML) and we’ve dressed it up with spanking gold-colored buttons (CSS), now it’s time to make it show messages when a required field is skipped and to never ever activate the button until the user fills up correctly all the required fields (JavaScript).
Combine all three layers and you’ve got that breakdancing streetdancer.
I’ve first used an iPhone and iPad before I experienced using an Android (particularly a meager Samsung Galaxy Y with Android 2.3). The very natural controls of Android were the static/consistent position of Back and its context menus (long pressing certain items particularly lists).
Then I had to use iPhone again and kept on tapping on the wrong places. Yes, it is all about habit and conditioning but I’d still find that back button useful for iPhone (instead of having it on the top toolbar).
A spoof of iPhone 5 and its back button.
And the context menu. Why do I need to take extra steps in deleting or editing an item? For example, I would like to delete a contact; in Android, long pressing a contact would bring up a context menu while in iPhone you would need to find the Edit button and find out what is available to edit.
I remember in the era of DHTML, right-click customized menus in webpages were made available. But it was against the norm and it was new and people just wanted to stick with what’s recognizable.
That shouldn’t happen in these times. We should be innovating towards what would make the lives of people easier and better (or at least not harder or worse).
A time will come when everything would have context menus. You would have an option to do something to anything you right-click on or long-press on. Or maybe to anything you point your Wikipedia gun at.
Designing HTML emails is just like designing a webpage. You go planning your page’s width and length of content and consider its appearance in your target browsers. Only that one of the browsers to consider is IE6! This is just an analogy to the fact that not all email clients have wide support for HTML and CSS.
Popular email clients include: Microsoft Outlook, Gmail, Yahoo! Mail, Hotmail, and email clients used by specific platforms like iPhone, iPad, and Android. All of these top clients should be considered for the simple fact that it just might be the one your recipients are using. You wouldn’t want to send a “broken” email, would you?
Here are two important things to remember in designing your HTML emails.
