W3C schuift drie api-specificaties naar voren als aanbeveling

De W3C heeft drie api's de status van candidate recommendation gegeven. Met de betreffende api's kunnen ontwikkelaars onder andere de prestaties van webapplicaties nauwkeurig meten binnen moderne browsers.

De api's die de candidate recommendations-status hebben ontvangen zijn User Timing, Performance Timeline en Page Visibility. User Timing biedt ontwikkelaars de mogelijkheid om de prestaties van webapps te meten door toegang te geven tot zeer precieze timingdata, terwijl de Performance Timeline-specificatie timing-informatie geeft voor navigatie-elementen. Verder moet de Page Visibility-api het voor developers eenvoudiger maken om te bepalen welke delen van een webapp zichtbaar zijn en welke niet. Zo zou bijvoorbeeld het cpu-gebruik van een webapplicatie verlaagd kunnen worden als deze niet zichtbaar is voor de gebruiker.

Met het stempel van candidate recommendation, die als een aanbeveling gezien kan worden, beschouwt de W3C de drie api's als voldoende volwassen om deze op termijn de status van proposed recommendation te geven. Dit is de laatste stap voordat voorgestelde api's een officiële standaard worden. Enkele aanvullende api's die binnen de W3C-organisatie worden ontwikkeld, waaronder de High Resolution- en de Resource Timing-api, moeten de mogelijkheden voor ontwikkelaars om goed presterende webapplicaties voor html5-browsers te bouwen, nog verder gaan vergroten.

Reacties (19)

[J.J.J. Bokma]

Het is dus /geen/ aanbeveling, maar een kandidaat, de eerste stap dus. De laatste stap is geen "standard", want hoewel dit woordje nu hier en daar opduikt op W3C noemen ze de dingen zelf nog steeds, uiteindelijk een "recommendation", of te wel in goed Nederlands een aanbeveling.

Titel op Tweakers is dus misleidend, en de samenvatting ook. Er zijn dus 3 kandidaten voor aanbeveling.

Zie ook: http://www.w3.org/2005/10/Process-20051014/tr#q74

Waar ze ook verder bij "recommendation" babbelen over "guidelines", of te wel "richtlijnen". Het is dus in hun eigen woorden ook geen standaard.

Er is verder (tenzij er recent iets veranderd is) maar 1 HTML standaard: ISO HTML (ISO/IEC 15445:2000(E)).

[OddesE]

Ja ok, officieel zijn het 'aanbevelingen', maar in de praktijk zijn het toch gewoon standaarden hoor. Ze zijn alleen niet bij wet vastgelegd of zo.

Maar ook bijvoorbeeld de standaarden voor e-mail en ander internetverkeer zoals POP, SMTP, FTP etc zijn vrijwel allemaal officeel geen standaarden maar 'requests for comment'...

Verder gebruikt W3C nogal vaak en expliciet dwingende termen zoals als MUST en MAY NOT en die schrijven ze dan ook echt zo met hoofdletters. Dus tja, wel een vrij dwingende recommendation...

[J.J.J. Bokma]

Heh, nee, dat is nu juist het trieste, in de praktijk zijn het juist geen standaarden (wat ook niet zo verbazingwekkend is, natuurlijk). Als een browsermaker morgen met een nieuw element of een attribute voor een specifiek element komt, dan mag W3C daar vrolijk achteraan hobbelen. Wat juist een groot gemis is, dat geen van de bekende browsers nu "W3C gecertificeerd zijn, en de standaard volgen.

Daarnaast, als ik een euro kon krijgen van elke site die beweerd XHTML te serveren maar dat niet doet... De grootste grap zijn de sites die naar W3C linken met een "valide ...." button, maar niet valideren :-).

En ja, ik weet wat RFCs zijn, en daar zie je precies dezelfde losse implementaties. Ook hier (en daar) zou het mooi geweest zijn als applicaties gecertificeerd zouden zijn, en de RFCs (dan standaarden) keurig zouden volgen. Je ziet nu in programmas dat men rekening moet houden met diverse gevallen "niet goed gelezen", of "tis geen standaard, dus we bakken er wat extras in". Daar kom je snel achter als je zelf iets met POP, SMTP, FTP, etc. gaat doen en die RFCs moet doorlezen (en later de uitzonderingen in de praktijk tegenkomt).

En die expliciet dwingende termen.... dat is gewoon iets wat altijd in goede documentatie gebruikt zou moeten worden. Net als in de RFCs wordt ook precies uitgelegd wat met die taal bedoelt wordt. Technische documenatie moet namelijk geen onduidelijke / dubbelzinnige taal bevatten. Want dan krijg je ontwikkelaars die het verkeerd lezen, en monsters zoals IE6. Kortom, lees het niet als oom agent gaat mij op de vingers tikken maar gewoon als duidelijke eisen waar je werk aan moet voldoen, niet vanwege straf, maar omdat je goed in je vak wilt zijn. En schrijf je eigen documentatie ook zo. Je moet eens voor de grap de documentatie van curl-lib doorkijken, dan snap je gelijk wat ik bedoel. Succes met het vinden van defaults, b.v.

Overigens heb ik er verder geen moeite mee dat W3C geen officiele standaard maak organisatie is, anders zaten we nu op "HTML 1999" of zo, en was men nog steeds aan het vechten over HTML 200X :-).

[johnkeates]

En nu maar hopen dat er niet weer een of ander groot bedrijf komt die denkt dat ze het beter weten... (Apple, Google, Microsoft) Het hele punt van het W3C is dat er een orgaan is dat de standaarden vaststelt, en dat de rest zich daar aan houdt. Als iedereen maar wat doet krijg je geen werkend www.

Verder valt het me op dat die API's een beetje veel lijken op die web console / development console elementen in WebKit en soms FireFox als er FireBug geinstalleerd is. Nu is de W3C standaard vast wel langer in ontwikkeling geweest, maar toch heb ik het idee dat het niet heel nieuw is. Wat natuurlijk wel nieuw is, is het browser-side meten i.p.v. aan de kant van de GUI.

[Romke]

Tsja. Een standaard stel je niet vast door al die bedrijven maar op te leggen hoe ze het moeten doen.

Bij die bedrijven zit enorm veel kennis. Kennis welke je als W3C hard nodig hebt. Bijkomend voordeel aan het gebruik van die kennis is dat je de developers die meegewerkt hebben aan de standaard al achter de standaard hebt. En als die lui bij de grootste browserbouwers werken.... Nouja.. Je snapt het wel

En een standaard is wat anders dan een nieuwe ontwikkeling. Aan standaarden gaat veel ontwikkeling vooraf. Daarom duurt het ook vaak 'lang' voor zo'n standaard klaar is. Je moet namelijk wel zeker weten dat 'ie aan de behoefte van gebruikers en ontwikkelaars voldoet. Meestal is die behoefte er pas als er al meerdere manieren op verschillende platformen zijn.

[Reactie gewijzigd door Romke op 2 augustus 2024 03:00]

[D.oomah]

Toch is het van belang dat er een organisatie is die iets als standaard aanwijzen. Als Google iets op de ene manier doet, Mozilla iets op de andere manier en microsoft haar eigen manier dan weet je als website ontwikkelaar niet meer waar je aan toe bent.

Nu kunnen Google, Mozilla, Microsoft en andere grote bedrijven aangeven op welke manier zij het opgelost hebben en dan kan W3C besluiten welke de beste manier is. Zo krijg je één standaard en weet je als kleine ontwikkelaar waar je aan toe bent.

In before the rest: http://xkcd.com/927/ alhoewel dat hier niet opgaat gezien er maar 1 HTTP standaard is

[OddesE]

Dit gaat niet over HTTP maar over API's die Javascript code draaiend in de browser in staat stellen om te interfacen met de browser en zo o.a. performance gerelateerde status op te vragen, zoals hoe lang het duurt om een pagina te laden.

Verder is het ook niet zo dat je met het W3C netjes één standaard zou krijgen. We hebben nu:

• HTML pre v4
• HTML 4.01 Strict
• HTML 4.01 Transitional
• HTML 4.01 Frameset
• XHTML 1.0 Strict
• XHTML 1.0 Transitional
• XHTML 1.0 Frameset
• XHTML 1.1 Strict
• XHTML 1.1 Transitional
• XHTML 1.1 Frameset
• HTML5

bron

En dan hebben we nog mobile en basic profielen en een set verschillende mimet ypes. Zo kun je XHTML serveren met mime type text/html, maar ook met mime type application/xhtml+xml... en dat maakt verschil! Verder hebben we nog XML + XSLT en een hele berg ongespecificeerde gedragingen, zoals Internet Explorer die ActiveX kan draaien, Chrome die grabbers toont om textarea's mee te resizen, Firefox met zijn spellingscontrole in text velden etc. Dan zijn er nog dingen als voice-markup (effe geen idee hoe het heet) en 3D (VRML, WebGL), graphische markup (SVG) etc.

Maar gelukkig worden de browsers elke dag beter. Ook is de markt veel gelijker verdeeld dan vroeger, toen IE 95%+ van de browser markt had. Tegenwoordig heeft Chrome net IE ingehaald en wordt de markt redelijk gelijk verdeeld onder de grootste drie browsers. Dit dwingt zowel web bouwers als de browser makers om rekening met andere browsers te houden en dat helpt het web pas echt voorruit.

* OddesE heeft niks tegen het W3C, maar wel vele uren van zijn leven verspild aan het leren van standaarden die niks werden

[Verwijderd]

Frames en pre-v4 gebruikt niemand meer. Xhtml 1.1 is naar mijn weten nooit uitontwikkeld, laat staan aanbevolen. Trans en strict verschillen nauwelijks van elkaar als je je css gescheiden houdt van de html. En zelf heb ik sowieso twijfels bij xhtml. Iets met exotische mime type en browsers die het als text/html tag soup parsen, al dan niet met fouten.

Dus in dat opzicht zie ik alleen html4 en html5 staan, met het gekke broertje xhtml1.0 wat daar wat rond hangt.

[Blaise]

Alle grote browserbouwers houden zich tegenwoordig vrij netjes aan standaarden, en als ze zelf iets verzinnen dan gebruiken ze een prefix en dan dragen ze het voor aan het W3C zodat het een standaard kan worden. In het verleden heeft vooral Microsoft gekke dingen gedaan, maar tegenwoordig (sinds IE7 ongeveer) gaat het steeds beter.

En deze functies zijn inderdaad (grotendeels) te vinden in je developer console, maar deze functionaliteit hoort natuurlijk eigenlijk thuis in het window object en niet in het console object.

Overigens zijn zo ook bezig om de console te standaardiseren, maar daar ligt de focus weer op andere dingen: http://www.w3.org/2011/08/browser-testing-charter.html

[Reactie gewijzigd door Blaise op 2 augustus 2024 03:00]

[bantoo]

Nee. Dom standaarden volgen heeft geen nut en zorgt alleen maar voor extreem trage ontwikkeling. De eeuwen die nodig zijn om een finale HTML5 spec te krijgen laat dit wel zien. W3C is vooral goed in zeer veel tijd te nemen voor hun spul.

[OddesE]

Wat je zegt klopt maar half.

Ja, het W3C heeft in het verleden lang de tijd genomen om standaarden te ontwikkelen die dan vervolgens eigenlijk vrijwel niet gebruikt worden.

Maar, nee, HTML5 laat dit nu juist *niet* zien. Bij HTML5 is men gewoon het meest logische aan het doen, namelijk het *naderhand* consensus zoeken over hoe features waarvan minstens twee browsers daadwerkelijk een implementatie hebben te implementeren. Zo krijg je standaarden die ten eerste ook daadwerkelijk goed werken en ten tweede ook echt nut hebben.

Kijk XForms, dat is nou een god voorbeeld van iets wat super lang duurt en vervolgens niet gebruikt wordt. Dát sucked. Maar dat men in HTML5 eindelijk bergen nuttige Javascript APIs toevoegt en elementen waar we al eeuwen op wachten zoals de VIDEO tag, dát is nu juist een goed voorbeeld van hoe het wél moet.

En dat HTML5 nog niet af is? Dat zal ook nog wel even duren. Men heeft bij HTML5 namelijk gekozen voor een radicaal andere aanpak. In plaats van te proberen in één ruk de hele standaard vast te leggen maakt men deze nu stukje bij beetje, feature voor feature. Het is dus eigenlijk ook onzin om te spreken over HTML5 support; Er is nog niet één browser die alle features ondersteunt en dat zal voorlopig ook nog wel even duren, want de standaard blijft groeien en evolueren. Maar dat maakt helemaal niet uit, want je gaat nu kijken naar feature support; ondersteunt deze browser feature SVG? Ja, dan maak daar gebruik van om fancy graphics te tonen. Nee? Ondersteunt hij dan misschien Canvas? Ja, teken de graphics naar het Canvas. Nee? dan tekenen we het plaatje op de server en sturen het geheel naar de client, of we gebruiken Flash etc, etc.

[Herko_ter_Horst]

Het is niet zo gek dat de standaard lijkt op wat er al is: de use-case voor deze standaard is gelijk aan die voor de door jou genoemde development tools.

[mashell]

Het hele punt van het W3C is dat er een orgaan is dat de standaarden vaststelt, en dat de rest zich daar aan houdt.

Ik dacht dat het punt was dat de industrie voorstellen doet, die alvast implementeren en die de w3c dan met een aantal jaar vertraging als standaard uitroept. Gaan zitten wachten tot de wijze grijze heren in de ivoren toren van het standaard insitiuut zelf iets bedenken is geen goed idee, dat duurt in het bijzonder van het w3c veel te lang en dat remt de innovatie.

[MacWolf]

Het hele punt van het W3C is dat er een orgaan is dat de standaarden vaststelt, en dat de rest zich daar aan houdt. Als iedereen maar wat doet krijg je geen werkend www.

Toch lijken er soms grote problemen voor te doen bij het vastleggen van standaarden. Voor sommige bedrijven gaat het standaardisatieproces soms niet snel genoeg. Om die reden is bijvoorbeeld WHATWG ontstaan (een werkgroep opgericht door Apple, Mozilla & Opera medewerkers). Ik denk dat WHATWG al veel goed werk gedaan heeft buiten W3C om (denk bijvoorbeeld aan het canvas element).

[arjankoole]

En nu maar hopen dat er niet weer een of ander groot bedrijf komt die denkt dat ze het beter weten... (Apple, Google, Microsoft) Het hele punt van het W3C is dat er een orgaan is dat de standaarden vaststelt, en dat de rest zich daar aan houdt. Als iedereen maar wat doet krijg je geen werkend www.

mede daarom zitten die 3, en opera en mozilla, ook al jaren in het W3C, en besluiten ze mee over deze standaarden.

Maar je zal vrees ik altijd eigenzinnigheid blijven houden, bij al deze browsers.

[FlowinG]

Laat de grap nu zijn dat de standaarden door diezelfde grote partijen voorgesteld worden. Als je bijvoorbeeld kijkt naar het High Resolution Time voorstel, zie je dat de editor een Microsoft dude is, Navigation Timing door een Google dude, en check de editors van die andere documenten ook.
(Performance Timeline, Resource Timing, User Timing)

[codebeat]

Het eerste wat ik dacht bij het lezen van dit artikel: "Zorg nu eens dat de HTML5 standaard rond is!" Want de snelheid testen etc, daar zijn al wel andere manieren voor om dat te testen. Bijvoorbeeld de google speedtest.

[Wim Leers]

Google Page Speed bedoel je. Dat is een synthetische test, net zoals bijvoorbeeld http://webpagetest.org. Da's zeker nuttig, maar vertelt je maar een deel van het verhaal, namelijk dat van hoe de performance evolueert in een gecontroleerde omgeving. Synthetische testen dienen dus om alles constant te houden behalve de code, zodat je kan zien of je optimalisaties een effect hebben.

Aan de andere kant heb je real user monitoring/real performance monitoring. Daarbij meet je de performance zoals die werkelijk ervaren wordt door eindgebruikers. Eindgebruikers hebben vaak een veel slechtere verbinding of een veel tragere computer dan de ontwikkelaars, en dus ook een veel hogere laadtijd (m.a.w. slechtere performance). Door middel van deze nieuwe API's wordt het mogelijk om veel betrouwbaarder performance metingen bij de gebruiker te doen. Al die gegevens worden vervolgens verzameld en geanalyseerd om de grootste bottlenecks bij échte gebruikers te vinden. Op die gegevens kan je dan weer data mining gaan toepassen.

Dit doen ze bij Google, Facebook, enzovoort om te weten te komen waar ze best hun tijd in steken om de gebruikerservaring van zoveel mogelijk gebruikers in één klap te verbeteren.

Zie http://wimleers.com/artic...lendar-2010-wpo-analytics voor een volledigere uitleg.

[codebeat]

Google Page Speed or whatever. Ik gebruik gtmetrix.com, veel betere statistieken dan die crappy webpagetest.org (sorry, werkt ook niet altijd even goed dus niet betrouwbaar).

Ontwikkelaars moeten altijd testen op oude hardware maar er is een grens. Je kunt een Windows XP bak hebben die dezelfde specs heeft als die van de buurman maar toch zijn de prestaties bij de buurman slechter. Het hangt allemaal van zoveel factoren af dat het onmogelijk is alle situaties te testen. Dus bijvoorbeeld de software die de gebruiker op zijn pc heeft staan, daar kun je en moet je ook niet willen dat je daar rekening mee moet houden.

Als je ervoor zorgt dat je scripts klein zijn (compact en snel), pagina's klein, css optimaal, geen fouten in de pagina, snelle server en caching in orde dan ben je in feite klaar. Als dat prima werkt op een wat ouder systeem dan is het prima toch. En als de test zoals gtmetrix dat uitwijst goed is maar bij de gebruiker niet, ja dan ligt het aan de systeem van de gebruiker, hier kun je onmogelijk rekening mee houden.

Dus gebruikers performance is bullshit, als jij voldoet aan standaarden en de gebruiker maakt een zooi van zijn of haar systeem, so be it. Daar kun je echt geen rekening mee gaan houden.

Van google weet ik dat ze er alles aan doen om de content zo klein mogelijk te houden etc. Daar gaan ze echt niet kijken of het bij een ieder snel laad, ze doen er immers al alles aan om alles zo snel en kleln mogelijk te krijgen dus moet het wel snel laden. Is dit niet het geval ligt het aan de configuratie van het systeem van de gebruiker maar niet aan hun systeem.

Optimaliseren kan nooit voor 100%, als je met gebruikers en systeemconfiguraties/prestaties gaat bezighouden ben je verkeerd bezig. Afhankelijk van de website, ergens moet je grenzen trekken want hoe oud is oud. Hoe ver moet je gaan. Als jij zorgt dat je aan allerlei optimale specificaties houdt dan is het okay meer kun je niet doen.

[Reactie gewijzigd door codebeat op 2 augustus 2024 03:00]