Webstandaarden en de toekomst
Over IE, standaarden en HTML 5
Als professioneel web-designer/developer/ontwerper/master is er toch het een en het andere dat verandert. Denkwijzen veranderen nu eenmaal en misschien door druk van buitenaf, en dan mag je zoveel principes hebben zoals je wil.
Het cliché van vroeger “de klant is koning” is nu een routine antwoord geworden.
Eerst en vooral de denkwijze
Tegenwoordig maakt het mij gene zak meer uit of je website valideert of niet, - diegene die ik maak wel - , of je nu HTML 4.01 transitional gebruikt of Strict of 1.1. Ik zoek naar info en lees artikels of deze nu in een feed-reader zitten ( zo zonder opmaakl weet je wel ) of op de site zelf als je navigatie nu een usability-test zou kunnen doorstaan of niet.
RSS begint ook de “gewone” webmens te bereiken dus eigenlijk waarom nog zorgen maken over layout of validatie ? Deze vraag stelde zich Erlend al, en hebben we dan echt nood aan een browser die je pagina niet weergeeft als deze niet correct volgens de regels is gemaakt. XHTML blijkt niet het succes te zijn geworden wat het beloofde te worden, en je zou pas een webmaster zijn geweest als je website met application/xhtml+xml werd geparst door alle browsers.
Deze doelen heb ik allemaal nagestreefd en voor wat ? Om nu met 3 computers thuis te moeten zitten ? 1 voor win browsers, 1 voor mac browsers - nog niet - en nog één voor Internet Explorer 7 die opeens ten toneel verschijnt en ook om conditional comment vraagt , en ooit misschien HTML 5 die ons nog meer roet in de dagelijkse tagsoep komt gooien ? Want we zullen toch een IE8 nodig hebben die daarmee kan werken, alle andere browsers zullen reeds ge-update zijn.
Vanaf nu moet ik ook
Webstandaarden bekijken vanuit het standpunt van de klant, en niet zoals ik het graag deed uit mijn eigen zicht, met alle regels in het hoofd en kant en klare oplossingen via CSS.
Beantwoorden van vragen van standaarden-purealisten en CSS-apostelen met clichés.
Gelezen: 1240 | XHTML, CSS, Webstandaarden







Op Monday 15 January 2007
Het probleem met niet-validerende websites is dat deze voor de mobiele surfers (een snel groeiende markt waar in de meeste gevallen geen browser met een ingebouwde parscorrectie aanwezig is omdat dit teveel rekenkracht kost) ontoegankelijk zullen zijn.
En het internet is ten slotte ook bedacht met als doel het verspreiden van informatie (universiteiten en dergelijke), dus op dat vlak gaat het nu alleen nog maar de goede richting uit.
Naar mijn mening is inhoud met rss (samengevatte informatie) in zijn volledig vorm aanbieden niet hét ideale verspreidingsmechanisme voor informatie, maar daar is xml wél voor bedacht
En bovenop die xml kan dan vervolgens de opmaak worden aangebracht. Als dit nu gebeurt door een serverside alternatief aan te bieden en/of een clientside processor te gebruiken, maakt me allemaal niet uit om eerlijk te zijn. Zolang het maar kan getransformeerd worden naar eigen wens.
Op zich vind ik het ook wel jammer dat XHtml 1.1 nooit écht heeft doorgebroken, want nu men eindelijk de toepassingen hiervoor begint te bedenken, staat de opvolger van html al in de steigers.
Het W3C neemt overigens delen van Html5 over in hun toekomstige aanbeveling, al is het nog maar de vraag als hun invloed in dit gebruikers voor gebruikers web (hypewoord iemand?
) niet wegebt ten voordele van de WHATWG.
Over application/xhtml+xml: het achterliggende principe klinkt misschien mooi op papier, maar in de praktijk is het opzettelijk incompatibel maken van deze standaard onvergefelijk. En ‘natuurlijk’ kan je met HTTP_ACCEPT werken, maar het web draait toch ook om uniformiteit..
Weet ook dat je virtuele besturingssystemen kan draaien
niet altijd even handig, maar toch zeker een budgetvriendelijkere oplossing.
En IE8 zal waarschijnlijk wéér een hoop frustratie en teleurstelling met zich meebrengen, net als IE7. Sommige dingen zullen blijkbaar nooit veranderen..
Ik ben ‘blij’ dat ik niet de enige ben die met dit soort problemen worstelt
en een website ontwikkelen uit zich in de (echte /bedrijfs)wereld inderdaad tot het sluiten van compromissen.
Op Monday 15 January 2007
Mark,
niet dat ik kritiek wil leveren maar herlees dit even:
Wenbstandaarden bekijken vanuit het standpunt van de klant, …..
webstandaarden ken ik wenbstandaarden daarintegen niet
Op Monday 15 January 2007
Mark, het is in principe hel simpel. Idealisme is prima, maar als je baas (of de accountmanager die het aan de klant beloofd heeft) zegt dat vanmiddag die site nog opgeleverd moet worden en je hebt de pech dat je die avond naar de verjaardag van je moeder moet dan ga je niet meer lopen nadenken over toegankelijkheid en validatie, Dan maar de lompe, snelle oplossing die in ieder geval werkt. Leuk? Nee. Fact of life? Ja… Als het moet ben ik zelfs niet te beroerd om framesets te gebruiken. Baas blij, klant blij en ik op tijd naar huis.
Ok, begin maar te schieten
Op Monday 15 January 2007
Nog even reageren op webscriptz…
Als je mensen wijst op spelfouten zorg er dan voor dat je zelf correct Nederlands schrijft. Daarentegen.
Op Monday 15 January 2007
Ik begrijp je probleem niet helemaal. Wat is het punt dat je wilt maken? Dat het niet meer uitmaakt of je standaarden gebruikt of niet?
Wat ik ook niet begrijp in de hele discussie rond het gebruiken van standaarden is dat mensen denken dat het gebruiken van webstandaarden moeilijker is, meer tijd kost en niet altijd haalbaar is. Dat begrijp ik echt niet.
Het bouwen volgens standaarden heeft het voor mij alleen maar veel makkelijker gemaakt. Websites werken in nagenoeg alle browsers. Websites zijn makkelijk te onderhouden (dankzij css etc). Het bouwen gaat snel en eenvoudig.
“Idealisme is prima, maar als je baas (of de accountmanager die het aan de klant beloofd heeft) zegt dat vanmiddag die site nog opgeleverd moet worden en je hebt de pech dat je die avond naar de verjaardag van je moeder moet dan ga je niet meer lopen nadenken over toegankelijkheid en validatie” Dit is een goed voorbeeld. Als je inderdaad snel een deadline te halen hebt, dan bouw je toch juist wel met standaarden? Dan zorg je er toch voor dat je netjes codeert en geen fouten maakt? Want ieder foutje kan er voor zorgen dat een of andere browser raar gaat doen. En zo’n fout opsporen kost veel meer tijd dan het gelijk goed doen.
Dat je in de haast een alt tag vergeet in te vullen, ok. Maar verder zie ik niet in hoe webstandaarden meer tijd of moeite zouden kosten. Voor mij geld het omgekeerde.
Op Monday 15 January 2007
Goh, het is gewoon zo dat je nooit perfectdingen kan afwerken. Bedoeling is wel dat je het zo goed mogelijk probeert te doen en een goede planning is daarbij natuurlijk ook essentieel. Ervaring helpt ook om problemen sneller uit de wereld te helpen.
Volgens mij gaan webstandaarden daar nog lang een ijkpunt bij blijven. RSS-lezers blijven helaas nog steeds een marginaal verschijnsel. Daarbij komt ook dat je met het grafisch ontwerp (dat je in dit geval met CSS erbijbrengt) echt wel het verschil kan maken in hoe iemand met een site omgaat en hoe hij er in verhouding toe staat. Vorm IS dus dikwijls functie
Op Monday 15 January 2007
De klant is inderdaad koning als het gaat over wat de website doet/inhoudt en hoe ze eruit ziet.
Hoe wij ze maken en coden gaat hem doorgaans weinig aan.
Ik vertel onze klanten amper over XHTML/CSS. Dat interesseert hen gewoon niet. Toch is elke site die wij opleveren volgens “de regels van de stiel”.
Ik zie het als een verplichting aan de klant om hen een valid site op te leveren, met alle voordelen in de toekomst -ook al beseffen ze dat niet altijd- .
Daarnaast is het ook een zekere trots die ons drijft om websites met degelijke code op te leveren.
Op Monday 15 January 2007
“Vorm IS dus dikwijls functie”
Het punt dat Erlend en Mark willen overbrengen is dat je pure xml informatie kan aanbieden (al dan niet gekoppeld aan een optionele stylesheet van de webmaster, kwestie van een huisstijl te hebben e.d.), en de gebruikers dus zélf de keuze laat om deze informatie naar eigen wens op te maken/transformeren (eventueel naar html, maar die keuze kan je dan aan de bezoekers zelf overlaten).
Misschien kan je dat beschouwen alsof dat het html wiel opnieuw wordt uitgevonden, maar deze aanpak biedt op zich véél meer mogelijkheden.
Op Monday 15 January 2007
Ik bekijk het een beetje omgekeerd. Veel sites hebben die inhoud sowieso apart steken in DB, XML of whatever. Ik vind het dus eerder een discussie OF die beschikbaar gesteld wordt los van de omgeving waarin ze normaal bedoeld is om te gebruiken. En voor de meeste sites (of hoe ik het dan op dat moment moet noemen
) is dat zeker een goede zaak.
Voor mij beperkt het internet zich echter niet enkel tot de data overbrengen maar ook hoe die wordt overgebracht, die absoluut een meerwaarde kan bijbrengen. En daarin is xml/newsreaders maar één deel van.
Op Monday 15 January 2007
Mijn ogen, mijn ogen, zoveel taalfouten! Blijkbaar stond er op het maken van deze post ook een deadline
@Matthijs: Het is altattribuut, niet alttag!
@Mark: Als je professioneel wil overkomen moet je ten minste het woord professioneel juist kunnen spellen! De tip hierbij die ze ons in de middelbare school meegaven en die we nooit zullen vergeten: je draagt 1 frak en 2 sokken, dus 1 f en 2 s’en!
Op Monday 15 January 2007
Zit zeker iets in, de informatiearchitectuur (onder andere door vormgeving) op zich is nét zo belangrijk als de data zelf.
Want als men deze data niet kan terugvinden in zijn pure vorm (rechtstreeks uit de database) of er niet behoorlijk in kan navigeren, is het aanbieden ervan vrij nutteloos.
Op die manier hoeft men ook niet alle informatie te downloaden, maar alleen de voor iedere zoektocht relevante.
Echter, als je de data kan presenteren volgens bepaalde afspraken (microformats/embedded metadata/.. , maar dan in bijvoorbeeld xml als drager) kan iedereen kiezen om deze data op een voor zichzelf overzichtelijke manier rangschikken/transformeren volgens categorie, tijd, geo-/thema tags, .. en zo het doel van een design als informatiearchitectuur voorbijstreven. En als je dan dit design alleen als gimmick gebruikt om je huisstijl te presenteren, of om te tonen hoe origineel (al dan niet toegankelijk) je iets kan presenteren dan kan je dit evengoed optioneel laten toepassen, en mensen hun eigen lievelingsvormgeving/uniforme toegankelijkheids’features’/.. laten gebruiken.
Het optionele karakter hiervan vind ik uiteraard belangrijk.
maar inderdaad nog geen volwaardig alternatief.
Want newsreaders en dergelijke zijn misschien een goeie aanloop naar dit principe toe
Op Monday 15 January 2007
Allereerst bestaat HTML Strict 1.1 noch XHTML Strict 1.1.
Daarnaast kan ik matthijs’ kritiek op Hueij helemaal snappen, ik werk vaak (veel) sneller als ik met semantische webstandaarden werk.
Op Monday 15 January 2007
@ iedereen:
Bedankt voor jullie massa aan reacties en voor degene die de point verloren hebben: Ik ben enorm gefrustreerd over het feit dat webdesign volgens de standaarden nu nog moeilijker geworden is dan dat het al was, beginnelingen zijn niet echt geneigd om deze last nu ook nog op zich te nemen.
Ik steun nog steeds de webstandaarden, maar maak mij niet meer druk over het feit dat anderen dit niet willen doen.
@ Danny & webscriptz: Sorry voor mijn spelfouten ( professioneel verkeerd schrijven was een echte schande ), zijn de laatste tijd uiterst zeldzaam, maar nu en dan …
Op Monday 15 January 2007
In ieder geval vind ik dat spelfaudten via mail gemeld mogen worden, teneinde dit soort comments te voorkomen
En de toekomst van webstandaarden ziet er zeker niet makkelijker uit, maar gaat wél de goede richting uit.
Op Tuesday 16 January 2007
Ik denk ook dat het zich, sinds de grote push van webstandaarden, wat heeft opgesplitst heeft in twee kampen. Eén kamp snapt niet meer dat je zonder webstandaarden zou werken en het ander heeft de hele ‘hype’ wat aan zich laten voorbijgaan.
Volgens mij is de eerste groep gelukkig wel groot genoeg ondertussen en zullen de mensen die achterblijven schoorvoetend ook beginnen overschakelen. Gewoon omdat iedereen op die manier werkt.
Op Wednesday 06 February 2008
Het is een taak om je als professioneel ontwerper met de techniek en de mogelijkheden bezig te houden. Vandaag hot is morgen oubollig. Het internet werkt organisch en zal uiteindelijk worden gevormd door zijn gebruikers.
Standaarden zijn handig maar niet zaligmakend.
Het spanningsveld is een website die door iedereen goed bekeken kan worden, standaarden zullen dus altijd een rol spelen maar wel op een dynamische wijze.
Uiteindelijk zal elke webstandaard om moeten als de gebruikers en ontwikkelaars van internet een andere kant op gaan. Wel of geen standaard, uiteindelijk wordt internet door zijn gebruikers bepaald.