I'm always weary of online tutorial websites that teach you how to effectively write HTML/CSS. Although the bios of the authors often refer to the amount of time they've spent working in the web industry, neither does it refer to the type of exposure they've had to different projects, nor does it mention their intentions.
If I were to develop CSS with a strong focus on browser compatibility, it would be far different from developing it with a focus on browser performance (read: Steve Souders). The same goes for CSS intended for longterm use and CSS written to support accessibility. These things are all different.
Websites like Smashing Magazine offer great tips on how to approach the technical issues inherent with web development, but the tutorials should be seen as just that; references. There's no such thing as a one-solution-fits-all. If there was, it would probably be one that far exceeds any clients' budget.
Showing posts with label CSS. Show all posts
Showing posts with label CSS. Show all posts
Sunday, May 9, 2010
Wednesday, May 5, 2010
Practical applications to reverse-engineering
I find myself spending a lot of time reverse-engineering other people’s work. That is, it’s rather typical that clients have existing systems and frameworks where the amount of documentation is tragically inadequate. The trick is to learn as much as you can about the author(s) and then emulate what they’ve done. And although it’s rather cliché to say this, you really can learn a lot about a person by sifting through their code.
I was working on a project last year which involved developing work specifically targeted for the Nintendo Wii browser. Even though it is powered by Opera, it doesn’t behave the same way as its desktop cousin. The issues are compounded by the fact that there is no official documentation from either Nintendo of America, Europe or Japan; thus it was necessary to break down the issues myself. The full list is a lot more explicit so I’ll simply fire off some of the most glaring facts:
- There lacks metrical data to gauge the user's environment. The following issues remain unresolved:
- There are different Nintendo Wii browser versions and they’re linked to firmware patches.
- There are different versions of Adobe Flash for the Wii browsers. While one version of Flash can handle video well, the other doesn't.
- During the initial launch of the console, the Wii browser costed $5. Someone found a hack to enable one of the apps –which then allowed for a modified version of the onboard browser to run: The legitimate $5 browser had a different resolution than the hacked. In 2009, the decision was made to offer the Wii browser at no charge, but the divide was already set.
- What are the dimensions one can work with on the Wii browser? 800x600? No. An obscure width to the likes of 813px. What’s even more strange is that when the <BODY> has a CSS width of 100%, any <DIV> set to “100%” will be locked at 813px.
- The Wii has a feature that allows users to zoom in and out of the page. This feature – coupled with the onscreen menu — throws Javascript haywire because the viewable screen height constantly changes.
- Anchor tags <A> as well as tags which can be clicked (ie. adding the Javascript function "location" to a div) will always have a visible border around it. I've yet to find a CSS or Javascript solution to this unsightly issue.
From this experience, I can only conclude that web development experts weren’t initially consulted by Nintendo before the browser was integrated onto their console. Since I don’t personally own a Wii, the likelihood that I'd develop personal work for such a platform is very slim. In any case, good luck to all those who have an interest in it!
Sunday, January 24, 2010
Hacks
A coworker of mine recently sent me a link to a website that showcased what CSS is capable of doing in terms of mimicking Javascript rollovers and basic behaviours. Although the site did appear to work as stated, I opened up the source code to discover extraneous hidden HTML markup that littered the page. With this new information, I’d have to say that the CSS didn’t work as stated.
CSS is supposed to contain the presentation markup. Javascript holds the behavioural scripting. HTML holds the content. When CSS is used to replace Javascript by means of littering on the page content, this becomes a hack. Using HTML and CSS to create behavioural hacks to do what Javascript can easily do. It’s a cool concept to execute, a poor architecture for implementation.
CSS is supposed to contain the presentation markup. Javascript holds the behavioural scripting. HTML holds the content. When CSS is used to replace Javascript by means of littering on the page content, this becomes a hack. Using HTML and CSS to create behavioural hacks to do what Javascript can easily do. It’s a cool concept to execute, a poor architecture for implementation.
Wednesday, November 25, 2009
Limitations and Guidelines
I've been working on a project where one of the personal goals I have set for myself is to try and maintain a consistent user experience. I'm well aware that "user experience" is often used quite loosely and if I were to ask a dozen people, I'd receive a dozen different answers. Regardless, I do think it's necessary to bring to light some of the things that have been surfacing in my head lately about online software development.
I'll first start by saying that I feel it's always necessary to maintain standards. Just as much as the iPhone has a consistent "swiping" animation, these visual aids --whether they're animation, behavioural or even just an underline on a text link-- need consistency. A user should be able to predict what happens when a cursor hovers over a button or when it is clicked. Intuitive design requires a level of predictability.
Even though the creative team has been rather reluctant with setting "limitations" to creativity, I've been trying to set guidelines. These guidelines are rudimentary at best, but they include standards for CSS, animation and behaviours on a per-project basis. Perhaps this may prove to hinder our designers, but I can't comprehend how ten different button rollover animations will help the end-user other than confuse them.
I'll first start by saying that I feel it's always necessary to maintain standards. Just as much as the iPhone has a consistent "swiping" animation, these visual aids --whether they're animation, behavioural or even just an underline on a text link-- need consistency. A user should be able to predict what happens when a cursor hovers over a button or when it is clicked. Intuitive design requires a level of predictability.
Even though the creative team has been rather reluctant with setting "limitations" to creativity, I've been trying to set guidelines. These guidelines are rudimentary at best, but they include standards for CSS, animation and behaviours on a per-project basis. Perhaps this may prove to hinder our designers, but I can't comprehend how ten different button rollover animations will help the end-user other than confuse them.
Monday, September 28, 2009
Naming schemes
Here is a list of minor things about the naming schemes of CSS classes, files and URLs which I've accumulated over the years. Some may be outdated, but nonetheless they were issues found over the course of the last decade of web development:
- Back in the Netscape days, some of the versions did not play well with underscores. This meant that underscores were specifically avoided to prevent CSS issues associated with Gecko browsers. This may not be an issue anymore but it is still avoided for SEO purposes.
- GOOD: <A CLASS="db-item">
- BAD: <A CLASS="db_item">
- Search engine optimization methods suggest using hyphens over underscores for both CSS classes and files.
- When CSS classes have numbers immediately proceeding hyphens, the Javascript in some browsers will error. This issue still exists in some IE browsers. Avoid numbers after hyphens!
- GOOD: <A CLASS="db-item1">
- BAD: <A CLASS="db-1">
- In the past, older, legacy servers weren't able to differentiate upper and lower case letters. They would call upon the same file regardless of case. This problem has been “fixed” and therefore, it opens up the possibility of having two different files named “test.jpg” and “Test.jpg”. I highly recommend filenames and URLs containing only lower case. Domains can never be case-sensitive, so why complicate this procedure by introducing capital letters into the URL? Does it make things easier for a user to remember the word AND casing?
- Classes as contextual information. Naming classes based on a visual aspect “middle-column” has always been frowned upon because CSS is supposed to separate presentation information from the HTML. Instead, class names that describe the component or information works far better.
- GOOD: "breadcrumb" or "main-content"
- BAD: "left-column" or "font-size12"
When it comes to web development on large-scale projects, I firmly believe in simplicity and consistency. When a decision has been made on the naming schemes, however wrong it may be, it's best to stick with it. This is a more pragmatic approach because it addresses several things:
- Developers will always need to work within some sort of limitation.
- As a developer, you probably weren't brought onto the project to re-code existing work.
And to be completely frank, if ever you *are* brought onto a large-scale project, the naming scheme should be the least of your concerns.
Subscribe to:
Posts (Atom)