Reacties op: Google: Snelheid voor semantiek http://www.mediakip.com/google-snelheid-w3c-semantiek/ Weblog van Michel Kuik over webdesign, usability en interactie ontwerp Sat, 28 Aug 2010 22:09:57 +0000 hourly 1 http://wordpress.org/?v=3.0.1 Door: jochem http://www.mediakip.com/google-snelheid-w3c-semantiek/comment-page-1/#comment-1304 jochem Tue, 24 Nov 2009 11:12:43 +0000 http://www.mediakip.com/?p=527#comment-1304 hopelijk werkt dit dan niet! alert('Oeps, snel dit fixen!') hopelijk werkt dit dan niet! alert(‘Oeps, snel dit fixen!’)

]]> Door: Xavez http://www.mediakip.com/google-snelheid-w3c-semantiek/comment-page-1/#comment-250 Xavez Wed, 08 Apr 2009 13:15:41 +0000 http://www.mediakip.com/?p=527#comment-250 Woops, blijkbaar worden de html-elementen die ik als voorbeeld heb gebruikt niet geëscapet. Sorry for the mess! :) Woops, blijkbaar worden de html-elementen die ik als voorbeeld heb gebruikt niet geëscapet. Sorry for the mess! :)

]]> Door: Xavez http://www.mediakip.com/google-snelheid-w3c-semantiek/comment-page-1/#comment-249 Xavez Wed, 08 Apr 2009 13:14:41 +0000 http://www.mediakip.com/?p=527#comment-249 Hmmm, ergens is dat ook wel logisch, semantiek wordt afgeleid van onze taal en onze taal is nu eenmaal vrij "lang". Het kleinste semantisch element is té poly-interpretabel om bruikbaar te zijn als onderscheidend element in HTML. Eigenlijk zouden we dan qua syntaxis teruggrijpen naar <b> <i> en . Het probleem is dat je dan in de toekomst, wanneer er misschien nieuwe elementen bijkomen, niet meer scalable bent... Je zou je wel kunnen afvragen waarom we bijvoorbeeld <a>, en hebben en daarnaast langere elementen als of in plaats van en of en . Het maakt het coden wel gemakkelijker als de namen languit geschreven zijn, maar vanuit een data-optimizationstandpunt (good god wat een woord) is het inderdaad niet zo optimaal... Food for thought! Hmmm, ergens is dat ook wel logisch, semantiek wordt afgeleid van onze taal en onze taal is nu eenmaal vrij “lang”. Het kleinste semantisch element is té poly-interpretabel om bruikbaar te zijn als onderscheidend element in HTML. Eigenlijk zouden we dan qua syntaxis teruggrijpen naar en . Het probleem is dat je dan in de toekomst, wanneer er misschien nieuwe elementen bijkomen, niet meer scalable bent…

Je zou je wel kunnen afvragen waarom we bijvoorbeeld , en hebben en daarnaast langere elementen als of in plaats van en of en . Het maakt het coden wel gemakkelijker als de namen languit geschreven zijn, maar vanuit een data-optimizationstandpunt (good god wat een woord) is het inderdaad niet zo optimaal… Food for thought!

]]> Door: Michel Kuik http://www.mediakip.com/google-snelheid-w3c-semantiek/comment-page-1/#comment-248 Michel Kuik Wed, 08 Apr 2009 12:40:45 +0000 http://www.mediakip.com/?p=527#comment-248 Het is ook begrijpelijk. Zeker als je het hebt over de schaal waarop Google werkt. Wat mij bevreemd is het feit dat de meest snelle manier niet de meest semantische manier is. Je zou ook kunnen stellen dat de standaarden blijkbaar niet altijd de beste zijn... Het is ook begrijpelijk. Zeker als je het hebt over de schaal waarop Google werkt.

Wat mij bevreemd is het feit dat de meest snelle manier niet de meest semantische manier is. Je zou ook kunnen stellen dat de standaarden blijkbaar niet altijd de beste zijn…

]]> Door: Xavez http://www.mediakip.com/google-snelheid-w3c-semantiek/comment-page-1/#comment-239 Xavez Tue, 07 Apr 2009 15:02:41 +0000 http://www.mediakip.com/?p=527#comment-239 Tja, het probleem is natuurlijk dat je bij Google op zo'n schaal werkt, dat er over elk element drie keer nagedacht moet worden. Als je bijvoorbeeld ettelijke miljoenen pagina's moet serven met een button met klasse "s" in plaats van "submit", dan kan ik alleen maar gokken wat voor een besparing dat oplevert in termen van bandbreedte en snelheid. Ik begrijp ze wel eigenlijk. Laat me het zo stellen: webstandaarden zijn een goeie guideline, maar in de uiteindelijke ontwikkeling spelen er soms veel meer factoren mee: ze zijn dus zeker niet de heilige graal. Bekijk het een beetje als spelling: het is belangrijk dat je die guidelines zo goed mogelijk volgt, maar uiteindelijk is de verstaanbaarheid van de boodschap criterium #1 in communicatie. Of je dat met pannekoeken of pannenkoeken doet, maakt eigenlijk weinig uit. Tja, het probleem is natuurlijk dat je bij Google op zo’n schaal werkt, dat er over elk element drie keer nagedacht moet worden. Als je bijvoorbeeld ettelijke miljoenen pagina’s moet serven met een button met klasse “s” in plaats van “submit”, dan kan ik alleen maar gokken wat voor een besparing dat oplevert in termen van bandbreedte en snelheid. Ik begrijp ze wel eigenlijk.

Laat me het zo stellen: webstandaarden zijn een goeie guideline, maar in de uiteindelijke ontwikkeling spelen er soms veel meer factoren mee: ze zijn dus zeker niet de heilige graal. Bekijk het een beetje als spelling: het is belangrijk dat je die guidelines zo goed mogelijk volgt, maar uiteindelijk is de verstaanbaarheid van de boodschap criterium #1 in communicatie. Of je dat met pannekoeken of pannenkoeken doet, maakt eigenlijk weinig uit.

]]>