3

I think supposedly, an ideal way is that CSS only deals with presentation aspect of a document, and so CSS and Javascript are de-coupled and it is a very clean solution. We can change any CSS or any Javascript without breaking the other.

But what if we implement fancy UI, such as grayish words in a search box, and the word will disappear once the user clicks in the box, those type of behavior? In such cases, CSS and Javascript are very coupled and changing CSS will affect the Javascript some where, and it is hard to handle because in a project, there can be 5000 lines of CSS and 8000 lines of Javascript, and the need to hunt each other down and change them together can make it buggy and hard to maintain. Is there a better way or ways of doing it so that it is more clean?

nonopolarity
  • 146,324
  • 131
  • 460
  • 740
  • I disagree. CSS is still completely presentation. JS involves DOM manipulation, not CSS manipulation. There is only tight coupling if you write _actively_ tightly coupled code – Raynos Apr 03 '11 at 16:47

5 Answers5

2

In some ways it's better, and some worse, but you could add the CSS in your javascript. Many jquery plugins for instance create all CSS needed as part of the script, meaning that the whole lot is in one place.

This is better because the CSS files and JS files are distinct, but it involves moving presentation into your JS layer.

Rich Bradshaw
  • 71,795
  • 44
  • 182
  • 241
  • How would you identify the things that you added CSS to? Part of it's purpose is classifying entities as sharing appearance or functionality - if you didn't include it in the markup, then you'd need a cross reference to IDs, I guess, which seems abstraction to the absurd. One of the very common ways people use jQuery is with marker CSS tags, which do exactly that - identify like entities so the client script can do stuff to them. – Jamie Treworgy Apr 03 '11 at 16:43
  • I wouldn't recommend creating CSS through javascript. Best to have .css files and dynamically creating ``'s – Raynos Apr 03 '11 at 16:45
  • Yes, I wouldn't do it that way, but for some properties it might make sense. – Rich Bradshaw Apr 03 '11 at 17:05
2

IMO, greyish words in a textbox is purely presentational not behavior, so using CSS to do that is perfectly fine. If you try to implement such UI in Javascript, that is muddying behavior for presentation.

If you have 5000 lines of css, you probably have a different problem.

Lie Ryan
  • 62,238
  • 13
  • 100
  • 144
  • how about 12 different pages and 50 partials, together with all different tabs, controls' hover effect and tooltip, etc... the CSS file can really grow – nonopolarity Apr 03 '11 at 16:30
  • The thing is. You should be able to halve those 5k lines of CSS with say SASS or some other CSS compiler. If you got that much CSS you really need a CSS compiler to control. – Raynos Apr 03 '11 at 16:43
  • @動靜能量 It's perfectly normal that your CSS file grows as your app's complexity grows. However I don't see how having 12 different pages and lots of custom controls forces you to use JS for presentation. Nothing is forcing you to use `el.style.color='red';` instead of `el.className = 'error_feedback'; // simplistic example`. That way, everything is nicely decoupled and changes in one domain won't impact the other. 5000 lines of CSS seems way overkill to me as well. – romainl Apr 03 '11 at 16:50
2

HTML 5 brings some functionality (such as the gray text on the search box, or new input types) to try making it cleaner, but yeah, I know what you mean. Lets just remember Microsoft dominated the web not too long ago, and made quite a mess out of it, adding tags such as the blink and markee (or was that Netscape?), and technologies like .htc (IE behaviors) and ActiveX.

There are a number of technologies to develop on the web, but client side I think CSS and Javascript are your only options, so I guess it all depends on how you write your code, and trying to use the newest specifications (although compatibility then becomes a problem...)

Good luck, and if you find something out, don't hesitate on letting us know! :D

Kevin Chavez
  • 949
  • 1
  • 11
  • 27
  • sure will. yeah HTML 5 is nice... just that IE 8 is still wildly used... maybe 2 years down the road, we can all happily forget about IE 8 when its usage is 6% – nonopolarity Apr 03 '11 at 16:33
  • Don't bank on 2 years, if the legacy of IE 6 is anything to go by! – Russ Cam Apr 03 '11 at 16:46
  • @RussCam We'll kill IE. Web development will move to not tolerate old browser support. Chrome and Firefox are picking up the fast cycles. We'll have FF9 and Chrome13 by 2012. IE<9 will die. – Raynos Apr 03 '11 at 16:59
  • @Raynos - I certainly agree with the sentiments, but when you have large corporations who outsource their IT support, they either won't pay or are just incapable of keeping up with new browser versions or browsers not bundled with the OS. It's a shame, but it is the reality. – Russ Cam Apr 03 '11 at 18:54
  • @RussCam Modern browsers have changed to very short release cycles. We no longer have a "new browser every 5 years" scheme. Companies are going to need to adapt to the fact that browsers are incrementing their version every 3 months. This should force old browsers to die or at least split the entire web development sector into two in terms of old browser support. – Raynos Apr 03 '11 at 18:57
1

HTML4 and CSS 2 don't implement the semantics needed to achieve what you describe, therefore you are ending up using javascript to solve these issues.

HTML5 and CSS3 have much better implementation for separating the layers as you describe, have CSS/HTML handle the UI and Javascript handle the logic. With the introduction of for example the HTML5 'placeholder', 'required' input attributes and the CSS3 advanced selectors and content properties you are able to achieve a much better structure.

For now, use unobtrusive js where possible and maybe with 5000 lines of CSS, consider splitting your CSS and javascript in more manageable chunks.

tomvo
  • 1,409
  • 1
  • 12
  • 21
0

I don't think the problem is tight coupling of CSS and Javascript, the problem is correctly using CSS. If you have a piece of CSS that is tightly coupled with a particular function (like your grey box), then you should not be re-using it anywhere else. If there are parts of it that are shared across the site (like the basic style) and parts specific to the functionality of that one element, then you should split the class into two.

CSS serves two purposes - styling, and identification of elements that should appear and function the same. So if changing a class breaks something, then you are misusing a class, or should have created another one. It's more than just styling, it's glue.

An analogy to object oriented programming would be creating inherited classes. If you had a class that was used in one place, and you needed to do something slightly different in another place, you wouldn't change that class, you would create an inherited class for your new situation, leaving the original unaffected. In CSS you would create another class and apply both the style class, and the one specific to the functionality, to your grey disappearing box. If you want to change the basic style, then you can safely update the class that only handles that. If you need to work on your specific gray box, you work only with the class that's unique to that piece of functionality.

Jamie Treworgy
  • 23,934
  • 8
  • 76
  • 119
  • for example, one usage is to have a div behind the the ``, (overlapping, with opacity). The grey words still show even when the user click on the input box, but once typing, the words disappear by `display:none` or `visibility:hidden` on the div. (like on Apple.com's search box, or StackOverflow's Ask Question's title box) If you change the CSS, won't that break the Javascript code? – nonopolarity Apr 03 '11 at 16:46
  • I don't understand. Are you talking about changing the actual named class applied to that element? Of course that would break things - the same as renaming an object in code would break your code. But why would you ever need to do that? If you have a class `fading_input` that you only used for input elements that should have the gray word faded out, you can change the actual styles within that class whenever you want. You don't change `fading_input` to `different_fading_input`, you change the definition of `fading_input` if you want to change the way it looks, and nothing would ever break. – Jamie Treworgy Apr 03 '11 at 16:50
  • ... if for some reason you wanted the flexibility to add/remove named styles to particular elements at will, you could always use an empty marker class that would never change, and is used by the Javascript to identify things, and add style classes. e.g. `class="fading_input_marker fading_input_style_option1"` – Jamie Treworgy Apr 03 '11 at 16:53
  • i mean http://store.apple.com/us so what if a developer came in and think: overlapping `` and `
    `, yuck! (or he tries to add something and the CSS is hard to work with the original design) he thinks: let's change that to a plain simple style, and the Javascript will be breaking, because it tries to look for the other div and fail, and effect is not working as well
     – nonopolarity Apr 03 '11 at 16:53
  • If the developer just edited the actual style (say, set it to `"display:none;"` as opposed to removed it) everything would be fine... CSS is glue. If you didn't use it that way, you'd have to use something else, like IDs, which are less flexible. It seems like you're asking, how can I violate a convention that's used in a given architecture without breaking something? You can't. It's part of the architecture. – Jamie Treworgy Apr 03 '11 at 16:55
  • @動靜能量 of course not. Whatever `visibility`or `display` you give to your element is of no importance to the script. In your JS, you only have to manipulate the `className` attribute of the element and not care at all about how it looks now or after your change. A missing field' label might be indicated with a red border or an orange background or whatever, it's still ``. – romainl Apr 03 '11 at 16:58
  • By the way - take a look at the apple store source. There's a span around that input with css class `field-with-placeholder`. However there's no definition in their style sheets for `field-with-placeholder` but it does appear in the javascript. THis is exactly what Apple has done: they used a marker CSS class, which is only used to identify elements that share that functionality, and then apply styles from JS. They can't change that class name on the span without breaking something (but why would anyone do that?) but they could easily add a class to style it or change the code. – Jamie Treworgy Apr 03 '11 at 17:00
  • Are you suggesting that when you change the _HTML_ markup your javascript breaks? Of course it does. – Raynos Apr 03 '11 at 17:01
  • yeah, if you add or remove a class, that's ok... but what if you design the HTML in a different way... add or remove element but if HTML doesn't change, then Javascript just changing the classes, and CSS just deal with the classes definitions, looks like that's good decoupling... but even so you may need to add class to a different element, so you need to change the Javascript when you change the CSS too – nonopolarity Apr 03 '11 at 17:07
  • @動靜能量 - you haven't solved one problem, you just replaced it with another. If you don't use classes to identify things in JS, then what would you use? IDs? Custom tags? You can't change those, now. How is that in any way preferable to just using classes? Again- it's just a convention. You need to use one. If your convention is that we use some CSS tags as markers, then you can't change them. – Jamie Treworgy Apr 03 '11 at 17:10
  • .. the issue isn't decoupling CSS and Javascript. It's making sure you have a well defined *convention*. Some classes will be used as markers, that identify certain functionality. Prefix them with something, if that helps. You can't change a marker on a piece of HTML without affecting how it will be manipulated in code. – Jamie Treworgy Apr 03 '11 at 17:12