W3C: HTML Working Group gaat werken aan 'html6'
De W3C laat weten dat het een tweede last call heeft afgekondigd voor het goedkeuringsproces van de html5-standaard. Daarnaast zal de HTML Working Group zich gaan richten op de ontwikkeling van de opvolger 'html6'.
De eerste last call werd in mei vorig jaar uitgegeven. Daarin konden deelnemers hun op- en aanmerkingen geven op de html5-standaard. Door middel van een last call-ronde kunnen de laatste struikelblokken worden weggenomen, aldus de W3C. Op zijn blog laat de organisatie nu weten dat het een tweede last call zal instellen, omdat er veel inhoudelijke wijzigingen zijn voorgesteld. Daarnaast zoekt de W3C kandidaten die html5 en de aanvullende html canvas 2d-standaard naar een uiteindelijke officiële specificatie willen begeleiden.
Naast het traject voor de ratificatie van html5, zal de W3C de HTML Working Group, die aan de wieg stond van de html5-standaard, een nieuwe opdracht geven. Zij zullen gaan werken aan de opvolger van html5 die mogelijk onder de naam 'html6' zal worden ontwikkeld.
Volgens de W3C is er grote vooruitgang geboekt met de implementatie van html5. Ook zou de webstandaard al op grote schaal op de internetmarkt worden benut. Het is echter nog steeds niet duidelijk wanneer html5 de status zal krijgen van een officiële webstandaard.
Reacties (106)
Zelf zie ik HTML5 toch niet veel gebruikt worden als ik eerlijk moet zijn. Kom vooral omdat o.a. IE lak aan support heeft... Dit zal bij HTML6 net zo zijn.
Denk dat dit wel gaat veranderen als het dadelijk de officiële standaard wordt dan moeten ze wel anders dan zal iedereen een andere browser nemen die wel aan hun wensen voldoet.
Iedereen overstappen? Weet je hoeveel mensen nog IE6 gebruiken?
Dat is wel aardig op zijn retour, bij ons in de google analytics is het nog maar een % of 3 van het totale verkeer.
7,1% wereldwijd, grootste aandeel licht in China.
Je moet kijken naar je doelgroep: voor Nederlandse websites is het bijvoorbeeld slechts 1 procent. Overigens komen al deze statistieken van deze website. De bron van deze website is dan weer een website (NetApplications) die - lijkt mij - veel door bedrijven bezocht worden en daar is upgraden van software vaak een probleem (veiligheid, compatibility etc.): het zou dus best kunnen dat het echte gemiddelde in Nederland nog lager ligt.
[Reactie gewijzigd door Xirt op 24 april 2012 23:18]
Weet je hoe oud IE6 is? Er is nog ongeveer 9 procent van de internet gebruikers die IE6 gebruikt, veelal geforceerd door corporate policy of gebrek aan licentie (China met pirated software).
Gebruikers moeten overstappen naar IE9 of Chrome of Firefox. Dit helpt de vooruitgang van het Internet enorm. Hoeveel tijd ik besteedt als Web developer aan IE7/8 problemenen is gewoon triest. Maar je kunt je klanten/bezoekers geen baggerwebsite laten zien....
Gebruikers moeten overstappen naar IE9 of Chrome of Firefox. Dit helpt de vooruitgang van het Internet enorm. Hoeveel tijd ik besteedt als Web developer aan IE7/8 problemenen is gewoon triest. Maar je kunt je klanten/bezoekers geen baggerwebsite laten zien....
En daarbij draag je rechtstreeks bij tot de reden waarom mensen nog niet onmiddellijk overstappen... (jammer genoeg overigens)
Bij ons in het bedrijf hebben ze ondersteuning voor IE7 en deels IE8 al geschrapt. We gebruiken zoveel mogelijk CSS3 dus websites kunnen er ook nog hoekig uitzien in IE8. So what. Als het maar werkt. Dus de oude browsers worden al uitgefaseerd.
Precies, dat is de manier. Het is ook niet nodig om een website exact hetzelfde er te laten uitzien. En ook het gezeur dat je klanten verliest wanneer je niet op IE gebruikers richt is ook een commercieel neuzel verhaal. Dat was misschien in het begin zo maar dat is nu allang niet meer zo.
Wil je goed kunnen surfen, heeft de gebruiker een goede browser nodig. En hoe kun je de gebruiker laten zien dat je een goede browser nodig hebt? Door ouwe meuk niet meer 'speciaal' te ondersteunen. Dan pas ziet de gebruiker de noodzaak eens te gaan upgraden. Als elke dev dat doet, moet jij eens kijken.
Dus stoppen met de hacks (speciaal voor IE) zoals CSSPie en dat soort spul. Niet ondersteunen van oude versie scheelt bovendien bakken met ontwikkelgeld, ook een goede reden.
Wil je goed kunnen surfen, heeft de gebruiker een goede browser nodig. En hoe kun je de gebruiker laten zien dat je een goede browser nodig hebt? Door ouwe meuk niet meer 'speciaal' te ondersteunen. Dan pas ziet de gebruiker de noodzaak eens te gaan upgraden. Als elke dev dat doet, moet jij eens kijken.
Dus stoppen met de hacks (speciaal voor IE) zoals CSSPie en dat soort spul. Niet ondersteunen van oude versie scheelt bovendien bakken met ontwikkelgeld, ook een goede reden.
Ben ik het volledig mee eens.
De vraag is alleen hoe je dat naar de klant toe kan verkopen, die wil natuurlijk dat iedereen zijn/haar hippe website volledig kan gebruiken/zien zoals het bedoelt is.
De vraag is alleen hoe je dat naar de klant toe kan verkopen, die wil natuurlijk dat iedereen zijn/haar hippe website volledig kan gebruiken/zien zoals het bedoelt is.
... natuurlijk ...
Je moet niet meer wensen op je klanten projecteren dan ze echt hebben.
Uiteindelijk is het maar net hoe je het ze verkoopt.
OT:
Ik kan zo eigenlijk niet bedenken wat ik graag in v6 zou willen zien.
Hehe, zodra het komt zal ik me wel weer afvragen waarom die functies niet eerder toegevoegd waren.
Je moet niet meer wensen op je klanten projecteren dan ze echt hebben.
Uiteindelijk is het maar net hoe je het ze verkoopt.
OT:
Ik kan zo eigenlijk niet bedenken wat ik graag in v6 zou willen zien.
Hehe, zodra het komt zal ik me wel weer afvragen waarom die functies niet eerder toegevoegd waren.
Je moet niet meer wensen op je klanten projecteren dan ze echt hebben.
Uiteindelijk is het maar net hoe je het ze verkoopt.
Precies.
Uiteindelijk is het maar net hoe je het ze verkoopt.
Precies.
Dit is natuurlijk een variatie op de 80/20-regel. Bij ons op het werk is het design-team volledig onafhankelijk van de webdevelopers, en dan ook nog eens semi-onafhankelijk van de business. Dit brengt situaties teweeg waar het design tjokvol rounded corners, box-shadows en andere fancy elementen zit, de business keurt dit goed maar eisen compatibiliteit met IE6+ en als designteam mag je dat dan proberen rechttrekken.
weet je hoeveel mensen nog een computer hebben van 15 jaar oud?Iedereen overstappen? Weet je hoeveel mensen nog IE6 gebruiken?
Mijne is bijna 10. (Dual Xeon.) Die doet zonder problemen Firefox 12.
En dan nog... ik vind dat mensen die IE6 gebruiken zich er wel bewust van mogen zijn dat ze niet het optimale uit het internet kunnen halen.
Ik vind dat mensen in een rolstoel er van bewust gemaakt mogen worden dat ze niet het optimale uit het leven kunnen halen. Dus laten we vooral geen rolstoel-oprit maken. Dat scheel bouwkosten en ach, het kost een paar procent bezoekers, maar mijn mening mag best wat kosten 
Een belangrijk verschil is dat bijna niemand ervoor kiest om op een rolstoel te gaan zitten terwijl de browserversie die je gebruikt wel een keuze is.
er is een hele grote groep die zich niet bewust is van die keuze hoor... voorbeeld: mijn moeder weet het verschil niet tussen internet explorer en het internet. Ze denkt dat het internet een programma is. Sowieso weten velen niet dat websites er soms mooier uitziet op een andere browser of dat ie sneller laadt. Laat staan dat ze rekening houden met de extra ontwikkelingskosten die een vintage browser ondersteunen met zich meebrengt...
Volgens mij zie je het verkeerd om. Voor heel veel normale mensen (wij tweakers uitgezonderd dus) is het Internet die blauwe e. Waarom een andere browser? Deze doet het toch? Dat is allemaal te lastig. En zo lang er in de statistieken van webpagina's die blauwe e met een groot marktaandeel voorkomt, zullen de bouwers ervan geen code toepassen die niet loopt binnen die blauwe e. Je gaat je klanten immers niet wegjagen. En als de bouwers het toch doen, dan worden ze al snel door de eigenaren van de sites ingeruild door bouwers die wel bekwaam zijn en bouwen voor de browser van hun doelgroep.
Je wil niet weten hoeveel mensen al zijn overgestapt op Google Chrome. Echt niet alleen tweakers maar juist ook gebruikers met PC's van 4 jaar of nog veel ouder. Waarom? Heel eenvoudig omdat die vele malen sneller is dan IE.
Dus juist voor de IE6 gebruikers is dit een laagdrempelige overstap met onmiddellijk al het snelheidsvoordeel. En met Chome is meteen ook HTML 5 aan boord.
Dus juist voor de IE6 gebruikers is dit een laagdrempelige overstap met onmiddellijk al het snelheidsvoordeel. En met Chome is meteen ook HTML 5 aan boord.
Er is maar 1 (vzviw) officiele HTML standaard: ISO HTML. Wat veel mensen "standaard" noemen is in W3C taal een "recommendation", een aanbeveling, niets meer en niets minder.
een webstandaard zodat je weet dat het in iedere browser hetzelfde uitziet met uitzonderingen daar gelaten "fluistert iets met IE"Er is maar 1 (vzviw) officiele HTML standaard: ISO HTML. Wat veel mensen "standaard" noemen is in W3C taal een "recommendation", een aanbeveling, niets meer en niets minder.
heeft voornamelijk te maken met het feit dat HTML5 nog niet 100% goedgekeurd is en het dus nog geen standaard is... Tuurlijk, je zal altijd verschillen houden tussen hoe de browsers de standaard interpreteert.
Klopt maar als het dadelijk standaard wordt dan zal het een stuk minder worden met uitlijnen van div's enz enz.
Duurt nog wel jaar of 6 - 10 hoor, voordat het overal gemeengoed is, zie bv IE6 en hoe lang dat nog gebruikt werd (in het bedrijfsleven, overheid, etc)
Zeg maar gerust hoe lang IE6 nog gebruikt wordt, vooral bij de (armere) instituten is dit gewoon helaas nog steeds de standaard browser.. Vaak wordt installatie van andere browsers niet toegelaten, of de computers aldaar trekken het gewoon niet
Hey jongens wakker worden! Wereldwijd staat IE6 op 0.5% in Nederland zelfs nog lager, IE7 op 2%.
Ik ontwikkel al zeker 2 jaar cross browser websites in html5, je moet gewoon goed opletten wat je wel en niet gebruikt en hoe je missende functionaliteit opvangt, ie6 kun je echt vergeten.
Ik ontwikkel al zeker 2 jaar cross browser websites in html5, je moet gewoon goed opletten wat je wel en niet gebruikt en hoe je missende functionaliteit opvangt, ie6 kun je echt vergeten.
7.1% nog, hoor.
http://www.ie6countdown.com/
http://www.ie6countdown.com/
natte vinger werk7.1% nog, hoor.
http://www.ie6countdown.com/
en die 7.1% is WW.. Met de grootste aantal in China.. Tenzij je chinese website ontwikkeld is het nog enigsinds de moeite maar voor de overige 99% totaal niet relevant meer
volgens StatCounter zit IE6 op 1.34%
http://gs.statcounter.com...-ww-monthly-201103-201203
http://gs.statcounter.com...-ww-monthly-201103-201203
Wereldwijd is het inderdaad 7.1%, waarvoor China bijna voor de helft verantwoordelijk is. Nederland en België zitten momenteel beiden aan 1.0%.
Slechts enkele sites van de overheid geven nog ondersteuning voor IE6 naar wat ik ervaar in mijn omgeving. Al de rest kijkt misschien eens snel hoe het er op IE6 uitziet, maar gaat niet voor 100% werking vanwege te weinig "return on investment".
Slechts enkele sites van de overheid geven nog ondersteuning voor IE6 naar wat ik ervaar in mijn omgeving. Al de rest kijkt misschien eens snel hoe het er op IE6 uitziet, maar gaat niet voor 100% werking vanwege te weinig "return on investment".
[Reactie gewijzigd door Glodenox op 24 april 2012 21:43]
Wij ontwikkelen voor min. IE8. Alles daaronder negeren wij. Jammer van die paar bezoekers. Die krijgen een nette melding middels een CSS popup.
Klanten die klagen dat een site niet zichtbaar is, leggen wij uit dat een browser uit 2001 (IE6) of 2006 (IE7) gewoon echt niet meer kunnen in het internet tijdperk anno nu. Niet alleen kwa standaarden, maar zeker ook kwa veiligheid!
Klanten die klagen dat een site niet zichtbaar is, leggen wij uit dat een browser uit 2001 (IE6) of 2006 (IE7) gewoon echt niet meer kunnen in het internet tijdperk anno nu. Niet alleen kwa standaarden, maar zeker ook kwa veiligheid!
Je kan vooral wel heerlijk werken met HTML 5 in Mobile Browsers 
Wat dat betreft zou het een keer mooi zijn als het W3C een reference browser zou maken. Die misschien niet echt snel is, maar wel 100% aan de geldende standaard voldoet. Als je browser daar dan van afwijkt, dan weet je dat je de standaard niet goed hebt geimplementeerd ... of je browser nu Chrome, Firefox of Opera, IE of Safari heet of dat je browser 99% van de markt in handen heeft of 0,1% dat maakt niet uit.
Die hebben ze al, maar is text-based 
Dan weet ik niet onder welke steen jij leeft. Als er iets heden dag belangrijk is geworden is het wel platform onafhankelijke software/diensten. Dit is mede te danken aan de wildgroei van os'en en devices. (bring your own device op werk/school) Ik kan het enkel toejuichen dat steeds meer leveranciers inzien dat IE/WIN only geen toekomst heeft. Wil je dat je product/dienst succesvol wordt? dan -moet- die platform onafhankelijk zijn. En wat vult dat gat op .... 
voor html5 en de ellende die het oplost
voor html5 en de ellende die het oplost
[Reactie gewijzigd door himlims_ op 24 april 2012 18:12]
Ben het helemaal met je eens, als web-developer heb je hier al heel veel aan als elke browser de standaard ondersteund dat scheelt je een hele hoop werk! en custom gerommel in je code.Ik kan het enkel toejuichen dat steeds meer leveranciers inzien dat IE/WIN only geen toekomst heeft. voor html5 en de ellende die het oplost
En toch zul je het moeten blijven controleren. Feitelijk zul je misschien minder (iets) custom code moeten schrijven, maar de controle zal (helaas) moeten blijven bestaan.
Daar twijfel ik ook zeker niet over.
Maar het stuk code dat je nu moet gaan knutselen zal een stuk minder zijn dan.
Maar het stuk code dat je nu moet gaan knutselen zal een stuk minder zijn dan.
Het gaat allemaal wel de goede kant op, maar je zult altijd met vertraging de verouderde browsers moeten supporten. Een aantal jaar geleden was het voor mij en menig webdeveloper nog standaard om rekening met IE6 te houden. Sinds meer dan een jaar of wat, is dat IE7. Over een aantal jaar zal het minimale IE9 zijn.
Het mooie is, dat hoeft lekker *niet*
Als software bouwer kan je zelf je eisen stellen. En met statistieken in de hand kun je zo naar de opdrachtgever toelopen, met een quote 'dit gaat het extra kosten om browsers van 10 jaar oud ook te ondersteunen, en dit gaat het extra kosten om IE8 ook aan de praat te krijgen.'
Meestal lost dat het probleem op, en zo niet krijg je iig betaald voor elk uur frustratie.
Verder, steeds meer apps zijn ontworpen om te werken op een tablet, of op een telefoon, of iig multi-device. Dat betekent ontwikkelen voor webkit based browsers, en daarmee sluit je IE 7 en 8 al snel uit
Als software bouwer kan je zelf je eisen stellen. En met statistieken in de hand kun je zo naar de opdrachtgever toelopen, met een quote 'dit gaat het extra kosten om browsers van 10 jaar oud ook te ondersteunen, en dit gaat het extra kosten om IE8 ook aan de praat te krijgen.'
Meestal lost dat het probleem op, en zo niet krijg je iig betaald voor elk uur frustratie.
Verder, steeds meer apps zijn ontworpen om te werken op een tablet, of op een telefoon, of iig multi-device. Dat betekent ontwikkelen voor webkit based browsers, en daarmee sluit je IE 7 en 8 al snel uit
@SchizoDuckie
Dan zeg de gemiddelde opdrachtgever het volgende: "Sorry maar we moeten je helaas teleurstellen dat we al een ander persoon hebben gevonden die het werk sneller en beter kan afhandelen."
Alle standaarden ondersteunen is een must bij alle werkgevers/opdrachtgevers wil je aangenomen worden er zijn namelijk wel tig anderen die wel alles ondersteunen zonder extra kosten of gedoe.
En als je alles in de html standaard schrijft op een juiste manier dan zou het gewoon goed moeten werken in de meeste browsers met een reset css, dat je css3 en nieuwere standaarden gebruikt is jouw keuze en als je die dan gebruikt dan is het ook jouw verantwoordelijkheid dat het overal op werkt, je kan niet zomaar met je vingertje naar de browsermakers wijzen...
Dan zeg de gemiddelde opdrachtgever het volgende: "Sorry maar we moeten je helaas teleurstellen dat we al een ander persoon hebben gevonden die het werk sneller en beter kan afhandelen."
Alle standaarden ondersteunen is een must bij alle werkgevers/opdrachtgevers wil je aangenomen worden er zijn namelijk wel tig anderen die wel alles ondersteunen zonder extra kosten of gedoe.
En als je alles in de html standaard schrijft op een juiste manier dan zou het gewoon goed moeten werken in de meeste browsers met een reset css, dat je css3 en nieuwere standaarden gebruikt is jouw keuze en als je die dan gebruikt dan is het ook jouw verantwoordelijkheid dat het overal op werkt, je kan niet zomaar met je vingertje naar de browsermakers wijzen...
[Reactie gewijzigd door seapip op 25 april 2012 18:15]
@seapip: In mijn geval zou ik dat niet erg vinden en heb je te maken met een eigenwijze beter wetende klant. Daar zal je wanneer het traject wel zou starten alleen maar last van ondervinden. Gaat alleen maar voor goedkoop en is buitensporig veeleisend (maar weet niet wat deze eist). Maar vaak is goedkoop niet een garantie voor op de langere termijn. Mijn neefje kan ook een website in elkaar zetten maar is het dan ook goed?
Sneller en beter gaat vaak niet samen, op de korte termijn misschien wel (effe snel in mekaar zetten) maar na verloop van tijd gaat het in de weg zitten. Sneller kan natuurlijk altijd maar is het dan per definitie beter? Dat hoeft dus niet zo te zijn.
Wat krijg je meestal dan? Vernieuwbouw. Dit is een fout die zo ontzettend vaak voorkomt, het korte termijn denken en kost, wanneer je alles bij elkaar optelt (nazorg e.d.) veel meer geld.
Dus wat is goedkoper? De manier van SchizoDuckie. Kun je de klant niet overtuigen dan is de klant niets voor jou en wanneer je wel de opdracht zou krijgen heb je er alleen maar gelazer mee. Wanneer een klant echt serieus is en je hebt een goed verhaal en je kunt verschillen laten zien denk ik heus wel dat ze mee zullen gaan.
Een website is geen document, het is software! Het is een mythe dat je alles maar voor de opdrachtgever moet doen. Het enige dat je moet doen is duidelijk zijn. Wanneer je duidelijk bent komen er minder snel vragen, jij bent degene die er verstand van heeft en dat moet je ook laten blijken.
Toch bekruipt mij het gevoel dat je niet helemaal snapt waar je het over hebt:
....dat je css3 en nieuwere standaarden gebruikt is jouw keuze en als je die dan gebruikt dan is het ook jouw verantwoordelijkheid dat het overal op werkt, je kan niet zomaar met je vingertje naar de browsermakers wijzen...
Dat je de browser(maker) niet de schuld moet geven is bullshit. Mensen kunnen ook andere oplossingen gebruiken om over het net te surfen. Mensen moet tijdig updaten etc. CSS3 gebruiken is een keuze maar wel een hele belangrijke, da's waar maar zou de werking van de site niet in de weg moeten staan. Als het werkt dan werkt het. Door nieuwe technieken te gebruiken blijft de site langer nieuw.
Sneller en beter gaat vaak niet samen, op de korte termijn misschien wel (effe snel in mekaar zetten) maar na verloop van tijd gaat het in de weg zitten. Sneller kan natuurlijk altijd maar is het dan per definitie beter? Dat hoeft dus niet zo te zijn.
Wat krijg je meestal dan? Vernieuwbouw. Dit is een fout die zo ontzettend vaak voorkomt, het korte termijn denken en kost, wanneer je alles bij elkaar optelt (nazorg e.d.) veel meer geld.
Dus wat is goedkoper? De manier van SchizoDuckie. Kun je de klant niet overtuigen dan is de klant niets voor jou en wanneer je wel de opdracht zou krijgen heb je er alleen maar gelazer mee. Wanneer een klant echt serieus is en je hebt een goed verhaal en je kunt verschillen laten zien denk ik heus wel dat ze mee zullen gaan.
Een website is geen document, het is software! Het is een mythe dat je alles maar voor de opdrachtgever moet doen. Het enige dat je moet doen is duidelijk zijn. Wanneer je duidelijk bent komen er minder snel vragen, jij bent degene die er verstand van heeft en dat moet je ook laten blijken.
Toch bekruipt mij het gevoel dat je niet helemaal snapt waar je het over hebt:
....dat je css3 en nieuwere standaarden gebruikt is jouw keuze en als je die dan gebruikt dan is het ook jouw verantwoordelijkheid dat het overal op werkt, je kan niet zomaar met je vingertje naar de browsermakers wijzen...
Dat je de browser(maker) niet de schuld moet geven is bullshit. Mensen kunnen ook andere oplossingen gebruiken om over het net te surfen. Mensen moet tijdig updaten etc. CSS3 gebruiken is een keuze maar wel een hele belangrijke, da's waar maar zou de werking van de site niet in de weg moeten staan. Als het werkt dan werkt het. Door nieuwe technieken te gebruiken blijft de site langer nieuw.
[Reactie gewijzigd door Erwines op 25 april 2012 00:39]
@Erwines
Oude software ondersteunen is helemaal niet zo'n onzin dat is alleen een gedachte die men aangeleerd heeft en meestal niet ten goede komt.
Want het is en blijft een feit dat IE7/8 nog steeds in een heel groot aantal wordt gebruikt, het niet hiervan ondersteunen is gewoon simpelweg een van de meest krankzinnige ideeën die er is het zou je namelijk alleen een heleboel bezoekers en klanten kosten en zelfs je imago kunnen schaden omdat men simpel weg je website beschrijft als "Hij werkt niet".
Oude software ondersteunen is helemaal niet zo'n onzin dat is alleen een gedachte die men aangeleerd heeft en meestal niet ten goede komt.
Want het is en blijft een feit dat IE7/8 nog steeds in een heel groot aantal wordt gebruikt, het niet hiervan ondersteunen is gewoon simpelweg een van de meest krankzinnige ideeën die er is het zou je namelijk alleen een heleboel bezoekers en klanten kosten en zelfs je imago kunnen schaden omdat men simpel weg je website beschrijft als "Hij werkt niet".
Niet ondersteunen, laten we zo zeggen: "ergens een grens trekken" Je moet er dus wel voor zorgen dat het werkt en wanneer het helemaal niet gaat werken een popupje bovenaan de pagina weergeven en vertellen dat het aan de browser ligt. Heb je in iedere geval gewaarschuwd dat het niet werkt, kunnen ze je daarop niet 'pakken'. Dan is het ineens een stuk minder erg. Als er niets over wordt gezegd is pas erg, want dan weet de gebruiker niet waar deze aan toe is. Dan denkt de gebruiker WTF die site werkt niet, snel weg van hier. Verder ligt er aan wat er niet werkt, is het het contactformulier kan dat ernstig zijn maar bijvoorbeeld een schaduwrandje minder valt best te behappen. Het mag een 'rommeltje' zijn maar de informatie moet te bereiken zijn, dan is er niets aan de hand.
Het is net als met Javascript. Hoeveel sites niet goed werken als Javascript niet is ingeschakeld. Maar geen melding, de gebruiker wordt niet geattendeerd op het feit dat het noodzakelijk is om Javascript in te schakelen. Wat zie je dus vaak: een gedeeltelijk lege pagina of helemaal niets. Dat heb je ook heel vaak met jQuery fancy things. Content moet in je pagina staan en niet in je script.
Als je IE7/IE8 gaat customizen met extra scripts ben je gewoon verkeerd bezig, je houd daarmee het gebruik van deze browsers in stand. Alternatieven genoeg dus waarom is het noodzakelijk oude meuk volledig te blijven ondersteunen. Dat je daarmee klanten verliest is commercieel geneuzel (dat was vroeger misschien zo, jaar 2002 en daarvoor) zeker wanneer de gebruiker erachter komt dat meer sites niet goed functioneren. En dat is het, door alle oude meuk te blijven ondersteunen houd je het gebruik alleen maar in stand. Maar nogmaals, je moet wel aangeven dat het niet werkt (je moet informatief blijven), bijvoorbeeld wat ik dan doe is een klein popupje aan de bovenkant van de pagina:
De browser die u gebruikt biedt geen ondersteuning voor de moderne webstandaardeb. Deze pagina wordt mogelijk niet goed weergegeven zoals het oorspronkelijk was bedoeld. Meer informatie? Klik hier.
Als meerdere devs dat doen, moet je eens kijken.
Het is net als met Javascript. Hoeveel sites niet goed werken als Javascript niet is ingeschakeld. Maar geen melding, de gebruiker wordt niet geattendeerd op het feit dat het noodzakelijk is om Javascript in te schakelen. Wat zie je dus vaak: een gedeeltelijk lege pagina of helemaal niets. Dat heb je ook heel vaak met jQuery fancy things. Content moet in je pagina staan en niet in je script.
Als je IE7/IE8 gaat customizen met extra scripts ben je gewoon verkeerd bezig, je houd daarmee het gebruik van deze browsers in stand. Alternatieven genoeg dus waarom is het noodzakelijk oude meuk volledig te blijven ondersteunen. Dat je daarmee klanten verliest is commercieel geneuzel (dat was vroeger misschien zo, jaar 2002 en daarvoor) zeker wanneer de gebruiker erachter komt dat meer sites niet goed functioneren. En dat is het, door alle oude meuk te blijven ondersteunen houd je het gebruik alleen maar in stand. Maar nogmaals, je moet wel aangeven dat het niet werkt (je moet informatief blijven), bijvoorbeeld wat ik dan doe is een klein popupje aan de bovenkant van de pagina:
De browser die u gebruikt biedt geen ondersteuning voor de moderne webstandaardeb. Deze pagina wordt mogelijk niet goed weergegeven zoals het oorspronkelijk was bedoeld. Meer informatie? Klik hier.
Als meerdere devs dat doen, moet je eens kijken.
Als je een commerciële webbased app hebt dan kan je niet anders dan er voor te zorgen dat het volledig werkt in IE7/8. Er zijn te veel mensen die het gebruiken, dus moet je het supporten. Kan je wel principieel gaan lopen doen, maar dan pakt de klant de concurrent wel. Je wilt die drempel zo laag mogelijk maken. In een concurrerende markt kan en wil je niet al te veel eisen gaan stellen.
Neem bedrijfscomputers. Vaak helemaal dichtgetimmerd (terecht), waarbij je dus als eindgebruiker afhankelijk bent van het beleid voor iedereen. Als jij dan toevallig een app hebt die moeilijk gaat doen, dan gaat het hele beleid niet veranderen. Ja als er genoeg vraag is wel, maar dat is een beetje het kip en ei verhaal.
Het is dan meer aan grote partijen als Google en Facebook e.d. daar het voortouw in te nemen, omdat zij het zich kunnen permitteren. Of als een ieder zich zeker voelt hetzelfde te doen, ga je gang, maar ik kijk wel uit. Bovendien, afgezien van af en toe die ene ergernis is het zoveel moeite ook niet.
Trek zelf de lijn onder IE7; IE6 krijgt een melding met netjes icoontjes van alle browsers om ze te downloaden. Er zijn dermate weinig mensen die die browser nog gebruiken, en hij wijkt erg veel af van de standaarden. Ook een Javascript melding aanwezig tussen noscript tags.
Neem bedrijfscomputers. Vaak helemaal dichtgetimmerd (terecht), waarbij je dus als eindgebruiker afhankelijk bent van het beleid voor iedereen. Als jij dan toevallig een app hebt die moeilijk gaat doen, dan gaat het hele beleid niet veranderen. Ja als er genoeg vraag is wel, maar dat is een beetje het kip en ei verhaal.
Het is dan meer aan grote partijen als Google en Facebook e.d. daar het voortouw in te nemen, omdat zij het zich kunnen permitteren. Of als een ieder zich zeker voelt hetzelfde te doen, ga je gang, maar ik kijk wel uit. Bovendien, afgezien van af en toe die ene ergernis is het zoveel moeite ook niet.
Trek zelf de lijn onder IE7; IE6 krijgt een melding met netjes icoontjes van alle browsers om ze te downloaden. Er zijn dermate weinig mensen die die browser nog gebruiken, en hij wijkt erg veel af van de standaarden. Ook een Javascript melding aanwezig tussen noscript tags.
@Arietje: Als het nu 98% IE gebruikt is het een ander verhaal maar dat is allang niet meer zo, zo rond de 50%. Geef mij dan maar de andere 50%, ook goed.
Bedenk ook dat een website of webapp tegenwoordig beter software kan worden genoemd. en net als met alle andere software kan het onmogelijk onder elk platform draaien (daar hangen eisen aan vast, of het moet zo ontzettend simpel zijn dat het gewoon overal kan draaien). Immers een app gebouwd onder Windows 7 werkt ook niet onder Windows 98.
Ik vind je argument wat aan de zwakke kant, als de ICT-afdeling zo starrig is om te wijken voor nieuwe eisen dan zegt dat iets over het beleid in het bedrijf. Waarschijnlijk werken ze dan ook nog met Windows 2000 ofzo. Prima om wat oudere zaken te ondersteunen maar op een gegeven moment gaat de techniek verder en kan de software veeleisender worden. Het is dan mogelijk dat nieuwe functies niet meer passen in het oude of gewoonweg niet mogelijk zijn met het oude. Dit zie je bij desktop apps ook, dus waarom dan niet met webapps? Omdat je dan klanten zou verliezen? Dat is een vastgeroeste opvatting uit het stenen tijdperk. Je kunt niet eindeloos compatible blijven. Jij laat je bang maken door deze opvatting. Natuurlijk zullen er mensen zijn die niet willen veranderen maar is dat jou probleem? Vind van niet. Dan maar niet de opdracht.
Zeker HTML5 en CSS3 kunnen kostenbesparend werken, het reduceren van plaatjes, strakkere en kleinere code (geen uitzonderingen) = bandbreedte gebruik reduceren en sneller laden. En niet te vergeten: scalable, resizeable zonder kwaliteitsverlies dus kan in theorie op elke resolutie werken (geen fuzzy pixels). Aan dit soort dingen wordt nog veel te weinig aandacht besteed.
Hetzelfde bij het UWV, hebben ze apps die alleen kunnen werken onder IE6/IE7 maar daarnaast hebben ze firefox geinstalleerd om op het web te surfen. Zo zie je dat het gemakkelijk mogelijk is om voor IE een alternatief te bieden.
Dus laat je niet bang maken door dat ze anders naar een ander bedrijf gaan. Jij moet laten zien dat je er verstand van hebt en met goede argumenten. Willen ze daar niet in meegaan dan is het geen partij voor jou.
Bedenk ook dat een website of webapp tegenwoordig beter software kan worden genoemd. en net als met alle andere software kan het onmogelijk onder elk platform draaien (daar hangen eisen aan vast, of het moet zo ontzettend simpel zijn dat het gewoon overal kan draaien). Immers een app gebouwd onder Windows 7 werkt ook niet onder Windows 98.
Ik vind je argument wat aan de zwakke kant, als de ICT-afdeling zo starrig is om te wijken voor nieuwe eisen dan zegt dat iets over het beleid in het bedrijf. Waarschijnlijk werken ze dan ook nog met Windows 2000 ofzo. Prima om wat oudere zaken te ondersteunen maar op een gegeven moment gaat de techniek verder en kan de software veeleisender worden. Het is dan mogelijk dat nieuwe functies niet meer passen in het oude of gewoonweg niet mogelijk zijn met het oude. Dit zie je bij desktop apps ook, dus waarom dan niet met webapps? Omdat je dan klanten zou verliezen? Dat is een vastgeroeste opvatting uit het stenen tijdperk. Je kunt niet eindeloos compatible blijven. Jij laat je bang maken door deze opvatting. Natuurlijk zullen er mensen zijn die niet willen veranderen maar is dat jou probleem? Vind van niet. Dan maar niet de opdracht.
Zeker HTML5 en CSS3 kunnen kostenbesparend werken, het reduceren van plaatjes, strakkere en kleinere code (geen uitzonderingen) = bandbreedte gebruik reduceren en sneller laden. En niet te vergeten: scalable, resizeable zonder kwaliteitsverlies dus kan in theorie op elke resolutie werken (geen fuzzy pixels). Aan dit soort dingen wordt nog veel te weinig aandacht besteed.
Hetzelfde bij het UWV, hebben ze apps die alleen kunnen werken onder IE6/IE7 maar daarnaast hebben ze firefox geinstalleerd om op het web te surfen. Zo zie je dat het gemakkelijk mogelijk is om voor IE een alternatief te bieden.
Dus laat je niet bang maken door dat ze anders naar een ander bedrijf gaan. Jij moet laten zien dat je er verstand van hebt en met goede argumenten. Willen ze daar niet in meegaan dan is het geen partij voor jou.
[Reactie gewijzigd door Erwines op 30 april 2012 01:54]
@seapip: Ik weet niet of je reactie nu op mij of SchizoDuckie is, maar het verhaal kan ook slaan op IE6 welke ik niet meer support. Het is zonde van de tijd om daar energie in te steken.
En dat het een keuze is om css3 te gebruiken, zeker, maar dat is niet alleen omdat ik dat zo leuk vind, maar de klant wil ook een beetje een moderne website met leuke foefjes.
Maar verder ben ik het niet helemaal eens met SchizoDuckie; IE8 wordt simpelweg nog te veel gebruikt om je site er niet in te laten werken. Een consessie doen op leuke extras ala, maar het moet allemaal in ieder geval werken en niet al te gek uit zien.
En dat het een keuze is om css3 te gebruiken, zeker, maar dat is niet alleen omdat ik dat zo leuk vind, maar de klant wil ook een beetje een moderne website met leuke foefjes.
Maar verder ben ik het niet helemaal eens met SchizoDuckie; IE8 wordt simpelweg nog te veel gebruikt om je site er niet in te laten werken. Een consessie doen op leuke extras ala, maar het moet allemaal in ieder geval werken en niet al te gek uit zien.
@Arietje
ja hij was gericht aan SchizoDuckie en ja IE8en IE7 hebben gewoon nog een veel te groot markt aandeel waardoor we niet zomaar kunnen stoppen met het supporten ervan.
ja hij was gericht aan SchizoDuckie en ja IE8en IE7 hebben gewoon nog een veel te groot markt aandeel waardoor we niet zomaar kunnen stoppen met het supporten ervan.
Wat een onzin, IE implementeerd de HTML standaard goed, maar dan wel alleen de onderdelen die final zijn. Microsoft hanteert de filosofie dat ze geen standaarden implementeren waarvan nog niet zeker is of ze gaan veranderen. Als html5 helemaal final is dan zal deze ook volledig ondersteund worden door IE.
Feit blijft dat IE in web-ontwikkeling een achterblijver blijft op de rest. Ze gaan niet snel genoeg mee, hun houding is uiterst conservatief (wat in een creatieve industrie niet handig is).
De andere browser-vendors hanteren een betere strategie: gewoon de nuttige dingen alvast implementeren. Er is nauwelijks verschil in html5 support in de populaire browsers, op IE na.
Microsoft zit in dezelfde commissie als de andere fabrikanten, ze weten heel goed hoe de standaard eruit komt te zien, ze zijn namelijk zelf aanwezig bij die gesprekken. Ze weten dus ook wat de andere vendors gaan doen, maar blijven te lang uit met het supporten van features vergeleken met de rest.
Het levert voor webdevelopers een extra stap op in het ontwikkel proces, als we steeds moeten zorgen dat het ook in IE fatsoenlijk blijft werken/uitzien. Het is onnodig ophouden van het proces naar mijn mening.
De andere browser-vendors hanteren een betere strategie: gewoon de nuttige dingen alvast implementeren. Er is nauwelijks verschil in html5 support in de populaire browsers, op IE na.
Microsoft zit in dezelfde commissie als de andere fabrikanten, ze weten heel goed hoe de standaard eruit komt te zien, ze zijn namelijk zelf aanwezig bij die gesprekken. Ze weten dus ook wat de andere vendors gaan doen, maar blijven te lang uit met het supporten van features vergeleken met de rest.
Het levert voor webdevelopers een extra stap op in het ontwikkel proces, als we steeds moeten zorgen dat het ook in IE fatsoenlijk blijft werken/uitzien. Het is onnodig ophouden van het proces naar mijn mening.
Vergeet niet dat Internet Explorer een langzame ontwikkelcyclus heeft en, belangrijker, een weinig automatische update. Mensen blijven vaak genoeg zitten met oude IE versies. Dat opzich is veel kwalijker dan dat ze halve standaarden implementeren.
Aan die automatische update zal ook veel veranderd, dacht dat ze in mei begonnen met het uitrollen van een update in enkele landen ter proef om IE6 en IE7 op Windows XP, IE7 en IE8 op Windows Vista en IE8 op Windows 7 uit te bannen.
Dat IE de standaard goed implementeert, kun je pas echt zeggen bij versie 9. Maar daar gaat het helemaal niet om. Internet Explorer is de énige browser, die nooit wordt geüpdatet, op beveiligings-updates na. De rendering engine (trident) wordt nooit van nieuwe dingen voorzien en ook bugs in de weergave worden nooit gerepareerd.
Alle andere browsers updaten gewoon de rendering engine.
Daardoor is élke versie van IE bij verschijnen feitelijk al verouderd en blokkeert weer jarenlang het gebruik van html, css, enz. die in álle andere browsers wel werkt.
Dat heeft helemaal niets met een goede of foute implementatie van de standaard te maken. IE 8 kan met css gewoon geen ronde hoeken weergeven en kan dat over 8 jaar ook nog niet, standaard of niet. IE 9 kan niet met transition uit de voeten en kan dat over tien jaar nog niet, of dat nou in de standaard zit of niet.
Zolang Microsoft het botweg vertikt IE op 'n normale manier te updaten, blijft het een klereding dat elke ontwikkeling jaren remt.
Alle andere browsers updaten gewoon de rendering engine.
Daardoor is élke versie van IE bij verschijnen feitelijk al verouderd en blokkeert weer jarenlang het gebruik van html, css, enz. die in álle andere browsers wel werkt.
Dat heeft helemaal niets met een goede of foute implementatie van de standaard te maken. IE 8 kan met css gewoon geen ronde hoeken weergeven en kan dat over 8 jaar ook nog niet, standaard of niet. IE 9 kan niet met transition uit de voeten en kan dat over tien jaar nog niet, of dat nou in de standaard zit of niet.
Zolang Microsoft het botweg vertikt IE op 'n normale manier te updaten, blijft het een klereding dat elke ontwikkeling jaren remt.
Inderdaad, en hiemee gaan ze (voor het eerst) in hun vingers snijden. Voor mij mag het, het gaat eigenlijk nog te langzaam. IE10 zal ook niet alles ondersteunen.
[Reactie gewijzigd door Erwines op 25 april 2012 00:44]
Onzin? Feit is dat pas vanaf IE8 er iets of wat aanvaardbare support is voor CSS2.1 en HTML4 Strict. Moesten IE6 en IE7 de formele standaarden inderdaad perfect ondersteund hebben, was er veel minder een probleem.
Maar als je ziet hoe IE6 niet eens child elements ondersteunt, geen fatsoenlijke floating of positionering ondersteunt, de ene renderfout na de andere veroorzaakt... zwijg je beter over het ondersteunen van standaarden in IE. Zelfs inline-block is buggy in IE7. De ACID2-test lukt pas in IE8.
En jaaa, vanaf IE8 is het allemaal wat bruikbaar. Maar dankzij die leuke verwevenheid tussen OS en browser, de rotte updatecycle van IE en het feit dat MS beter zou stoppen met ondersteunen voor alles onder IE8, en deze zomer enkel IE9 en IE10 zou mogen ondersteunen, heeft wel geleid tot de puinhoop die we nu hebben.
Sorry voor de rant, maar IE zal de webdevelopers nog veel mogen aaien en paaien eer het 6/7-fiasco vergeten is hoor...
Maar als je ziet hoe IE6 niet eens child elements ondersteunt, geen fatsoenlijke floating of positionering ondersteunt, de ene renderfout na de andere veroorzaakt... zwijg je beter over het ondersteunen van standaarden in IE. Zelfs inline-block is buggy in IE7. De ACID2-test lukt pas in IE8.
En jaaa, vanaf IE8 is het allemaal wat bruikbaar. Maar dankzij die leuke verwevenheid tussen OS en browser, de rotte updatecycle van IE en het feit dat MS beter zou stoppen met ondersteunen voor alles onder IE8, en deze zomer enkel IE9 en IE10 zou mogen ondersteunen, heeft wel geleid tot de puinhoop die we nu hebben.
Sorry voor de rant, maar IE zal de webdevelopers nog veel mogen aaien en paaien eer het 6/7-fiasco vergeten is hoor...
HTML wordt prima door IE9/10 ondersteund, je moet voor sommige CSS3 handelingen soms nog wel een voorteken gebruiken zoals -ie-. Dat hebben alle browsers overigens. Chrome en Safari hebben -webkit-, opera heeft -o- en firefox heeft -moz-. Dat is effe wennen, maar waarschijnlijk kun je die op den duur wel weghalen.
Het gaat in ieder geval prima om sites om te zetten. Waar het eerder mis gaat is met de javascript, maar ook daar komen de browsers steeds meer bij elkaar
Het gaat in ieder geval prima om sites om te zetten. Waar het eerder mis gaat is met de javascript, maar ook daar komen de browsers steeds meer bij elkaar
Gewoon even ter melding. Voor IE is het niet -ie- maar -ms-.
Nog nooit IE9 of hoger gebruikt?
HTML5 op websites valt inderdaad nog tegen, waarschijnlijk door IE inderdaad.
In apps en dergelijke is het echter al een stuk normaler om HTML5 te gebruiken. Met de lancering van Windows 8 zal dit alleen nog maar toe nemen... Belangrijk is echter wel dat je dan inziet dat HTML geen web(site)-only taal meer hoeft te zijn...
In apps en dergelijke is het echter al een stuk normaler om HTML5 te gebruiken. Met de lancering van Windows 8 zal dit alleen nog maar toe nemen... Belangrijk is echter wel dat je dan inziet dat HTML geen web(site)-only taal meer hoeft te zijn...
Onzin, Microsoft houd in mijn ogen de beste strategie aan: niet implementeren wat nog niet af is, voorkomt dubbel werk, zowel voor de ontwikkelaars van IE als de ontwikkelaars van websites. HTML5 wordt op dit moment door IE trouwens voldoende ondersteund. Zolang het geen standaard is, is er geen nood.
Het probleem is dat ze dus ook niet implementeren wat wél af is. Pas in een nieuwe versie wordt css, html, e.d. toegevoegd. Bestaande browsers krijgen nooit nieuwe dingen.
Als Microsoft dingen inderdaad zou implementeren als ze af waren, dan was het probleem van IE 'n stuk minder, want dan zou ook IE 6 met delen van html5, css3, enz. kunnen werken.
Als Microsoft dingen inderdaad zou implementeren als ze af waren, dan was het probleem van IE 'n stuk minder, want dan zou ook IE 6 met delen van html5, css3, enz. kunnen werken.
Errmm HTML5 is zo goed als af hoor... ze gaan iet voor niks verder met HTML6Onzin, Microsoft houd in mijn ogen de beste strategie aan: niet implementeren wat nog niet af is, voorkomt dubbel werk, zowel voor de ontwikkelaars van IE als de ontwikkelaars van websites. HTML5 wordt op dit moment door IE trouwens voldoende ondersteund. Zolang het geen standaard is, is er geen nood.
Dat zegt natuurlijk helemaal niets. Ze weten misschien dat er geen nieuwe dingen meer bijkomen ... kan ook niet anders komt HTML5 nooit af. Dat betekent natuurlijk niet dat je niet alvast verder kunt gaan denken. Ik weet bijvoorbeeld dat Microsoft al met een 128 bit versie van Windows bezig is (Windows 10 meen ik) ... dat betekend echter niet dat Windows 9 al zo goed als af is.ze gaan iet voor niks verder met HTML6
Daar ben ik het niet mee eens. Waar denk je dat de wijzigingen in Drafts vandaan komen? Die komen van browsers die de draft implementeren en merken dat er bepaalde dingen nog niet optimaal zijn.
Als iedereen dus de strategie zou aanhouden zouden we straks met een kreupele standaard zitten.
Als iedereen dus de strategie zou aanhouden zouden we straks met een kreupele standaard zitten.
Waarom nog investeren in html5 als html6 er al weer aan komt?
en html5 is voor 99.9% van de sites toch overkill.
en html5 is voor 99.9% van de sites toch overkill.
Vond dat er al veel toegevoegd was in HTML5 ben benieuwd wat 6 ons gaat brengen.
Als HTML5 dadelijk standaard is dan zijn we hopelijk ook af van het overal rekening mee houden in browsers.
Denk aan Internet Explorer 8 en 9 enz. Als het allemaal HTML5 wordt dan is het een stuk makkelijker.
Ook mobile apparaten zullen het natuurlijk ondersteunen en dan is het daar ook goed op zichtbaar.
Als HTML5 dadelijk standaard is dan zijn we hopelijk ook af van het overal rekening mee houden in browsers.
Denk aan Internet Explorer 8 en 9 enz. Als het allemaal HTML5 wordt dan is het een stuk makkelijker.
Ook mobile apparaten zullen het natuurlijk ondersteunen en dan is het daar ook goed op zichtbaar.
Mobiele apparaten hebben nu allemaal al min of meer hun eigen specifieke html5 extensies.
Met het officieel worden van de standaard zullen veel specifieke implementaties alsnog een slag moeten krijgen om de uiteindelijke standaard te ondersteunen. Ik ben alleen bang dat dat niet met de standaard ingebakken software 1-2-3 gaat lukken. Dus veel patches/flashes met alle gevolgen van dien (meer dan de helft van de smartphones zal wel geen update krijgen)
Uiteindelijk levert het denk ik voor de bestaande generatie telefoons weinig goeds op. Die zullen na verloop vantijd een heleboel pagina's niet meer kunnen tonen.
Met het officieel worden van de standaard zullen veel specifieke implementaties alsnog een slag moeten krijgen om de uiteindelijke standaard te ondersteunen. Ik ben alleen bang dat dat niet met de standaard ingebakken software 1-2-3 gaat lukken. Dus veel patches/flashes met alle gevolgen van dien (meer dan de helft van de smartphones zal wel geen update krijgen)
Uiteindelijk levert het denk ik voor de bestaande generatie telefoons weinig goeds op. Die zullen na verloop vantijd een heleboel pagina's niet meer kunnen tonen.
Ik vraag me af hoelang ze er uiteindelijk over hebben gedaan, en hoelang websites er al gebruik van maken zonder dat het als standaard is verklaard.
Zodra het een standaard is verklaard, moet iedereen zich dan ineens houden aan wat de W3C vind wat standaard is?
Zodra het een standaard is verklaard, moet iedereen zich dan ineens houden aan wat de W3C vind wat standaard is?
Ze hebben er erg lang over gedaan, sinds 2004 zijn ze er al mee bezig. Hier zie je meteen het nadeel als er een consortium van bedrijven achter een standaard zitten. Teveel politiek, teveel belangen waardoor het tergend traag gaat.
Het zou eigenlijk al in 2010 klaar moeten zijn omdat in 2008 al een stop was gezet op wijzigingen. Maar bedrijven vonden het nodig om in 2009 nog steeds wijzigingen door te voeren waardoor het uitgesteld werd naar nu.
Was ook altijd met die JCP standaarden bij Sun, ook een groep bedrijven, deden er ook altijd jaren over.
Het zou eigenlijk al in 2010 klaar moeten zijn omdat in 2008 al een stop was gezet op wijzigingen. Maar bedrijven vonden het nodig om in 2009 nog steeds wijzigingen door te voeren waardoor het uitgesteld werd naar nu.
Was ook altijd met die JCP standaarden bij Sun, ook een groep bedrijven, deden er ook altijd jaren over.
De volledige afronding word trouwens niet voor 2018 verwacht.
In zekere zin wel dan weet je wel zeker dat je website overal goed zichtbaar is en dat er geen gebreken zijn of dat iets verkeerd staat of erger nog mist!.Zodra het een standaard is verklaard, moet iedereen zich dan ineens houden aan wat de W3C vind wat standaard is?
De ontwikkelaar wil een zo compatibel mogelijke website. De gebruiker heeft meer zekerheid van een goede browser en site. Klinkt goed, zulke standaarden op dit gebied.
Ik dacht dat HTML5 een 'levende standaard' moest worden met de naam 'HTML'. Blijkbaar zijn ze daar alweer van teruggekomen... 
Dit was door de WHATWG gezegd. Dit is een ander orgaan, dat bestaat uit een aantal bedrijven uit de web business. En het staat ook volledig los van de W3C, welke bij deze juist een duidelijk statement geeft dat HTML5 wel een echte standaard zou moeten worden.
Dat is volgens mij niet helemaal waar, want de WHATWG werkt wel samen met de W3C. Hoe ik het begrepen heb is:
De W3C begon met XHTML 2 en daar waren een aantal mensen (onder andere van Mozilla, Apple en Opera) het niet mee eens. Die vormden een groep, de WHATWG (http://www.whatwg.org/) die begon te werken aan twee implementaties: Web Applications 1.0 en Web Forms 2.0. Deze waren bedoeld om HTML uit te breiden. Later hebben ze die twee samengevoegd en noemden ze het simpelweg HTML5. De W3C ondertussen zag dat het niet helemaal goed ging met XHTML 2, en begon zélf met HTML 5 (met spatie...). Uiteindelijk begrepen ze ook wel dat XHTML 'm niet zou worden en hebben ze die geloosd, en hebben ze hun eigen HTML 5 samengevoegd met die van de WHATWG. De twee organisaties werken nu dus samen aan HTML5.
Zoals SiliconError zegt is de WHATWG inderdaad van plan om van HTML een 'levende standaard' te maken. Mijns inziens is dat ook een juiste wijze, want nieuwe dingen kunnen snel geïmplementeerd worden: er hoeft door niet eerst gewacht te worden tot de héle specificatie is goedgekeurd. Hoewel nu natuurlijk al veel HTML5-zaken in browsers zitten, lijkt het me toch veel handiger om die versienummers te lozen. Vooral web developers lijken nog wat afwachtend, ze willen pas beginnen met implementeren als het een échte standaard is.
Het web evolueert echter snel en versienummers voor HTML horen daar denk ik niet bij. Als nieuwe zaken voortaan gelijk in de HTML-standaard worden opgenomen, zullen browsers ze snel implementeren en zullen web developers denk ik ook minder huiverig zijn om nieuwe dingen uit te proberen.
Ik denk dat de W3C uiteindelijk wel zal mee gaan met de WHATWG, omdat die laatste veel meer draagvlak onder de grote internetbedrijven heeft. Maar zoals wel vaker zal het wat tijd nodig hebben...
De W3C begon met XHTML 2 en daar waren een aantal mensen (onder andere van Mozilla, Apple en Opera) het niet mee eens. Die vormden een groep, de WHATWG (http://www.whatwg.org/) die begon te werken aan twee implementaties: Web Applications 1.0 en Web Forms 2.0. Deze waren bedoeld om HTML uit te breiden. Later hebben ze die twee samengevoegd en noemden ze het simpelweg HTML5. De W3C ondertussen zag dat het niet helemaal goed ging met XHTML 2, en begon zélf met HTML 5 (met spatie...). Uiteindelijk begrepen ze ook wel dat XHTML 'm niet zou worden en hebben ze die geloosd, en hebben ze hun eigen HTML 5 samengevoegd met die van de WHATWG. De twee organisaties werken nu dus samen aan HTML5.
Zoals SiliconError zegt is de WHATWG inderdaad van plan om van HTML een 'levende standaard' te maken. Mijns inziens is dat ook een juiste wijze, want nieuwe dingen kunnen snel geïmplementeerd worden: er hoeft door niet eerst gewacht te worden tot de héle specificatie is goedgekeurd. Hoewel nu natuurlijk al veel HTML5-zaken in browsers zitten, lijkt het me toch veel handiger om die versienummers te lozen. Vooral web developers lijken nog wat afwachtend, ze willen pas beginnen met implementeren als het een échte standaard is.
Het web evolueert echter snel en versienummers voor HTML horen daar denk ik niet bij. Als nieuwe zaken voortaan gelijk in de HTML-standaard worden opgenomen, zullen browsers ze snel implementeren en zullen web developers denk ik ook minder huiverig zijn om nieuwe dingen uit te proberen.
Ik denk dat de W3C uiteindelijk wel zal mee gaan met de WHATWG, omdat die laatste veel meer draagvlak onder de grote internetbedrijven heeft. Maar zoals wel vaker zal het wat tijd nodig hebben...
[Reactie gewijzigd door Chris7 op 24 april 2012 19:26]
Je vergeet een gevolg dat de hele zooi weer lastig maakt: De je zit dan vast aan de adoptie ratio van zowel de browser makers als de gebruikers.
Je kunt wel maandelijks nieuwe features toevoegen aan HTML, maar als je moet gaan zitten wachten tot elke browser boer dat in zijn browser heeft zitten en tot dat je gebruikers eindelijk op een versie zitten die dat support ben je weer even ver als nu.
Veel gebruikers en vooral bedrijven zijn niet blij met een snelle uitrol van nieuwe browsers (zie het enorme gezeurs om de nieuwe firefox update cycle), plus hoewel browser makers vrij snel nieuwe features toevoegen zijn ze nog steeds bezig met HTML5 te implementeren.
Dus straks zit je weer code te schrijven om je fancy nieuwe features een vergelijkbare werking te geven op de browsers die nog niet mee zijn, want je kunt niet hebben dat je site niet werkt bij je klanten.
Je kunt wel maandelijks nieuwe features toevoegen aan HTML, maar als je moet gaan zitten wachten tot elke browser boer dat in zijn browser heeft zitten en tot dat je gebruikers eindelijk op een versie zitten die dat support ben je weer even ver als nu.
Veel gebruikers en vooral bedrijven zijn niet blij met een snelle uitrol van nieuwe browsers (zie het enorme gezeurs om de nieuwe firefox update cycle), plus hoewel browser makers vrij snel nieuwe features toevoegen zijn ze nog steeds bezig met HTML5 te implementeren.
Dus straks zit je weer code te schrijven om je fancy nieuwe features een vergelijkbare werking te geven op de browsers die nog niet mee zijn, want je kunt niet hebben dat je site niet werkt bij je klanten.
In principe maakt het niet uit of de doctype aanpast. Uiteindelijk moet de parser toch begrijpen om wat voor code het gaat. Ik gok overigens niet dat er bij HTML6 weer zoveel verschillende dingen bij komen, dat een geheel nieuwe doctype nodig zal zijn.
[Reactie gewijzigd door Martinspire op 24 april 2012 19:23]
Het doctype heeft niets met de weergave te maken. Een geldig doctype zorgt er alleen maar voor dat in standard mode en niet in quirks mode (of almost standard) wordt weergegeven. Dus dat 'n marge bij de breedte wordt opgeteld, dat soort dingen.
Het is 'n wijd verbreid misverstand dat het doctype zegt welke versie html moet worden weergegeven. Als je volgens de standaard werkt, wordt élke versie hetzelfde weergegeven.
Het doctype voor html 5 is alleen <!DOCTYPE html>
Zonder versie. Dat hoeft ook niet, want het is alleen nodig om te zorgen dat de site in standard mode wordt weergegeven. Voor html 6/7/8/9/10 is dus ook geen nieuw doctype nodig.
Wát elke browser kan weergeven, dat is 'n ander verhaal. Als <time> niet in de browser is geïmplementeerd, kan de browser daar niets mee. Maar áls het is geïmplementeerd, dan wordt het, als er een geldig doctype is, altijd op dezelfde manier weergegeven.
<!DOCTYPE html> is ' n heel pragmatisch doctype. Er is gekeken naar het kortste doctype waarbij álle browsers (zelfs IE 6) in standard mode weergeven.
Het is 'n wijd verbreid misverstand dat het doctype zegt welke versie html moet worden weergegeven. Als je volgens de standaard werkt, wordt élke versie hetzelfde weergegeven.
Het doctype voor html 5 is alleen <!DOCTYPE html>
Zonder versie. Dat hoeft ook niet, want het is alleen nodig om te zorgen dat de site in standard mode wordt weergegeven. Voor html 6/7/8/9/10 is dus ook geen nieuw doctype nodig.
Wát elke browser kan weergeven, dat is 'n ander verhaal. Als <time> niet in de browser is geïmplementeerd, kan de browser daar niets mee. Maar áls het is geïmplementeerd, dan wordt het, als er een geldig doctype is, altijd op dezelfde manier weergegeven.
<!DOCTYPE html> is ' n heel pragmatisch doctype. Er is gekeken naar het kortste doctype waarbij álle browsers (zelfs IE 6) in standard mode weergeven.
Persoonlijk heb ik zoiets en html5 dan. Het beloofde crossplatform wondermiddel is een regelrechte ramp. In theorie allemaal mooi, echter in de ene browser draait dit niet lekker van html5 de andere dat weer niet. Vroeger mikte je er gewoon met flash een filmpje uit, tegenwoordig moet je dezelfde filmpjes in mp4 en webm formaat leveren en daarnaast nog ogg en als ultieme afvang methode ook nog een flash versie meeleveren, wil je alles pakken. Ik verlang echt terug naar Flash wat op alle platforms er gelijk uitzag, het blijft jammer dat Apple in z'n eentje die plugin de nek heeft omgedraaid.
[Reactie gewijzigd door zap8 op 24 april 2012 18:29]
Denk dat vele toch liever met HTML5 willen werken.
Flash is ook zwaar voor de CPU enz. dit komt dan bij HTML5 weer ten goede.
Op mobile apparaten (Ook Laptops) kan flash nogal veel CPU en dus Batterij zuipen.
Het resultaat is dan dat mensen zich hier weer aan gaan ergeren en alle apparaten waar je het op wilt bekijken moeten flash hebben.
Als HTML5 standaard wordt heb je dat dus niet meer nodig in zekere zin en het zal een stuk minder kracht kosten. En het kost ook nog eens minder dataverkeer wat tegenwoordig natuurlijk ook erg duur is bij de providers
Flash is ook zwaar voor de CPU enz. dit komt dan bij HTML5 weer ten goede.
Op mobile apparaten (Ook Laptops) kan flash nogal veel CPU en dus Batterij zuipen.
Het resultaat is dan dat mensen zich hier weer aan gaan ergeren en alle apparaten waar je het op wilt bekijken moeten flash hebben.
Als HTML5 standaard wordt heb je dat dus niet meer nodig in zekere zin en het zal een stuk minder kracht kosten. En het kost ook nog eens minder dataverkeer wat tegenwoordig natuurlijk ook erg duur is bij de providers
waarom denk je dat flash veel cpu en dus batterijen gebruikt? Waarom denk je dat dit anders zou zijn bij html5 bij dezelfde soort verwerkingen? Waarom zou html5 minder kracht kosten dan flash (bij wie de plugin al jaren wordt geoptimaliseerd)? Waarom zou html5 minder dataverkeer kosten? Die js bestanden worden niet meegerekend bij het dataverkeer ofzo? Dan denk ik dat de gecompileerde code van flash toch echt een stukje kleiner is dan allemaal losse textbestanden.
Oftewel veel geblaat, weinig nagedacht, zoals de meeste discussies over flash.
Overigens ben ik het redelijk eens met zap8, maar als er iemand verantwoordelijk is geweest voor het minder populair worden van Flash is het Adobe zelf wel. Door te laat door te hebben dat andere platformen ook belangrijk werden en door de developers tegen zich in het harnas te jagen, met 'gedwongen upgrades' en spelletjes met prijzen. Adobe heeft zijn monopoliepositie flink misbruikt en daarom zijn er genoeg developers die het niet erg vinden dat ze wegvallen.
Oftewel veel geblaat, weinig nagedacht, zoals de meeste discussies over flash.
Overigens ben ik het redelijk eens met zap8, maar als er iemand verantwoordelijk is geweest voor het minder populair worden van Flash is het Adobe zelf wel. Door te laat door te hebben dat andere platformen ook belangrijk werden en door de developers tegen zich in het harnas te jagen, met 'gedwongen upgrades' en spelletjes met prijzen. Adobe heeft zijn monopoliepositie flink misbruikt en daarom zijn er genoeg developers die het niet erg vinden dat ze wegvallen.
Teveel CPU en batterijen? Simpel: de extra plugin die nodig is om Flash content weer te kunnen geven. Die draait als overlay boven de content van je browser. Je hebt dus de resources van je browser, met daar bovenop de resources die de Flash plugin nodig heeft.
Canvas in html5 heeft geen plugin nodig, die draait native op elk platform. Wij zijn van een Flash applicatie overgestapt naar Javascript + canvas. De reden: Flash kon de hoeveelheid data niet meer efficient verwerken. Javascript is hier een stuk sneller in, dat is namelijk het sterkste punt van de taal.
Toen we overstapten naar canvas waren zelfs onze grootste datasets geen punt meer. Er zit bij Flash gewoon een extra laag over je site om Flash content te kunnen afspelen via de plugin, wat meer resources trekt dan nodig is vergeleken met een native oplossing.
En de gecompileerde grootte is niet minder, je kunt javascript namelijk ook nog minimizen en comprimeren en gewoon serveren met de rest van de javascript van je site. Dit gaat om een paar KBs, daarentegen heb ik wel .swf files gezien met de grootte van enkele MBs.
Bovendien hebben ze Javascript langer kunnen optimaliseren dan Actionscript en Flash in het algemeen. Javascript bestaat simpelweg langer (en nog steeds) omdat het gewoon een snelle taal is. Daarom hebben ze tegenwoordig (weer) server-side Javascript.
Canvas in html5 heeft geen plugin nodig, die draait native op elk platform. Wij zijn van een Flash applicatie overgestapt naar Javascript + canvas. De reden: Flash kon de hoeveelheid data niet meer efficient verwerken. Javascript is hier een stuk sneller in, dat is namelijk het sterkste punt van de taal.
Toen we overstapten naar canvas waren zelfs onze grootste datasets geen punt meer. Er zit bij Flash gewoon een extra laag over je site om Flash content te kunnen afspelen via de plugin, wat meer resources trekt dan nodig is vergeleken met een native oplossing.
En de gecompileerde grootte is niet minder, je kunt javascript namelijk ook nog minimizen en comprimeren en gewoon serveren met de rest van de javascript van je site. Dit gaat om een paar KBs, daarentegen heb ik wel .swf files gezien met de grootte van enkele MBs.
Bovendien hebben ze Javascript langer kunnen optimaliseren dan Actionscript en Flash in het algemeen. Javascript bestaat simpelweg langer (en nog steeds) omdat het gewoon een snelle taal is. Daarom hebben ze tegenwoordig (weer) server-side Javascript.
[Reactie gewijzigd door Wizz15 op 24 april 2012 19:06]
Die plugin is juist weer winst voor de site zelf. Plugin draait lokaal, de rest moet van internet geplukt worden.
Ben het er niet mee eens dat javascript sneller zou zijn dan flash. Vooral als je veel in je DOM hebt staan, trekken veel mobiele apparaten het gewoon niet meer. Voor simpele pagina's als tweakers maakt het weinig uit, maar als je echt applicaties wilt simuleren wordt het heel traag. En dan bedoel ik met name het gebied van animaties.
Waarom denk je dat native-applicaties altijd zoveel sneller starten en lopen dan de html-versies? De startup van flash vs html5 lijkt me niet echt van toepassing op de cpu/batterijtijd. Die startup mag toch niet langer dan 5 seconden duren, het gaat erom dat een applicatie minder verbruikt als alles eenmaal geladen is. Het maakt niet uit of je 5kb of 5mb in het geheugen laad, daar staat het toch wel stil. Het gaat erom hoeveel acties je vervolgens moet doen om hetzelfde effect te bereiken.
Ben het er niet mee eens dat javascript sneller zou zijn dan flash. Vooral als je veel in je DOM hebt staan, trekken veel mobiele apparaten het gewoon niet meer. Voor simpele pagina's als tweakers maakt het weinig uit, maar als je echt applicaties wilt simuleren wordt het heel traag. En dan bedoel ik met name het gebied van animaties.
Waarom denk je dat native-applicaties altijd zoveel sneller starten en lopen dan de html-versies? De startup van flash vs html5 lijkt me niet echt van toepassing op de cpu/batterijtijd. Die startup mag toch niet langer dan 5 seconden duren, het gaat erom dat een applicatie minder verbruikt als alles eenmaal geladen is. Het maakt niet uit of je 5kb of 5mb in het geheugen laad, daar staat het toch wel stil. Het gaat erom hoeveel acties je vervolgens moet doen om hetzelfde effect te bereiken.
Javascript != DOM. Javascript is prima te gebruiken buiten de DOM, en uiteraard is het gewenst dat de opmaak van de pagina geoptimaliseerd is voor mobiele apparaten. Dat staat verder los van de discussie, aangezien de DOM niets met de performance van Javascript of Flash te maken heeft. Beide profiteren niet van een constant veranderende DOM.
In Flash liepen we tegen allerlei limieten aan die gewoon niet bestaan in een browser pagina. Een storende limiet is de grootte van afbeeldingen die Flash je laat laden (max 8000 pixels hoog). Ik snap dat dat geen normaal gebruik is voor een website, maar het is wel perfect mogelijk in een normale html omgeving.
Bovendien werkten we met datasets van 1000 records groot, en Flash liep volledig vast op het verwerken van die data. In Javascript is het in milliseconden gebeurd. Dat komt door de overhead veroorzaakt door de plugin die (soms slecht) geoptimaliseerd is voor de omgeving waarin hij draaide.
Bovendien geef je zelf in je laatste alinea aan dat native-applicaties sneller starten. Native is qua performance altijd beter dan via een extra laag. Waarom dit dan niet voor zou Flash gelden snap ik niet helemaal.
Ik heb het bovendien ook niet gehad over startup tijd, maar ook hier is Javascript toch weer sneller. Javascript wordt namelijk uitgevoerd terwijl het wordt ingeladen door de browser. Flash begint pas met uitvoeren nadat de webpagina + plugin is geladen, wat toch weer als extra vertraging wordt ervaren door gebruikers.
Flash gebruikt meer batterijen omdat het constant blijft draaien, ongeacht of je bezig bent met de Flash content op de pagina of niet. De cpu heeft meer te doen op die pagina, dan wanneer er geen Flash aanwezig zou zijn op diezelfde pagina. Dan is de plugin namelijk ook niet geladen en aan het wachten op instructies om uit te voeren.
Applicaties emuleren doe je trouwens ook niet met Flash, aangezien je daar slechts beperkt UI kan emuleren. Met html krijg je al een functionerende UI aangeboden, waarom moeten we daar nog een extra plugin bovenop draaien?
In Flash liepen we tegen allerlei limieten aan die gewoon niet bestaan in een browser pagina. Een storende limiet is de grootte van afbeeldingen die Flash je laat laden (max 8000 pixels hoog). Ik snap dat dat geen normaal gebruik is voor een website, maar het is wel perfect mogelijk in een normale html omgeving.
Bovendien werkten we met datasets van 1000 records groot, en Flash liep volledig vast op het verwerken van die data. In Javascript is het in milliseconden gebeurd. Dat komt door de overhead veroorzaakt door de plugin die (soms slecht) geoptimaliseerd is voor de omgeving waarin hij draaide.
Bovendien geef je zelf in je laatste alinea aan dat native-applicaties sneller starten. Native is qua performance altijd beter dan via een extra laag. Waarom dit dan niet voor zou Flash gelden snap ik niet helemaal.
Ik heb het bovendien ook niet gehad over startup tijd, maar ook hier is Javascript toch weer sneller. Javascript wordt namelijk uitgevoerd terwijl het wordt ingeladen door de browser. Flash begint pas met uitvoeren nadat de webpagina + plugin is geladen, wat toch weer als extra vertraging wordt ervaren door gebruikers.
Flash gebruikt meer batterijen omdat het constant blijft draaien, ongeacht of je bezig bent met de Flash content op de pagina of niet. De cpu heeft meer te doen op die pagina, dan wanneer er geen Flash aanwezig zou zijn op diezelfde pagina. Dan is de plugin namelijk ook niet geladen en aan het wachten op instructies om uit te voeren.
Applicaties emuleren doe je trouwens ook niet met Flash, aangezien je daar slechts beperkt UI kan emuleren. Met html krijg je al een functionerende UI aangeboden, waarom moeten we daar nog een extra plugin bovenop draaien?
De plugin gebruikt zelf nouwelijks resources, die worden gebruikt door de Actionscript virtual machine, net als javascript wordt afgehandeld door een javascript virtual machine, zoals v8 in chrome, of Carakan voor Opera. Canvas wordt netzogoed aangestuurd door een aparte engine als flash content.
Mijn ervaring tussen de kracht van js en actionscript is juist andersom. JS geeft het juist eerder op dan AS, wel is het verschil de afgelopen jaren veel kleiner geworden, omdat men zich sinds een paar jaar enorm heeft ingezet om de javascript engines te verbeteren. Qua pure code execution denk ik dat js zelfs sneller is, maar met de rendering van het beeld erbij gebruik ik liever flash. Daarbij is canvas leuk en aardig, maar je sluit er nogal wat mensen mee uit, omdat het pas sinds kort door de meeste browsers wordt ondersteund en het is zeker nog niet iets waar je vanuit kunt gaan dat zelfs maar meer dan de helft van de bezoekers de content ook kan zien.
Swf's van enkele MB's bevatten natuurlijk niet alleen code. Ik heb ook websites gezien die met alle afbeeldingen, css html, pdf's etc bij elkaar 200MB zijn. Net zo goed als ik swf's van een paar kilobytes heb gezien, die complete 3d werelden opbouwden. Dat is natuurlijk een kwestie van op de juiste manier inladen en ja, er zijn genoeg mensen die dat fout doen. Neemt niet weg dat dezelfde code in AS zowel wordt gecomprimeerd, als omgezet naar bytecode, zonder dat de maker iets meer hoeft te doen dan cntrl-enter te klikken. Js is in het beste geval heel wat meer werk en dan nog waarschijnlijk groter.
JS en AS komen uit dezelfde ECMA standaard, althans.. as3 is gebaseerd op de ecmascript 4 standaard. Die zijn al relatief heel oud. De javascript engines die nu hoge ogen gooien zijn echter allemaal vrij recent, net als de toevoegingen van JIT compilers en andere optimalisaties. Met dat soort verbeteringen is de flash player al veel langer bezig, gewoon omdat het al veel eerder de taak was van Flash om dingen te animeren en in beweging te zetten. Voorheen - toen js nog veracht werd door een grote groep mensen - had javascript die taak helemaal niet.
Mijn ervaring tussen de kracht van js en actionscript is juist andersom. JS geeft het juist eerder op dan AS, wel is het verschil de afgelopen jaren veel kleiner geworden, omdat men zich sinds een paar jaar enorm heeft ingezet om de javascript engines te verbeteren. Qua pure code execution denk ik dat js zelfs sneller is, maar met de rendering van het beeld erbij gebruik ik liever flash. Daarbij is canvas leuk en aardig, maar je sluit er nogal wat mensen mee uit, omdat het pas sinds kort door de meeste browsers wordt ondersteund en het is zeker nog niet iets waar je vanuit kunt gaan dat zelfs maar meer dan de helft van de bezoekers de content ook kan zien.
Swf's van enkele MB's bevatten natuurlijk niet alleen code. Ik heb ook websites gezien die met alle afbeeldingen, css html, pdf's etc bij elkaar 200MB zijn. Net zo goed als ik swf's van een paar kilobytes heb gezien, die complete 3d werelden opbouwden. Dat is natuurlijk een kwestie van op de juiste manier inladen en ja, er zijn genoeg mensen die dat fout doen. Neemt niet weg dat dezelfde code in AS zowel wordt gecomprimeerd, als omgezet naar bytecode, zonder dat de maker iets meer hoeft te doen dan cntrl-enter te klikken. Js is in het beste geval heel wat meer werk en dan nog waarschijnlijk groter.
JS en AS komen uit dezelfde ECMA standaard, althans.. as3 is gebaseerd op de ecmascript 4 standaard. Die zijn al relatief heel oud. De javascript engines die nu hoge ogen gooien zijn echter allemaal vrij recent, net als de toevoegingen van JIT compilers en andere optimalisaties. Met dat soort verbeteringen is de flash player al veel langer bezig, gewoon omdat het al veel eerder de taak was van Flash om dingen te animeren en in beweging te zetten. Voorheen - toen js nog veracht werd door een grote groep mensen - had javascript die taak helemaal niet.
Apple is echt niet de enige, heb Flash al jaren als een stoorzender gezien en ben ook blij dat mensen er nu eindelijk van af stappen. Tegenwoordig gooi je het fimpje trouwens gewoon op Youtube en embed je het vervolgens tenzij je echt bandwidth teveel hebt ;l
Flash is wel wat meer dan alleen iets om filmpjes mee af te spelen he...
Wordt ook veel gebruikt bij banners, maar die zien de meeste mensen toch liever gaan.
Wordt ook veel gebruikt bij banners, maar die zien de meeste mensen toch liever gaan
.
Hij gebruikte het argument van video codecs dus ik wou hem er direct even op wijzen dat het niet echt een heel relevant iets meer is als het op grote problemen van het web aan komt ;d
Als je cleane html code schrijft valt dat hartstikke mee. Natuurlijk heb je voor sommige dingen nog wel eens wat browser-specifieke css nodig, maar meer ook niet meer echt. Wel zou ik graag willen zien dat ze de css standaard nog iets uit gingen breiden.
Website standaarden vind ik best meevallen, html email-opmaak daarentegen
: Dat is pas een pure hel.
Website standaarden vind ik best meevallen, html email-opmaak daarentegen
: Dat is pas een pure hel.
Liever zie ik dat HTML op de schop gaat. Ik vind het maar een inefficiënte markup taal. Problemen die sinds 1984 al getackled zijn op de desktop (Win of Mac) zijn nodeloos complex met css en javascript.
Ik deel je mening wat betreft de markup taal HTML. Javascript is een heel sterke taal en heeft zeker bestaansrecht (ook buiten de browser). Er zitten wat fouten in, maar die worden met Harmony hopelijk opgelost.
Je moet ook geen desktop applicaties willen maken met Javascript + css, daar zijn al jaren betere en efficiëntere alternatieven voor. Voor simpele cross-platform applicaties is het echter een sterke combinatie, vooral omdat het platform onafhankelijk is.
Dit heb je niet met Windows of OSX (in mindere mate vanwege beperkte UNIX compatibiliteit). Die applicaties proberen ook een heel ander probleem op te lossen.
Je moet ook geen desktop applicaties willen maken met Javascript + css, daar zijn al jaren betere en efficiëntere alternatieven voor. Voor simpele cross-platform applicaties is het echter een sterke combinatie, vooral omdat het platform onafhankelijk is.
Dit heb je niet met Windows of OSX (in mindere mate vanwege beperkte UNIX compatibiliteit). Die applicaties proberen ook een heel ander probleem op te lossen.
Het is helemaal geen inefficiente markup taal als je weet waar je mee bezig bent. Ik zie vaak zat websites die allemaal met unieke id's en unieke css werken, terwijl je juist die dingen makkelijk kunt oplossen.
Het grote probleem is dat de koppeling tussen client-side en server-side wat lastig is te regelen, maar eens je een goede verbinding hebt ingesteld, is het een fluitje van een cent om (mbv html5,css3+javascript) een applicatie te "simuleren"
Het grote probleem is dat de koppeling tussen client-side en server-side wat lastig is te regelen, maar eens je een goede verbinding hebt ingesteld, is het een fluitje van een cent om (mbv html5,css3+javascript) een applicatie te "simuleren"
Html is prima als markup als je nagaat waar het aan moet voldoen. Probleem is dat je met makkelijker maken flexibiliteit verliest die nodig is.
Dat gezegd hebbende, heb je concrete voorbeelden over wat jij vindt hoe het beter zou kunnen?
Dat gezegd hebbende, heb je concrete voorbeelden over wat jij vindt hoe het beter zou kunnen?
In de ideale situatie zou het zo moeten zijn dat zowel de standaard als de implementatie aangeleverd worden door de W3C of een soortgelijke instantie. Dit zou als gevolg hebben dat iedere browser altijd aan de standaard voldoet en dat wijzingen in de standaard aanzienlijk sneller doorgevoerd kunnen worden.
Zoals het nu gaat is het gewoon bakwerk. Bij de ene versie van Internet Explorer werkt feature X weer niet en bij de ander werkt feature Y niet. Het resulteerd hoe dan ook in een te grote hoeveelheid custom code voor compatibiliteit.
Dus tenzij de hele insteek op de schop gaat, verwacht ik voor HTML5 weinig verbetering.
Zoals het nu gaat is het gewoon bakwerk. Bij de ene versie van Internet Explorer werkt feature X weer niet en bij de ander werkt feature Y niet. Het resulteerd hoe dan ook in een te grote hoeveelheid custom code voor compatibiliteit.
Dus tenzij de hele insteek op de schop gaat, verwacht ik voor HTML5 weinig verbetering.
Was HTML 5 niet bedoeld met een sliding scale waardoor het bleef door ontwikkelen en er dus geen HTML6 nodig was?
ik hoop ergens dat HTML6 wel weer een herkenbare doctype krijgt
anders voorzie ik dat iedere browser zelf op een eigen gaat interpreteren wat voor taal er precies gebruikt wordt
anders voorzie ik dat iedere browser zelf op een eigen gaat interpreteren wat voor taal er precies gebruikt wordt
Browsers boeit het niet welke versie HTML gebruikt wordt, en zolang de syntax en parsing rules niet veranderen is dat ook geheel niet relevant voor een browser. Zelfs voor een developer is het niet echt relevant; je ontwikkeld gewoon naar de huidige status quo en zolang dat in de toekomst maar blijft werken is dat versienummertje ook niet interessant.
Op dit item kan niet meer gereageerd worden.
Onderwerpen
Populair: Tablets E3 2013 Mobiele telefoons Google Sony Apple Microsoft Games Politiek en recht Consoles
© 1998 - 2013 Tweakers.net B.V. onderdeel van De Persgroep, ook uitgever van Computable.nl, Autotrack.nl en Carsom.nl • Hosting door True
