Slashdot Mirror
Mozilla Extending Javascript?
Nomad128 writes "Mozilla's Deer Park 1 Alpha RC appears to have extended the Javascript spec for the first time in quite some time. New features include Array object methods "every" (logical AND), "some" (logical OR), "map" (function mapping), and "forEach" (iteration). They also appear to have added native XML support. Will this speed up the development of AJAX applications and give Moz a leg-up over IE7?"
I don't think the Javascript extensions will be used very much. Personally, I'm coding Javascript that will work in most browsers, which means I have to specifically exclude this new Javascript unless IE et al also implement it (and even then, older browsers still won't like it). Not to be anti-Mozilla, but this does sound a bit like embrace and extend to me. (Yes, I know it's open source and others can read the specs.)
On the other hand, it looks like the things that they did add were mostly based on standards and the DOM spec, so we'll see where this goes.
It's better to vote for what you want and not get it than to vote for what you don't want and get it.
- E. Debs
Ok I understand there are several benefits to this for extension writers. However, I seriously doubt that it will be used in many other places. After all who wants to write web pages that won't work properly in IE and Safari?
Philosophy.
This isn't a case of 'embrace and extend', microsoft-style -- this is a case of extra functionality needed to write extensions. Any web developer using these for public apps is clearly a butt-head.
Do daemons dream of electric sleep()?
... and not something that the Mozilla guys could futz around with on a whim.
Mind you, we are talking about the people who brought you the BLINK tag.
Coming soon - pyrogyra
My dyslexic eyes first read "Mozilla's Deer Park" as "Mozilla's Dark Peer". I was pretty disappointed when I corrected myself. Having a P2P darknet with a XUL frontend would be pretty badass, after all.
Oh well, time to RTFA.
pi = 3.141592653589793helpimtrappedinauniversefactory7
They're not extending javascript from what I can see. It looks like they're implementing some features that weren't implemented before.
Great.
So, people used to get pissed off about Microsoft playing around with scripting features in IE that weren't available on other platforms, but now it's going to be an *advantage* for Mozilla?
Hello-o-oo-oooo-o-ooooo...
- Rory [Microsoft Employee] | Free dirt: neopoleon.com
I view these developments as steps on the road of Mozilla 2.0 It makes sense that a new major version of the open source browser includes innovations just like what Netscape did for their Navigator.
I think we're going to see some of the same things added to IE7's Javascript engine, but implemented differently.
Which means more special-case code for web developers.
tasks(723) drafts(105) languages(484) examples(29106)
Maybe this time they'll actually not think that two digit years are automaticaly in the 20th Century.
Or, heaven forbid, they'll actually use the actual standards based (and *GASP* Microsoft sponsored) ECMAScript as a base which had already fixed their embarassingly humerous (for a 1995 language) Y2K bug...
I agree, lets bundle it with Linux.
Hmm..
It is no longer uncommon to be uncommon.
What is the status with other web browsers Safari, Konqueror, Opera thay have little market share and say. Are thay ready?
Great more exstentions, more media I want to block, ugh... Why can't anyone write something to block all of this stuff out, I don't want to see graphics, or animations, or hear sounds, I love Opera, and it is my browser of choice but I still have to deal with unwanted flash animations. I am stuck on 26.4 bps dialup, due to bad phone lines, and lack of avaliability for cable/dsl/direct wireless. I do not want or need to see more bloat in webpages.
Ok, I am whining again, but you would whine too if you had to surf porn at 2.5 k/s.
Like arts? Like cheesy little Indie mags? Check out www.artwerkmag.com, and don't laugh at the bad coding please.
Deviance from standards (at least in a web environement) is bad because the code that works in one browser won't work in another browser.
But that's not necessarly a bad think in my opinion. If one browser starts extending and empowering web developper in many and novel ways, this browser may well raise the bar for all browsers and shit expectation (if developper find, in mass, that the features are worthwhile, cool, useful, etc...).
However, deviance from standards are bad if they are unsignificant, unrevolutionary, unimportant, just a little improvement (not to confound with many little improvments that combined can make a big difference).
So if you're going to deviate from standard, do it big time!
The other killer feature is, of course, SVG support by default -- unlike the crappy Adobe plugin, fast and reliable SVG support. A lot of stuff that is currently done in Flash can be done in SVG without any dependency on non-free software (or unstable, experimental open source players). Personally, I'm most excited about its possible uses in Wikipedia. Unlike a bitmap file, an SVG can be collaboratively edited: translate text, fix mistakes, and so on. Beyond illustrations, SVG is also useful for zoomable timelines, of which Wikipedia has quite a few, and which are already exported as SVG.
I think that Firefox support for SVG could be a major reason to switch from other browsers if we come up with cool SVG-based applications (not that we really need more reasons to switch!). One thing that would be neat is the ability to generally pan and zoom an SVG file even if there are no JavaScript controls for that, I haven't seen that functionality. Perhaps a bookmarklet or GreaseMonkey script could do the trick.
I can't wait for the final version, but I'd be happy to wait 3 months longer if that's how long it takes to get it ready for primetime. One thing is for sure: Firefox 1.1 will kick butt.
Many of the new Array methods are similar to methods I've written myself and used for years. Admittedly the methods themselves aren't part of the ECMA spec, but object extension via prototyping is a core feature of the language. It shouldn't be difficult to implement them on your own for other browsers.
They'll just run a bit faster in Mozilla/FireFox, is all, since they'll be run as part of the interpreter rather than as interpreted code.
Most of the other stuff is based on W3C standards.
Short version: I'll continue to do cool stuff quickly in Moz and spend time writing workarounds for MSIE, just like I've been doing for the last 4-5 years. Nothing particularly new about that.
Il n'y a pas de Planet B.
Because even "modern" browsers don't all support the same specs, at most only a small subset is supported across different browsers/platforms.
FalconShould there be a Law?
Most, if not all, Mozilla extensions use Javascript, so that's most likely what these changes are aimed at. I don't think you're supposed to use them on public webpages; if the Mozilla guys really care, then they'll also make sure that these extensions won't work in that case.
quidquid latine dictum sit altum videtur.
Most, if not all, Mozilla extensions use Javascript, so that's most likely what these changes are aimed at. I don't think you're supposed to use them on public webpages; if the Mozilla guys really care, then they'll also make sure that these extensions won't work in that case.
Funny... that exact same argument didn't work for Microsoft with their extensions to Java... why should we let Mozilla get away with it?
Coming soon - pyrogyra
Don't deviate from standards, extend them. Make sure standards are followed then go beyond the standards, just make sure doing so doesn't create problems with the standards.
FalconShould there be a Law?
World Peace would be nice too.
"It's the height of ridiculousness to say for those 9 lines you get hundreds of millions."
It's kind of nice that the moz developers are extending the Javascript specs; and it'd certainly be nice if MS were to follow their lead.
But anyone who thinks that this will have any impact on browser use needs to think again.
OK, there will be a few websites that will use the new stuff and either break IE or put up a 'get a decent browser' page. But most people can't afford to throw away a vast majority of their market. So they need to write code that will work in IE; and if you've already written code that works in IE and Mozilla you won't bother redoing it just for Mozilla; even if the Mozilla-specific code could be half the length and easier to follow. So users won't have any incentive to switch to a Mozilla browser.
Is is basically a direct-mode graphics canvas, as specified by WhatWG canvas specification, which allows you to draw all kinds of graphic primitives using Javascript. This is based on Apple's implemented in Safari.
I would hope that some highly innovative graphics-applications can become possible using Javascript, when this goes mainstream.
Mozilla Extending Javascript = yes (read the posting)
Are web designers going to use it = no since they like "write once, run everywhere"
Will extension developers use it = yes
Will anybody remember the person responsible for Javascript in the first place?
Well, see for yourself, a document that he maintains Roadmap
Because there are certain things that it's not ok to do when you have a monopoly that it would be ok to do if your an underdog?
So now we tilt the playing field in favor of Mozilla. The problem is, when do we un-tilt it?
"My God...it's full of trolls!"
I wish they'd extend it by replacing it with python.
The cake is a pie
Uh, wow. Ever heard of domain? Let's see you get ANY php to run in ANY browser : P
... it reduces the need to do things like redeclaring variables just to be used in a for loop:
... why is this a Bad Thing? of course other than the fact that I can only use it in one non-existant browser : )
lmao
More to the point foreach is great
so instead of:
var y = x.childNodes;
for(var i=0; iy.length; i++){
do something with y[i]
}
i could just do
foreach(x.childnodes as y){
do something with y
}
So getting back to the point
Peace,
sk
Microsoft's problem with respect to Java was that in extending it they were breaching a contract with Sun. Of course arguments about why they were doing it didn't help them; their contract didn't provide for any such exemptions. Mozilla have no contractual obligations, that I'm aware of, to implement JAvascript/ECMAscript in any particular way.
I don't care about the case; I care about the arguments that nearly everyone on Slashdot made at the time as to why Microsoft were in the wrong - namely that they were deliberately making it harder to write cross-platform code that worked the same way everywhere.
When asked why this was a problem when you can turn off the extensions using a command line switch, nearly everyone wrote back that it was still subverting standards, and that software developers wouldn't know the difference between writing Microsoft-specific Java code, and regular, Sun Java code.
The exact same argument applies here. If this goes ahead, developers won't know when they're writing Mozilla Javascript code, and when they're writing standards-correct ECMAScript code.
The amount of hypocrisy on slashdot is amazing. It seems to be like this:
When Microsoft subverts open standards in an embrace and extend manner, it's evil.
When Mozilla (or anyone else does it), it's great! It's good! It's expected! It's the way innovation goes forward!
At least you guys could discuss amongst yourselves and put out a consistent message at some point. Or heck, just be honest - if it hurts Microsoft, it's A-OK by us!
Coming soon - pyrogyra
var html = <hmtl/>
html.head.title = "my title";
print(html);
This prints as:
<html>
<head>
<title>my title<title>
<head>
<html>
Although this is a contrived example, I find the ability to access XML as native objects using dot-notation to be very convenient and useful.
C'mon, mods, the parent poster makes a good point. It's only "flamebait" if you're ready to apologize for the hypocrisy of the Mozilla developers.
For the record, the new methods are NOT ECMA standards, according to the Array object reference. In other words, developers relying on these methods will be locking themselves into Gecko, unless other vendors scramble to support them, which they will likely do in buggy and incomplete ways--which, incidentally, is exactly what standards (like ECMAScript) were supposed to prevent.
I suspect we'll be seeing similar non-standard extensions to CSS and (X)HTML in the months and years to come, rendering the W3C more and more irrelevant. The standards armistice was always a nice dream, I guess, and it was good while it lasted. So much for that.
The problem is, when do we un-tilt it?
That one is easy. When everyone starts using Firefox and we start liking something else.
In fact, so much faster that now I'll need to do EVEN MORE cross-browser compatibility testing. Yay!
Like it wasn't bad enough with the conflicting methods in IE and Moz's javascript implementations.
...but no inline-block. At least, not according to this page. :(
The roots of education are bitter, but the fruit is sweet.
--Aristotle
Compare the amount of IE written in Java to the amount of Mozilla written in Javascript. Compare the advantages of having a Windows-specific Java program to a 100% portable Java program. Compare the active progress of the Java standard under its developer vs. the stagnant progress of the Javascript standard, and ask yourself which language needed outside help more.
Looks like hypocracy on the surface, but if you dissect the issue most of it goes away. That said, I'd much rather see active development of and participation in open web standards by these organizations, but none of them have even achieved full CSS2 compliance yet.
You're failing to distinguish between the language and implementations of the language.
By analogy, the C++ language has changed once since 1997 (with the technical corrigendum that fixed a couple relatively minor issues).
However, it was only fairly recently that there has been a compiler and library that has implemented the standard apparently correctly.
This does not mean that when a compiler writer adds support for the hell that is 'export' he or she is extending the language. By contrast, the only thing they're extending is the amount of the language their tool implements.
I don't know what the OP was thinking, but I suspect it's along those lines.
(Granted, from the other posts it sounds like Mozilla is in fact extending the language.)
This entry in Asa Dotzler's blog contains links for downloading this release candidate of Deer Park Alpha 1.1.
The article has links to New Web Developer Features and New Extension Developer Features. There's also a page listing New Browser Features and an unofficial page listing Notable bug fixes.
The shareholder is always right.
you must be kidding yourself. MS added functionality to do what, not for developers to use them. Extending a standard aka EMCAScript, IS extending it, they are doing exactly what MS and Netscape did back in the day.
But I do not mind that because otherwise we would not have font, css and many of the other things people take for granted in html.
I love questions answer themselves.
http://virtuelvis.com/
Although I think Microsoft's concept of Avalon and XAML replacing HTML is shite (and it's been tried before), AJAX has proved the concept of better client-side support within browsers. For those of us who've been using Javascript to do things like confirm webforms, create dynamic menus and load Javascript arrays with useful data for fast access over the years, we're wondering what all the fuss is about of course.
Mozilla, Firefox, other browsers and the W3C need to make this much easier to do for web developers to make sure that Avalon and XAML never gets off the ground when Longhorn hits. They need to do what Netscape did for the web when the whole thing first took off - get there first.
Whether IE supports it or not is Microsoft's problem, no one else's.
We don't even need one version of PHP. Javascript makes an excellent language for server-side scripting, and would be a worthy standards-based replacement for the proprietary & screwy PHP language.
Whenever I hear the word 'Innovation', I reach for my pistol.
I wish that Mozilla would only allow these language extensions (such as the -moz CSS properties) to work in Mozilla extensions. These are obviously useful language tools, but the web is divided enough as it is. This way, the browser extension development scene could serve as a test bed to language extensions. The new syntax and functions don't seem to have been widely tested. If somebody finds a problem with the initial release, will the next version of Mozilla have a new syntax? These extensions should be proposed to a standards organization. People need to stop dumping more undocumented, unstandardized stuff into the web. The way things are going, web developers will soon have to target 4 versions of Mozilla, 3 versions of Internet Explorer, Konqueror, 2 versions of Safari, and Opera.
I think what deserves more attention is the badass development of cairo into Mozilla.
Check out the blog of the main developer thats doing this development. Hes got some excellent demo screenshots.
http://weblogs.mozillazine.org/roc/
I usually do not, since I don't want silly animations chewing up cycles, or annoying floating thingees obscuring content.
Sure, it's annoying to have to click through menus to turn javascript or java back on for those few pages where I need it, but that's less annoying than having it turned on by default.
PHP has had foreach for an extremely long time. It has existed since PHP 4, and could be easily coded in before that.
got sig?
When Microsoft subverts open standards in an embrace and extend manner, it's evil.
When Mozilla (or anyone else does it), it's great! It's good! It's expected! It's the way innovation goes forward!
You are not arguing with any kind of logic. I still don't understand why comments like this get modded up. Sigh. So let me break this down real slow for you.
The problem with MS's Java extensions wasn't that they added extra functionality to the language or the VM. The problem was that they did so in a non-open manner so that no other implementation of the Java language or runtime could replicate the functionality exactly, causing breakage when developers end up using MS-specific features.
The way Mozilla is adding features to Javascript is open. The specs are out there and the code is out there. ANYBODY can re-implement the features for complete compatibility -- including by copying-and-pasting the code into IE. Do you understand this? The boys in Redmond are NOT locked out of being able to achieve complete compatibility the way other developers were locked out of achieving compatibility with MS's extensions to Java.
For the last time: adding features and extending platforms is NOT a bad thing. This is how innovations occur. What is evil is to do so in a non-open manner so that the extensions cannot be copied and re-implemented by others.
Hopefully we'll not have more of these "slashdot is hypocritical" arguments. It's only hypocrisy when you don't understand what was wrong with MS's behavior.
I'm actually with you there. The important W3C standards were always pipe dreams. In reality, browser compatibility headaches persist, even between projects like Gecko and KHTML that try their damnedest to adhere to the standards. And not only has the W3C been a failure--it has also substantially set back the pace of innovation by discouraging developers and coders from trying new things. Hordes of slavish standards fanatics stand ready to pounce on you the minute you try.
Oh, and fuck you too.
solveMyProblem();
-Max
IMHO, the big trap, particularly for newbies to javascript is using features/functions that are not part of the standard without knowing it.
ie it should be very recognisable that you are using something that is not part of the ECMA standard.
In Java land, that's made somewhat obvious by the import statement - the namespace for standard is java/javax, and, eg com.* or org.* etc are for everything else.
Actually the same should be the case for HTML etc.It should be obvious when there are tags/features being used outside of the standard just by looking.
The best way to let people code to standards is making it easy as hell to tell what is standard or not - without reading a gazillion pages of specs that they may not even understand.
ws
So does Anonymous Coward have good karma?
I care about the arguments that nearly everyone on Slashdot made at the time
I don't know why this is so hard to understand: Slashdot has around 800,000 registered users. A typical Slashdot story will have around 500 comments from perhaps 200 or 300 different registered users, i.e. around 0.03% of all.
Let this sink in: the set of people commenting on a story will be a highly selected sample of those who care about that particular subject, and it won't necessarily be representative of Slashdot readership.
At least you guys could discuss amongst yourselves and put out a consistent message at some point.
Are you serious?
I guess I don't get it. If one is only developing for a private intranet and will not be accessed by any other browsers except Mozilla, then this is basically creating propriatary software where anything goes anyway. Otherwise it seems to be similar to the old Netscape/MS IE extensions war for browsers that caused so many problems years ago ( and still is causing problems).
What happens if the company wants to scale up later to allow clients to view or to incorporate this great new stuff on the/a public website. It just doesn't make much sense to me in the long run.
Am I missing something important here?
I'll switch my OS X machines to Firefox as the default browser when it gets a little less sluggish. Hopefully the 1.1 release will make headway in that department.
Damn, doesn't it sound familiar to embrace-and-ex...
Well, let's see. Netscape invented JavaScript, Microsoft did its best to break it. But, not without the help from the Mozilla Foundation, the proprietary plot has been demolished and by now everyone, except the most lazy and ignorant, seems to know that you can't trust Microsoft's innovations to lead you to the light.
But isn't it about the time to make another step forward? And who would YOU choose to bring you there? As for me - I, for one, welcome our new stag-headed lizard overlords!
Yeah, It wasn't really the "embrace and extend" thing that MS did that was bad. it was the third step, which was to not share their extensions.
It's really a semantic argument I guess. In the confines of the term "embrace and extend", extending is something bad. While writing "extensions" to software, or suggesting "extensions" to a standard is something that happens all the time.
Standards aren't codified to stop all development and make things boring. They're written so that there's one place and system for making extensions, and sharing them.
One time I threw a brick at a duck.
I've found this interesting since some sites use images as cursors for IE, and that would be a welcome improvement to Firefox also:
URI values on CSS cursor properties
On Windows, OS/2 and Linux (Gtk+ 2.x) one can now use an arbitrary image as the mouse cursor while a given DOM node is being hovered. Any image format supported by Gecko can be used for the image (SVG, animated GIF, and ANI cursors are not supported).
I hope they add a real concatenation operator. Using the plus sign for string concats is confusing and problematic.
Table-ized A.I.
JavaScript != Java! Sun has absolutely nothing to do with this whatsoever.
Mozilla javascript will run on Mozilla for Windows, AND on Mozilla linux, etc. Mozilla itself is cross platform, even if some Mozilla javascript is not.
Java was intended to be cross-platform. By corrupting the API, Microsoft attempted to wreck the cross platform centerpiece of Sun's intellectual property.
That said, Mozilla is either standards compliant or not. Mozilla should have gotten this into the standard before incorporating it, not the other way around.
3 things about computers: they're alive, they're self-aware, and they hate your guts.
"They also appear to have added native XML support. Will this speed up the development of AJAX applications"
Actually, if you can use the XMLHttpRequest method you do not need to use XML at all. You can send & receive plain text data.
They're not futzing around with ECMAScript; they're implementing parts of ECMA-357.
This specification has been around since June 2004, look it up on http://www.ecma-international.org/
Your argument isn't very insightful if you haven't found that you can do for(i in varname[i]) to access in sequence all of the variables in arrays or even objects.
the point still stands that you have to type out 'x.childNodes[i]' instead of e.g. 'y'. But yes, thanks for the tip : )
Wait, didn't IE do this? And all the tech-saavy people went crazy because people started using the browser specific "codes" that ended up causing incompatibilities? Let not have a double standard. We cannot blame IE for its browser specific codes, when we are doing the same thing. Besides, Mozilla has no where near the market share to really push this.
oh yeah.. forgot because it sucked so much.
I am the Alpha and the Omega-3
Funny... that exact same argument didn't work for Microsoft with their extensions to Java... why should we let Mozilla get away with it?
If you don't want to use the new functions, don't. A bit of javascript that renders in IE doesn't magically not work in Mozilla because of these new functions. Effectively, they're adding a few new functions to their standard implementation - they're not changing the way pre-existing functions work (like MS did with Java).
If you want something similar to PHP's foreach, you can use for
As I've remarked in another post, implementing these methods in a cross-browser and forward-compatible fashion is not difficult if you know what you're doing:Test:You've now just implemented these methods for browsers that don't support them, and they won't break in a JS interpreter that *does* have native support for them. I've used a bunch of array methods that I stole from PHP and Python in this way for ages.
Works in any browser that supports JS 1.2 and up. Tested in Mozilla/Linux, FireFox/Windows, FireFox/FreeBSD, Konqueror/Linux, Konqueror/FreeBSD, Opera/Linux, Opera/Windows, and even MSIE.
That wasn't so hard, now, was it?
(I will leave passing in parameters to the called functions as an exercise for the interested reader.)
Il n'y a pas de Planet B.
As someone who is a professional Java programmer from way back, who watched this whole thing unfold, I think that you are somewhat mistaken about this.
The problem with Microsoft's extensions to Java was not that they refused to grant Sun permission to implement them. The problem was that the extensions were a violation of the contract that Microsoft had signed, which stated that they needed to reproduce the Java language EXACTLY as it was stated in the Java Language Specification. This is needed in order to achieve binary interoperability between different implementations of the Java language.
The proper way for Microsoft to have added these extensions was to work with Sun (possibly paying them...) in changing the language standard, thus forcing all implementations of the standard to adopt the new features. Microsoft knew this (it's written quite clearly in the contract), but deliberately chose not to do so, and instead chose to violate their contract, presumably so that they could fragment the Java community with an incompatible version of Java (and encouraging people to write code that would only run on it) and thus prevent the community from achieving a consensus that could threaten Microsoft.
Java, by design, is not supposed to be extended piecemeal by individual JVM vendors. It's supposed to be extended by changes to the specifications, which are then implemented by ALL the vendors. Agreeing to support this principle is a requirement of becoming a Java licensee.
I think that Mozilla unilaterally adding features to Javascript creates exactly the same sorts of problems. I don't want to have to code web pages differently for every different kind of browser out there. Instead, the Mozilla folks should talk to the people who manage the ECMAScript standard and should get the new features added there. That way, everybody has a clearly specified, agreed-upon definition of exactly what the new feature is supposed to do, which is far preferable to everybody vaguely trying to reproduce Mozilla and other browsers bug-for-bug.
I don't understand this logic at all. The browser must be extended to meet the needs of its users. One of my biggest gripes is that Javascript was abandoned before it became a "complete" language. Now its forever stuck in limbo because corporations are too caught up in bureaucracy to download and utilize a FREE product? The stupidity warp around Microsoft never ceases to amaze me ...
or sleep(), delay() or whatever they want to call it, window.setInterval() is a big ol POS on a project I'm working on because I can't maintain state with it.
09f911029d74e35bd84156c5635688c0
It really pleases me as a (semi-)closet Lisp programmer to see such extensions, as they closely resemble something so near to my heart, such as this or this ;-)
Those are very handy features, but I've already written small functions to do all that, and they'll work in any browser. I try to code for the greatest common denominator.
The Microsoft analogy doesn't apply here; they sought to monoplize the market with their closed proprietary products and kill off competitors. Mozilla is different; it's open source. There's no danger of that happening with an open source product. I think It's excellent that they're extending the language; after all, innovation is welcome in open source... things need NOT stagnate, and standards can be revised to meet the needs of the times.
Well, that's why the SI units aren't "one size fits all". That's why there are SI prefixes. We have not only meter, but also centimeter, kilometer, etc...
In most situations where traditional units are still used, they do not make more sense. An obvious example is the use of feet for measuring height in aviation (hektometers would make a lot more sense). And in those situations where traditional units actually are more convenient (if such situations exist), it would be much better to invent a similar unit, with a simple conversion factor into the SI system (such as half-meters, half-liters, or whatever...).
Take a look at my bookmarks on metrification for some interesting articles on this.
I did. And there were several interesting things to note. First, people are fairly good at rationalizing the status quo: "Because this is the way it's always been done, it must be the best way". Secondly, people are selfish: "Because I don't see any problems with measuring in hogshead/bell, I don't see why anyone else should be confused". Third, people will invent excuses to legitimate their irrational behaviour: "Even in sweden they use inches for measuring bolts" (as if they had any choice, the bolt has to actually fit the machine). Lastly, people always resist change (which happened to be the only valid argument I found)
The difference is that it's Javascript, not Java. At around the same time they were extending Java, Microsoft was also extending Javascript. No one really complained about that. They even tried to push VBscript as a replacement that did exactly the same things with different syntax. Everyone just ignored it.
ECMAScript is meant as a bare-bones embedded language that gets extended for the specific platform. There's also a standard way of embedding it into a web browser (from a different standards body), but it started as a baseline of how the major browsers implemented it and has grown mostly by adopting vendor extensions that became popular.
Java was designed from the ground up with a fat standard library and the motto "Write once, run anywhere."
-- . . ramblin' . . .
Microsoft doesn't just extend specifications, they slightly modify/break the implementation so that it doesn't stay fully compatible with the original standards.
They did it for Java, they did it for Javascript (JScript), they did it for HTML (MSHTML) and they did it for CSS.
"The way we can tell it's C# instead of Haskell is because it's nine lines instead of two." -- wadler
You guys know that xmlHttpRequest isn't part of any standard now don't you?
"The way we can tell it's C# instead of Haskell is because it's nine lines instead of two." -- wadler
They're merely useful tools that can be replicated (with lower performances) on any browser that complies to the ECMA-262 specifications.
xmlHttpRequest is not part of any standard and has been implemented first in IE5. Has anyone complained? no?
"The way we can tell it's C# instead of Haskell is because it's nine lines instead of two." -- wadler
i'm not sure who created the javascript language, but like css and html, isn't there a group that controls and maintains javascript upgrades and extensions? it's nice that mozilla made some useful extensions, but unless the rest of the browser market follows, it'll become a useless feature.
right now, javascript is @ 1.2 (i may be wrong about this). why not make a javascript 1.3 that includes these extra features. i mean, it's like microsoft ie supporting some weird formatting and standard which breaks every other browser. people complain about that, but when mozilla does the same thing, people don't?
some are going to say, in javascript, you can check to see which browser people are using and code according. if that was the case, i'd be coding twice, one for mozilla/firefox, the one for the rest of the browsers, which basically defeats the purposes of these "extensions".
HD Trailers
Mozilla have not "extended" the spec, merely their implementation of Javascript to take in 1.5 features.
See here:
http://developer-test.mozilla.org/docs/JavaScript
but do we need to consider pop-up blocker as a break of standard? It makes many JS code not work any longer, although most of us like this. Anyway, nice to see that Microsoft also catches up with us to break the standard with its SP2.
Mozilla isn't cross platform, it's a separate platform.
I am trolling
Er, java 5: System.out.printf( "%10.2f", x);
Remember the good old days when creating extensions to specs (MS) used to bring the wrath of the world. It's ok now hoever because Mozilla has done it!
Karma means nothing to me, so suck it...
It would be freaking nice to have many of the events that IE added in Mozilla.
DragStart
DragStop
RighClick
Just to name a FEW... I see NO reason they cannot be added.
Funny thing, though, fence materials (high tensile smooth wire, woven cattle wire, barbed wire, etc) still come in units of rods, even though they don't say it per say on the label. Even the european stuff (I still have a couple of rolls of Baekert green-coat high tensile woven wire sitting around, imported from Britain) is measured the same way. One roll of wire = 1 Rod in length.
It's silly to blame most of the "old" measurements on the US, when most/all of them had their origins in European or British traditional measurements...
I mean, what web developers want is standardisation, not even more differences between browsers!
It'd be better to gain concensus when extending a language, as Sun does with Java. That way, it's a de-facto standard before anyone has even implemented it, and then can gain standardisation.
Standardization follows implementation here, and in many cases. Where standardizers wait to implement, and instead design on paper and by consensus, you usually get something bigger, slower, and later than if implementors had competed, or taken first base by moving fast and doing a good enough job.
I'm hoping to avoid design-by-committee bloating ECMA-262 Edition 4. Wish me luck!
Sounds like we're on the same page. Good luck. :)