meyerweb.com

Skip to: site navigation/presentation
Skip to: Thoughts From Eric

JavaScript Will Save Us All

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 EdwardsIE7 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?

67 Responses»

    • #1
    • Comment
    • Wed 22 Oct 2008
    • 0954
    Justin wrote in to say...

    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
    • Wed 22 Oct 2008
    • 1111
    Received from Useful Links (22/10/2008) | Apramana

    […] JavaScript Will Save Us All […]

    • #3
    • Comment
    • Wed 22 Oct 2008
    • 1119
    Tony wrote in to say...

    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
    • Wed 22 Oct 2008
    • 1124
    Received from 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
    • Comment
    • Wed 22 Oct 2008
    • 1155
    mike wrote in to say...

    yes please. :)

    • #6
    • Comment
    • Wed 22 Oct 2008
    • 1221
    Kyle Weems wrote in to say...

    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
    • Comment
    • Wed 22 Oct 2008
    • 1234
    Matt Wilcox wrote in to say...

    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
    • Wed 22 Oct 2008
    • 1238
    Received from 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
    • Comment
    • Wed 22 Oct 2008
    • 1242
    Mike D. wrote in to say...

    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
    • Comment
    • Wed 22 Oct 2008
    • 1345
    Scott Gale wrote in to say...

    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
    • Comment
    • Wed 22 Oct 2008
    • 1519
    Ash Searle wrote in to say...

    @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
    • Comment
    • Wed 22 Oct 2008
    • 1634
    Matt Chaput wrote in to say...

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

    • #13
    • Pingback
    • Wed 22 Oct 2008
    • 1730
    Received from 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
    • Comment
    • Wed 22 Oct 2008
    • 1733
    rob cherny wrote in to say...

    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
    • Wed 22 Oct 2008
    • 1757
    Received from » 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
    • Wed 22 Oct 2008
    • 1831
    Received from JavaScript和CSS标准扩展 | 一宅堂

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

    • #17
    • Comment
    • Wed 22 Oct 2008
    • 1950
    Sean Hogan wrote in to say...

    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
    • Comment
    • Thu 23 Oct 2008
    • 0352
    Dao wrote in to say...

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

    • #19
    • Pingback
    • Thu 23 Oct 2008
    • 0626
    Received from John On Web Stuff » Blog Archive » JavaScript Will Save Us All

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

    • #20
    • Comment
    • Thu 23 Oct 2008
    • 0818
    Stephen Hill wrote in to say...

    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
    • Thu 23 Oct 2008
    • 0819
    Received from 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
    • Comment
    • Thu 23 Oct 2008
    • 0907
    rob cherny wrote in to say...

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

    • #23
    • Comment
    • Thu 23 Oct 2008
    • 1241
    Kyle Weems wrote in to say...

    @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
    • Comment
    • Thu 23 Oct 2008
    • 1507
    Ivan wrote in to say...

    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
    • Thu 23 Oct 2008
    • 1543
    Received from 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
    • Comment
    • Fri 24 Oct 2008
    • 0502
    Georg Tavonius wrote in to say...

    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
    • Comment
    • Fri 24 Oct 2008
    • 1152
    Chris Hester wrote in to say...

    One of your best posts ever.

    • #28
    • Comment
    • Sat 25 Oct 2008
    • 0427
    Alan Gresley wrote in to say...

    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
    • Sat 25 Oct 2008
    • 1102
    Received from 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
    • Sun 26 Oct 2008
    • 0254
    Received from Eric’s Thoughts on Sizzle

    […] JavaScript Will Save Us All […]

    • #31
    • Comment
    • Sun 26 Oct 2008
    • 2145
    Erik wrote in to say...

    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
    • Comment
    • Mon 27 Oct 2008
    • 0724
    Jowra wrote in to say...

    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
    • Mon 27 Oct 2008
    • 1001
    Received from 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
    • Comment
    • Mon 27 Oct 2008
    • 1211
    westworld wrote in to say...

    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
    • Comment
    • Mon 27 Oct 2008
    • 1220
    Chris Hester wrote in to say...

    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
    • Mon 27 Oct 2008
    • 1416
    Received from 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
    • Comment
    • Mon 27 Oct 2008
    • 2131
    Douglas wrote in to say...

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

    • #38
    • Pingback
    • Mon 27 Oct 2008
    • 2317
    Received from Weekly Link Round-Up #52 | Trevor Davis

    […] JavaScript Will Save Us All […]

    • #39
    • Pingback
    • Tue 28 Oct 2008
    • 0546
    • #40
    • Comment
    • Thu 30 Oct 2008
    • 1057
    David Rogers wrote in to say...

    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
    • Comment
    • Thu 30 Oct 2008
    • 1554
    Richard Fink wrote in to say...

    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
    • Comment
    • Fri 31 Oct 2008
    • 1052
    Derek Featherstone wrote in to say...

    @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
    • Comment
    • Sat 1 Nov 2008
    • 2103
    jim doran wrote in to say...

    Thank you Eric!

    • #44
    • Pingback
    • Mon 3 Nov 2008
    • 1712
    Received from 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
    • Comment
    • Tue 4 Nov 2008
    • 0129
    Clay McIlrath wrote in to say...

    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
    • Comment
    • Wed 12 Nov 2008
    • 1005
    Stephan Helbig wrote in to say...

    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
    • Comment
    • Wed 19 Nov 2008
    • 0417
    Thomas Maierhofer wrote in to say...

    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
    • Wed 19 Nov 2008
    • 0434
    Received from What I’ve been reading - James Padolsey

    […] JavaScript will save us all […]

    • #49
    • Pingback
    • Wed 3 Dec 2008
    • 0451
    Received from 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
    • Sat 6 Dec 2008
    • 0845
    Received from 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
    • Mon 8 Dec 2008
    • 1204
    Received from 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
    • Tue 9 Dec 2008
    • 1952
    Received from 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
    • Comment
    • Fri 19 Dec 2008
    • 2115
    Luke Cameron wrote in to say...

    border-radius anyone?

    • #54
    • Pingback
    • Fri 16 Jan 2009
    • 0452
    Received from 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
    • Comment
    • Fri 16 Jan 2009
    • 1547
    Daniel Wachsstock wrote in to say...

    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
    • Fri 16 Jan 2009
    • 1718
    Received from 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
    • Sun 1 Mar 2009
    • 0654
    • #58
    • Comment
    • Fri 13 Mar 2009
    • 1632
    Deryk wrote in to say...

    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
    • Sat 6 Jun 2009
    • 2049
    Received from I HATE You Internet Explorer! | Random Ramblings

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

    • #60
    • Comment
    • Tue 9 Jun 2009
    • 1703
    David Joseph wrote in to say...

    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
    • Tue 11 Aug 2009
    • 0029
    Received from 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
    • Thu 21 Jan 2010
    • 1134
    Received from 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
    • Sun 24 Jan 2010
    • 0534
    Received from 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
    • Tue 2 Feb 2010
    • 1123
    Received from 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
    • Sat 8 May 2010
    • 1359
    Received from 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
    • Comment
    • Mon 14 Jun 2010
    • 1653
    Mason Fischer wrote in to say...

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

    • #67
    • Pingback
    • Fri 20 Aug 2010
    • 1400
    Received from 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 […]

Leave a Comment

Line and paragraph breaks automatic, e-mail address required but never displayed, HTML allowed: <a href="" title=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <cite> <code> <del datetime=""> <em> <i> <q cite=""> <strike> <strong>



Remember to encode character entities if you're posting markup examples! Management reserves the right to edit or remove any comment—especially those that are abusive, irrelevant to the topic at hand, or made by anonymous posters—although honestly, most edits are a matter of fixing mangled markup. Thus the note about encoding your entities. If you're satisfied with what you've written, then go ahead...


October 2008
SMTWTFS
September November
 1234
567891011
12131415161718
19202122232425
262728293031  

Sidestep

Feeds

Extras