: More capability from CSS so i've just finished a book to learn CSS. (known HTML since high school but didn't have the initiative to pick up CSS 'til now). anyways, ever since i started reading
so i've just finished a book to learn CSS. (known HTML since high school but didn't have the initiative to pick up CSS 'til now).
anyways, ever since i started reading about pseudo-classes in CSS i always thought it was a:
vast assortment of states for almost any tags. this would allow different formatting/layouting for any STATE of ANY ELEMENT. this would then be the mechanism to have pop-up/drop-down/tabbed menus/interactive buttons, controlling the INTERACTIVE look and feel of a page. this made sense, as CSS has always been aimed for formatting/layouting.
then i got to the end of the book and didn't find it. the most was the all-too-familiar using pseudo-classes, "hover", "visited", etc on to alter the formatting of the anchor element itself. www.w3schools.com/css/css_pseudo_classes.asp only lists a dozen pseudo-classes. so basically the rest of the elements needs to be handled by using onclick, onmouseover, etc, which are all javascript.
then i was dreaded with the notion that those interactive look and feel, even from popular and widely conforming websites, like youtube, facebook, google, etc, was achieved using javascript. i haven't gone through each of the said sites to see exactly how the code achieved those effects (it's gonna take me a while to decipher as i'm a novice in javascript; didn't even look at the .js files). but... it is JS, isn't it??
anyways, isn't it better if CSS does atleast most of the INTERACTIVE look and feel as i delineated in the point block above? implementing a drop-down navigation menu would then be like:
if :hover is true for a button, then change the block formatting (as the button is actually a sinlge lined block). the children blocks would have their "display" style property turned on (previously hidden). they are then set on having a solid background color, padding, borders, etc.. now dispalyed, the user may interact with them like ordinary links.
the rest, mostly that requires information processing, will be through javascript.
i guess my biggest objection to implementing the interactive look and feel using JS is that you can't always fall reliably back on it.
older and rarer browsers may full support of CSS but not JS.
JS maybe disabled
JS is usually slower (unless script is turned into binary and probably JIT-ed). this is more evident in mobile devices.
More posts by @Carla537
1 Comments
Sorted by latest first Latest Oldest Best
Rule of thumb:
HTML is for content,
CSS is for presentation,
JavaScript is for interactivity.
Of course, CSS allows you to have a minimum of interactivity (like hovered links), and CSS3 is pushing this even more (like animations), but still, don't expect too much from CSS when it comes to interactivity: you mostly have to rely on JavaScript for that¹.
As for the assertion that CSS allows the formatting of any state of any element, this is simply not true. Look at file submit element of a form. This one is probably the most terrible one when it comes to formatting, since you cannot change nearly anything in the layout, colors, etc.
In order to have a common look and feel for those (mostly form-related) elements, other websites are effectively using JavaScript, sometimes even Silverlight or Flash.
Last but not least, the argument that JavaScript may not be supported or be disabled is not valid, for two reasons:
Your intent is to use JavaScript to enhance the interaction design of the website. Lacking custom styles or a few pretty animations for a minority of users shouldn't bother you. In the same way, when you use rounded corners with CSS, you simply don't bother about people who use obsolete versions of IE.
Most web applications won't and financially can't align themselves on the minority of users who don't have JavaScript, just because throwing away JavaScript makes it impossible to do AJAX, client-side validation, etc.
I'm not saying that you shouldn't consider cases of users with JavaScript disabled. You should, but exclusively to comply with accessibility rules. In the same way, you shouldn't rely on CSS neither, because blind people won't see colors, widths and padding, but still should be able to access the information.
As for the performance of JavaScript on mobile devices, I recall, in 2001, that XHTML was a buzz, because its XML form would allow mobile devices to parse it quickly: HTML parsers were just too slow for those devices. In reality, better hardware adoption by the users was much faster then the adoption of XHTML by the developers, and now, nobody cares about how slow HTML parsing is: it's fast enough on every modern smartphone. In the same way, in 2001, we would never imagine how fast JavaScript would be on Chrome and other browsers. Now, we use it, and it just works.
¹ Note that HTML allows you to put presentation inside as well. While using HTML for presentation is a bad thing, there is nothing wrong in using CSS for interactivity. It's just that CSS is too limited when it comes to animations, states, etc.
Terms of Use Create Support ticket Your support tickets Stock Market News! © vmapp.org2024 All Rights reserved.