Microsoft en Mozilla oneens over toekomst Javascript

Mozilla en Microsoft zijn het onderling oneens over de volgende versie van EcmaScript, de basis voor onder andere Javascript. Chris Wilson, platform architect van Microsofts IE-team, ziet niet veel in het door Mozilla gesteunde EcmaScript 4.

Wilson schreef dinsdag op zijn blog dat het mogelijk moet zijn om met een fonkelnieuwe opvolger van Javascript de scripttaal te bevrijden van de huidige beperkingen en incompatibiliteit, 'without breaking the Web'. Microsofts JScript-team heeft onlangs een lijst met verschillen tussen Jscript en EcmaScript versie 3 gepubliceerd, waarmee bij de de bouw van een nieuwe scripttaal rekening gehouden moet worden. Alleen dan kunnen de huidige implementaties van Javascript ondersteund blijven, denkt het bedrijf.

De voorgestelde wijzigingen in EcmaScript 4 zouden leiden tot niet goed functionerende websites en -applicaties, omdat het samengaan van een fundamenteel gewijzigde scripttaal in combinatie met backwards compatibele code nooit goed kan uitpakken. Volgens Wilson is er echter amper met de voorstanders te praten: 'Helaas lijkt dit op een ES4-ja-of-nee ruzie. Ik denk dat niemand in de loopgraven moet springen en wij hebben nooit willen zeggen dat alles aan ES4 slecht is.' Vervolgens stelt hij dat alle kritiek op EcmaScript 4 zonder meer door de voorstanders wordt weggehoond.

Brendan Eich, chief technology officer bij Mozilla en schepper van Javascript, is een van die voorstanders van EcmaScript Edition 4. Hij beweert in een open brief dat Chris Wilson met zijn blogpostings leugens verspreidt. Volgens Eich heeft iedereen tijdens het onwikkelingstraject van EcmaScript 4 voldoende tijd gehad om kritiek te geven, en heeft Microsoft dat achterwege gelaten. Bovendien zou Microsofts EcmaScript-interpretatie juist voor problemen zorgen: de lijst met verschillen tussen EcmaScript 3 en JScript 'is Microsofts probleem, en dat probleem mag geen seconde in de weg van EcmaScript 4 staan', aldus Eich. Bovendien is er weliswaar een 'heftige, fundamentele discussie' tussen de diverse partijen geweest, maar zouden de 'verzinsels' van Wilson over een vijandige benadering uit de hoek van de EcmaScript 4-voorstanders gemakkelijk weerlegd kunnen worden.

Reacties (89)

[jurriaan]

Ik snap het probleem eigenlijk niet helemaal. Waarom zou javascript2 backwards compatible moeten zijn? Het is toch prima mogelijk om beide parse-engines in de browser op te nemen en aan de hand van het version attribuut een van beide te geruiken. Het lijkt mij juist een uitstekend moment om de verschillende javascripten van de verschillende browserversies te verenigen in 1 standaard. Dat oudere browsers de nieuwe versie dan niet zullen ondersteunen is iets waar je als ontwikkelaar rekening mee moet houden. Dat kan lastig zijn en in de 'beginfase' de adoptie wat verlagen, maar dat is niet anders dan met versie 1.6, 1.7, 1.8 etc van het huidige javascript.

Ook bij Actionscript (ook gebaseerd op Ecma 4 tegenwoordig) zul je ervan uit moeten gaan dat de gebruiker de nieuwste versie van de flashplayer heeft om de laatste versie te kunnen gebruiken. Maar uiteindelijk lijkt me dit een betere situatie dan oude (en deels 'verkeerde') code te blijven ondersteunen.

[crisp]

Versionering is een implementors nachtmerrie. Niet alleen kost het 2 keer zoveel moeite om seperate scripting-engines te ontwikkelen en onderhouden, maar je blijft ook zitten met het feit dat je de problemen in de huidige implementaties en de onderlinge verschillen dan niet oplost terwijl de huidige content op het web zeker niet zal verdwijnen en voor een groot deel ook niet aangepast zal worden.

Verder loop je het risico dat vendors op een gegeven moment de 'oude scripting engine' helemaal niet meer gaan ondersteunen waardoor hedendaagse content straks niet meer volledig toegankelijk zal zijn en ' weg zal rotten'. Het doel van standaardisering is juist om dat te voorkomen en daarom is het ook belangrijk dat nieuwe versies zoveel mogelijk backwards compatible blijven met vorige versies (afgezien van bugfixes). ECMAScript 4 placht dat ook te doen.

Het probleem van ondersteuning van oudere browsers is altijd maar een relatief tijdelijk probleem, oude content daarentegen is een bijzonder zwaarwegend probleem van niet tijdelijke aard.

[Reactie gewijzigd door crisp op 23 juli 2024 16:05]

[Little Penguin]

Ik snap het probleem eigenlijk niet helemaal. Waarom zou javascript2 backwards compatible moeten zijn?

Don't break the web.

Mozilla, Opera en Adobe (et al) zijn op dit momen naar een nieuwe versie van ECMAScript (wat dus JavaScript 2 moet worden) toe aan het werken die volledige compatible is met ES3 - zodat je geen gebruik hoeft te maken van 2 verschillende engines.

Dat is alleen maar toe te juichen, want op die manier kun je gradueel overschakelen naar de nieuwe versie en kun je -mitst goed opgezet- met veel code-reuse toch een maximale experience aan zowel gebruikers van bestaande browsers alswel aan gebruikers van nieuwe browsers (Firefox 4) geven.

[SPee]

'Don't break the web.'

Maar als je dat niet doet, dan kom je nooit verder. Dat heeft Microsoft wel geleerd.
Als je iets totaal nieuws wilt, dan moet je niet blijven vasthouden aan het oude.
Anders blijf je aan het oude vast zitten.

Er zijn veel wensen om te vernieuwen en ik denk dat veel ervan niet kan samenwerken met het huidige Javascript. Dus Mozilla geeft aan, dat doen we niet.
Maar dat is kortzichtig denken. Als je nu niet totaal anders doet, dan blijf je op dezelfde weg doorgaan, totdat je vastloopt.
En nu is het goede moment om over te gaan. Veel bedrijven hebben er oog voor en houden er rekening mee met compliancy. Als er dan iets nieuws komt, dan zullen ze óf op de huidige manier doorgaan totdat ze aanpassingen gaan maken, of het vrijwel direct gebruiken.
Met een goede versioning zal het goed gaan.

[Little Penguin]

Maar als je dat niet doet, dan kom je nooit verder. Dat heeft Microsoft wel geleerd.
Als je iets totaal nieuws wilt, dan moet je niet blijven vasthouden aan het oude.
Anders blijf je aan het oude vast zitten.

Microsoft heeft nooit anders geredeneerd en doet dat nog steeds niet - het bedrijf heeft er 6 jaar over moeten doen om helemaal los te komen van DOS-compatibiliteit.

Verder is zegt Microsoft OOK hetzelfde. - dus over dat credo zijn ze het wel eens, maar niet over de uitvoering.

Er zijn veel wensen om te vernieuwen en ik denk dat veel ervan niet kan samenwerken met het huidige Javascript.

Heb je daar ook een feitelijke onderbouwing voor? Talen als C++ en Delphi (Object Pascal) hebben een klassiek iterative omgeving goed weten uit te breiden tot een object-georienteerde omgeving. Ik zie niet in waarom dat bij JavaScript ook niet mogelijk is.

Dus Mozilla geeft aan, dat doen we niet.

Wat Mozilla (en Opera en Adobe) willen is een uitbreiding die te vergelijken is met die van C++ t.o.v. C en van Delphi (Object Pascal) t.o.v. (Turbo) Pascal.

Maar dat is kortzichtig denken. Als je nu niet totaal anders doet, dan blijf je op dezelfde weg doorgaan, totdat je vastloopt.

Want?

Zolang je er voor zorgt dat de nieuwe features de oude niet in de weg zitten en dat de nieuwe geen last hebben van de oude features zie ik niet in waarom je vast zou moeten lopen.

En nu is het goede moment om over te gaan. Veel bedrijven hebben er oog voor en houden er rekening mee met compliancy. Als er dan iets nieuws komt, dan zullen ze óf op de huidige manier doorgaan totdat ze aanpassingen gaan maken, of het vrijwel direct gebruiken.

Veel bedrijven maken nog gebruik van IE 6 en zullen echt niet in 1x overstappen op IE8.5 of IE 9.

Qua compliancy heb je inderdaad wel gelijk, maar dan nog zal het moeten werken op het bestaande systeem. En dat betekent dat je pas op z'n vroegst ergens in 1012 gebruik zal kunnen gaan maken van de nieuwe features.

Met een goede versioning zal het goed gaan.

Met goede versioning zal het uitrollen van ES4 inderdaad goed gaan. Maar ik neem aan dat je dat niet bedoelt. Als er echter een compleet nieuwe taal komt dat is versioning zo-wie-zo geen issue - je kiest dan of voor JavaScript of voor "DifferentScript".

Het is overigens Microsofts goed recht om ES4 niets te vinden, maar waarom hebben ze dat een jaar eerder niet gezegd? Men gaat nu pas kritiek leveren nu ES4 richting een afwerkfase komt qua documentatie/specificatie - en dat ik rijkelijk laat.

[Coju]

Klopt helemaal, komt bij de Microsoft sinds jaar en dag geen Windows 98 en alles daarvoor ondersteunt, waarom dan wel de javascripts van de browsers die destijds verscheept werden met datzelfde Windows.

[Brantje]

Wie houd zich nou niet aan de regels?
Mozilla of Microsoft?
EcmaScript, heb ik nog niet eerder van gehoord.

[Little Penguin]

Zoals je kunt lezen in bovenstaand bericht is het de intentie van Mozilla, Opera en Adobe (wss zullen KDE en Apple hier ook wel bij horen) om bovenop ECMAScript-3 een verbeterde versie te maken die dan als versie 4 door het leven zal moeten gaan.

Het is absoluut niet de bedoeling dat ES4 incompatible gaat worden met ES3 - "don't break the web" is het credo hierbij. ES4 moet er echter wel voor zorgen dat toepassingen zoals AJAX e.d. beter gaan werken/performen.

ES4 (dat uiteindelijk moet zorgen voor JavaScript 2.0 in Mozilla e.d.) is dus ook compatible met ES3 (de bestaande JavaScript/JScript) implementatie. Het is dus niet zo dat Mozilla (et al) aan het werken zijn aan een taal die incompatible is - de taal is uitgebreider, maar gewoon compatible met ES3.


Microsoft daarentegen lijkt helemaal geen wijziging te willen aan ES - zij vinden de bestaande implementatie goed en werken, naar het lijkt, liever aan een nieuwe taal die dan naast ES3 (het huidige javascript dus) moet ontstaan. Hierdoor zal een bestaande library echter wel aangepast moeten worden als men gebruik wil maken van deze nieuwe scriptingtaal -> ofwel dubbel werk.

Als iedereen (inclusief MS) naar ES4 toe gaat werken kunnen we geleidelijk aan overstappen op de mogenlijkheden van ES4 (omdat we niet in 1x alle libraries moeten herschrijven) - zodra browsers die alleen ES3 aankunnen onder de 2-5% marktaandeel gezakt izjn kunnen we dan zelfs volledig gebruikmaken van alle ES4 features.

Na bovenstaade inleiding is dus ook een antwoord te geven op de volgende vraag:

Wie houd zich nou niet aan de regels?
Mozilla of Microsoft?

Zowel Mozilla als Microsoft houden zich op dit moment aan de ES3 regels - hoewel er in de Microsoft versie nog her en der wel onopgeloste bugs zitten. Een bedrijf met een omzet/winst als MS heeft echter genoeg middelen om ook deze bugs op te lossen en het is mijns inziens ook een schande dat dit nog steeds niet gebeurt is.

Echter:
Met ES3 kunnen we niet per definitie naar Web2.0+ (zeg maar Web3.0) toewerken, ES4 moet dit echter wel/beter mogelijk maken. Het is dus een goede zaak als alle browsers ES4 gaan ondersteunen.

Microsoft heeft hier geen zin in - de reden laat zich helaas raden en op dat raadsel zijn meerdere antwoorden mogelijk...

N.B. de afkorting 'ES' staat voor ECMAScript en hierboven staat uitgelegd wat met deze term bedoeld wordt...

[crisp]

Microsoft heeft hier geen zin in - de reden laat zich helaas raden en op dat raadsel zijn meerdere antwoorden mogelijk...

Het is sowieso verwonderlijk dat Microsoft na acht jaar stilte rond JScript en zo laat in het ontwikkelproces van ES4 (een open proces waar MS zelf grotendeels een passieve rol in heeft gespeeld) opeens beren op de weg meent te zien. Ook het JScript deviations from ES3 document wordt gebracht met een boodschap die spreekt van "grote implementatieverschillen tussen browsers onderling" en daarbij de-facto (MS') standaarden die de stap naar een compleet nieuwe taal zouden rechtvaardigen.

Ik heb wel een mogelijk antwoord op het raadsel: MS ziet zichzelf op technisch vlak jaren achterlopen op de concurrentie en is nu bang om uiteindelijk de boot te missen. Daarnaast heeft MS eigen proprietary technologieën ontwikkeld zoals Silverlight/XAML welke ze het liefst naar voren zouden willen schuiven als een vervanging van JScript en HTML. MS houdt gewoonweg niet van open standaarden omdat ze niet van eerlijke competitie houden, zeker niet als ze (door hun eigen schuld) niet de pole position hebben...

[Reactie gewijzigd door crisp op 27 juli 2024 17:03]

[Korben]

Wel erg kort door de bocht, ik denk dat Microsoft ondertussen op andere vlakken wel heeft bewezen dat ze niet vies zijn van standaarden en dat ze ook in staat zijn om vanuit het niets de koppositie te pakken (denk aan .NET).

Overigens heeft Microsoft wel degelijk gewerkt aan JScript. JScript.NET bijvoorbeeld, en dan quote ik even van Wikipedia:

The most recent version of JScript is JScript .NET, which is based on the yet-unfinished edition 4 of the ECMAScript standard...

[Little Penguin]

Wel erg kort door de bocht, ik denk dat Microsoft ondertussen op andere vlakken wel heeft bewezen dat ze niet vies zijn van standaarden

Concrete voorbeelden?

Microsoft zal alleen agressief standaarden promoten als ze zelf nog in een achterstandspositie zitten - vóór plm. 2001 zijn er (mede door Microsoft) in een korte tijd 3 versies van ECMAScript in elkaar gezet, MS was hier een drijvende kracht achter omdat men op dat moment nog tegen een enorm marktaandeel van Netscape aan moest boksen.

Op het moment dat MS meer dan plm 85% marktaandeel had is alle "innovatie" qua webstandaarden bij het bedrijf stil komen te liggen. Men heeft sindsdien niet eens de bugs uit haar eigen implementatie van ES3 gehaald.

De enige reden dat er nu weer aan IE gesleuteld wordt is ook het feit dat men significant marktaandeel aan het verliezen is - in sommige landen is het marktaandeel zelfs gedaalt tot 50% (of lager).

Overigens heeft JScript.NET geen toegevoegde waarde voor de gebruiker omdat de browser die MS levert deze versie niet ondersteunt.

[Alex]

Ik vind het erg grappig dat je deze 'bugs' aanhaald. Er zijn er wel een aantal te vinden in IE, maar 95% van de zaken die jij als bugs ziet, zijn expected behaviours.
Laten we ervan uitgaan dat de bugs zoals jij ze noemt daarnaast niet oplosbaar zijn qua design? Dat de architectuur van een programma wat zo diep gebruik maakt van Windows om snel te renderen(niet per pagina, maar per footprint lijkt IE toch vaak sneller als alternatieven).

Het is vrij kort door de bocht heen om te zeggen dat MS deze bugs gewoon op moet lossen. Je hebt namelijk geen idee van de impact die een bug, in jou ogen, heeft op het totale idee wat er heerst binnen het architectuurteam van IE binnen MS.

Om nog maar eventjes te zwijgen van de Language Designers. MS heeft op dit moment de beste taalontwikkelaars binnen haar muren zitten. Neem een Anders hejlsberg, Erik Meijer, Herb Sutter, Brian Beckman, etc. Ik geloof absoluut dat zij de impact van ECMAScript 4 goed kunnen inschatten. Het grappige is dat ECMA v3 niet zoveel verschilt met JScript, en JScript op zijn beurt weer ondersteund wordt door alles behalve Mozilla. Het valt op een paar sructurele puntjes. Mozilla ontwikkeld ECMA v4 door en wil deze puntjes niet opnemen of compatible maken. Tsja... als MS mag je dan best op je strepen gaan staan. Mozilla op haar beurt lijkt ook niet te snappen dat we moeten werken aan een web wat overal en altijd werkt. Dat je met een nieuwe browser niet kunt eisen dat webdevelopers hun sites gaan herbouwen.

Het is absoluut goed dat Mozilla verder wil met ECMA. Jammer alleen is dat het ook nog lijkt alsof er meer commerciele (Google) doelen achter zitten. Zij hebben grote plannen met ECMA, en winden daar geen doekjes om. Jammer voor MS is dat ze te lang vanaf de zijlijn toegekeken hebben hoe Mozilla zichzelf in een hoop bochten kronkelde met o.a. Google Toolbars in haar installers...

Nou en dan nog eventtjes wat concrete voorbeelden van standaarden van MS:
http://en.wikipedia.org/wiki/Common_Language_Runtime > http://www.ecma-internati...ns/standards/Ecma-335.htm
http://en.wikipedia.org/wiki/C_Sharp > http://www.ecma-internati...ns/standards/Ecma-334.htm
http://en.wikipedia.org/wiki/Office_Open_XML > http://www.ecma-internati...ns/standards/Ecma-376.htm

@Little Penguin: Ik zie ene hoop MS bashing, maar onderbouw het graag, zaken als concrete voorbeelden had ik in 30 seconde van Google gevist...

[crisp]

Ik vind het erg grappig dat je deze 'bugs' aanhaald. Er zijn er wel een aantal te vinden in IE, maar 95% van de zaken die jij als bugs ziet, zijn expected behaviours.

Heb je het door het MS JScript team zelf opgestelde document gelezen? Ik en anderen hebben zelfs nog een aantal voorbeelden gepost op het JScript team blog, en volgens mij zijn er nog wel meer voorbeelden te bedenken waar IE's ES3-implementatie afwijkt van de specificatie zelf. Natuurlijk zal een deel te wijten zijn aan ambiguiteiten in de specificatie van ES3 zelf, maar voor een groot deel zijn het toch echt bugs...

Laten we ervan uitgaan dat de bugs zoals jij ze noemt daarnaast niet oplosbaar zijn qua design? Dat de architectuur van een programma wat zo diep gebruik maakt van Windows om snel te renderen

En dat is een aanname gebaseerd op wat?

(niet per pagina, maar per footprint lijkt IE toch vaak sneller als alternatieven).

Qua javascript performance scoort IE toch meestal het slechtst...

Het is vrij kort door de bocht heen om te zeggen dat MS deze bugs gewoon op moet lossen. Je hebt namelijk geen idee van de impact die een bug, in jou ogen, heeft op het totale idee wat er heerst binnen het architectuurteam van IE binnen MS.

Microsoft blijft zelf erg vaag over hun redenen om bepaalde bugs niet te fixen. Het "we don't want to break the web" argument heb ik nog nooit door hun gekwantificeerd zien worden.

Om nog maar eventjes te zwijgen van de Language Designers. MS heeft op dit moment de beste taalontwikkelaars binnen haar muren zitten. Neem een Anders hejlsberg, Erik Meijer, Herb Sutter, Brian Beckman, etc. Ik geloof absoluut dat zij de impact van ECMAScript 4 goed kunnen inschatten.

Jep, de developers bij Mozilla (Brendan Eich himself o.a.), Opera en Apple zijn maar amateurs vergeleken bij deze Microsoft helden.

Het grappige is dat ECMA v3 niet zoveel verschilt met JScript, en JScript op zijn beurt weer ondersteund wordt door alles behalve Mozilla. Het valt op een paar sructurele puntjes.

Verschilt niet zoveel? JScript is een ECMAScript v3 implementatie. En wat bedoel je met "ondersteund worden"? Dat alle andere browservendors behalve Mozilla JScript geimplementeerd hebben? Sommigen zullen hooguit een aantal IE-quirks op dat vlak geimmiteerd hebben, maar JScript is puur MS-proprietary hoor.

Mozilla ontwikkeld ECMA v4 door en wil deze puntjes niet opnemen of compatible maken. Tsja... als MS mag je dan best op je strepen gaan staan.

Nou maak je het nog mooier. Voor ES4 is er juist ook gekeken naar interoperability issues. Het hele ontwikkelproces van ES4 is een open proces waar Microsoft ook voor uitgenodigd is; ze zijn echter lange tijd passief gebleven en zijn pas op het allerlaatste moment aangekomen met bezwaren en een voorstel om ES4 terug te brengen tot een ES3.1. Overigens zonder duidelijke rationale.

Mozilla op haar beurt lijkt ook niet te snappen dat we moeten werken aan een web wat overal en altijd werkt. Dat je met een nieuwe browser niet kunt eisen dat webdevelopers hun sites gaan herbouwen.

Ik weet zeker dat de vendors van alternatieve browsers dat vanuit hun eigen ervaringen dondersgoed snappen; zij hebben jarenlang IE's quirks moeten reverse-engineeren en weten als geen ander hoe complex de materie is. Juist daarom is het van essentieel belang dat het web gedragen gaat worden door open en interoperable standaarden, juist om te voorkomen dat sites van nu straks herbouwd moeten gaan worden of anders niet meer toegankelijk zijn en weg zullen rotten.

Het is absoluut goed dat Mozilla verder wil met ECMA. Jammer alleen is dat het ook nog lijkt alsof er meer commerciele (Google) doelen achter zitten. Zij hebben grote plannen met ECMA, en winden daar geen doekjes om. Jammer voor MS is dat ze te lang vanaf de zijlijn toegekeken hebben hoe Mozilla zichzelf in een hoop bochten kronkelde met o.a. Google Toolbars in haar installers...

Care to elaborate? Wat je hier schrijft is niets meer dan ononderbouwde beschuldigingen, maw: FUD. Het zou zo uit de mond van Steve Ballmer kunnen komen...

Nou en dan nog eventtjes wat concrete voorbeelden van standaarden van MS: [...]

Ratificatie van een technisch document maakt iets nog niet een standaard in de brede zin van het woord. Daarvoor moet de beschreven technologie ook breed gedragen zijn en door meerdere partijen interoperable geimplementeerd zijn. Voor hoeveel van deze voorbeelden geldt dat? We weten bijvoorbeeld allemaal wat een geweldige standaard OOXML wel niet is...

@Little Penguin: Ik zie ene hoop MS bashing, maar onderbouw het graag, zaken als concrete voorbeelden had ik in 30 seconde van Google gevist...

Ik zie van Little Penguin meer onderbouwing dan van jou

[crisp]

Sinds wanneer is .NET een open standaard?

En JScript.NET is een heel ander beest dan JScript in WSH (het is sowieso vreemd dat ze voor .NET wel ES4 als basis nemen en dat voor WSH zeggen niet te kunnen/willen). Daarbij is 'gebaseerd op' niet gelijk aan 'confirmerend aan'.

[elteck]

Microsoft heeft hier geen zin in - de reden laat zich helaas raden en op dat raadsel zijn meerdere antwoorden mogelijk...

Toch zou me dat verbazen. Wanneer gerbuikers gedwongen worden om Firefox/Opera te gebruiken om hun favoriete paginas correct te laten weergeven, gaat dat natuurlijk wel ten koste het marktaandeel van Microsoft's exploder. Het lijkt me dat Microsoft er alles aan gelegen is om op zijn minst compatible te zijn.
Of bedoel je dat ze ES4 proberen te vertragen, omdat ze daar zelf nog niet klaar voor zijn?

[RobIII]

http://en.wikipedia.org/wiki/Ecmascript

Concreter:

quote: http://en.wikipedia.org/wiki/Ecmascript

ECMAScript is the name of the scripting language standardized in ECMA-262. Both JavaScript and JScript aim to be compatible with ECMAScript, while providing additional features not described in the ECMA specification.

The name "ECMAScript" was a compromise between the organizations involved in standardizing the language, especially Netscape and Microsoft. Brendan Eich, the creator of JavaScript, is on record as saying that "ECMAScript was always an unwanted trade name that sounds like a skin disease.

[Reactie gewijzigd door RobIII op 27 juli 2024 17:03]

[OpenMinded]

Welke regels?
Als het over leugens en bedrog gaat (FUD) dan heeft gezien de historie van het liegen en bedriegen van Microsoft de Mozilla ontwikkelaar ongetwijfeld VOLKOMEN gelijk.
Het klinkt precies als Microsoft om eerst geen kritiek te hebben en dan vervelend te gaan doen.
Ongetwijfeld wil men niet meewerken omdat ze het niet 100% zelf onder controle hebben.
En als er iemand zijn grote scheur moet houden over backward compatibility zijn het die prutsers bij Microsoft wel. Tot op de dag van vandaag geen fatsoenlijk OS of browser gebouwd die goed backward compatible is (zoals bijvoorbeeld een recent Apple of Linux OS) en ook nog eens NIETS volgens standaarden bouwen.
IE 6 en 7 kunnen niet eens fatsoenlijk een standaard pagina renderen en dan nu al over Javascript beginnen?
Volgens mij is het in ieders belang dat er met standaarden gewerkt wordt, met name voor de ontwikkelaars.
Wat ik overigens even mis is een relatie met W3C.
Zou het niet handig zijn als zij er iets over roepen?

Ik kan niet wachten op de dag dat iedereen de rommel van Microsoft die niet voldoet aan standaarden keihard laat vallen vor alternatieven.
Dan zijn ze heel snel complient.
Ter info: Microsoft moest zo nodig zijn eigen implementatie weer maken en degene die de standaard zou moeten bepalen is de ECMA:
http://nl.wikipedia.org/wiki/JavaScript

[mOrPhie]

Ecma is een standaarden-organisatie. Meer standaard kun je niet.

[Verwijderd]

Bah ik vind het nu al irritant dat ik rekening moet houden met verschillende browsers als ik wat in Javascript maak, en zit er absoluut niet op te wachten om alles twee keer te chrijven in verschillende variaties.
Standaarden zijn niet voor niets standaarden. Het feit dat microsoft daar schijt aan heeft zorgt voor de problemen.

Voorbeeld:
In CSS heb je de de mogelijkheid cursors aan te passen, met (hoe toepasselijk)
cursor: type;
Nu heb je het type genaamd pointer en daarmee krijg je zo'n klik hand met gestrekte wijsvinger. Die grapjassen van microsoft hebben bedacht om dat zelfde klaar te spelen met cursor: hand;. Dat lijkt handig, maar is dus verrot, want er zijn veel voorbeeld dingen op internet waarbij lui hand gebruiking ipv pointer. Hierdoor leren anderen het verkeerd aan en krijgen mensen met andere browser dan IE niet juiste pagina's.

En wat boeit een cursor dan denk je, maar er zijn legio andere situaties, probeer maar een de x en y coordinaten van de muis met javascript te pakken te krijgen. Wordt helemaal leuk als je in een pagina met scrollbar zit.

[Verwijderd]

Het is zo makkelijk om anti Microsoft te zijn.

Laat ik het eens anders zeggen. Microsoft is met IE al jarenlang de onbetwiste marktleider. Marktleider wil zeggen dat je wat in de melk te brokkelen hebt.

Als er dan allerlei veel kleinere organisaties willen proberen de reus hun eigen standaarden op te leggen, dan is het vrij logisch dat die reus daar soms tegenin gaat.

Ik kan ook wel een standaard in het leven roepen die voorschrijft dat gloeilampen ovaal moeten zijn in alle richtingen en dan zal niemand roepen dat Philips zo'n rotbedrijf is omdat ze die standaard niet volgen.

Het is al erg goed van Microsoft dat ze zoveel meewerken met standaarden. Sure ze wijken er ook wel eens vanaf, maar ja, IE is hun product en iedere fabrikant staat het vrij om een product te maken zoals hij/zij dat zelf wil. De consument kan dan kiezen wat hij wil gebruiken.

De hele standaardendiscussie als het over browsers gaat, is gewoon raar. Verplaats die discussie in welke andere technische sector dan ook, en men ziet in hoe ridicuul hij is.

[Maestro]

Je vergelijking gaat wat mij betreft mank. Stel je maar eens voor dat Philips eenzijdig besluit om de fitting niet meer aan de E27 norm te laten voldoen, maar een eigen E24 norm verzint.

Dat zal als resultaat hebben dat elke armatuurfabrikant een convertor mee moet leveren. En ik geloof niet dat je de armatuurfabrikanten daar blij mee maakt, de consument verwacht nl. wel in jouw armatuurtje een lamp van de marktleider te plaatsen. Het wordt nog ernstiger als de nieuwe E24 fitting tot gevolg heeft dat E27 lampen niet meer goed werken.

(E27 is de naam voor het grote type schroeffitting op lampen)

[bl0m5t3r]

het enige is dat E27 nog geen standaard was toen philips bedacht om E24 te gebruiken. en philips zelfs E24 als standaard heeft aangeboden, maar dit helaas heeft verloren.

ik denk dat iets in die ruwe lijn met jouw verhaal erbij wat meer naar de werkelijkhied toe komt. zoals het hierboven beschreven "wilden westen" (paar reacties terug), is er flink door ontwikkeld en niet gewacht op standaarden, met alle gevolgen van dien. op dit moment is iedereen weer naar elkaar toe aan het groeien, gelukkig maar.

moet dit even kwijt als toevoeging op jouw reactie, en ben zelf zelfs een vervent mozilla aanhanger. doch enige nuance naar microsoft leek me hier gepast.

[Verwijderd]

De consument kan dan kiezen wat hij wil gebruiken.

daar zit het hem net. de consument wilt gewoon gebruiken wat hij heeft en wat werkt. microsoft speelt hier heel handig op in en levert zijn IE mee met windows. waardoor IE op een onnatuurlijke manier groot is geworden (en blijft).

op zich, het feit dat mozilla nog zoveel gedownload wordt, geeft aan dat IE wel degelijk niet in de smaak valt bij de gebruikers. anders zouden deze geen moeite doen om het te vervangen!

moraal van het verhaal: als IE appart verkocht zou worden, of er gewoon een downloadlink op de bureaublad zou staan van zowel IE als FF, zou IE al lang geen marktleider zijn geweest. maar natuurlijk, dan heeft de consument ECHT keuze, en kiest hij wat hij het beste acht. in de meeste gevallen is dit FF...

dus alvorens te roepen dat microsoft maar het arme bedrijf is dat elke keer op zijn kl*** krijgt omdat ze de standaarden niet volgen, wanneer dit "perfect normaal" is. stel je voor dat NVIDIA spontaan beslist om een andere versie van PCI-E te maken. en vervolgens verbiedt aan andere voor dit uit te werken. aangezien heel veel mensen NVIDIA kaarten hebben en geen ATI (waaronder ikzelf) zullen er dus een heleboel mensen gedwongen worden over te stappen naar hun nieuwe PCI-E poort. en alle andere beeldkaarten zullen niet werken op deze mobo's.
DAT is exact wat microsoft doelt met zijn "eigen standaarden" (wat tevens in naam fout is, want als jij de engiste bent die je tech gebruikt, is het geen standaard).

@SMa
op zich is het geen probleem om de MS standaarden in het even wat te implementeren. zelfs solaris zou dit in theorie kunnen.
microsoft maakt het probleem door moeilijk te doen en perfect functionerende talen persee moet vervangen met zijn eigen implementatie (die eigelijk hetzelfde doet en alleen maar zorgt voor meer werk voor de ontwerpers).

het is trouwens niet aan de browsermakers om te bepalen wat de volgende standaard gaat zijn, hier hebben we standardizatiebureau's voor. het is wel aan de browsermakers om de huidige standaarden te volgen.

stel je voor dat je voor safari, FF, opera, konqueror, netscape, IE, links, lynx enz enz allemaal appart zou moeten programmeren. daarvoor hebben we deze standaarden. VOLG ZE DAN OOK!!!

[Verwijderd]

Zo had ik het nog nooit bekeken!
En je hebt idd wel een punt, het is niet aan de kleintjes om de reus iets op te leggen.

Microsoft's standaarden werken in feite evengoed als de algemeen aanvaarde standaarden, het is gewoon een probleem om ze samen te laten werken.

[Neko Koneko]

Het punt is echter, de standaarden die MS gebruikt moeten niet alleen goed zijn, maar ook open zodat anderen ze ook kunnen gebruiken. Ik denk persoonlijk dat daar een groot deel van het probleem ligt.

[7.01D]

Het is zo makkelijk om anti Microsoft te zijn.

Ze maken het inderdaad wel erg makkelijk

[RobIII]

De voorbeelden die je noemt hebben geen drol met ECMAscript te maken maar met de DOM implementatie (x/y coords) / CSS implementatie (hand/pointer).

Daarnaast is (bijvoorbeeld) het "hand/pointer probleem" enkel een probleem voor mensen die zich baseren op uitspraken van "nitwits", ofwel niet de officiële instanties/documentatie. Eigen schuld als je dan dat advies opvolgt en het blijkt later niet (meer) te werken.

[Reactie gewijzigd door RobIII op 27 juli 2024 17:03]

[Verwijderd]

het punt wat ik wil maken is dat ik ervan schijt dat er van standaarden wordt afgeweken. Dan moet je met die irritante checks komen om die incompatibilities op te lossen.

En vaak genoeg kom ik sites tegen die gebaseerd zijn op uitspraken van "nitwits". Die nitwits heb je niet als iedereen zich aan de standaard houdt.

Nog een voorbeeld:
http://www.w3schools.com/htmldom/met_select_add.asp

[RobIII]

Sure; er zijn wat verschillen. Dat heeft ook te maken met de explosieve groei die 'het web' in een bepaalde periode heeft doorgemaakt. Als je dan als browser-vendor (ik heb het niet specifiek over IE/FF/Whatever) een beetje voorop wil liggen kan ik me voorstellen dat je zo nu en dan wat implementeert voordat een logge organisatie er z'n goedkeuring over heeft gegeven. Dat kan soms jaren duren, terwijl je god-weet-hoeveel lui hebt die zeuren dat ze het nu willen hebben/gebruiken. Daarnaast stammen de meeste "ernstige" verschillen uit die betreffende "wild-west" tijd en is er de laatste tijd steeds meer verbetering op dat vlak bij alle(!) browservendors. Mijn punt is: iedereen is er schuldig aan. De browservendors die afwijken van de standaarden, de gebruikers/developers die dingen verkeerd implementeren en features "misbruiken" waar ze niet voor bedoeld zijn etc.

Ik word ook niet vrolijk van verschillen of implementaties die van standaarden afwijken. Maar het is allemaal niet zo wereldschokkend dat er een complete 'oorlog' over moet ontstaan bij iedere scheet waar het gaat over een item dat iets te maken heeft met browsers / internet / standaarden / etc. Daar word ik persoonlijk veel moeier van.

Overigens is jouw aangehaalde probleem prima zonder browserhacks te doen:


var option = createElement('option');
dropdown.appendChild(option);

Voila.

[Reactie gewijzigd door RobIII op 27 juli 2024 17:03]

[Little Penguin]

het punt wat ik wil maken is dat ik ervan schijt dat er van standaarden wordt afgeweken. Dan moet je met die irritante checks komen om die incompatibilities op te lossen.

Als je er problemen mee hebt zul je zelf over moeten stappen naar een standaard-compliant browser (stemmen met je voeten) en daarnaast zo veel mogelijk mensen in je omgeving ook over moeten laten stappen.

Microsoft gaat de standaarden echt volgen...


...als ze merken dat het niet-volgen van deze standaarden hun significant marktaandeel kost.

[alienfruit]

Maar Microsoft kan toch ook gewoon de Tamarin implementatie van ECMAScript 4 gebruiken? Hebben ze al helemaal geen implementatie verschillen Tja, dat het niet backward compatible is... Lekker belangrijk

[Little Penguin]

ECMAScript is wel backwards compatible met ES3 dus dat is geen issue.

Microsoft kan/wil geen gebruik maken van Tamarin en heeft blijkbaar te weinig geld om voor een update van de JScript engine die in IE gebruikt wordt te zorgen.

Och arme Microsoft, we zouden medeleiden met je moeten hebben

[crisp]

Och, dan hebben we altijd nog ScreamingMonkey; een ES4 script-engine plugin voor browsers als IE

[joho]

Mijn mening, en natuurlijk geheel niet te bewijzen, is dat het Microsoft niet om vooruitgang in J/ECMA/Java-script te doen is maar om de vooruitgang van anderen te frustreren zodat de eigen alternatieve technologie (.NET / silverline / XAML) er in vergelijking beter uit gaat zien. Dus dat ze jaren niets doen lijkt mij dus geen toeval, dat komt juist goed uit.

[Verwijderd]

Ik denk dat dit ook nog wel eens te maken kan hebben met Microsofts plannen met de Silverlight plugin. Dat moet de grote flashkiller worden en flash is meen ik 100% ECMAScript compatible. Of zeg ik nu iets raars?

[Leftblank]

ECMAScript is overigens wat de meeste mensen 'Javascript' noemen, dit is niet helemaal duidelijk in 't artikel. Op dit moment wordt dus over 't algemeen ECMAScript v3 gebruikt, wat al weer uit 1999 stamt.

Overigens staat op Wikipedia een mooie lijst met nieuwe features/verbeteringen t.o.v. de huidige scripts, het lijkt op 't eerste gezicht een mooie uitbreiding te zijn door meerdere features standaard te ondersteunen, zoals JSON encoding.

[CrashOne]

Volgens mij is dat niet helemaal waar, JavaScript is net als JScript en Actionscript gebaseerd op ECMAscript en zijn dus niet het zelfde.

Verder erg jammer we straks mogelijk weer een drempel erbij krijgen om "nette" websites te maken.

[Verwijderd]

Microsoft is begonnne met JScript als antwoord op JavaScript van Netscape, wat begin jaren '90 de de facto standaard scripttaal werd binnen browsers. ECMAScript is een standaard, die de 'basis' van beide talen beschrijft, maar het is dus een interface, geen implementatie.

Het klopt daarom wel degelijk om te zeggen dat ECMAScript is wat de meeste mensen 'javascript' noemen, omdat Javascript de naam was van de taal waar het allemaal mee begonnen is, en omdat de meeste mensen niet weten dat JScript en Javascript eigenlijk 2 verschillende implementaties zijn van ECMAScript.

[2playgames]

Dus als ik het goed begrijp is het zo: Als je ECMAScript met Java vergelijkt, dan is
Java = ECMAScript
Java standaard class library + JRE = Javascript/JScript

[Herko_ter_Horst]

Je bent niet erg precies met je terminologie, waardoor deze vergelijking meer vraagtekens oproept dan dingen duidelijk maakt.

Als je al een vergelijking wilt/kunt maken, dan is ECMAScript meer vergelijkbaar met de (verzameling) JSR(s) die bijvoorbeeld Java Standard Edition beschrijven. JavaScript en JScript zijn dan vergelijkbaar met bijvoorbeeld de JREs van Sun en IBM die die standaard implementeren.

De verschillen zitten dan in de implementatie: sommige Java programmeurs maken gebruik van classes uit de com.sun.* of sun.* packages die met Sun's JRE worden meegeleverd (ondanks waarschuwingen om dit niet te doen). Die classes zul je in IBM's JRE niet aantreffen, waarmee je Java programma dus incompatible wordt met die JRE. Dit is vergelijkbaar met de extra features van JavaScript c.q. JScript.

[Little Penguin]

Dus als ik het goed begrijp is het zo: Als je ECMAScript met Java vergelijkt, dan is
Java = ECMAScript
Java standaard class library + JRE = Javascript/JScript

Nee.

ECMAScript is een (vrijwel geheel geslaagde) poging om tot 1 standaard te komen die door diverse browsers begrepen wordt. Hierbij heeft men de features die in JavaScript (ontwikkeld door Brendan Eich van Netscape/Mozilla) en van JScript (de kloon hiervan) duidelijk beschreven en er her en der een uitbreiding op gemaakt.

Uiteindelijk hebben zowel Microsoft als Netscape/Mozilla (en Opera en Apple e.d.) hun implementaties zodanig aangepast/geschreven dat alle moderne browsers in staat zijn om ECMAScript te interpreteren.

Vergelijking met Java of andere talen is hier dus niet van toepassing en maakt het ook niet duidelijker, zoals hierboven ook omschreven staat...

[jochemd]

Actionscript (AS, de scriptingtaal van Flash) is een beetje een verhaal apart.

Versie 2 van Actionscript was losjes gebaseerd op de ECMAscript standaard met een heleboel aanpassingen en uitbreidingen (zoals de jscript en javascript implementaties van Mozilla en Microsoft). Bij de introductie van ActionScript 3 heeft Adobe echter besloten om standaard compliance zwaarder te laten wegen dan backward compatibility. AS3 is voor de volle 100% ECMAscript. Features die in AS2 zaten maar niet in de ECMAscript standaard zijn uit AS3 gehaald.

[JeanJeremy]

Ik heb een jaartje Tibco adapters gebouwd op basis van ECMAscript en ik kan je vertellen dat dat een stuk beperkter is dan javascript. Al moet ik toegeven dat ik niet weet of dat ECMA v3 was

[Verwijderd]

het lijkt op 't eerste gezicht een mooie uitbreiding te zijn door meerdere features standaard te ondersteunen, zoals JSON encoding.

Het likt me pas mooi als dit wordt doorgevoerd:
http://www.whatwg.org/specs/web-forms/current-work/

[Michali]

Dat heeft er direct toch niet zo veel mee te maken? Misschien heeft het enkele uitbreidingen met betrekking tot de DOM waarmee het een en ander te manipuleren is, maar een echte uitbreidingen aan de taal JavaScript is het niet. Het is ook meer een uitbreiding of extensie van HTML.

Hoe dan ook, ik zou er idd. ook zeker blij mee zijn als dit eenmaal geïmplementeerd is.


@Aesar:

HTML5 van whatwg ben ik ook wel positief over. Ik ben benieuwd hoe dat gaat vorderen. Iets wat ik ook wel graag geïmplementeerd wil zien zijn server events naar de browser toe. Opera ondersteund dit al, je kunt er hier wat meer over lezen:

http://my.opera.com/WebApplications/blog/show.dml/438711

Heel handig voor AJAX applicaties. Je kunt dan bijvoorbeeld je GUI laten updaten als er iets gewijzigd is op de server, zonder dat je de hele tijd hoeft te pollen.

[Reactie gewijzigd door Michali op 27 juli 2024 17:03]

[mrFoce]

Betekend dit dat we straks (naast de verschillende CSS bestanden) ook verschillende .JS bestanden zullen krijgen Wordt steeds lastiger om een website te maken die op alle browsers hetzelfde werkt (als iedereen z'n eigen standards blijft ontwikkelen)

[Reactie gewijzigd door mrFoce op 27 juli 2024 17:03]

[aikebah]

Nee hoor, die krijg je niet... anders had je ze nu al... je hebt gewoon de mazzel dat je met je javascript nog niet bent aangelopen tegen de verschillen.

[ZpAz]

Nu heb je ook af en toe dingen die verschillend uitpakken als je JS gebruikt in diverse browsers.

[Little Penguin]

De grootste verschillen zijn niet zozeer het gebruik van ECMAScript (JavaScript in normale mensentaal).

Het probleem waar je vooral mee te maken hebt, dat is het niet compatible zijn van de gebruikte DOM en Event modellen. Microsoft heeft sinds 2001 niets meer gedaan om deze beter te ondersteunen - waardoor er uiteindelijk 2x code geschreven moet worden (een keer voor de DOM die door alle browsers, muz IE, begrepen wordt en een keer voor IE...)

Overigens geldt hetzelfde bij CSS, ondanks het feit dat Microsoft honderden miljoenen dollars in kas heeft is het bedrijf niet in staat om een browser te maken die aan de standaarden voldoet.

Helaas moet MS gedwongen worden en men zal de standaarden alleen gaan implementeren als ze gedwonen worden door de consument...

[Kiphaas7]

Het is al langer bekend dat MS zijn "eigen" standaarden mbt tot bijvoorbeeld layout rendering had voordat de w3c voorschriften duidelijk van de grond kwamen. IE heeft nog altijd de 2 verschillende gedragsprotocollen die kunnen worden aangeroepen met een correct (of incorrect) doctype zoals je waarschijnlijk wel weet. Ze konden destijds niet ineens die oude eigen standaard laten vallen omdat ze dan een heleboel websites zouden "kapotmaken".


Dat ze in de "goede" mode nog altijd fouten hebben zitten is inderdaad onbegrijpelijk, maar enige nuancering is wel nuttig bij je post....

EDIT: Heeft niks met ECMAscript te maken, meer dat ik nuancering nodig vond.

[Reactie gewijzigd door Kiphaas7 op 27 juli 2024 17:03]

[crisp]

Het is voor MS ook veel interessanter om hun eigen proprietary technologieën te promoten, daarom wordt er ook nauwelijks tijd en geld gestoken in het fixen van hun implementaties van open standaarden maar destemeer in de ontwikkeling van eigen technologieën. Daarnaast proberen ze met leugens en FUD huidige standaardisatie-processen zoveel mogelijk te frustreren.

Zie onder andere ook Brendan Eich's antwoord op Microsofts voorstel voor een "minimalist approach" mbt uitbreiding/verbetering van ECMAScript (meer in de vorm van een maintenance 3.1 release dan een compleet nieuwe versie):

One interpretation of your efforts here, in all charity, is that your employer wishes to handicap the standardized Web. As I keep saying, this is not relevant to ECMA TG1’s deliberations.

[Jaco69]

Als dat zo is moeten sommige maar eens stoppen met MS internet explorer te ondersteunen i.p.v. iedereen die geen MS IE heeft weg te sturen.

[Cameleon73]

Probleem is dat IE een middel is, en geen doel. Het doel is om mensen je site te laten gebruiken ... waardoor je gedwongen wordt om IE6 (of soms nog *huiver* IE5) te ondersteunen.

[Little Penguin]

Als dat zo is moeten sommige maar eens stoppen met MS internet explorer te ondersteunen i.p.v. iedereen die geen MS IE heeft weg te sturen.

Het probleem is dat je als website bouwer het niet kunt maken om (meer dan) 50% van je bezoekers weg te jagen.

Toch moet ik toegeven dat voor de sites die ik zelf af en toe maak ik inderdaad al wel sterk na aan het denken ben om gebruikers van IE6 een 'upgrade to Firefox' button aan te bieden en de site sterk versimpelt of zelfs helemaal niet te tonen.

Browsers van voor 2001 ondersteun ik zo-wie-zo niet meer, dus Netscape 4, IE 5.5 gebruikers hebben dan pech.

Overigens zul je bij ECMAScript 4 ook nog lange tijd gedwongen zijn om dezelfde functionaliteit ook in een ES3 editie aan te bieden, hierbij maakt het niet uit of MS nu wel of niet mee gaat werken t.o.v. ES4.

Pas als meer dan plm 90% van de gebruikers overgestapt is op een ES4 compliant browser hoef je geen zorgen meet te maken op de ondersteuning t.o.v. ES3...

[Michali]

Dit conflict is juist ontstaan omdat verschillende partijen hun best doen om alles zo goed mogelijk samen te laten werken. Dat er dan af en toe een onenigheid ontstaat lijkt me wel logisch. Het is dan wel te hopen dat ze wel tot een oplossing komen, want dit soort gesteggel zal, denk ik, niet bepaald positief uitpakken voor de mensen die er later mee moeten gaan werken. Wel is het gelukkig zo dat de browsers steeds meer dezelfde standaarden zullen gaan ondersteunen, dus erger dan de huidige situatie zal het niet worden.

[Verwijderd]

Zolang beide partijen backwards compatible blijven naar zichzelf, kan het niet lastiger worden om bestaande features te gebruiken. Het zou alleen jammer zijn als partijen hun eigen standaard blijven handhaven voor nieuwe features, want dat maakt ze veel minder bruikbaar...

[i-chat]

die hebben we al heel lang,

om maar wat termen erin te gooien Document.contairer en dergelijken ...

we zijn al jaren bezig om te checken wel brouwser er word gebruik om op basis daarvan, dingen weer te geven of functies een klein beetje aan te passen...

ik ben zelf geen webguru maar heb bijv wel eens sites gezien die naasst verschillende templates style sheets en JS-code zelfs nog eens verschillende imapges gebruikte >> IE had GIFjes en Gecko krijg PNGtjes.

[xaddict]

Het valt toch wel op hoe geweldig Microsoft het niet vind standaarden te doorbreken.

Ze houden zich niet aan css1, maar voegen scrollbar functies toe, ze houden zich niet aan css2, voegen functies toe EN ondersteunen het niet volledig. Ze ondersteunen het canvas-gedeelte niet (wel ondersteund door firefox, opera, netscape, safari, etc. Misschien dat IE for mac het wel ondersteund aangezien het de enige standards-compliant browser is die Microsoft ooit heeft laten bouwen).

Ze ondersteunen grote implementaties van web2.0/readwriteweb niet (vooral de problemen omtrent Flex en FlashLite op bijvoorbeeld Windows Mobile vallen op), ze ondersteunen het correcte box model niet, maar verzinnen hun eigen. ze verzinnen eigen javascript en css filters (Blur, Glow, etc.) en nu weigeren ze mee te gaan met een nieuwe standaard Ecma. Volgens mij gaat microsoft op het browser-gebied een pijnlijke dood tegemoet als ze niet snel iets doen aan hun gezeik tegenover mensen die pioniers zijn in standaardisatie.

[Verwijderd]

maar jij hebt geen standaard gemaakt, bent geen speler in de browsermarkt, hebt geen vestand van zaken...

als de juiste persoon op de juiste moment met het juiste idee komt, DAN kan er een standaard van komen.

tevens, er is nooit 1 persoon die de standaard "goedkeurd", dit is altijd wel een team of commisie. en deze hebben wel verstand van zaken.

[Verwijderd]

microsoft had volgens mij niet al te lang geleden zich voorgenomen om compatibility te verbeteren en zich beter te comformeren aan standaarden.

en wat doen ze vervolgens, gaan gewoon de oude weg verder en frustreren de zaak weer.

er is maar een oplossing, massaal stoppen met IE gebruiken zodat men zich ook niet meer genoodzaakt voelt om te conformeren met microsoft troep.

[Verwijderd]

microsoft zegt dan ook het ene, en doet het andere.

verdeel en heers......

wat leer je hier nu uit? microsoft (en eigelijk vele andere bedrijven, maar dit doet er niet toe op deze moment) valt niet te vertrouwen of te geloven. het is nog steeds een commercieel bedrijf, en deze zijn alleen uit op winst (niet alleen microsoft is zo, maar deze neemt wel heel aggresieve/achterbakse tactieken om de markt te "veroveren")

in a sense, dit is slechts een gevolg van kapitalisme.....