Slashdot Mirror

Want OO in JavaScript? http://dean.edwards.name/weblog/2006/03/base/

Want error handling in JavaScript? https://developer.mozilla.org/en/Core_JavaScript_1.5_Guide/Exception_Handling_Statements

I don't see how canvas is relevant right now. It will be when it is finished, perhaps. For now, target Flash if you need that functionality.

The general idea is relevant in the same way that having native drawing capabilities in any environment where you're doing development is relevant. The specific tool, it's relevant for anyone using a browser that supports it.

Flash: it's not a bad technology, and it's pretty nice that the level of penetration it has made it reliable -- and even a layer on top of which people could implement Canvas, for vendors who are lagging behind (and whose careful "enterprise development cycle" causes them to break implementations based on VML with new releases). But it's vendor dependent, it's actually limited in some ways if you want to do programmatic drawing without having to create the symbols/clips inside another tool first, and it's not as nicely integrated with the rest of the environment it lives in as Canvas is.

Web trash = Web developers; not really designers, not really software engineers. Trendy, braindead, and useless in any real industry. They're responsible for such brilliant technologies as "ruby on rails" and other poorly designed frameworks that blow away collective millions of dollars of investor cash on energy and hardware in order to save them tiny amounts of time and make their code trendier.

Hmm. I'd thought we were talking about client-side web development. Perhaps some kind of uncommonly broad brush is being applied here.

They're the sort of people who would complain that their job is too difficult because they have to target a conservative feature set based on the real-world deployment of unstandardized technologies.

The gestalt's never been "this is too hard for us to do." In fact, I don't think it's hard to find examples of a kind of near-perverse glee in figuring out how to work around various browser deficiencies. And it's pretty clear as a group, web developers figured out not only how to target the conservative feature set you would have apparently espoused but how to do a lot more beyond that. The complaints have almost always centered around how much less time would be wasted and how much more could get done if browsers that supported certain features were more widely deployed.

And really, it's not particularly unreasonable. I mean, if brain-dead worthless trash of the web development world could hack together a mess of Javascript to make Internet Explorer comply more closely with the CSS 2/2.1 specs... why exactly couldn't the professional real engineers who I'm sure you'd argue work for Microsoft offer the same?

Yeah, I was correct. Get over it.

You're technically correct for IE8, but obviously only barely, and you're apparently not interested in tuning in on why your link arguably fails as a practical measure, and conveniently forgetting that your statement is wrong for a large chunk of the last decade by even the measure you've offered up.

There is a chunk of Javascript that can get you 90% of the way to IE compatibility a lot of the time. Saves days of my life.

Use NoScript to turn the useful message system on permanently while leaving the slower (and often third-party dependent) ad system turned off?

Then watch web developers obfuscate their script URLs so that NoScript has trouble distinguishing useful message systems from the ad systems that pay their salaries.

While it is true that some things require scripting, a lot of things could be better accomplished through clever use of DHTML

Then perhaps one of us misunderstands what "DHTML" means. I always thought it meant scripted manipulation of the CSS and HTML DOM, and Wikipedia appears to agree: "DHTML allows scripting languages to change variables in a web page's definition language".

and CSS

Unless the web developer has to use script to simulate things that are broken or missing in Windows Internet Explorer's implementation of HTML and CSS. Remember the "IE7" script by Dean Edwards that made IE 6's support for CSS more robust?

Yes, and also to shrink variable names, arguments, etc. See Javascript compression guru Dean Edwards's take on the subject.

I see this as more of a value add for people using other outward facing google products -- namely google apps and google pages. Why have a brazillion copies of these things on their servers (and using up their customers' storage limit) when they can offer it up once.

It also ensures that all web-sites using these projects can keep up to date automatically, so any security hole or bug gets fixed immediately for sites that take advantage of this.

As well, I can see this as a benefit for users of noscript and the like. If you've already white listed "code.google.com" (or wherever it's being hosted) on one site's implementation, any other site using it will automatically be cool too.

Besides, you can already do this with their google code repository. go look at Dean Edward's projects. All of them are hosted on google code, and he specifically recomends pointing to the google server from your site. This seems to be just an extension for other open source projects. Sure this could be handled by the individual projects themselves, on their own servers. But why have your site hammered by the infinite visitors of the sites that use your product when Google is willing to absorb the hammering for you.

Write your pages for mostly-standards-compliant browsers, then use http://dean.edwards.name/ie7/ to make them look right in IE. Sure, your pages will take an extra few tenths of a second to render in IE, but it saves you hours of fucking around to make it look right.

IE7 fully supports the alpha channel in PNG, so the problem is solved. Screw the older versions; they're easily fixed with a JavaScript hack provided by /IE7/.

Lame approach to the solution. It invalidates the style sheet. It requires to copy-paste nearly the same code for each image. It requires you to write the dimensions manually for each image. It does not work for embedded images (<img src... /> ).

Be virtuously lazy and reuse the IE7 library instead. (Not related to the topical web browser.)

Dean Edwards' javascript syntax highlighter handles several languages (you can easily add your own) and operates via DHTML behaviors so you don't even need to include the script files in the page. It works in most browsers.

http://dean.edwards.name/my/examples/star-light/

What you need to use it is a blog that will let you post files to the server or create your own custom HTML templates, and then let people post HTML code. Code wrapped in <pre class="javascript"> gets highlighted correctly.

If you can't post files, a bit of hacking around with the source code and you can embed it in a template and invoke it manually with javascript.

Wordpress lets you post your own HTML templates with script - either install it on your own server or go for their free hosted service at wordpress.com.

I was dreading the inevitable process of trying to get a new CSS design working in IE 6; but hopefully now I don't have to :)

I was dreading the inevitable process of trying to get a new CSS design working in IE 6; but hopefully now I don't have to :)

The "IE7" Javascript library by Web guru Dean Edwards has helped me a lot with the IE6 blues.

It allows IE6 to render transparent PNGs (using ActiveX[?] hooks built-in to IE that allow it to render 8-bit transparency, but is mysteriously not enabled for PNGs by default) and programmatically alters the DOM and parsed CSS to enable complex subselectors and a smattering of CSS2/3 selectors as well (including fixed background positioning!). It adds ~20K to pages using it, but it's a one-time cost as IE caches Javascript.

It's not a magic bullet, and sometimes causes issues itself, but definitely worth a look. Cause no one likes hacking their carefully-constructed divs back to tables, just to support a broken POS browser. (I also enjoy the irony that third-party Javscript hackers seem to be able to make more progress with IE's CSS compatibility than the actual IE team.)

The "IE7" Javascript library by Web guru Dean Edwards has helped me a lot with the IE6 blues.

It allows IE6 to render transparent PNGs (using ActiveX[?] hooks built-in to IE that allow it to render 8-bit transparency, but is mysteriously not enabled for PNGs by default) and programmatically alters the DOM and parsed CSS to enable complex subselectors and a smattering of CSS2/3 selectors as well (including fixed background positioning!). It adds ~20K to pages using it, but it's a one-time cost as IE caches Javascript.

It's not a magic bullet, and sometimes causes issues itself, but definitely worth a look. Cause no one likes hacking their carefully-constructed divs back to tables, just to support a broken POS browser. (I also enjoy the irony that third-party Javscript hackers seem to be able to make more progress with IE's CSS compatibility than the actual IE team.)

To address the thread-starter's comment in this /. thread, Opera isn't being ignored by just people in discussions like this. It's ignored by users as well; Opera is remarkably unpopular.

I'll offer some reasons why I ignore Opera:

• Opera is proprietary software. I value my software freedom, so I'm not willing to lose it by using software that doesn't respect my freedom to run, inspect, share, and modify the program any time I want for any reason I want. I refuse to discuss free and proprietary software as though they have an equivalent effect on the user by framing the issue exclusively on technical features or cost.
• Opera doesn't obey the CSS3 I'm interested in (if it implements anything in CSS3 at all). I understand that CSS3 isn't official, but with Gecko I get support for some CSS3 selectors that let me do nice things such as fast tabs with :target. I don't use MSIE, but there is a clever set of JS scripts to add some CSS3 support and fix some of the bugs in MSIE.
• Opera doesn't have the rich set of extensions I can find for Firefox. This is probably a corollary to the first point about software freedom.

'Don't worry, IE7 will solve all of your problems."

Well, actually it does. Except I'm talking about this IE7: http://dean.edwards.name/IE7/

I installed that, and suddenly I was able to write standard css, and not go crazy trying to make IE work.

It's actually quite wonderful. I don't know why Microsoft can't aford to fix it's own bugs, and needs other people to do it for them, but hey, at least it works.

I think I should go back to the days of plain-jane HTML and just deal with it

Because that wasn't even more of a mess??

Nested tables, embedded styles everywhere... sure, it works now, but only because the browser developers had so much time to get it to work, and developers have gotten used to it.

It's a horrible way to do layout. You end up with a twisted combination of layout and content - which means your web programmers have to have a bit of graphic design in them, and your graphic designers have to know a little bit about programming. To change something - for example, to move a menu from a horizontal bar at the top to a vertical menu on the right side - requires a ton of work. For a complex enough design, it may mean starting over, because you're 12 tables deep and are losing track of the row because there's too many rowspan=3's. Not to mention, there's no easy way to make a "print" or accessable version without having a whole separate layout.

Using CSS, you get a nice clean HTML layout. In fact, it's almost to the point where a web designer can be responsible for the CSS, and the programmer for the HTML*. Going back to the previous example, if your menu is in a div, and defined with an unordered list, then to move that navbar it's only a matter of changing the CSS. Don't need to touch the HTML (or corresponding server-side code that generates it) at all.

A nice thing about developing this way is the page is viewable before even putting in the CSS. In fact, it can be viewed easily by ANY browser (albeit without formatting) including text-based browsers and even the first generation web browsers. Making a printable version is just a matter of another stylesheet (and if you use the 'cascade' properly, you can have one that sets up the main layout, and one that modifies that for print, or one main, and two that inherit with specific changes - one for screen, one for print). Screen readers will have no problem with it. Search engines will index it easily.

Now, yes, it does have a learning curve. It takes a lot of reading to understand layout in CSS, as well as CSS in general. Current web developers often think "I know web development, I can do CSS" then get frustrated because things don't work (case in point, the original article). Really, they haven't bothered to learn it. There are a ton of great sites out there to help with this, and a couple google searches will find them. It's not something that happens overnight though, it takes a fair bit of reading and experimenting.

* There's still a few 'hacks' that are sometimes required to make the CSS work (ie, adding a 'wrapper div' around certain things), but these will hopefully be addressed eventually in newer versions of CSS. There's also the issue of IE .. but as long as you develop in a standards-based browser, and don't do anything TOO funky, it's usually not overly difficult to get IE to work (there's always the "IE7" javascript hack). We can only hope that when Microsoft actually releases the real IE7, they get it right.

If IE7 does actually work, I would hope that the web would basically go to a "your browser is too old to view this page, please upgrade..." and provide links to firefox, IE7, and opera or whatever. I normally hate browser detection, but the faster we get rid of IE5/6 the better.

Then I open up IE, shut my eyes, and run screaming from the room(usually right into the closed door.) Simple effects and a basic CSS driven menu system leave IE page renders in ruins. I then have to spend more timing trying to get it to work in IE then I spent writing the entire page.

The lightweight script is a single-line inclusion in your HTML/XML document. No alteration of your original markup is necessary. Neither do you have to alter your CSS.

Another extension that Opera recently added is that it now supports the DOMContentLoaded event. This means that now every popular browser (IE, Mozilla/Firefox/Netscape, Opera, and Safari/Konqueror) can now call scripts once the DOM has been loaded, but before the page has finished loading (i.e., before images are done downloading).

There is a fix for the broken PNG support. There are several scripts out there such as "IE7" and pngfix.js. I like the pngfix.js one as it's very small and only fixes png support.

According to WaSP (the people who wrote the Acid2 test), Safari passed first, followed by iCab and Konqueror. and Safari was the first browser to have a public release that rendered it.

That makes Opera the 4th browser to render Acid2 correctly.

This page has a bit of info on it, http://dean.edwards.name/weblog/2005/04/acid2-sp/

No, that's wrong. Even if it isn't that important who did it first, but that it gets done at all, the facts should be right.

Safari did it first, then iCab, then Konqueror, and now Opera. See http://dean.edwards.name/weblog/2005/04/acid2-sp/ . This order is not the "release" order, but when an alpha/beta/nightly passed the test, and the developer(s) told us.

If we consider released versions, I'm not sure what order we get, but I believe only Safari and Konqueror have released the compliant versions yet.

I hate JavaScript as much as the GP probably does, but for sites that are designed to work that way (e.g. live.com and Google's personalised homepage), I can understand the use of JavaScript/ECMAScript. However, your stupid floaty menu widget can be accomplished perfectly in CSS, and for browsers that don't support that, there are both JavaScript fallbacks and simple browser-based fallbacks that will still allow the user to view the site just fine.

Basically, designing to degrade gracefully is what you need to do.

You can do that with the base64 URL scheme. See here.

It is supported by Firefox already. Is that what they use? Site is ./ed so I couldn't check...

A good way to not-release-the-source is some sort of binary distribution that cannot be trivially decompiled.

No such thing exists anymore. Even complex C/C++ programs can be decomplied quite easily. It's just that people feel more exposed with JavaScript because the code is distributed in source form. Try a packer/obfuscator like this one instead. The code can still be extracted by someone smart enough, but it does put a barrier in their way.

No comment :
http://www.flickr.com/photos/alaskana/93697347/

It is looking extremely bad, look like MS has done nothing !
Guys, you got no excuses, Dean Edwards has done lot of fix on his own with a bunch of JS scripts !!!
See http://dean.edwards.name/IE7/ So, why are you not able to do the same with tens of developpers on board and years in front of you ?

Plz mod this up, as IE7 is only a small upgrade and will not improve user experience (but tab browsing, RSS, XMLHttp scripting and a few cosmetics ....) this is a very limited improvement an should be called IE6.1 IMHO !!!

You can actually force IE 5.5 and IE 6 to parse pages correctly, including CSS. All you have to do is add a few lines to your page that other browsers treat as comments. The script is called IE7, and I've been having good experiences with it. It also fixes the PNG support (yes, alpha transparency).

Yes, I know, it's pretty obvious that anything even remotely useful doesn't work in Internet Explorer. But for something as non-essential as this, JScript is suitable as a workaround. You can easily emulate max-width in Internet Explorer with JScript.

The designer of the flash application would have to supply all the features normally available in the browser - maybe you can get flash components that do this.

Part of my point was that you can't emulate the browser features properly - see my middle-clicking example.

By the way I have written DHTML code and it is *not* trivial the differences in the DOM between IE and Mozilla.

Well that's the DOM, not AJAX itself. While I agree that the differences can be quite annoying at times (although not at the 50% you claim), the majority of the API people actually use on a regular basis is fairly consistent between browsers, and work like IE7 etc etc increase conformity considerably.

Right, so the intelligent thing would be to explain to my clients that it's Microsoft's fault and not mine that the site I just designed for them doesn't display properly for 9 out of 10 of their customers? After all, I followed the standards and it would be stupid not to!

Correct. And then you do as you mention below in your post and bill the client accordingly.

"Sorry Mr. Client, standards evangelism is far more important to me than your customers. Now, when should I be expecting payment?" Yeah, that'll fly.

Or you could talk to them like intelligent people. The appalling standard of Microsoft software is well known in the business world.

I think I'll keep using my current methodology: Design to the standards first, then add whatever hacks are needed to handle the various browser bugs in secondary stylesheets to ensure the widest possible compatability across as many browsers and platforms as I can.

There are numerous hacks, such as the great IE 7 hack, but these only plaster over the problem.

Call me crazy, but keeping the client and their customers satisfied (and, as a result, making the site display properly for as many visitors as I possibly can, rather than just those that use a "standards compliant" browser) and subsequently getting paid for my work is more important to me than beating the standards drum.

I mentioned in a previous post how I spent weeks converting this website with property in nice, france to pure CSS. Take a look in IE and Firefox and you will see there are still a few glitches in IE. It's just not worth my clients time paying to fix them and so they will stay. Works fine in Opera. Fixing cross-browser problems hits the laws of diminishing returns, where you spend a disproportionate time fixing more and more minor IE glitches that are totally unpredictable.

Phillip.

http://dean.edwards.name/IE7/

(not affilliated, just a happy user)

IE7 does this. That "IE7" isn't the next version of Internet Explorer; rather, it is a JavaScript library that will rewrite standards-compliant stylesheets to IE-bugginess-compatible stylesheets. No ActiveX required.

This is actually quite good, because it means that IE7 will probably work on IE7. :-)

It seems that VML never became a W3C recommendation, as it was superseded by SVG. MSIE only supports VML because it's a Microsoft Office format. As far as I know, there are no plans to support SVG natively in MSIE.

Perhaps it is possible to get MSIE to support a simple subset of SVG by first transforming it into VML. Since both formats are based on XML, perhaps it could even be done on the client side using XSLT. Has anyone tried this? It could be packaged as part of IE7 (the Dean Edwards hack, not the next version of MSIE)?

If such a hack were accomplished, it could spark the development of some nifty SVG-based applications. With Opera, Mozilla/Firefox and Safari all supporting SVG natively (now or in the near future), and MSIE supporting it via VML, it would be possible to reach a wide audience without any plugins!

Here :
http://dean.edwards.name/IE7/

Contains numerous CSS & DOM bugfixes. This bunch of scripts transfor a bloatish uncomplient IE in a "normal" browser ;-)

How much people is there at MS coding the bug fixes on IE ? Coz, Dean has made this on his own as a hobby guys !!!!

If they haven't said they will support 2.1 in IE7, what does that tell you? Until they DO agree to fully support standards, my original point stands regardless of any nitpicking over whether CSS2 is in fact partially flawed or not. BTW, I just did a Google search on IE7 and CSS2. Here's an interesting blog comment. And here's Eric Meyer's thoughts back in March.

You can enjoy some of that compatibility and adherence to W3C standards right now with Dean Edwards' IE7 Compliance Patch, which improves a large amount of IE's CSS, particularly :hover and the box model.

Well, yes and no.

It's relatively easy to make complex pages which look the same on all browsers and use exactly the same HTML. CSS is another story... it seems that many web authors simply haven't discovered IE7 yet, so they author their pages for IE instead of the standard.

So in the end, you have to blame the web sites for not being standards compliant in the first place. If they all were, eventually Microsoft would have to fix their issue or die not being able to render any sites at all.

Why/How can Firefox, which runs happily on W2K and others, offer better security, while IE cannot do the same on an OS developed by MS itself?

According to Microsoft, IE is integrated into the operating system itself -- it is no longer a standalone application. Ostensibly they did this to allow greater desktop-to-Internet integration, but given the inherent insecurity of ActiveX, the tendency for the forces of evil to use it maliciously, and the inability of users to lock it down, it's not exactly a hot selling point these days.

Firefox, on the other hand, stands to benefit immensely from all this. It offers a free, lightweight, standalone browser whose programming environment makes it easy for developers to extend its functionality without coopting its security (so far). It does this without any hooks into the operating system, and offers a variety of ways to combat malware, popups and generally obnoxious behavior (Flash movies, rampant advertising, etc).

Microsoft might claim that they won't be releasing any further security patches or functional upgrades to Windows 2000 or IE6. But as of September 2004, ~49% of Windows users still use Windows 2000 or lower (98, 95, NT, etc). Trying to scare users into upgrading their OS, so they can take advantage of a marginally improved, questionably more secure Windows, doesn't seem to be working anymore. And I'm by no means a Linux zealot -- I'm an ASP/SQL programmer, have been using Windows since v3.1, and am a huge fan of Microsoft's development tools / languages.

Besides landing my most recent job, discovering Firefox was the best tech-related thing that's come along in recent memory. It's inspired me to start learning more about client-side development again, after seeing what's possible with AJAX (Asynchronous Javascript And XML), standards-compliant CSS and XHTML. Once Dean Edwards' CSS-based IE7 stylesheet matures a bit more, developers will be able to instantly upgrade the set of standards-compliant available to IE 5/6 users. At that point, who will need IE 7? The days of developing wonderful new HTML and CSS tags that are only supported by one browser are in decline...... Firefox's market share has risen to just under 10% in the past year, while Microsoft's market share has dropped to under 90% for the first time since Netscape was still relevant. IE7 won't become ubiquitous for a long, long time, especially if Microsoft doesn't plan on making it available to users of its older operating systems. Why would developers of any web applications besides IE-only Intranets/Extranets create products that utilized features only available to a very small set of the installed user base?

So whatever, Microsoft. Dig your own grave, if you insist upon doing so. I'll continue to use your server-side tools, provided something better and easier-to-use doesn't come along, but at this point, you've lost me as a client-side developer of IE. Not that you should care, of course..... but if you can lose a devoted developer like me, I have to wonder how many others you've push away. It appears it's not all about "Developers, Developers, Developers!", as Steve Ballmer & Co. would have us believe.

http://dean.edwards.name/IE7/

It is already bringging numerous compliances fixes on the DOM and CSS !

Vive IE7, Vive Dean ;-)

By the way, compliant browser such as Firefox does not need any fixes to implement the standards correctly, and do not contain any currently security breach.... unlike the expected IE7 ?

See http://dean.edwards.name/IE7/intro/ for a good start on a Cross Browser compatibility enhancing JS script.

This is not production quality yet, but I came across this project today and it looks very intriguing. I like the potential to fix IE back to IE5 despite Micro$oft's lack of initiative in this area for the next release.

http://dean.edwards.name/ie7/

Right now I'm just rooting for selectors. If they get those going I'll be REALLY happy. +, >, [attrib=], etc, that's be great.:hover working on all elements would be a nice addition too.

Look up Dean Edwards's IE7 Behavior. It fixes a bunch of selectors and more.

Right now I'm just rooting for selectors. If they get those going I'll be REALLY happy. +, >, [attrib=], etc, that's be great.:hover working on all elements would be a nice addition too.

Look up Dean Edwards's IE7 Behavior. It fixes a bunch of selectors and more.

Really, just looking at the Microsoft Fanboys referenced in that article.

"Internet Explorer (7?) is all I need."

They're right, of course.... and here it is:

http://dean.edwards.name/IE7/

"sure it is, depending on your definition of 'withstand'. if you write your code to gracefully handle cases where the elements it is looking for aren't found and don't rely too heavily on the ordering of elements within the page, then it should continue to work in all but the most extreme modifications."
But my point is that Greasemonkey can make any modifications it wishes. You can't assume anything any more, which is an almost useless position to be in. For example, Dean Edwards found his syntax highlighter (which has to "rely too heavily on the ordering of elements within the page") was broken by a Greasemonkey plugin:
http://dean.edwards.name/weblog/2005/03/ungreased/

"which will notify the user that it is greasemonkey (or something similar) and not your web page that is causing the problem"
Well, that's all well and good, but the site is still broken, which was my entire point. Your reply was that I should blame the guy who wrote the Javascript that couldn't account for every single possibility. Fine, let's go and write Javascript that makes bugger all assumptions about the page it's operating on. Great, we've increased download size and development time, since we now have to test every possible eventuality.

Personally, I'm in the "the user can do what they want with the data given to them" camp, but let's not fool ourselves that these things aren't without cost.

By making it easy to write client-side scripts that modify webpages as you surf, it shifts the balance of power from content creators to content consumers.

Google has tried something similar before with their toolbar and ISBNs.

That said, I am going to use this guide to disable Greasemonkey. I write websites so I can present ideas to people. I don't want them to see my site the way they want to see it. I want them to see it the way it was meant to be seen. That way I can provide content based on expectations of standards compliance.

If you want to display my content with your own formatting, use my RSS feed.

IE will (mysteriously) ignore the underscore prefix and parse the second style, while compliant browsers only recognize the min-height style.

If designers didn't rely on obscure parsing bugs like the one in your post, that wouldn't be a problem. There's nothing elegant or clever about exploiting parsing bugs to fix another bug. In an ideal world the browser developers would fix both the parsing bug and whatever other bug the parsing bug is designed to work around. Since we're never gauranteed of this, why take the risk? If you're a professional developer with past projects in the hundreds when IE7 hits the streets, can you then afford to turn back the clock and revisit most of them because you relied on parsing bugs, rather than more concrete methods. (Ahem, conditional comment style sheets) You'd be completely screwed. If you don't fix your client websites, your reputation will go the way of the dodo. If you do you'll have weeks upon weeks of unpaid work.

IE may have miserable CSS support, but at least it provides some very clear, built-in work-arounds for its problems. (JScript, behaviors, conditional comments, all that propreitary garbage that we can use to fabricate something resembling standards support).