Take the 2-minute tour ×
Webmasters Stack Exchange is a question and answer site for pro webmasters. It's 100% free, no registration required.

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. http://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.

  1. older and rarer browsers may full support of CSS but not JS.
  2. JS maybe disabled
  3. JS is usually slower (unless script is turned into binary and probably JIT-ed). this is more evident in mobile devices.
share|improve this question

closed as not constructive by Su', John Conde Mar 29 '13 at 12:18

As it currently stands, this question is not a good fit for our Q&A format. We expect answers to be supported by facts, references, or expertise, but this question will likely solicit debate, arguments, polling, or extended discussion. If you feel that this question can be improved and possibly reopened, visit the help center for guidance.If this question can be reworded to fit the rules in the help center, please edit the question.

1 Answer 1

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:

  1. 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.

  2. 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.

share|improve this answer
    
thnx MainMa for answering. you bring up a very good point at (2). a lot of sites already makes AJAX a minimum requirement to the site to work, thereby mandating javascript already. but some sites simply don't need AJAX yet, making it more seem like JS is a burden just to achieve the desired interactivity. letting CSS do it crosses out the need for JS. –  Amnat Heer Mar 29 '13 at 20:11
    
the part: "so basically the rest of the elements needs to be handled by using onclick, onmouseover, etc, which are all javascript." i wish to change "onmouseover" to "ondblclick". –  Amnat Heer Mar 29 '13 at 20:12
    
the part: "so basically the rest of the elements needs to be handled by using onclick, onmouseover, etc, which are all javascript." i wish to change to: "so basically for any other events for any elements they need to be handled by 'ondblclick', 'onkeypress', etc, which are all javascript". –  Amnat Heer Mar 29 '13 at 20:22
    
the 2nd comment i wanted to edit, but time expired, so i couldn't, so just ignore it. see, i thought :link, :visited, :active, :hover, :focus were all exclusively just for <a> –  Amnat Heer Mar 29 '13 at 20:23

Not the answer you're looking for? Browse other questions tagged or ask your own question.