JavaScript Will Save Us All

Published 16 years, 1 week past

A while back, I woke up one morning thinking, John Resig’s got some great CSS3 support in jQuery but it’s all forced into JS statements.  I should ask him if he could set things up like Dean Edwards‘ IE7 script so that the JS scans the author’s CSS, finds the advanced selectors, does any necessary backend juggling, and makes CSS3 selector support Transparently Just Work.  And then he could put that back into jQuery.

And then, after breakfast, I fired up my feed reader and saw Simon Willison‘s link to John Resig’s nascent Sizzle project.

I swear to Ged this is how it happened.

Personally, I can’t wait for Sizzle to be finished, because I’m absolutely going to use it and recommend its use far and wide.  As far as I’m concerned, though, it’s a first step into a larger world.

Think about it: most of the browser development work these days seems to be going into JavaScript performance.  Those engines are being overhauled and souped up and tuned and re-tuned to the point that performance is improving by orders of magnitude.  Scanning the DOM tree and doing things to it, which used to be slow and difficult, is becoming lightning-fast and easy.

So why not write JS to implement multiple background-image support in all browsers?  All that’s needed is to scan the CSS, find instances of multiple-image backgrounds, and then dynamically add divs, one per extra background image, to get the intended effect.

Just like that, you’ve used the browser’s JS to extend its CSS support.  This approach advances standards support in browsers from the ground up, instead of waiting for the browser teams to do it for us.

I suspect that not quite everything in CSS3 will be amenable to this approach, but you might be surprised.  Seems to me that you could do background sizing with some div-and-positioning tricks, and text-shadow could be supportable using a sIFR-like technique, though line breaks would be a bear to handle.  RGBa and HSLa colors could be simulated with creative element reworking and opacity, and HSL itself could be (mostly?) supported in IE with HSL-to-RGB calculations.  And so on.

There are two primary benefits here.  The first is obvious: we can stop waiting around for browser makers to give us what we want, thanks to their efforts on JS engines, and start using the advanced CSS we’ve been hearing about for years.  The second is that the process of finding out which parts of the spec work in the real world, and which fall down, will be greatly accelerated.  If it turns out nobody uses (say) background-clip, even given its availability via a CSS/JS library, then that’s worth knowing.

What I wonder is whether the W3C could be convinced that two JavaScript libraries supporting a given CSS module would constitute “interoperable implementations”, and thus allow the specification to move forward on the process track.  Or heck, what about considering a single library getting consistent support in two or more browsers as interoperable?  There’s a chance here to jump-start the entire process, front to back.

It is true that browsers without JavaScript will not get the advanced CSS effects, but older browsers don’t get our current CSS, and we use it anyway.  (Still older browsers don’t understand any CSS at all.)  It’s the same problem we’ve always faced, and everyone will face it differently.

We don’t have to restrict this to CSS, either.  As I showed with my href-anywhere demo, it’s possible to extend markup using JS.  (No, not without breaking validation: you’d need a custom DTD for that.  Hmmm.)  So it would be possible to use JS to, say, add audio and video support to currently-available browsers, and even older browsers.  All you’d have to do is convert the HTML5 element into HTML4 elements, dynamically writing out the needed attributes and so forth.  It might not be a perfect 1:1 translation, but it would likely be serviceable—and would tear down some of the highest barriers to adoption.

There’s more to consider, as well: the ability to create our very own “standards”.  Maybe you’ve always wanted a text-shake property, which jiggles the letters up and down randomly to look like the element got shaken up a bit.  Call it -myCSS-text-shake or something else with a proper “vendor” prefix—we’re all vendors now, baby!—and go to town.  Who knows?  If a property or markup element or attribute suddenly takes off like wildfire, it might well make it into a specification.  After all, the HTML 5 Working Group is now explicitly set up to prefer things which are implemented over things that are not.  Perhaps the CSS Working Group would move in a similar direction, given a world where we were all experimenting with our own ideas and seeing the best ideas gain widespread adoption.

In the end, as I said in Chicago last week, the triumph of standards (specifically, the DOM standard) will permit us to push standards support forward now, and save some standards that are currently dying on the vine.  All we have to do now is start pushing.  Sizzle is a start.  Who will take the next step, and the step after that?

Comments (67)

  1. Mozilla, at least, does not make unrecognized CSS rules or properties accessible from JavaScript. IE does, which is why Dean Edward’s IE7 works. I’m not sure what other browsers do. One would have to write code to retrieve the raw stylesheet and parse it manually to see “new” selectors and properties.

  2. Pingback ::

    Useful Links (22/10/2008) | Apramana

    […] JavaScript Will Save Us All […]

  3. On a few projects I have sent an IE6 jQuery file to add a .hover or .submit class to replace things that don’t work on IE such as :hover or input[type=submit]. Something like this would be really handy as it would save my time and let me get on with important parts.

  4. Pingback ::

    Sizzle - Code Candies

    […] kommt etwas ganz heisses auf uns zu. John Resig schreibt an einer JS-Bib, die Eric Meyer schonmal zum Jubeln anregt: Sizzle. Was es macht? Es analysiert das CSS nach CSS3-Regeln, und baut dann jQuery, dass die […]

  5. yes please. :)

  6. At last! I’d been kicking around the idea of mimicking support of certain CSS3 abilities with JavaScript, but now I can be lazy and enjoy the fruits of a smarter, harder-working person’s labor. Sweet!

    @Justin – You may not be able to access CSS styles in Mozilla with JS via the normal stylesheet-related functions, but you can access the sheets via a technique like Ajax and then parsing the text inside. It’s not exactly as quick, mind you, but I did something when creating a script that would convert CSS3 pseudoclasses into classes for browsers that didn’t support the CSS3 selectors.

  7. Wow, Sizzle is EXACTLY the answer to a post I wrote a while back, about why CSS _must_ borrow more from programming languages to succeed in future. And here it is, a solution which incorporates a lot of the stuff I was talking about and which gives a middle finger to the W3C’s rational of “but CSS shouldn’t allow complex logic, and designers don’t want it anyway” (Bert Bos…)

    I hope you don’t mind me linking to my thoughts on CSS’s future, I think they tie in pretty well with what’s being said here.
    http://mattwilcox.net/archive/entry/id/991/

  8. Pingback ::

    CSSquirrel : JS Has Always Been Hot, But Now It’s Sizzling

    […] Meyer wrote a little post about new project in development by John Resig called Sizzle that should be making every web […]

  9. Marching to our own standards, as you know, is something I’ve been pounding the table for for more than four years now. Everyone is capable of creating a benevolent new standard. What determines whether it is a “real” standard is not determined by who creates it, but rather who endorses and uses it.

    Widespread use = standard.

    One of the nicest examples I’ve seen of something along the lines of what you mention above is The Wolf’s <a href=”Absolute Clearance. The ability to clear absolutely positioned columns as if they were floats, using javascript… brilliant and ever so useful.

  10. Why is it that you contend that JavaScript is lightening fast at traversing these elements?

    Even with the new versions of jQuery, on IE6 and IE7, doing DOM traversal and manipulation still seems to slow down the page loading quite a bit.

    Lately, I have been able to optimize my page load times simply by replacing the DOM manipulation and traversal done in my JavaScript initialization functions with upfront rendering by CSS and my server-side templating language.

    It makes me tentative to go down the road of using JavaScript to replace CSS’ inadequacies.

  11. @Kyle Using AJAX to retrieve raw CSS is going to conflict with cross-site scripting restrictions. i.e. can you access CSS from other domains? Are you following YSlow’s recommendations to put all static content (CSS) on a CDN (another domain?)

    Also, how do you spot the difference between a rule the browser doesn’t understand, and one it does – without coding knowledge in for every browser? Does mutiple background-image support suddenly mean that element.style.backgroundImage is an array instead of a string? In all browsers?

  12. Of course, adding extra DIVs to implement CSS tricks will probably break your other CSS selectors, and your DOM code, eventually.

  13. Pingback ::

    links for 2008-10-22 — Oivallisia juttuja

    […] JavaScript Will Save Us All Miksi odottaa vuosia CSS3-tukea selaimilta, kun osan uusista CSS-määrittelyistä voisi toteuttaa lennossa JavaScriptillä? Samaa voisi soveltaa myös HTML5:n muuntamiseksi HTML4:ksi. Villi idea, jolle löytyy varmasti myös vastalauseita. (tags: javascript jquery css3 webdev html) […]

  14. Hmmmm … unless I misunderstood …

    So at the Ajax Experience John Resig spoke a little bit about Sizzle but I don’t recall him saying anything about parsing CSS rules from files, etc. He seemed to be describing it as a standalone selector engine ala CSSQuery, only it could be plugged into jQuery and Prototype etc. etc. etc. But the specifying selector work would still have to be JS driven.

    I’d be delighted, don’t get me wrong.

    We will see. Either way, I still enjoy being able to specify advanced selectors in jQuery and have IE6 etc. apply a class that I know one day can GO AWAY.

    Maybe John will post here and discuss ;-)

  15. Pingback ::

    » CSS3 durch JavaScript?automatisch « Trash-Log Blog Archive

    […] Meyer will nicht darauf warten, dass alle Browser CSS3 unterstützen, er sieht JavaScript als Lösung. JavaScript soll automatisch CSS-Angaben auslesen und entsprechend umsetzen. Mehrere […]

  16. Pingback ::

    JavaScript和CSS标准扩展 | 一宅堂

    […] Meyer的blog文章JavaScript Will Save Us All（感谢Dexter […]

  17. There would be lots of restrictions on this solution:
    – Until we get CS-XHR the JS library can only read same-domain CSS files.
    – If the CSS-upgrade-in-JS adds elements to the DOM then other DOM manipulation code needs to work around it.

    What we really need is a solution like XBL2.

  18. There’s some confusion about what Sizzle does. rob cherny is right.

  19. Pingback ::

    John On Web Stuff » Blog Archive » JavaScript Will Save Us All

    […] Eric’s Archived Thoughts: JavaScript Will Save Us All. […]

  20. Hi Eric,

    I don’t agree with what your suggesting here because your essentially suggesting that people should go out and write their own CSS rendering engines.

    This is theory sounds fine; however, Web Developers/Designers currently have to battle with the differences in Real browser rendering engines and now we’ll have to take into consideration JavaScript rendering engines… if we choose to use them.

    Personally, I’m going to stick with Progressive Enhancement.

    Stephen

  21. Pingback ::

    Internet Explorer 8 event - Wolf’s Little Store

    […] to this, Eric Meyer wrote an article about John Resig’s Sizzle project, that might be able to help bridging the gap, so we can finally use all the exciting properties […]

  22. @Dao maybe, but i think the spirit of what Eric and other others are saying is pretty close to the mark.

  23. @Ash – Granted, that adds an extra wrinkle when the stylesheets are on another domain. But cross-site Ajax scripting solutions exist, so that’s something that can be worked around if need be. Since Resig is way more talented than I am at this, I’m suspecting he’s going to use a better solution to the “accessing rules that Mozilla ignores” problem that Justin mentioned.

  24. Yeah I don’t think sizzle works that way, but it might be nice. A problem with js-based resolution of selectors is also that the dom might be updated via ajax, and then after the selectors would need to be re-applied. To make that transparent to the developer seems reaaaaly tricky.

  25. Pingback ::

    Ist denn der erste April? auf trilodge computin blog

    […] Autorin aufgefasst, lese ich das jetzt in den Blogs anerkannter deutscher Webentwickler. Und selbst Eric Meyer schlägt vor CSS-Inkompatibilitäten mit JavaScript zu lösen. Bitte was?! Jungs, das […]

  26. Sizzle is definitly a standalone DOM-Selection engine. If you would want one of those who seems to be working right now, I consider Peppy a nice and really fast one. But both are not designed for reading css.

    But still, I consider this idea of yours, eric, as a really good one. One that is worth to be followed. If someone finds a way to make this happen and working fast, it really could push forward the way we designer could use the browsers and design websites for it.

    Cheers

  27. One of your best posts ever.

  28. And web standards just fly right out the window. I can see Bert Bos shaking his head over this hybrid JS / CSS language that you and others are proposing. Will you stop pandering to the interest of MS and their antiquated bundled software called IE. Break the web now.

  29. Pingback ::

    L’avenir des frameworks JS ? | WebDev-FR

    […] un peu ce que s’est dit Eric Meyer dans un billet publié mercredi dernier où il donne de bonnes idées pour les moteurs à […]

  30. Pingback ::

    Eric’s Thoughts on Sizzle

    […] JavaScript Will Save Us All […]

  31. With all the work being done to add variables/constants and expressions to CSS, and the widespread use of JS libraries to enhance websites, it feels more and more like the two should merge.

    Make CSS part of javascript so that I can interact with it without loading a large JS library.

    Further, imagine if HTML didn’t have a fixed set of tags, then you could have all the semantics you wanted – and you wouldn’t need all those IDs and classes littering your markup just to style or add functionality to your site!

  32. Totally wrong. There are so many users out there with javascript turned off, browsers without javascript support (mobiles and others).

    The important thing should still be (X)HTML and CSS progressivly enhanced through js. What you and others are propagating, is a new web build only on javascript.

    This Web 2.0/AJAX stuff has already lead into many, many websites that are unusable without js. Not need for more of this.

  33. Pingback ::

    Dev Blog AF83 » Blog Archive » Veille technologique : Android, PHP, Javascript, debug, etc.

    […]  http://meyerweb.com/eric/thoughts/2008/10/22/javascript-will-save-us-all/ : “le javascript va tous nous sauver” par Eric Meyer, une pointure en CSS. […]

  34. Maybe something Google(http://code.google.com/apis/ajaxlibs/) could host. One file for every browser. After a while people would have it cached.

  35. Further, imagine if HTML didn’t have a fixed set of tags, then you could have all the semantics you wanted…

    Welcome to XML Erik!

  36. Pingback ::

    Webdesignerisland » Blog Archive » Hilfe zur Selbsthilfe

    […] wieder sorgt der IE6 für Diskussionen, zuletzt wieder erneut angefacht durch einen Artikel von Eric Meyer. Der IE6 ist nach wie vor weit verbreitet und seine Probleme im Bezug auf Webstandards und […]

  37. Would it be too lame if I said this was the most exciting thing I read all day?

  38. Pingback ::

    Weekly Link Round-Up #52 | Trevor Davis

    […] JavaScript Will Save Us All […]

  39. Pingback ::

    Max Design - standards based web design, development and training » Some links for light reading (28/10/08)

    […] JavaScript Will Save Us All […]

  40. Call me a purist, but it seems that this approach, while novel, is more of an academic exercise and a bold hack, not a solution (note: I realize that this opinion will probably get me flamed :/). Using javscript to add additional markup in order to “simulate” multiple bg images is just _asking_ for headaches, IMO. I know that’s an extreme example, but let’s not get to thinking that javascript will save the browsers and alleviate all our problems.

    What Eric suggested initially is a great idea: use your CSS3-compliant javascript library of choice to apply CSS3-compliant style rules to elements that the browser’s rendering engine has politely ignored. We already do this with all those wacky (and insanely helpful) CSS2 selectors, so why not keep building?

    That’s my 2 cents.

  41. Eric,
    Javascript to the rescue on another front, as well:
    ZoomPerfect is the name of the product and it quite elegantly solves a problem that has been, for years, presumed to be unsolvable.
    It uses javascript to turn Internet Explorer’s Text Size menu into a true Text Zoom and/or Style-Switcher; enabling IE to size and resize text set in pixels; detect and modify Zoom levels; and a lot more.
    Works transparently, quite amazing.
    It’s in “preview” at the moment awaiting a more solid Beta of IE8.
    All invited to stop by, check it out, and sign up for updates until the final release.

  42. @jowra, you say that:

    The important thing should still be (X)HTML and CSS progressivly enhanced through js. What you and others are propagating, is a new web build only on javascript.

    I don’t read this suggestion as a web that is built only on JavaScript at all. It is still progressive enhancement and not built solely on JavaScript. This is a means to get extensions as a temporary solution for shortcomings in CSS3 implementations in browsers. Eric says so himself when he talks about using the JS to extend CSS and markup. Extend means it would already work on its own, but it would work better when JS is enabled.

    That is progressive enhancement — maybe not as first envisioned, but it still builds on that solid platform.

    @Eric: I’m very much interested in this idea; we’re using it in a number of ways already to extend and enhance the accessibility and usability of the web — we’re fixing behaviours, bugs and other problems with the way things work by using JavaScript. It seems perfectly logical to me to explore what you’re suggesting, provided that there is a solid foundation of HTML, CSS and JS upon which we would build.

  43. Thank you Eric!

  44. Pingback ::

    ProjectX Blog » Blog Archive » Xlinks digest - 4 / 11 / 2008

    […] is a collection of links as discovered by the ProjectX Team “Mr CSS” Eric Meyer – Javascript will save us all Added on 11/04/2008 at 12:22AM Why start-up pitches fail Added on 11/04/2008 at […]

  45. I had a very similar idea to this, but it went a little further.. along with supporting CSS3 by dissecting the stylesheets, wouldn’t it be cool to have the framework read and render XML and XML styles and if the browser was one that didn’t natively support XML styles, it would then replace the xml with a div with a class that was equivelent? Check it out..

    <xml>
    <error>Your page had an error</error>
    </xml>

    <style>
    error { color: red; }
    </style>

    The framework would then replace this in non-compliant browsers with:

    <html>
    <div class="error">Your page had an error</div>
    </html>

  46. This would sure make life a lot easier. The only browser that currently supports css selectors like #my_id input[type=radio]:checked + label correctly is FireFox 2+ as far as I know. I use it in one of my recent projects, iStylr – CSS Template Generator anyhow and therefore limit access to FireFox users only (not the best way – I know)

  47. Your statements are great! The same problem is the support of CANVAS element and SVG support. On my own project i must use excanvas to emulate the canvas element on IE.

    jQuery plugin to put a canvas in the background of a div and paint round corners, gradients or whatever you want on it

    And Microsoft statet: “no support of canvas in IE8”. Without JavaScript I’m lost…

  48. Pingback ::

    What I’ve been reading - James Padolsey

    […] JavaScript will save us all […]

  49. Pingback ::

    Décembre 2008 : Mashup

    […] Voila maintenant quelques temps que je me fait à l’idée que le CSS n’est bien que quand il est utilisé a fond, donc quand il est utilisé via JS (Merci IE …). Eric meyer nous en parle ici : JavaScript Will Save Us All […]

  50. Pingback ::

    Sizzle | Ajaxonomy

    […] some have many have expressed great excitement at the idea of having a common selector engine, not all are enthusiastic about the idea. Valerio […]

  51. Pingback ::

    Richard Strucke - Deconstruct - Design - Develop » JavaScript, Red Headed No More

    […] our browsers, and possibly more than anything — our JavaScript libraries. A recent post over at MeyerWeb points to the fact that Javascript has not only matured, but is pushing the future of browsing. […]

  52. Pingback ::

    Six Questions: Eric Meyer on CSS3 - Six Revisions

    […] by JS will be in people using JS to "silently" add advanced CSS to browsers.  I wrote about this recently, and I’m pretty sure it’s just a matter of time before it actually happens.  […]

  53. border-radius anyone?

  54. Pingback ::

    Ferdinando De Meo | visual designer, front-end developer | blog personale e portfolio » VIETATO ASPETTARE

    […] Tralasciando le applicazioni per il mobile che si apprestano – era ora! – a diventare un fattore irrinunciabile per il successo di qualunque piattaforma, nelle comunità di sviluppatori si affaccia l’esigenza di mettere in pratica e sperimentare i nuovi linguaggi, definire standard per i metadati e la semantica che superino gli esperimenti e le esperienze di questi anni. Basta dare un’occhiata all’ultimo e illuminante articolo di John Alssop su A List Apart, o considerare che la versione 1.3 di Jquery appena rilasciata praticamente apre le porte ai selettori CSS3; tutto sembra andare nella direzione auspicata da Eric Meyer qualche mese fa. […]

  55. The idea of using js to fix browser CSS has been implemented in Andy Kent’s JSS and I have a CSS parser/jQuery-plugin adapter (to do things like div { -jquery-shakeUp: fast 5px } in the stylesheets. The documentation still needs work, but the code works nicely in all the major browsers. Demo here.

  56. Pingback ::

    Hacking at 0300 : jQuery CSS parser

    […] that the browser cannot handle, and uses jQuery to implement them. Eric Meyer recently had a similar idea. $.cssparser.isValidSelector takes a string and returns true if the browser recognizes it as a CSS […]

  57. Pingback ::

    En İyi JavaScript Kaynakları « Popüler İnternet Kültürü

    […] http://meyerweb.com/eric/thoughts/2008/10/22/javascript-will-save-us-all/ […]

  58. Brilliant Eric. As more and more modern browsers support CSS3 we use javascript to fix the old non-compliant ones. If it’s a bit slower on ie6 so be it – it’s time to move on. This is the ultimate in progressive enhancement. I also support the idea of creating our own sellectors, we are the ones building the web, so we should be the ones helping to design the architecture as well – from the ground up.

  59. Pingback ::

    I HATE You Internet Explorer! | Random Ramblings

    […] The legendary Eric Meyer on how javascript can help us. […]

  60. The problem is not with older browsers but with those choose or have inflicted upon them no JS or worse (potentially) firewalls with adaptive JS support…

  61. Pingback ::

    CSS3 and IE | Joel Herron

    […] I say we get over it CSS 3 just isn’t happening any time soon, the css working group has failed us, and for the near future maybe Eric Meyer might have more than he thought with his post on javascript as our saviour. […]

  62. Pingback ::

    Ambient User Experience « my mcLife

    […] entry was in no small part inspired by Eric Meyer’s talk Javascript will save us all at An Event Apart San Francisco. In his presentation, Eric noted that any code-wielding […]

  63. Pingback ::

    Best of 2009 – JavaScript | JavaScript | prowordpress.org

    […] JavaScript Will Save Us All Eric Meyer’s opinion on why we should look to JavaScript to extended standard support badly lacking in many browsers, instead of waiting for the browser vendors to implement them. […]

  64. Pingback ::

    The Withering Away of Flash.

    […] practicality to become a deeply philosophical choice. It is by default accessible, semantic, and extensible. Visitors to the site can print the content, copy it, re-size it, steal it, and manipulate it with […]

  65. Pingback ::

    Does HTML5 need JavaScript2? | Visualrinse | Design and Development by Chad Udell

    […] foray in mobile, one of those things for me right now is JavaScript. Often maligned, sometimes heralded, it’s obvious people have lots of opinions on what is one of the most widely deployed […]

  66. The first step: http://code.google.com/p/css3shiv/

  67. Pingback ::

    Web Design, Web Development » Blog Archive » Universal Internet Explorer 6 CSS

    […] Transcending CSS, recommending Dean Edwards‘ ie7-js scripts. Eric Meyer has also written that JavaScript Will Save Us All to “use the browser’s JS to extend its CSS support”. I still think that this is an option […]

Add Your Thoughts

Meyerweb dot com reserves the right to edit or remove any comment, especially when abusive or irrelevant to the topic at hand.

HTML allowed: <a href="" title=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <cite> <code> <em> <i> <q cite=""> <s> <strong> <pre class=""> <kbd>

if you’re satisfied with it.

Comment Preview