[DISC] SEO, hoe denken we daarover?

[Verwijderd]

Modbreak:

Dit topic is afgesplitst van Webwereld: hoe het niet moet (en waarom) / markup

Dat developers richting gebruik van "div'" gaan in plaats van de zo vaak opgehemelde semantiek ligt imo puur aan de community eromheen icm het blogosfeertje dat er heerst. De css layout geilheid die een tijdje geleden overweldigend aanwezig was, met bijna complete offeraltaren voor de meest simpele voorbeeldjes in css zijn hier debet aan.

En vervolgens krijg je 1001 volgelingen die elkaar maar wat napraten, maar die de achterliggende redenen totaal niet begrijpen. Immers, die andere 1000 personen hebben het puur over css layout, tabeless design. De mensen die dit lezen gaan vervolgens aan het kloppen om alles om te zetten naar "div" immers, het was toch de bedoeling dat je geen tables meer zou gebruiken volgens dat artikel En daar komt nog bij dat elke semantiek insteek qua zoekalgoritmes nog steeds crap is. Google en semantiek, vooralsnog niet. Semantiek is maar 0.X procent van de ranking factoren.

Dat is hetzelfde als die mensen die nog steeds beweren dat een website friendly urls moet hebben want dan wordt die meer geindexeerd tov dynamic urls.

Nog steeds is er in het bedrijfsleven echt een "I don't give a shit" mentaliteit op dit onderwerp. Het zal de directie geen warm tintelend gevoel opleveren als hij in de source kijkt, en nog steeds denken developers dat dit het geval is omdat ze redeneren uit de techniek. Er zijn geen tco of roi modellen toe te passen (waar ze wel een warm tintelend gevoel van krijgen), en de investeringen zijn nog altijd aanzienlijk in tegenstelling tot wat de bloggers ons willen laten geloven. En zeker in India en Roemenië, waar je tegenwoordig veel outsourcing ziet zijn ze qua web nog ver achter. Ze redeneren nog als software engineers, en niet als web developers.

Dat is deels een issue van de techniek, maar ook een issue van missende ondersteuning door IE van die techniek. Komt nog bij, dat het semantiek verhaal totaal niet speelt bij developers, maar wel bij webdesigners. Met webdesign alleen is tegenwoordig geen droog brood meer te verdienen, dus die investeringen moeten voor een bedrijf ergens vandaan komen. Vooralsnog is het nog steeds een technology push waar ik zelf ook aan mee doe, maar die bedrijfsmatig gezien nog steeds niet aanzienlijk meer rendabel is, of uberhaupt valt te berekenen naar een model.

[ Voor 13% gewijzigd door André op 09-05-2005 23:56 ]

[Verwijderd]

Dat is hetzelfde als die mensen die nog steeds beweren dat een website friendly urls moet hebben want dan wordt die meer geindexeerd tov dynamic urls.

Is dat niet zo dan? Zelfs Google heeft aangeduid dat het hebben van zulke URIs wel degelijk voordelen biedt. (Daarnaast merk ik het zelf ook nogal...)

[faabman]

Verwijderd schreef op maandag 09 mei 2005 @ 10:17:
Nog steeds is er in het bedrijfsleven echt een "I don't give a shit" mentaliteit op dit onderwerp. Het zal de directie geen warm tintelend gevoel opleveren als hij in de source kijkt, en nog steeds denken developers dat dit het geval is omdat ze redeneren uit de techniek.

Directieleden zullen geen warm gevoel krijgen wanneer ze in de source kijken. Maar dat bedrijven er mee bezig zijn wordt imho toch wel bewezen door bijv. de recent online geplaatste site van TNT www.tnt.com

Er zijn geen tco of roi modellen toe te passen (waar ze wel een warm tintelend gevoel van krijgen), en de investeringen zijn nog altijd aanzienlijk in tegenstelling tot wat de bloggers ons willen laten geloven.

Je kunt per definitie op elke investering een ROI of TCO model toepassen, dus deze redenering klopt niet. Het probleem is dat er (nog) veel te weinig (wetenschappelijk) onderzoek wordt gedaan naar de vraagstukken die relevant zijn voor websites. En dan heb ik het niet alleen over ROI / TCO, maar ook over vraagstukken als toegankelijkheid / bruikbaarheid / etc.

Verwijderd schreef op maandag 09 mei 2005 @ 10:17: En daar komt nog bij dat elke semantiek insteek qua zoekalgoritmes nog steeds crap is. Google en semantiek, vooralsnog niet. Semantiek is maar 0.X procent van de ranking factoren.

Dat is hetzelfde als die mensen die nog steeds beweren dat een website friendly urls moet hebben want dan wordt die meer geindexeerd tov dynamic urls.

Is dat zo?? Pas voor een aantal sites beide methoden toe en die sites worden behoorlijk goed geïndexeerd...

[AtleX]

faabman schreef op maandag 09 mei 2005 @ 10:59:
[...]

Directieleden zullen geen warm gevoel krijgen wanneer ze in de source kijken. Maar dat bedrijven er mee bezig zijn wordt imho toch wel bewezen door bijv. de recent online geplaatste site van TNT www.tnt.com

http://validator.w3.org/c...ntgroup/en_corporate.html
Maar 1 klein, eenvoudig op te lossen, foutje. Dat vind ik inderdaad netjes. Al is het op sommige achterliggende pagina's nog wel een bende

1
[...]


Is dat zo?? Pas voor een aantal sites beide methoden toe en die sites worden behoorlijk goed geïndexeerd...

Toen ik mijn website van crap code naar nette XHTML had omgebouwd steeg mijn indexering tot bijna 100% en de 'vindbaarheid' steeg ook sterk. Mijn hoeveelheid bezoekers verdrievoudigde in de eerste 2 maanden na het online zetten van de nieuwe site. Dus ja, semantiek is belangrijk en Google heeft dat ook al eens gemeld al kan ik die pagina nu even niet vinden

[ Voor 6% gewijzigd door AtleX op 09-05-2005 11:21 ]

[BtM909]

Bedoel je deze link: http://www.google.nl/intl/nl/webmasters/guidelines.html

[Verwijderd]

Verwijderd schreef op maandag 09 mei 2005 @ 10:47:
[...]
Is dat niet zo dan? Zelfs Google heeft aangeduid dat het hebben van zulke URIs wel degelijk voordelen biedt. (Daarnaast merk ik het zelf ook nogal...)

Nope, Google, en elke andere moderne spider indexeert een dynamische site net zo goed als een site met friendly urls. De techniek is in de loop van de jaren zo verbeterd dat het een poep en een scheet is geworden voor spiders.

Waar het verschil zit, is dat een friendly url based site "sneller" wordt geindexeerd puur omdat Google een dynamische site die al van nature iets zwaarder is, niet wil platleggen met zijn spider en deze dus opzettelijk iets minder snel laat indexeren. In de praktijk maakt dit op zijn hoogst een dag uit, niet interessant dus voor een complete friendly urls investering waar je het risico loopt op verlopen urls en de verhoogde kosten qua onderhoud.

[Verwijderd]

AtleX schreef op maandag 09 mei 2005 @ 11:16:
[...]

http://validator.w3.org/c...ntgroup/en_corporate.html
Maar 1 klein, eenvoudig op te lossen, foutje. Dat vind ik inderdaad netjes. Al is het op sommige achterliggende pagina's nog wel een bende

[...]

Toen ik mijn website van crap code naar nette XHTML had omgebouwd steeg mijn indexering tot bijna 100% en de 'vindbaarheid' steeg ook sterk. Mijn hoeveelheid bezoekers verdrievoudigde in de eerste 2 maanden na het online zetten van de nieuwe site. Dus ja, semantiek is belangrijk en Google heeft dat ook al eens gemeld al kan ik die pagina nu even niet vinden

Semantiek is maar een piepkleine factor in je ranking. Een belangrijk onderdeel van hogere ranking is ook de prioriteit die je website krijgt. Zodra je website een behoorlijke verandering heeft ondergaan krijgt je website daar een rankings factor voor. Het gaat er niet om hoe hoog je staat, het gaat erom hoe lang je in de top 10 blijft staan.

Er zijn een enorme hoeveelheid factoren waar Google op bepaald, en de toppers zijn PageRank, Inkomende links met keywords in de tekst, keywords in url, domain, title, en ja nog steeds de metatags. Voorbeeld is bijvoorbeeld de keywords metatag, waarbij google controleerd of er voor elke keyword in ieder geval een referentie is in de body van je document. Verder heb je nog het aantal outside links, de context van een link, de stabiliteit van links...etc..

Er wordt zeker gekeken naar woorden die tussen <b> of <strong> staan, maar wat de semantische vorm daarvan is, dat is maar een minor factor.
Elke commerciele website met interesse in zoekmachines zal ook aankloppen bij partijen als Gladior, die dagelijks niets anders doen dan websites ranken voor zoekmachines. Het is niet voor niets dat de algoritmes van Google continue worden aangepast om het deze bedrijven moeilijk te maken.

[ Voor 21% gewijzigd door Verwijderd op 09-05-2005 11:40 ]

[faabman]

Verwijderd schreef op maandag 09 mei 2005 @ 11:27:
Nope, Google, en elke andere moderne spider indexeert een dynamische site net zo goed als een site met friendly urls. De techniek is in de loop van de jaren zo verbeterd dat het een poep en een scheet is geworden voor spiders.

Waar het verschil zit, is dat een friendly url based site "sneller" wordt geindexeerd puur omdat Google een dynamische site die al van nature iets zwaarder is, niet wil platleggen met zijn spider en deze dus opzettelijk iets minder snel laat indexeren. In de praktijk maakt dit op zijn hoogst een dag uit, niet interessant dus voor een complete friendly urls investering waar je het risico loopt op verlopen urls en de verhoogde kosten qua onderhoud.

Google raad anders wel aan om URLs te gebruiken zonder vraagteken...

In de praktijk maak je niet alleen gebruik van statische URLs omdat dat goed is voor zoekmachines, maar ook omdat de totale navigatie door je site erdoor wordt verbeterd. Denk hierbij aan de mogelijkhied van gebruikers om je URI te "hacken" en een duidelijker overzicht van de positie / relaties van een pagina binnen je site. Het "risico" van verlopen URLs is af te vangen door je 404 pagina te vervangen door een pagina met een boodschap en je sitemap...

Verwijderd schreef op maandag 09 mei 2005 @ 11:34:
Elke commerciele website met interesse in zoekmachines zal ook aankloppen bij partijen als Gladior, die dagelijks niets anders doen dan websites ranken voor zoekmachines. Het is niet voor niets dat de algoritmes van Google continue worden aangepast om het deze bedrijven moeilijk te maken.

Ik raad opdrachtgevers juist altijd af om in zee te gaan met partijen als Gladior. En dat is dan vooral om de strekking van dit artikel.

SEO ligt wat mij betreft veel meer in het online zetten van voor jou doelgroep relevante content in een technisch geoptimaliseerd jasje. Zo nodig ondersteund door Ad Campagnes en copywriters om de relevantie van je content te verbeteren. Het enige bedrijf wat ik ken en stelt het zo aan te pakken is Tribal.

we gaan nu wel heer ver offtopic geloof ik

[Verwijderd]

faabman schreef op maandag 09 mei 2005 @ 12:05:
Google raad anders wel aan om URLs te gebruiken zonder vraagteken...

Heb je hier een bron van? Er is geen enkele technische beperking voor spiders. Het vraagteken=deny verhaal is echt al geruime tijd niet meer aan de orde, maar het wordt nog steeds in stand gehouden.

In de praktijk maak je niet alleen gebruik van statische URLs omdat dat goed is voor zoekmachines, maar ook omdat de totale navigatie door je site erdoor wordt verbeterd. Denk hierbij aan de mogelijkhied van gebruikers om je URI te "hacken" en een duidelijker overzicht van de positie / relaties van een pagina binnen je site. Het "risico" van verlopen URLs is af te vangen door je 404 pagina te vervangen door een pagina met een boodschap en je sitemap...

Nofi, begin nu niet met zaken als URI hacking te gooien, dan ga je echt met non-argumenten gooien URI hacking heeft niets te maken met Google maar met de website. Het is een van de beginselen om gevoelige informatie niet de mogelijkheid te geven gecached te worden (oa session ids), en idem voor een andere soorten informatie die je toegang geven tot informatie waar je niet mag komen. Dat Google vind dat de risico's door middel van static urls relatief lager worden is dat het benoemen van een probleem met een maskering van het probleem. Het probleem blijft, het wordt alleen niet meer dynamisch toegankelijk gemaakt. Als dergelijke zaken mogelijk zijn, dan zit er in de basis van je applicatie iets fout, en niet in de presentatie en de toegang tot die presentatie.

Static urls hebben zeker hun doel, maar dan wel op een manier die een bezoeker voorziet van de standaard adressen als /shop /products /contact maar dan heb je de functionaliteit ook wel gehad. Er is geen enkele bezoeker die een url als http://www.tweakers.net/p.../lcd/apple/cinema/22inch/ net zo goed onthoud als http://www.tweakers.net/pricewatch.aspx?productid=10 om maar even met een enorm belachelijk voorbeeld te komen.

Gladior zit qua dienstverlening absoluut op het randje, en tja dat je is gepakt kan worden, dat is een risico wat je loopt en daar hou je rekening mee. Sterker nog, je wordt gepakt als je zulke dienstverlening gaat doen. De resultaten echter, of ze nu netjes zijn of niet, zijn lovend dus de moeite waard. Een full service bureau als Tribal ermee vergelijken is dan ook appels en peren vergelijken. Tribal levert een totaal andere dienstverlening en daarbij ook een totaal ander prijskaartje. Tribal zet je niet op alles wat los en vast zit in, dat doe je echt met een specifieke plan en een doel, het is geen accesoire van je website. Gladior is een product, Tribal is het bureau wat een product inzet in een totale marketingactiviteit en ze hebben toevallig een eigen product naast hun andere activiteiten. Gladior is ook puur een SEO boer, ze doen niets aan viral marketing of wat dan ook.

[ Voor 15% gewijzigd door Verwijderd op 09-05-2005 13:43 ]

[Verwijderd]

Rowanov schreef op maandag 09 mei 2005 @ 13:19:
[...]

Dat was juist het hele punt van Zengarden, de designer van Zengarden zegt zelf ook (in zijn boek o.a.) dat zijn code vanuit semantisch oogpunt vele male beter had gekund. Hij heeft het echter zo gedaan zodat de deelnemers iets meer 'haakjes' hadden om hun design aan op te hangen. Voor de rest kom je ook best wel veel span's tegen in de code van Zengarden en dat had ook wat minder gekund. AL met al was Zengarden meer om deze techniek bij een wat groter publiek over te brengen en dat is imho aardig gelukt.

Is dat boek een beetje leuk eigenlijk? Ik heb het een paar weken besteld bij amazon.com maar ik heb het nog steeds niet Als het goed is sta ik er ook in (alleen m'n naam, maar toch leuk )

Verwijderd schreef op maandag 09 mei 2005 @ 13:35:
[...]


Heb je hier een bron van? Er is geen enkele technische beperking voor spiders. Het vraagteken=deny verhaal is echt al geruime tijd niet meer aan de orde, maar het wordt nog steeds in stand gehouden.

Als u kiest voor het gebruik van dynamische pagina's (bijvoorbeeld pagina's waarin het karakter '?' in de URL voorkomt), bedenk dan dat veel zoekmachines makkelijker overweg kunnen met statische dan met dynamische pagina's. Het helpt als u werkt met korte parameters en als u het aantal parameters klein houdt. Bron: Google

Je hebt deels wel gelijk dat er geen technische beperkingen zijn maar toch raden ze het af. Ik werk zelf ook veel liever met nette urls. Die zijn makkelijker te onthouden en er zijn inderdaad zoekmachines die ?bla=tralal&sjalala=nee niet accepteren. Google is niet de enige zoekmachine ter wereld

Maar ik geloof dat dit wel weer heel erg off-topic gaat

[faabman]

Verwijderd schreef op maandag 09 mei 2005 @ 13:35:
[...]


Heb je hier... ...gehouden.

quote: http://www.google.nl/intl/nl/webmasters/guidelines.html

Als u kiest voor het gebruik van dynamische pagina's (bijvoorbeeld pagina's waarin het karakter '?' in de URL voorkomt), bedenk dan dat veel zoekmachines makkelijker overweg kunnen met statische dan met dynamische pagina's. Het helpt als u werkt met korte parameters en als u het aantal parameters klein houdt.

Nofi, begin... ...voorbeeld te komen.

Of ik begrijp jou niet, of jij begrijp mij niet. Ik doel in ieder geval op dit verhaal en dan specifiek over de betekenis die daar aan het begrip hacken wordt gegeven

Gladior... ...dus de moeite waard.

Ik vraag me af of de resultaten lovend zijn, als ik naar het

Een full service... ...wat dan ook.

Ik denk dat Tribal SEO wel degelijk als een apart product benadert... Het punt wat ik probeer te maken is dat Tribal SEO aanpakt op een manier die in ieder geval niet strookt met de regels die zoekmachines opstellen en waarvan ik zelf heb ervaren dat ze wèl werken (pas zelf eigenlijk dezelfde methode toe).

[ Voor 45% gewijzigd door faabman op 09-05-2005 14:11 . Reden: ff de quotes wat ingekort ]

[Verwijderd]

De friendly urls, zoals ze die uitleggen in de link is inderdaad wat ik dus al noemde, /shop / products verhaal. De herkenbare kant dus HET doel van friendly urls in eerste instantie. Maar qua hacking van een dienst, dat moet je niet gaan wijten aan de presentatievorm van een link. Dat bedoelde ik

Dat was wat ik dus zei SEO, is een onderdeel van de marketing waar ze over praten. Ad campaigns is imo ook geen SEO. Het is een middel in het totale marketing plaatje. Dat Tribal dat onder zoekmachine optimalizatie zet, dat moeten ze helemaal zelf weten natuurlijk, maar het is toch echt een marketing instrument, geen optimalisatie instrument. Vergeet ook niet de tarieven van ad campagns, die zijn niet mis en kunnen zorgen voor onaangename kosten ... dat hebben we zelf ook eens op de harde manier gemerkt

Dit gaan idd zwaar offtopic, ..

[ Voor 4% gewijzigd door Verwijderd op 09-05-2005 14:36 ]

[eamelink]

Verwijderd schreef op maandag 09 mei 2005 @ 14:35:
De friendly urls, zoals ze die uitleggen in de link is inderdaad wat ik dus al noemde, /shop / products verhaal. De herkenbare kant dus HET doel van friendly urls in eerste instantie.

Maar dan gaat het naar User Friendly URLS en niet naar Search Enginge FU's. Opzich zouden user friendly urls best handig kunnen zijn, stel je voor dat een domein.com/contact altijd naar een contactpagina wijst, en een domein.com/sitemap altijd naar een sitemap, of in ieder geval bij véél websites. Dat zou opzich handig zijn.

Maar over het algemeen zijn die dingen niet echt nuttig, in m'n bookmarks gooi ik net zo graag een uri van 150 tekens als eentje van 60 die 'friendly' is. Hoevaak typ je nou zelf vaak een uri in, die veel verder gaat dan een (sub+)domein plus hooguit één dir? Ik vrij zelden moet ik zeggen.

[faabman]

Verwijderd schreef op maandag 09 mei 2005 @ 14:35:
De friendly urls, zoals ze die uitleggen in de link is inderdaad wat ik dus al noemde, /shop / products verhaal. De herkenbare kant dus HET doel van friendly urls in eerste instantie. Maar qua hacking van een dienst, dat moet je niet gaan wijten aan de presentatievorm van een link. Dat bedoelde ik

Mooi, dan bedoelden we in ieder geval hetzelfde

Dat was wat ik dus zei SEO, is een onderdeel van de marketing waar ze over praten. Ad campaigns is imo ook geen SEO. Het is een middel in het totale marketing plaatje. Dat Tribal dat onder zoekmachine optimalizatie zet, dat moeten ze helemaal zelf weten natuurlijk, maar het is toch echt een marketing instrument, geen optimalisatie instrument.

Daar heb je idd een punt. Misschien is het in deze idd beter om van zoekmachine-marketing te spreken.

Vergeet ook niet de tarieven van ad campagns, die zijn niet mis en kunnen zorgen voor onaangename kosten ... dat hebben we zelf ook eens op de harde manier gemerkt

Ervaar zelf vooral dat je goed op je maximale dagbesteding moet letten.

Dit gaan idd zwaar offtopic, ..

En daarom heeft André e.e.a afgesplits

[.Johnny]

Kan iemand misschien de autoriteit posten die beweert dat HTML semantische opmaak toestaat? Volgens mij wordt hier structuur en semantiek door elkaar gehaald. Sinds wanneer zegt een <p> tag iets over de inhoud? hoe kun je dat dan semantisch noemen? in XML kun je daar nog wel over beginnen, maar zolang 't over HTML gaat kun je die verwarring beter voorkomen.

[T-MOB]

GIJoke schreef op dinsdag 10 mei 2005 @ 01:14:
Kan iemand misschien de autoriteit posten die beweert dat HTML semantische opmaak toestaat? Volgens mij wordt hier structuur en semantiek door elkaar gehaald. Sinds wanneer zegt een <p> tag iets over de inhoud? hoe kun je dat dan semantisch noemen? in XML kun je daar nog wel over beginnen, maar zolang 't over HTML gaat kun je die verwarring beter voorkomen.

Als je bedoelt dat het het woord ongelukkig gekozen is ben ik het wel met je eens . Maar een <h1> zegt toch echt meer over het belang van de inhoud dan een <span class="kop1">. In dezelfde trant geeft een <ul> of <dl> beter aan dat er een relatie is tussen de de kinderen ervan dan een <div> vol spans die leuk gestyled zijn. Dat is wat men bedoeld met semantische opmaak. Een computer heeft toch geen flauw benul van betekenis, ook niet met XML. Maar om daar nu over te gaan zeveren...

[Verwijderd]

Nope, Google, en elke andere moderne spider indexeert een dynamische site net zo goed als een site met friendly urls. De techniek is in de loop van de jaren zo verbeterd dat het een poep en een scheet is geworden voor spiders.

Dus /contact en /?id=43 worden op dezelfde manier geindexeerd? Zelfs het gebruik van - of _ maakt uit in een URI voor indexering. Hoewel het klopt dat ook "dynamische URIs" (onzinnige naam uiteraard aangezien de URIs die ik voor m'n weblog gebruik ook niet echt een statische pagina representeren ofzo) geindexeerd worden geloof ik dat er wel degelijk verschil zit bij de zoekresultaten.

[Verwijderd]

GIJoke schreef op dinsdag 10 mei 2005 @ 01:14:
Kan iemand misschien de autoriteit posten die beweert dat HTML semantische opmaak toestaat? Volgens mij wordt hier structuur en semantiek door elkaar gehaald. Sinds wanneer zegt een <p> tag iets over de inhoud? hoe kun je dat dan semantisch noemen? in XML kun je daar nog wel over beginnen, maar zolang 't over HTML gaat kun je die verwarring beter voorkomen.

wat vertel je me nu? wat is volgens jou de definitie van semantiek dan?
in xml kan je helemaal nik smet semantiek, juist omdat xml niks betekend, in voorgedefinieerde talen als xhtml, mathml etc heb je semantiek, maar met elk taaltje dat je zelf verzint, heeft een ander (of een machine) in eerste instantie geen flauw benul waar je het over hebt, omdat ze de woorden niet kennen.

In html kent iedereen de woorden, iedereen weet dus dat een <p> een alinea is, dat is semantiek. Een <p> zegt dus wel iets over de inhoud, namelijk dat het een alinea is.

en over friendly URL's: een ander argument is dat als je je hele achterliggende systeem zou veranderen (php naar asp ofzo om maar eens rigoreus te doen), je je friendly url's kan behouden, verder is het handig voor marketing, publicaties (een deeplink in een tijdscrift moet je echt wel overtypen en een URI vol ? en & kan hier makkelijker voor fouten zorgen), eigenlijk in elke andere vorm van communicatie dan de digitale (ja tweakers, die zijn er ook ), is het handig een URI te hebben die minder foutgevoelig is.

[ Voor 22% gewijzigd door Verwijderd op 10-05-2005 08:39 ]

[.Johnny]

wat zegt een alinea over de inhoud dan? het zegt alleen iets over hoe je je document vormgeeft, namelijk dat je een paragraaf hebt. Waar het over gaat wordt door een <p> niet bepaalt. Het kan net zo goed over vissen als over computers gaan. Of op een andere laag; het kan niet zo goed de introductie zijn als de hoofdtekst.
neem bijvoorbeeld een <b>. Vaak zul je hiermee iets aan willen duiden dat belangrijk is, maar niet altijd. De semantische waarde van een <b> tag is dus laag. Als je een <warning> zou kunnen definieren, heb je wat anders en dat kan dus wel met XML. De semantische mogelijkheden van XML liggen dus veel hoger; wat jij bedoelt met onafgesproken tagging heeft alleen maar te maken met hoe je je semantiek structureert, maar daar heb je ontologieen voor. Dat geldt natuurlijk ook voor wat gezegd wordt over het al dan niet kunnen intepreteren van betekenis door een computer; dat wordt mogelijk gemaakt door ontologieen; zolang er geen betekenis door tagging aan een document wordt gegeven kan een systeem er zeker niets mee nee.

[ Voor 18% gewijzigd door .Johnny op 10-05-2005 10:14 ]

[Verwijderd]

Volgens mij heb je niet goed door wat semantiek nu eigenlijk betekent. Het gaat erom dat je aangeeft wat de functie is van een bepaald stuk, boeit geen kont of het over vissen of computers gaat.

het zegt ook niks over hoe je je document vormgeeft, daar heb je css voor, een <p> geeft alleen aan dat het een alinea is, en die functie blijft hetzelfde, ongeacht je onderwerp. Zodoende kunnen machines er iets mee.

<b> heeft idd weinig semantische waarde, <strong> daarentegen weer wel, <warning> kent geen enkele machine, dus het heeft absoluut geen nut dat te gebruiken

als jij je eigen spreektaaltje ontwikkeld heb je misschien wel heel treffende woorden voor datgeen wat je wil zeggen, alleen je hebt er helemaal niks aan omdat niemand anders begrijpt wat je bedoelt. Zolang je taal niet vastgelegd is (in woordenboeken of door w3c of iemand anders), heeft jou taal absoluut geen semantiek, geen betekenis voor een ander. Zodra je een taal hebt die wel iedereen kent wordt je ineens begrijpbaar.

[ Voor 30% gewijzigd door Verwijderd op 10-05-2005 10:24 ]

[faabman]

Over semantiek is genoeg te vinden met Google en de Search

Verwijderd schreef op dinsdag 10 mei 2005 @ 02:10:
[...]
Dus /contact en /?id=43 worden op dezelfde manier geindexeerd? Zelfs het gebruik van - of _ maakt uit in een URI voor indexering. Hoewel het klopt dat ook "dynamische URIs" (onzinnige naam uiteraard aangezien de URIs die ik voor m'n weblog gebruik ook niet echt een statische pagina representeren ofzo) geindexeerd worden geloof ik dat er wel degelijk verschil zit bij de zoekresultaten.

Heb laatst een artikel op searchenginewatch gelezen waarin werd gesuggereerd dat zoekmachines ook gebruik maken van de woorden die in de URI staan. Wanneer je dus bedrijfsnaam.nl/profiel hebt dan zou dit extra waarde moeten geven wanneer bijvoorbeeld op profiel wordt gezocht...

Ik verwerk zelf ook de taalcode in mijn URI. Zo ontstaan er dus URIs als /nl/sitemap en /fr/plan-du-site etc. Een argument hiertegen is gebruik maken van een andere extensie per taal. In de meeste gevallen blijkt echter dat de domeinnaam voor de specifieke taal al is vastgelegd.

[Verwijderd]

http://www.google.nl/search?q=define:google

Waarom zie ik toch zo veel url's waarin de woorden glossary, dictionary of terminology staan? Een goede beschrijvende URL wordt wel degelijk beter geindexeerd. Anne gaf daar al een goed voorbeeld van; /contact of /?page=31

[alienfruit]

Ach, dat SEO is een langdurig proces, als je het maart eenmalig doet. Dan heeft maar eventjes zin, het is echt iets waar je continue mee bezig moet zijn. Niet leuk dus.

[Verwijderd]

Ach, dat SEO is een langdurig proces, als je het maart eenmalig doet. Dan heeft maar eventjes zin, het is echt iets waar je continue mee bezig moet zijn. Niet leuk dus.

?

"Care to elaborate?"

Ik sta voor meerdere keywords erg hoog in Google, zonder ook maar iets direct aan SEO te doen. Voorbeelden zjn "internet explorer 7", "anne", "redirect in php", "html5", et cetera.

[Verwijderd]

/me bevestigd: goeie sematische code is de beste SEO die je kan doen, en het kost gewoon geen extra moeite (als je weet waar je mee bezig bent)

[T-MOB]

Verwijderd schreef op dinsdag 10 mei 2005 @ 10:20:
Volgens mij heb je niet goed door wat semantiek nu eigenlijk betekent. Het gaat erom dat je aangeeft wat de functie is van een bepaald stuk, boeit geen kont of het over vissen of computers gaat.

offtopic:
Volgens mij heb jij niet helemaal door wat semantiek betekent. Semantiek is traditioneel gezien betekenisleer, voor uitgebreidere definities is google je vriend. In de computerwereld wordt het begrip wel gebruikt om aan te duiden of bepaalde statements logisch correct zijn. Een semantische fout in HTML is lastig, maar zou er ongeveer zo uit kunnen zien.

code:

<h1><h3>Heading</h3></h1>

offtopic:
Dit is syntactisch correct, maar het is bogus omdat het onzin is dat tekst zowel <h1> als <h3> is.
Wat GIJoke terecht opmerkt is dat wat men "semantische HTML" noemt eigenlijk weinig met semantiek te maken heeft. Zoals je zelf aangeeft geven HTML tags alleen de functie van een bepaald stuk tekst aan. Ze zeggen niets over de betekenis ervan. Dit in tegenstelling tot XML waarbij de volgende code wél betekenis verschaft (iig voor mensen, maar computers kunnen sowieso niets met semantiek omdat een computer geen flauw benul heeft van de symbolen waarnaar wij met taal refereren):

code:

<friend>
 <name>Mophor</name>
 <gender>Male</gender>
 <age>25</age>
</friend>

offtopic:
Verder ben ik het helemaal met je eens dat het praktischer is om een gestandaardiseerd taaltje te hebben zoals HTML, ben ik het ook met je eens dat machines er meer mee kunnen als je de tags gebruikt waar ze voor zijn. Sterker nog ik kan er zelfs mee leven dat men het semantische HTML noemt, maar ik vind wel dat het woord slecht gekozen is...

[ Voor 5% gewijzigd door T-MOB op 10-05-2005 21:53 . Reden: 't moest 25 zijn... ;) ]

[drm]

T-MOB:

offtopic:
Volgens mij heb jij niet helemaal door wat semantiek betekent. Semantiek is traditioneel gezien betekenisleer, voor uitgebreidere definities is google je vriend.

Het punt is dat als je niet allemaal dezelfde betekenisleer hanteert de betekenisleer zijn functie verliest. P is vastgelegd als paragraaf, dat weet "iedereen", en daarom heeft het betekenis. Als ik een andere semantiek vast ga leggen voor mijn eigen taaltje, moet ik eerst zorgen dat iedereen weet dat ik met P "porno" bedoel, anders heeft het geen zin. Aangezien het onmogelijk is die semantiek aan de hele wereld duidelijk te maken heeft het geen zin een eigen semantiek te hanteren en des te meer die van een geaccepteerde autoriteit als het w3. Ik denk dat je dat wel snapte, maar ik zeg het toch nog maar even

[mullah]

Als je het in html over semantiek hebt slaat dat niet op de betekenis van de tekst die tussen de tag staat, maar de betekenis van het element in de structuur van het document .. daar heet het hypertext markup language voor. Je geeft dus de structuur van het document weer in een bepaalde taal, en die taal heeft zijn eigen semantiek.

(zo dacht ik altijd dat het in elkaar zat dan)

[Verwijderd]

of het woord nu wel of niet gelukkig gekozen is, als het gaat over semantiek in html/xhtml/xml/whateverml gaat het om wat ik beschreef, verder zijn we het geloof ik wel eens.

ik heb het ook over semantiek in html, niet semantiek van willekeurig wat dan ook. die <h1><h3> constructie is wel fout, maar vooral omdat de structuur niet toegestaan (om overduidelijke redenen, want het is bogus), een constructie als <p>Heading</p>, da's een "echte" semantische fout.

offtopic:
maak er maar 25 van

edit: idd, wat hierboven gezegd wordt

[ Voor 10% gewijzigd door Verwijderd op 10-05-2005 17:35 ]

[alienfruit]

"Care to elaborate?"

Ik sta voor meerdere keywords erg hoog in Google, zonder ook maar iets direct aan SEO te doen. Voorbeelden zjn "internet explorer 7", "anne", "redirect in php", "html5", et cetera.

Je blijft als website niet automagisch bovenaan staan, als je niks aan je website doet. Dit is niet iets wat niet vanzelfsprekend is voor sommige product websites om dit vaak biji te werken. Op die manier kan het dus zijn dat er websites komen met een betere positie in de resultaten. Oftewel tijd om weer werk te maken van SEO.

[imp4ct]

'k Heb nu bijna volledig deze topic gelezen en 'k moet zeggen, 't is ingewikkeld. Semantiek, CSS, werken met <div>'s etc... Soms denk je, waarom is het allemaal nodig ??

Allé, kweet nu niet maar zou je gaan zeggen dat een site die opgemaakt is uit zo min mogelijk tabellen en eigenlijk volledig layout-gericht op CSS draait een "slechtere" site is qua code dan een site die gemaakt is met <div>'s en die toestanden ? Of is het gewoon, je moet mee met de tijd ?

Ook wat Semantiek nu eigenlijk is, wat ik er van "opgevangen" heb heeft het dus totaal niets te maken met hoe je site opgebouwd is etc... maar dat het gaat om hetgeen wat er tussen tags staat, inhoudsgerichte dingen enzow ? Right ?? Als er iemand een "simpele" verklaring nog heeft, 'k zou ze altijd wel eens willen weten, want ik twijfel nu fel of ik niet beter m'n site volledig ga ombouwen met <div>'s dan ze te laten staan in <table> style.

[Vinnienerd]

HTML is toendertijd ontworpen om voor wetenschappers makkelijk en snel op het Internet (of ARPAnet) documenten te publiceren. HTML-tags gebruikte je toen om je document structuur en vorm te geven.

CSS is daarna in het leven geroepen om opmaak van inhoud te scheiden. Maar als een browser by default al CSS-stijlen koppelt aan HTML-tags, wat heeft het dan voor een zin om nog semantisch te gaan HTML-en? Een browser ziet het verschil niet tussen een <b> en een <span style="font-weight: bold;">.
Mensen, het kan een browser geen reet schelen welke van de beide je kiest, hij gaat je er niet minder aardig om vinden...of Google het leuk vindt is een ander verhaal, maar dat zal Anne wel beter weten.

Vanuit het designoogpunt is semantisch coden dus niet nodig, een browser kan er toch altijd even goed mee over weg. Echter, ranzige HTML-Frontpage4.0-code is een ander verhaal. Daar vallen tables ook onder, IMHO. Onthoud: tabellen zijn voor tabulaire data, niet voor layouts die zo in elkaar donderen. t Is IMHO gewoon zelfmoord, zeker in 2005. Met CSS forceer je gewoon een strakke en stabiele layout, desnoods doe je alles in een container met alle hoeken van de div's gedefinieerd als procenten.

[drm]

Ook wat Semantiek nu eigenlijk is, wat ik er van "opgevangen" heb heeft het dus totaal niets te maken met hoe je site opgebouwd is etc... maar dat het gaat om hetgeen wat er tussen tags staat, inhoudsgerichte dingen enzow ? Right ?? Als er iemand een "simpele" verklaring nog heeft, 'k zou ze altijd wel eens willen weten, want ik twijfel nu fel of ik niet beter m'n site volledig ga ombouwen met <div>'s dan ze te laten staan in <table> style.

Het punt is dat tabellen gebruikt worden voor layout tegenwoordig in de meeste gevallen niet meer nodig is. Het is dan ook geen kwestie van tabellen t.a.t. vermijden maar gewoon de elementen toepassen die in de context van het document het beste de inhoud van dat deel van het document beschrijven, of beter gezegd: betekenis geven. Je bent op dat punt dus bezig met het structureren van je document en niet meer het stijlen. Stijlen doe je met CSS.

Een <div class="header"> heeft geen betekenis (semantische waarde) omdat het namelijk alleen op basis van een classname iets vertelt over wat de inhoud van het div element is. Aangezien er over de betekenis van classnames alleen door de auteur iets zinnigs gezegd kan worden (er zijn namelijk geen standaarden of richtlijnen voor) is het voor een browser of een zoekmachine niet veel anders dan: <div class="paard"> of <div class="joop">. Daarom moet je in zo'n geval dus een <h1> gebruiken; daarvan is de betekenis (semantische waarde) wel vastgelegd en geef je dat stukje tekst of het plaatje dat daar in staat die semantische waarde die het moet krijgen, namelijk de waarde van een koptekst op het niveau 1.

Je gebruikt divs in principe alleen daar waar er geen element voor handen is dat op enige wijze beter de inhoud van het element zou beschrijven.

Je gebruikt tables in principe alleen wanneer je te maken hebt met gegevens die op horizontale en verticale wijze direct verband met elkaar hebben. Het gebruik van een table voor een formulier is dus in principe helemaal niet fout. Je hebt namelijk een kolom met labels voor de velden en een kolom met velden (verticaal verband) en per regel een label dat het veld rechts daarvan aanduidt (horizontaal verband). Let dus op dat je niet gaat denken dat tables helemaal nergens meer goed voor zijn.

Dat tegenover een table die de navigatie van de content scheidt: Die twee onderdelen houden feitelijk geen enkel verband met elkaar (behalve dan dat ze in hetzelfde document staan, maar dat stonden ze toch al). In zo'n geval kun je die twee onderdelen van een document beter scheiden met div's (divisions) om 2 redenen:
1. Het is flexibeler met stijlen; je kunt de navigatie bijvoorbeeld ook rechts plaatsen, of onderaan je pagina als je dat zou willen
2. De inhoud van een in het andere geval gebruikte tabel wordt niet ten onrechte als gerelateerde data gezien.

[imp4ct]

Dus als ik het goed begrijp is het "beter" om toch de site ooit eens te gaan omzetten naar <div> - <h1>'s, etc... ?? Zodat ik meega met de tijd. 't Enigste wat mij wat tegensteekt is die positionering met <div>'s maar soit. Dit went wel na een tijd eens je emee bezig bent.

Bedankt voor de fijne uitleg, 'k snap het nu. Nu maar hopen dat ze niet in de nabije toekomst weer met nieuwe dingen gaan afkomen, dat je weer helemaal kan gaan re-coden, want fijn is anders. 'k Weet ook wel, "je moet het niet doen". Maar 'k vind als goeie site moet je met de tijd meegaan en dus ook je code.

[T-MOB]

I_M_P_A_C_T schreef op dinsdag 10 mei 2005 @ 23:48:
Dus als ik het goed begrijp is het "beter" om toch de site ooit eens te gaan omzetten naar <div> - <h1>'s, etc... ?? Zodat ik meega met de tijd. 't Enigste wat mij wat tegensteekt is die positionering met <div>'s maar soit. Dit went wel na een tijd eens je emee bezig bent.

Het omzetten naar <div>'s en <h1>'s is niet per definitie beter. Waar het om gaat is dat je bewust kiest voor bepaalde elementen omdat ze een bepaalde relatie voorstellen. Een menu bijvoorbeeld kun je maken door een <div> te vullen met <a> tags.

code:

<div id="menu">
 <a href="sitemap">sitemap</a>
 <a href="contact">contact</a>
</div>

Dat geeft dan allicht aan dat de links met elkaar een geheel vormen, maar beter is het bijvoorbeeld om een <ul> te gebruiken.

code:

<ul id="menu">
 <li><a href="sitemap">sitemap</a></li>
 <li><a href="contact">contact</a></li>
</ul>

Dat geeft aan dat het gaat om een groep van elementen die met elkaar een lijst vormen. Afzonderlijke elementen dus die zijn gegroepeerd. Wordt het menu gecompliceerd dan kan een <dl> een betere keus zijn.

code:

<dl id="menu">
 <dt><a href="sitemap">sitemap</a></dt>
 <dt><a href="contact">contact</a></dt>
 <dd><ul>
  <li><a href="contact/jan">Jan</a></li>
  <li><a href="contact/piet">Piet</a></li>
 </ul></dd>
</dl>

Wel, daar geef je dus op ene structurele wijze mee aan dat je binnen de groep contact zowel Jan als Piet kunt contacteren. Qua presentatie kun je dit laatste menu op tig manieren voor elkaar krijgen (ook met de <div> vol <a>'s), maar voor iedereen die je presentatielaag mist is deze laatste methode het duidelijkst. Daaronder vallen zowel google als mensen det een textbrowser. Laatsgenoemde kan zeker als je twijfelt over hoe je een goede pagina opbouwt een fijn hulpmiddel zijn. Ziet het er leesbaar uit zonder stylesheet, dan ben je doorgaans op de goede weg...

Bedankt voor de fijne uitleg, 'k snap het nu. Nu maar hopen dat ze niet in de nabije toekomst weer met nieuwe dingen gaan afkomen, dat je weer helemaal kan gaan re-coden, want fijn is anders. 'k Weet ook wel, "je moet het niet doen". Maar 'k vind als goeie site moet je met de tijd meegaan en dus ook je code.

In de nabije toekomst zal men met nieuwe dingen komen, dat heet vooruitgang. Helemaal recoden om "met de tijd mee te gaan" lijkt me overdreven. Je koopt toch ook niet elke 3 maand een nieuwe auto omdat er een verbetering in de autotechniek behaald is...

offtopic:
@Mophor, DRM: we zijn het idd wel eens over het hoe en wat in HTML qua semantiek. Maar ik heb het altijd raar gevonden dat het semantiek genoemd wordt, exact om de reden die GIJoke aangeeft. Dat iets een alinea is zegt niets over de inhoud. Misschien moet ik me gewoon neerleggen bij Mullah's uitleg, before we get into semantics again

[Verwijderd]

code:

<dl id="menu">
 <dt><a href="sitemap">sitemap</a></dt>
 <dt><a href="contact">contact</a></dt>
 <dd><ul>
  <li><a href="contact/jan">Jan</a></li>
  <li><a href="contact/piet">Piet</a></li>
 </ul></dd>
</dl>

En het blijkt weer eens dat niet iedereen het begrepen heeft. No offense. "HTML is hard".

Een definitie groep bestaat uit een of meer DT elementen gevolgd door een of meer DD elementen.

Als er iets geen subpagina heeft gaat het bovestaande ontwerp dus al fout. En dan nog gaat het fout aangezien er een UL genest wordt in een DD in plaats van meerdere DD elementen te gebruiken. En dan nog zou het per HTML4 als fout gerekend kunnen worden, maar voor DL wordt meestal de toekomstige definitie van HTML5 aangehouden namelijk dat deze serie van elementen niet specifiek voor definities gebruikt hoeft te worden. (Ze kunnen dus gebruikt worden om dingen te groeperen die een "header - child" relatie hebben.)

[T-MOB]

Verwijderd schreef op woensdag 11 mei 2005 @ 02:12:
[...]
En het blijkt weer eens dat niet iedereen het begrepen heeft. No offense. "HTML is hard".

Een definitie groep bestaat uit een of meer DT elementen gevolgd door een of meer DD elementen.

Als er iets geen subpagina heeft gaat het bovestaande ontwerp dus al fout. En dan nog gaat het fout aangezien er een UL genest wordt in een DD in plaats van meerdere DD elementen te gebruiken. En dan nog zou het per HTML4 als fout gerekend kunnen worden, maar voor DL wordt meestal de toekomstige definitie van HTML5 aangehouden namelijk dat deze serie van elementen niet specifiek voor definities gebruikt hoeft te worden. (Ze kunnen dus gebruikt worden om dingen te groeperen die een "header - child" relatie hebben.)

No offence taken... Maar sorry, uit de W3C spec haal ik dat zowel het weglaten van van <dd>'s bij <dt>'s als het plaatsen van block-level content in een <dd> is toegestaan. Oftewel waar heb je het over?

[alienfruit]

Verder heb je dan nog het gebruik van DL voor het opbouwen van formulieren "the new way"...

[faabman]

alienfruit schreef op woensdag 11 mei 2005 @ 10:22:
Verder heb je dan nog het gebruik van DL voor het opbouwen van formulieren "the new way"...

Ehmm, lijkt me wel dat impliciet / explicit labels prefaleren boven de dl constructie.

Maar, nu weer even back ontopic, we hebben dus bepaald dat gestructureerd HTML en User Friendly URIs helpen bij het bereiken van hogere rankings. Daarnaast hebben we ook nog hetgeen waar het uiteindelijk allemaal om draait en dat is de content van de site. Zelf heb ik wel eens sites gebouwd waarbij de content niet goed gestructereerd was of waarin te veel vakgebonden termen werden gebruikt. Hoe gaan jullie daarmee om? De klant adviseren om beter gestructereerde content aan te leveren / te gebruiken en minder vaktermen? Of direct een copywriter gebruiken?

Hoe gaan zoekmachines in jullie ervaring om met lange pagina's? In een artikel wat ik laatst tegenkwam werd gesuggereerd dat zoekmachines meer waarde geven aan content in het begin van een pagina. Wanneer je dus een persbericht van 8 pagina's op één htmlpagina plaatst dan kan het dus zijn dat de belangrijkste elementen een minder hoge waarde krijgen. Een mogelijke oplossing hiervoor is het opsplitsen van het document. Zijn er nog meer oplossingen?

[T-MOB]

faabman schreef op woensdag 11 mei 2005 @ 10:51:
Hoe gaan zoekmachines in jullie ervaring om met lange pagina's? In een artikel wat ik laatst tegenkwam werd gesuggereerd dat zoekmachines meer waarde geven aan content in het begin van een pagina. Wanneer je dus een persbericht van 8 pagina's op één htmlpagina plaatst dan kan het dus zijn dat de belangrijkste elementen een minder hoge waarde krijgen. Een mogelijke oplossing hiervoor is het opsplitsen van het document. Zijn er nog meer oplossingen?

Is het bij lange content niet sowieso een goed gebruik om te beginnen met een samenvatting of op zijn minst een heldere inleiding waarin de strekking van de tekst wordt uitgelegd. Ik stel me zo voor dat dat ook de reden is dat een zoekmachine mer belang hecht aan de content op het begin van de pagina.

Daarnaast kun je in een lange tekst een heldere koppenstructuur (meerlaags) aanbrengen met bij voorkeur een "table of contents" aan het begin van de tekst. Maar ook dat is niet iets specifiek voor HTML. Ook in een gedrukte tekst van enige omvang zou ik die aanbrengen, stel je maar eens een boek voor met alleen koppen voor hoofdstukken en verder géén inhoudsopgave en/of subkoppen. Daar vind je nooit meer iets nuttigs in terug...

[Verwijderd]

No offence taken... Maar sorry, uit de W3C spec haal ik dat zowel het weglaten van van <dd>'s bij <dt>'s als het plaatsen van block-level content in een <dd> is toegestaan. Oftewel waar heb je het over?

Ik had het niet specifiek over de inhoud van een DD. Wat ik bedoel is dit:

code:

<dt>foo
<dt>bar
<dd>terms

Op het moment dat je een DD weglaat na de eerste DT vallen die DT en de daaropvolgende DT (en de daaropvolgende mits het een direct sibling is) samen in een definitiegroep.

Ik zei niet dat je syntax fout was, ik zei dat het gebruik fout was.

[T-MOB]

Verwijderd schreef op woensdag 11 mei 2005 @ 11:43:
Ik zei niet dat je syntax fout was, ik zei dat het gebruik fout was.

offtopic:
Aha, dus als ik het goed zou willen doen zou ik lege <dd>'s moeten invoegen, of beter gewoon <ul>'s nesten.

[Verwijderd]

Volgens HTML4 is het gebruik van DL voor een menu sowieso fout. Een lege DL lijkt me een hack, dus inderdaad, gewoon een UL.

[Verwijderd]

ook <div> dient een bepaald doel en is dus ook geen hoerelement. Een pagina compleet opbouwen met <div> is net zo'n klets als met tabellen. Een pagina bestaat uit een body, met daarin <div>, <blockquote>, <map> en <form> elementen.

Hierin heb je dan weer de aliniea's lijsten en tabellen, waarbinnen zich weer de inline level elementen bevinden.

(dat body overigens geen <map> element mag bevatten vind ik wel vaag. Anne, heb jij daar toevallig een kijk op?)

[ Voor 22% gewijzigd door Verwijderd op 11-05-2005 13:26 ]

[Verwijderd]

MAP is van het type 'special' dat alleen binnen een 'inline' context mag voorkomen. (Maar mag zelf alleen 'block' of AREA bevatten.) Aangezien 'body' alleen 'block' toelaat (in Strict) lijkt het me vanuit theoretisch oogpunt duidelijk.

De echte reden zal wel zijn dat het teveel gedoe was voor het maken van de DTD. HTML5 kent gelukkig niet dat soort nutteloze restricties en heeft een logischer interactie tussen elementen ogesteld. (Vooralsnog.)

[imp4ct]

Verwijderd schreef op woensdag 11 mei 2005 @ 02:12:
[...]
En het blijkt weer eens dat niet iedereen het begrepen heeft. No offense. "HTML is hard".

Een definitie groep bestaat uit een of meer DT elementen gevolgd door een of meer DD elementen.

Als er iets geen subpagina heeft gaat het bovestaande ontwerp dus al fout. En dan nog gaat het fout aangezien er een UL genest wordt in een DD in plaats van meerdere DD elementen te gebruiken. En dan nog zou het per HTML4 als fout gerekend kunnen worden, maar voor DL wordt meestal de toekomstige definitie van HTML5 aangehouden namelijk dat deze serie van elementen niet specifiek voor definities gebruikt hoeft te worden. (Ze kunnen dus gebruikt worden om dingen te groeperen die een "header - child" relatie hebben.)

Hoe moet die code dan op de juiste manier Anne ?

[Verwijderd]

zoals hij zegt, nested ul's (of ol's als de volgorde van belang is)

als toevoeging:

HTML:

<dl>
  <dt>aap</dt>
  <dt>fiets</dt>
  <dd>vervoermiddel</dd>
</dl>

is iets anders als

HTML:

<dl>
  <dt>aap</dt>
  <dd></dd>
  <dt>fiets</dt>
  <dd>vervoermiddel</dd>
</dl>

in het eerste geval is "aap" ook een vervoermiddel, in het tweede geval is er gewoon geen beschrijving. Het is dus (in dit geval) geen hack ofzo om een lege dd erin te stoppen.

[ Voor 77% gewijzigd door Verwijderd op 13-05-2005 10:13 ]

[Verwijderd]

Vinnienerd schreef op dinsdag 10 mei 2005 @ 23:31:
HTML is toendertijd ontworpen om voor wetenschappers makkelijk en snel op het Internet (of ARPAnet) documenten te publiceren. HTML-tags gebruikte je toen om je document structuur en vorm te geven.

CSS is daarna in het leven geroepen om opmaak van inhoud te scheiden. Maar als een browser by default al CSS-stijlen koppelt aan HTML-tags, wat heeft het dan voor een zin om nog semantisch te gaan HTML-en? Een browser ziet het verschil niet tussen een <b> en een <span style="font-weight: bold;">.
Mensen, het kan een browser geen reet schelen welke van de beide je kiest, hij gaat je er niet minder aardig om vinden...of Google het leuk vindt is een ander verhaal, maar dat zal Anne wel beter weten.

Vanuit het designoogpunt is semantisch coden dus niet nodig, een browser kan er toch altijd even goed mee over weg. Echter, ranzige HTML-Frontpage4.0-code is een ander verhaal. Daar vallen tables ook onder, IMHO. Onthoud: tabellen zijn voor tabulaire data, niet voor layouts die zo in elkaar donderen. t Is IMHO gewoon zelfmoord, zeker in 2005. Met CSS forceer je gewoon een strakke en stabiele layout, desnoods doe je alles in een container met alle hoeken van de div's gedefinieerd als procenten.

Een <b> tag is volgens mij dan ook niet semantisch correct. Immers geven <b>, <i> en <u> informatie over de presentatie. Deze veeg ik ook op een hoopje samen met de <font> tag. Als je ergens de nadruk op wilt leggen gebruik je <em> of <strong>. Die geven geen informatie over de presentatie. Via CSS style je deze tags, bijvoorbeeld font-style: italic, font-weight: bold, text-decoration: underline, etc.

[Verwijderd]

een browser kan er idd niet beter of slechter mee overweg (aangenomen dat ook je niet semantische code wel valide is), en interpreter kan zeker wel beter overweg met semantische code (bijvoorbeeld door <em> met nadruk uit te spreken.)

browser geven een default style omdat dat duidelijker is, als alles geen style heeft (wat is dat uberhaupt, want het moet toch getoond worden), is het niet mogelijk om handig koppen te onderscheiden van broodtekst bijvoorbeeld, of een hierarchie in koppen te ontdekken, door default styleing is dat wel te doen. Bekijk voor de lol een pagina eens in lynx, die doet niks met de css, maar laat toch een heading als zodanig herkenbaar zien.

[ Voor 52% gewijzigd door Verwijderd op 11-05-2005 16:29 ]