dit is het sub forum "Personeel Gevraagd / Personeel Aangeboden" waarom word hier een discussie gehouden over webstandaarts ?
Likes: 0
dit is het sub forum "Personeel Gevraagd / Personeel Aangeboden" waarom word hier een discussie gehouden over webstandaarts ?
Ik heb dit bericht niet geplaatst om iemand aan te vallen, mij pakken op spelvauten is dan ook nogal kinderachtig. Ik denk inderdaad dat een webdeveloper zich moet profileren als een expert op het gebied waar hij voor ingehuurd wordt. Je zou het kunnen vergelijken met een auto - als je die in reparatie brengt kunnen ze je benzineslang vast wel met duck-tape ofzo vastzetten. En waarschijnlijk zal je auto dan nog gewoon werken.
Maar het is niet goed, tabellen gebruiken om je layout te positioneren is niet waar HTML oorspronkelijk voor bedoelt is. En ik ben me er van bewust dat webstandards iets is waar je uren en uren werk in moet stoppen voor je het kunt, maar als jij alleen geeft over dat kleine stukje tevredenheid naar de klant toe waar hij wel van weet denk ik niet dat je helemaal goed bezig bent met webdesign. Het is een totaalpakket wat je de klant aanbied, een stukje service, een stukje vertrouwen wat de klant in je heeft en wat je ook waar hoort te maken door een kwalitatief hoog product af te leveren. En als ik een broncode zie in HTML, en hij is weer eens vies, dan vind ik het jammer dat er niet wat meer moeite in is gestopt.
Nogmaals, ik ben hier niet om ruzie te maken - ik wilde alleen eens een punt aankaarten om achter de redenen te komen van bepaalde mensen om niet voor webstandards te kiezen.
De site die je overigens zag is een community die al een aantal jaar onder mijn beheer is, is een IPB systeem die door onszelf gecombineerd is met een zelfgebouwd CMS. Ik denk niet dat het er toe doet wat door mij afgeleverde websites zijn.
Voor mensen die hulp nodig hebben kan je www.w3schools.com bezoeken, op deze website zijn erg veel artikelen te vinden.
Het probleem van tabellen vs div/css is dat met tabellen de klanten mogelijk in een editor lekker aan de slag kunnen gaan en/of een andere developer heeft sneller zicht hoe alles in elkaar zit.
Wanneer kiest voor div/css dan ten eerste moet een andere developer wil die het aanpassen 2 bestanden doornemen en compleet uittekenen waar wat staat wat mogelijk toch wel aan de lastige kant is.
Ik vind dat je het gebruik van webstandaarden zoveel mogelijk moet toepassen voor zover dit praktisch haalbaar is. Voor een kleine site is het geen probleem (voor mij) om netjes een XHTML Strict design neer te zetten die ook nog eens crossbrowser werkt. Maar op moment dat je gaat werken aan grotere portal sites moet je soms keuzes maken.
Om maar een voorbeeld te noemen:
Ik gebruik op 1 pagina meerdere formulieren, bijvoorbeeld een zoekformulier, een inlogformulier enz. Hierin geef ik een hidden veld mee die doorverwijst naar een bepaalde pagina. Als ik dit netjes wil doen volgens XHTML standaarden hoort er bij elk veld een id attribuut gekoppeld te zijn.
Maar nou ga ik op 1 pagina geen twintig verschillende id's gebruiken voor een veld dat altijd dezelfde functie heeft. Dat de validator daardoor een error geeft vind ik op zo'n moment niet belangrijk.
Ik kan het wel aanpassen, maar dat kost zoveel meerwerk (stylesheets, serverside coding) dat het gewoon niet rendabel is.
Daarnaast vind ik dat ook de webstandaarden niet heilig zijn. De validator begint al te zeuren als je een heading tag (<H2> bijv.) binnen een paragraaf zet, terwijl dit op grond van semantiek juist zou moeten.
Als ik namelijk een subkop wil hebben binnen een bepaald stuk tekst, moet ik nu eerst de huidige paragraaf afsluiten (</p>) dan de <h3>subkop</h3> plaatsen en dan verder gaan met de paragraaf <p>.
Als we echt via de standaarden werken, keur dan maar 90% van de website af omdat ze niet werken volgens het HTTP protocol.
(Met name de POST en GET)
Dat slaat natuurlijk nergens op.Origineel geplaatst door nlrobert
Daarnaast vind ik dat ook de webstandaarden niet heilig zijn. De validator begint al te zeuren als je een heading tag (<H2> bijv.) binnen een paragraaf zet, terwijl dit op grond van semantiek juist zou moeten.
Als ik namelijk een subkop wil hebben binnen een bepaald stuk tekst, moet ik nu eerst de huidige paragraaf afsluiten (</p>) dan de <h3>subkop</h3> plaatsen en dan verder gaan met de paragraaf <p>.
Logisch dat een HEADING niet in een paragraaf kan staan.
@ Triloxigen, daar doel jij op?
Ceph, CloudStack en ZFS consultancy: 42on B.V.
Lees hier de webhostingtalk.nl forum regels en voorwaarden!
(Disclaimer: Ik heb het niet over php post of get, maar om http post en get)Origineel geplaatst door Wido
@ Triloxigen, daar doel jij op?
Een GET mag niks meer doen dan pagina's ophalen, terwijl een GET vaak ook iets update, dingen controleerd, etcetc.
Volgens het HTTP protocol is dit eigenlijk niet de bedoeling.
De reden dat de Google Web accelerator onveilig was en niet goed werkte omdat weinig websites zich er aan houden.
Ik weet niet meer de exacte details, het gehele HTTP protocol uit m'n hoofd leren staat niet op m'n priotiteiten lijst![]()
Of, de prijs is laag.Origineel geplaatst door Triloxigen
Hoe kom je erbij dat correct gebruik van HTML zorgt voor snelheid, overzichtelijkheid en nog meer van dat soort onzin?
En dat beetje extra dataverkeer van wat extra tags genereert is ook verwaarloosbaar.
Bedrijven besteden het uit omdat ze er juist geen verstand van hebben, ze maken soms alleen de verkeerde keuze.
En die keuzes zijn vaak gebaseerd op zaken 'want dat is een kennis van...'.
Een paragraaf kan bestaan uit meerdere alinea's. Als jij dan binnen die paragraaf een subtitel zou willen plaatsen, lijkt me dat met het oog op een semantische structuur je dan kiest voor een HEADING (bijvoorbeeld h4 of h5).Origineel geplaatst door Wido
Dat slaat natuurlijk nergens op.
Logisch dat een HEADING niet in een paragraaf kan staan.
Laatst gewijzigd door nlrobert; 18/10/05 om 17:48.
Een Heading mag niet binnen een paragraaf staan.
Dat is al zo sinds i.i.g. HTML 2.0
Laatst gewijzigd door rexp; 18/10/05 om 17:49.
Ik probeer laatste tijd ook al mijn site te maken volgens de standaarden (dus ook die van mijn klanten).
En inderdaad, mijn klanten boeit het niet of het een table of een tableless website is. Als het maar werkt.
Maar het grote voordeel is dat ik aan de klant kan laten zien, dat zijn website ook mooi te maken is voor print-out of pda, zonder dat ik compleet nieuwe templates moet bouwen. Het enige wat ik moet doen is de styles aanpassen.
En natuurlijk, validated websites zijn niet 100% crossbrowser, maar het komt er altijd een flink in de buurt.
Het doet er in zoverre toe dat de luitjes die het hardste tegen tabellen trappen ze zelf ook met grote regelmaat gebruiken. Zo ook jouw community site.Origineel geplaatst door Wes
Maar het is niet goed, tabellen gebruiken om je layout te positioneren is niet waar HTML oorspronkelijk voor bedoelt is. En ik ben me er van bewust dat webstandards iets is waar je uren en uren werk in moet stoppen voor je het kunt, maar als jij alleen geeft over dat kleine stukje tevredenheid naar de klant toe waar hij wel van weet denk ik niet dat je helemaal goed bezig bent met webdesign. Het is een totaalpakket wat je de klant aanbied, een stukje service, een stukje vertrouwen wat de klant in je heeft en wat je ook waar hoort te maken door een kwalitatief hoog product af te leveren. En als ik een broncode zie in HTML, en hij is weer eens vies, dan vind ik het jammer dat er niet wat meer moeite in is gestopt.
Nogmaals, ik ben hier niet om ruzie te maken - ik wilde alleen eens een punt aankaarten om achter de redenen te komen van bepaalde mensen om niet voor webstandards te kiezen.
De site die je overigens zag is een community die al een aantal jaar onder mijn beheer is, is een IPB systeem die door onszelf gecombineerd is met een zelfgebouwd CMS. Ik denk niet dat het er toe doet wat door mij afgeleverde websites zijn.
Maakt mij persoonlijk niet uit hoor.. maar dan moet je niet aankomen met vieze code. Zeker niet als je zelf de css in je pagina bak.
Zelf gebruik ik tabellen in de regel voor het grove werk om daarna met css het laatste stukje te doen. Werkt perfect met alle browsers waar ik mee test.. Dit zowel op win als op linux..
Laten we afspreken dat we ons aan de W3C houden zodra alle browsers dat ook doen :-)