First, all developers are very thankful for CSS. No question about it.
Prior to CSS, all the visual formatting of a webpage was coded directly in the HTML markup. For a website to have a unified theme, each page would have to repetitively define the layout and color scheme. Changing the look and feel of the website, however, was a nightmare. Changing just one color in your website’s theme would require editing every page of your site.
Luckily, CSS solves that.
CSS Then
CSS was proposed to tackle the very issue described. By separating the presentation from the content, you could define the visual formatting of your site once and link to it externally from different webpages. Editing the style of your website would only entail editing the external stylesheet. This process also naturally uncluttered the HTML markup. By stripping the code that formatted the pages visually, only the content remained. You could then place content in the HTML tags that were proposed to hold such content, i.e. use table for table/chart content as opposed to formatting the layout. Separation of the content and presentation allowed for easier maintenance, for when you wanted to fix the page’s content, you looked in the HTML, and when you wanted to fix the layout, you looked in the stylesheet.
Additionally, you could style all tables at once, or all paragraphs at once, or target specific headings or lists. Via inheritance, grouping, and the various ways to select elements in CSS, you would only need to define a particular style once. This solved the previous repetition problem of having to, for example, manually specify that all the text in the tables are red for every table that you encountered.
One webpage could also draw sources from multiple style sheets, allowing for greater modularity and flexibility with your website designs. CSS also allowed for different mediums of display to have different presentations. For example, you may wish to format the printed version of your website differently than the screen (monitor) version.
Another issue that CSS addressed was web accessibility. Visually impaired users rely on their computer’s screen reader technology to read the page’s information back to them. Suppose you had an image that described some product’s features as text inside the image. The screen reader would be incapable of reading the text from the image, and a visually impaired person would not be able to learn about the product’s features. It would be repetitive for a non-visually impaired user to see text on a webpage that listed the same features shown on the image, but this repetitive list would be necessary for the screen reader to read the information back to the user. The solution is once again CSS, where you could simply hide or remove the presentation of the text from the website. Then, a non-visually impaired user would not see the content, but the content would still exist in the HTML markup for the screen reader to process.
There are many advantages that CSS brought to web developing. Despite all the issues CSS addressed, there are still more problems. It is however, in the areas of weakness that lie great opportunities for improvement.
CSS Now
One of the biggest hurdles that CSS is still facing today is browser support. It has certainly improved from a decade ago. Before, the nature of the problem was that browsers did not fully support all the specifications of CSS. Version 1 of CSS (CSS1) was completed in December 1996, and it wasn’t until March 2000 that one browser (Internet Explorer 5.0 for the Macintosh) supported over 99% of the specification (and supported it correctly). Though other browsers at the time “supported” CSS, they were severely incomplete and had a lot of bugs. One of the biggest crises that CSS faced was in the way that several versions of Internet Explorer implemented the box model. IE interpreted the width definition incorrectly, and being the dominant browser, websites catered to IE, thus causing many sites to break when viewed in standards-compliant browsers. Since people still use older browsers that are not CSS standards-compliant, cross-browser testing of websites is still necessary to this day.
Thanks to the competition between the browsers battling for the number of users though, modern browsers do support stable versions of CSS. The nature of the browser support issue is now in the varying ways that browsers support draft versions of the CSS specification.
You could point the finger at the W3C (World Wide Web Consortium) for their turtle-pace development process of the CSS specifications. Recall that CSS1 was released in December 1996. CSS2 was first drafted in November of 1997 and published with a “recommendation” status in May, 1998. Meanwhile, CSS2.1 was also drafted in November of 1997. To shed light on the slowness, CSS2.1 was in its fourth “candidate recommendation” status in September 2009, then was back to its fifth “last call working draft” status in December 2010, and then to its second “proposed recommendation” status in April 2011. (Note that its first “proposed recommendation” draft was back in March 1998.)
CSS2.1 has mostly been stable, so it enjoys support from all modern browsers. CSS3 meanwhile, is the newest. It is separated into modules instead of a massive single draft. The earliest drafts that were part of CSS3 were published in June 1999. Some modules are in more stable statuses than others. But due to the lack of the final “recommendation” status of CSS3, browsers are supporting the newest CSS specifications with browser-dependent CSS rules, more formally known as vendor-specific prefixes. Browsers that render webpages using the WebKit layout engine will process the CSS rules with the prefix “-webkit” while Gecko engines will process the rules with prefix “-moz” (since Gecko is created by Mozilla). Examples include “-webkit-transform” or “-webkit-transition,” based on the CSS3 draft.
People have mixed feelings about using vendor-specific prefixes. However, I think they will help speed up the development pace of the CSS specifications.
Moving Forward
Some argue that vendor-specific prefixes are proprietary code, and that the creators may change its usage on a whim. This is a rather generic fear though, as most vendors who release their version of the rule have referenced the working drafts of the CSS specifications, where the more stable-status modules can especially help in providing reasonable expectations of what the final draft will be like.
Another argument against vendor-specific prefixes is that it forces the developer to write really repetitive code, a separate rule for each vendor. Repetitive code is against good coding practices and potentially causes headaches for maintenance later on. Vendor-specific prefixes also do not pass CSS validation. While validation encourages good coding practices and is important, a user’s interaction with the webpage is arguably more important since the webpage is ultimately the final product and goal, not the elegance of the code itself.
The bright side of vendor-specific prefixes is that it can influence the speed of the W3C’s decision-making process when it comes to finalizing the CSS3 specifications. If there exist several vendor-specific-prefix rules that are the same in behavior and usage (besides the name of the rule where it varies in the prefix), the W3C can be more confident in finalizing that particular rule since so many people are already using it. It also exerts pressure on the W3C to quickly finalize it since the community at large already supports it.
Vendor-specific-prefix rules also prevent the usage of hacks developed to exploit the different implementations of the layout engine embedded in the different browsers and their versions. Hacks are often not obvious and sometimes make no sense whatsoever. For example, the following is a sample CSS hack:
padding: 10px;
width: 200px;
w\idth: 180px;
height: 200px;
heigh\t: 180px;
If the code appeared without comments, it may confuse the reader. It would be difficult to figure out which browser’s parser was being exploited to render a consistent box model. Contrast this to vendor-specific prefixes, which are explicit in which browser they affect in nature.
Hacks are also a very reactive approach, one that is taken after the developer realizes something “doesn’t work.” Vendor-specific prefixes on the other hand, are proactive. The widespread adoption of hacks will not help the W3C constructively in coming up with a solution. They only point out that there is a problem, as the W3C would not formalize a hack. Meanwhile, vendor-specific prefixes are proposed solutions in themselves. For example, the usage of the gradient rule is proposed differently by the different browsers/layout-engines.
WebKit browsers propose the gradient rule usage to be:
Whereas Mozilla proposes the rule usage to be:
The W3C now has examples to look at when considering the final specifications.
Conclusion
CSS has solved many issues that plagued web developers in the younger days of the internet. But as the web changes and grows, new problems are faced and web developers need more powerful tools. One of the biggest issues with CSS now is in the way that the CSS drafts are interpreted by the different browsers, as these drafts are not finalized specifications. Vendor-specific prefixes are just one aspect that can help CSS move forward from this issue. It is a good compromise between (1) enjoying newly proposed CSS features now and (2) waiting years and years until they become part of the final specification.
References
http://en.wikipedia.org/wiki/Cascading_Style_Sheets
http://www.alistapart.com/articles/prefix-or-posthack/
http://www.wise-women.org/tutorials/csstut/flow_kl_2.jpg
http://www.toothpastefordinner.com/072709/css-programmer.gif
http://www.blooberry.com/indexdot/history/css2.htm
http://www.w3.org/standards/history/CSS2
http://webdesignerwall.com/tutorials/cross-browser-css-gradient
No comments:
Post a Comment