[ALG Webdev] CMS en de utopie van een perfecte HTML markup

[m.w]

Als eerste wil ik even duidelijk maken dat ik met 'perfect' doel op de punten waar de vooruitstrevende web-ontwikkelaar de laatste jaren op hamert zoals: well-formed html, semantiek, gescheiden structuur en presentatie etc.

Het doel van deze post is een discussie te starten over het volgende wat mij enorm frustreerd als web-ontwikkelaar.

Zoals zovelen bied het webdev-bedrijfje waar ik werk ook een zelf ontwikkeld CMS aan voor haar klanten.
In dit geval gaat het om een CMS gericht op het MKB, waarbij je dus niet aan een grote portal engine moet denken, maar meer aan een template parser die content pagina's, geschreven in een WYSIWYG-editor (FCKeditor, HTMLArea voorheen), parsed.

Klanten kunnen dus 'gemakkelijk' zelf de content wijzigen zoals ze dat gewend zijn in een text-verwerker als Word.

Waar nu mijn grote frustratie ligt is het feit dat een gebruiker/klant gewoon geen ontwikkelaar is.

Een voorbeeld:

Je levert de site op met goed gestructureerde/semantieke (X)HTML waarbij de vormgeving/presentatie volledig met CSS is gedaan.
Nu gaat de klant na een tijdje de content zelf wijzigen.
Het gevolg: tagsoup.

Ook al validereert:

HTML:

<font size="6"><span style="font-weight: bold;">Inleiding</span></font><br/><br/>Hier volgt een inleiding<br/></code>

Beter was geweest:

HTML:

<h1>Inleiding</h1>
<p>Hier volgt een inleiding</p>

Het eerste code fragment is een voorbeeld van de HTML die FCKeditor genereert, HTML van andere editors is soms helemaal om te huilen.
Het tweede code fragment is de manier waarop ik het gedaan zou hebben.

Maar een klant interesseert zich over het algemeen niet voor semantiek, want

Het ziet er toch uit zoals ik het bedoeld heb?

Voor de meeste ontwikkelaars is het schijnbaar nog steeds moeilijk om structureel te denken inplaats van visueel, getuige het grote aantal tagsoup sites anno 2005, laat staan voor een gebruiker.

Dit is nog maar een klein voorbeeld van wat ik hier in de praktijk tegenkom.
Vandaag zag ik bijvoorbeeld dat een gebruiker een heel Word-document in de editor had ge-paste, bij het zien van de bron hiervan ben ik eerst maar even een blokje gaan fietsen voordat ik verder ging met m'n werk.

Een aantal opties die ik kan bedenken om dit te verbeteren

1. Klanten/gebruikers beter trainen zodat ze op een juiste manier omgaan met de WYSIWYG-editor.
   Maar kun je dat eigenlijk wel verlangen ?
   Je zou een klant goed moeten informeren over de meerwaarde ervan. Maar dan nog zouden ze het op een verkeerde manier kunnen oppikken.
   
   Voorbeeld:
   
   Je verteld een klant dat het gebruik van paragrafen is aan te raden wanneer je je content wilt opdelen in jawel, paragrafen, (via Format op 'Normal' in FCKeditor).
   Een aantal weken later zie je opeens 5 lege p elementen achter elkaar om zodoende 'wat' witruimte te creeëren.
   
   Misschien kun je ze inderdaad beter trainen, maar dan nog zouden ze nooit via een WYSIWYG-editor ongeveer dezelfde code kunnen genereren die jij normaal uit de losse pols wappert in je text-editor.
2. De functionaliteit van de WYSIWYG-editor te minimaliseren zodat je geen visuele aanpassingen meer op de content kun maken (font-family, font-size, color, bold, italic, underlined etc.)
   Maar probeer dit maar eens aan je baas te verkopen, zal die niet zeggen dat een product met minder functionaliteit niet verkoopt ? De WYSIWYG-editor is immers het stokpaardje van je CMS.
3. Een andere editor gebruiken
   Ik heb al verschillende editors geprobeert, maar FCKeditor blijkt veruit de beste te zijn.
4. Content editen via een Markdown syntax, zoals in Wordpress.
   Persoonlijk vind ik dit ideaal en is het ongeveer mijn interpretatie van het 'managen' van 'content', een gebruiker wordt op deze manier geholpen om structureel te denken, maar is dit niet te technisch voor klanten ?

Ik heb topics als [CMS] Voor -en nadelen als gebruiker en [Alg] Wat missen de bestaande web based html editors? gelezen, hier worden een aantal opsommingen en gedachtes besproken,
maar wat zijn jullie ervaringen en zijn er wellicht mensen met goede raad?

[alienfruit]

Tja, als eerste plakken vanuit Word blokkeren. Vervolgens een betere editor gebruiken zoals TinyMCE of een eigen creatie die meer rekening houdt met de XHTML, zoals XStandards. Verder kan je ook bepaalde dingen als links of andere dingen wel via WYSIWYG laten invoeren. Maar vervolgens achter de schermen de code vervangen. <A -> <link:bla /> ofzo. Verder je CMS met goede voorbeelden aanleveren, of documentatie erbij. Een handig lisjtje van hoe voeg ik dit en dat toe e.d.

[ Voor 3% gewijzigd door alienfruit op 19-07-2005 23:02 ]

[André]

Optie 2 is de optie waar ik mee gezien heb dat leken goede pagina's kunnen maken. Je beperkt de gebruikers in hun doen en laten en geeft ze precies de stijlen die ze kunnen gebruiken en geen andere.

Om dit even nader uit te leggen: er is zeg maar een pulldown waaruit je het volgende kan kiezen:

Paginatitel
Subtitel
Subsubtitel
Strong
Italic
Small

In die pulldown kun je net zoals bijvoorbeeld in Word al zien welke kleur en grootte de stijl heeft.

En dan nog een aantal elementen die ze in kunnen voegen:

Image
List
Link
Horizontal ruler

Met deze middelen kunnen complete content pagina's geschreven worden die er allemaal qua stijl goed uitzien en semantisch correct zijn. Daarna geef je de pagina een naam en description en vervolgens geef je hem een plek in het menu.

Met deze manier kun je door het switchen van 1 CSS het hele intranet anders stijlen

[Zoefff]

Ik ben het volledig met André eens, gewoon zo minimalistisch mogelijk houden, en daarnaast een goede uitleg/handleiding toevoegen waar duidelijk in staat hoe je met de editor om moet gaan, en wellicht nog iets eenvoudigs over semantiek.

Over het algemeen (met uitzondering op speciale gevallen natuurlijk) zal een gebruiker niet al te ingewikkelde dingen van plan zijn. Documentjes publiceren (titel/subtitels/paragrafen) en wellicht een plaatje of tabelletje ertussen, meer lijkt me absoluut niet nodig.

Het kopieren vanuit Word moet je inderdaad blokkeren, of er anders voor zorgen dat de tekst volledig van alle styles gestript word (maar weet niet of dat mogelijk is).

[Verwijderd]

Wij werken idd ook met beperkte mogelijkheden.
Je kan de menubalk van FCKeditor bv. heel makkelijk aanpassen.

Deze pas ik altijd aan naar de klant. Meestal met alleen de standaard bold, italic, undelined, special caracters, enz. en natuurlijk de "paste from Word" knop.

Dingen zoals lettertype of grote absoluut niet door de klant laten bepalen.
Vervolgens de content in een db zetten en met een template opmaken (xml/xsl oid)

[KeeZ]

volgens mij is het mogelijk bij FCKeditor door word gegenereerde HTML tags te strippen op onzinnge dingen...

zelf gebruik ik ook veel diverse CMS systemen... maar met name Mambo voor mijn klanten of wordpress voor de iets kleinere bedrijfjes die het zich kunnen veroorloven iets meer tijd te investeren in het systeem erachter (tegenwoordig kan je ook al nieuws 'mailen' das beter..)

maar uiteindeijk zal je toch niet alles kunnen voorkomen... dat je als ontwerper / developer een bepaalde perfectie nastreefd lijkt me een prima doel maar dat kan je niet van je gebruikers verwachten. Wel waarschuw ik binnen mijn eigen geschreven handleiding gebruikers op het aanpassen binnen sourcecode e.d. en de gevolgen daarvan.. die worden gewoon in rekening gebracht

[Verwijderd]

Ik ben het gewoon niet met je eens dat er geen editors zijn die volgens de semantiek werken. In mijn topic WYSIWYG Editors in Javascript heb ik ook duidelijk onderscheid gemaakt tussen 2 paradigma's; full content (menu, header, content etc) of content-only editors (die werken vaak volgens semantiek).

Content only editors zijn er wel, maar die zijn vaak commercieel; XStandard, eWebEditPro en NextAvenue zijn voorbeelden van editors volgens het tweede paradigma.

[ Voor 8% gewijzigd door Verwijderd op 20-07-2005 11:31 ]

[CaptBiele]

Ik sluit me ook aan bij Andre. Houdt het zo eenvoudig mogelijk. Ik moet erbij vermelden dat dit alleen geldt voor het zelf kloppen/wijzigen van content.

alienfruit schreef op dinsdag 19 juli 2005 @ 23:02:
Tja, als eerste plakken vanuit Word blokkeren.

Dit zou ik nooit doen. Ik heb ook meegewerkt aan een cms, en dit is gewoon functionaliteit die content beheerders vaak gebruiken. Mijn ervaring is dat je beter kan accepteren dat het een tagsoup wordt.
Als je dit blokkeert, stuit je gebruikers op de borst, en dat mag niet. Want de enige die iets om de tags geeft, dat is de ontwikkelaar. En je mag niet van gebruikers verwachten dat ze ineens "nette" html kunnen kloppen.
Probeer je ook in te leven in de rol van manager en/of eindgebruiker.

[equationunequal]

alienfruit schreef op dinsdag 19 juli 2005 @ 23:02:
Tja, als eerste plakken vanuit Word blokkeren. Vervolgens een betere editor gebruiken zoals TinyMCE of een eigen creatie die meer rekening houdt met de XHTML, zoals XStandards. Verder kan je ook bepaalde dingen als links of andere dingen wel via WYSIWYG laten invoeren. Maar vervolgens achter de schermen de code vervangen. <A -> <link:bla /> ofzo. Verder je CMS met goede voorbeelden aanleveren, of documentatie erbij. Een handig lisjtje van hoe voeg ik dit en dat toe e.d.

Plakken uit Word hoef je met Tiny niet eens te blokkeren. Tiny heeft een functie die brakke word mark-up opschoont en niet valide html elementen uit je code haalt. Ik heb daarnaast nog een php functie geschreven die bepaalde stukken code vervangt. Zo replaced hij bv. "align="center" voor class="bla". Alles 100% afvangen lukt natuurlijk nog niet, maar hiermee kom je al aardig in de buurt...

[MaZo]

De code die een WYSIWYK-editor standaard uitpoept is in veel gevallen toch gewoon aan te passen, zodat je code 'valideerbaar' blijft?

[Not Pingu]

alienfruit schreef op dinsdag 19 juli 2005 @ 23:02:
Tja, als eerste plakken vanuit Word blokkeren.

Oefff... dat is nou juist het grootste voordeel van de standaard designmode in IE en FF.
Als developer ben je daar misschien huiverig voor, maar het is zo'n goede toevoeging aan de workflow dat je er eigenlijk niet onderuit kunt. Bovendien, je kunt nog zo'n goede, krachtige en prettige editor maken, je zult nooit kunnen tippen aan Word. Zeker niet omdat mensen daarmee al bekend zijn.

Echter een knopje 'plakken vanuit Word' is ook weer zoiets. Wat als de gebruiker daar nou niet op klikt? Beter is om aan de onkeyup en onmouseup events een functie te hangen die checkt of de tekst bijv. "class=Mso" bevat, dan weet je iig dat er vanuit Word geplakt is. Vervolgens filter je er een hoop zut uit. Dit herhaal je natuurlijk aan de serverkant.

Dat houdt het voor de gebruiker makkelijk en simpel.

[Zoefff]

MaZo schreef op woensdag 20 juli 2005 @ 12:04:
De code die een WYSIWYK-editor standaard uitpoept is in veel gevallen toch gewoon aan te passen, zodat je code 'valideerbaar' blijft?

Ja, maar daar gaat het niet (helemaal) om. De code kan nog zo goed valideren, maar dat wil niet meteen betekenen dat de code semantisch ook klopt.

Zoals de TS al aangeeft,

HTML:

<font size="6"><b>Titel</b></font>
<br>
<br>
<font size="2">Paragraaf blaat</font>

valideert even goed als

HTML:

<h1>Titel</h1>
<p>Paragraaf blaat</p>

maar toch is dit 2e voorbeeld veel beter.

[m.w]

Ik ben het gewoon niet met je eens dat er geen editors zijn die volgens de semantiek werken. In mijn topic WYSIWYG Editors in Javascript heb ik ook duidelijk onderscheid gemaakt tussen 2 paradigma's; full content (menu, header, content etc) of content-only editors (die werken vaak volgens semantiek).

Ik heb zojuist TinyMCE geprobeert en die maakt eigenlijk wel aardige code, mits je deze op de juiste manier gebruikt. Maar ik betwijfel of gebruikers het op kunnen brengen om, na een training, goed met zo'n editor te kunnen omgaan.

De code die een WYSIWYK-editor standaard uitpoept is in veel gevallen toch gewoon aan te passen, zodat je code 'valideerbaar' blijft?

Die kan ik inderdaad aanpassen ja, maar een gebruiker/klant die niet bekend is met webstandaarden niet.

[Verwijderd]

Dat niveau haal je toch niet met component gerichte cm systemen, omdat elk component daar op zichzelf volgens een vast stramien een template heeft en totaal niet rekening houdt met wat er om heen zit. En dat is ook een reden dat je vaak zaken ziet als:

code:

<div class="article">
  <h2 class="article_title"></h2>
  <span class="article_body"></span>
</div>

ipv

code:

<div class="article">
  <h2></h2>
</div>

En vanwege het gemis aan outline borders ook nog erg veel

code:

<table class="article">
  <tr>
     <td class="article_title"></td>
  </tr>
  <tr>
    <td class="article_body"></td>
  </tr>
</table>

[ Voor 68% gewijzigd door Verwijderd op 20-07-2005 12:24 ]

[MaZo]

m.w schreef op woensdag 20 juli 2005 @ 12:21:
[...]
Die kan ik inderdaad aanpassen ja, maar een gebruiker/klant die niet bekend is met webstandaarden niet.

Dat is dan toch niet nodig? Zolang jij zorgt dat de WYSIWYG-editor altijd valideerbare (en correcte) code uitpoept, heb je niks met de klant te maken zolang zij de 'Word' editor gebruiken. Tenzij ze zelf nog eens in de HTML gaan lopen knoeien, iets wat in veel gevallen mogelijk is met die WYSIWYG dingen.

[Bosmonster]

Snap je laatste redenaties niet helemaal. Ons CMS heeft ook de editor functionaliteit erg beperkt, juist ter bescherming van de klant.

Geen fonts, font-sizes en kleuren. En content die gepaste wordt, wordt naar tekst geconverteerd.

Verkoopt anders als een trein en klanten zijn juist te spreken over de eenvoudigheid en het feit dat ze nooit hun eigen site kunnen verneuken.

[m.w]

Dat is dan toch niet nodig? Zolang jij zorgt dat de WYSIWYG-editor altijd valideerbare (en correcte) code uitpoept, heb je niks met de klant te maken zolang zij de 'Word' editor gebruiken. Tenzij ze zelf nog eens in de HTML gaan lopen knoeien, iets wat in veel gevallen mogelijk is met die WYSIWYG dingen.

De editors van tegenwoordig genereren wel (x)html valide code, dus dat is het probleem niet.
Wat wel een probleem is dat semantiek bepaald wordt door de gebruiker. Een onwetende gebruiker kan dus geen semantiek correcte code genereren met een WYSIWYG-editor.

Snap je laatste redenaties niet helemaal. Ons CMS heeft ook de editor functionaliteit erg beperkt, juist ter bescherming van de klant.

Ik heb dat hier wel eens voorgesteld, maar ik kreeg alleen negatieve reacties.

[ Voor 18% gewijzigd door m.w op 20-07-2005 13:20 ]

[Bosmonster]

In hoeverre is semantiek uberhaupt belangrijk voor een content veld?

Even uitgaande van het feit dat je de rest van de pagina uit wel correcte templates opbouwt, inclusief dingen als titel (h1), etc.

Dat de code van de klant vervolgens gewoon p's, tabellen, span's etc is lijkt me niet echt een probleem dan. Het enige dat ik kan bedenken is eventuele header-onderverdelingen (h2, h3, etc), maar is dat zo belangrijk?

Overigens is de klant toegang geven tot html in een wysiwyg editor wel het laatste dat ik zou doen.

En als je negatieve reacties krijgt dan neem ik aan dat die ook wel goed onderbouwd zijn. Er zijn voor klanten namelijk geen voordelen aan het hebben van uitgebreide mogelijkheden voor dingen als fonts, kleuren en groottes. Het enige dat hieruit kan komen is verneuken van hun eigen design.

Sterker nog, klanten zijn het altijd 100% met ons eens dat dit soort dingen er niet in zitten. Zelfs underline hebben er uitgezet en dat snappen ze ook als we even uitleggen waarom. "Oh ja, natuurlijk. Dat is mooi, want m'n collega's maken er anders toch een puinhoop van!" zeggen ze dan. En als ze 20-30k voor een beheerbaar siteje hebben neergeteld is het wel fijn dat die niet binnen een week er niet meer uitziet.

[ Voor 21% gewijzigd door Bosmonster op 20-07-2005 13:53 ]

[alienfruit]

Je kan ook niet van de klant verwachten dat hij de ideën achter semantieke code gaat leren, hij heeft vaak wel wat beters te doen.

[m.w]

alienfruit schreef op woensdag 20 juli 2005 @ 13:58:
Je kan ook niet van de klant verwachten dat hij de ideën achter semantieke code gaat leren, hij heeft vaak wel wat beters te doen.

Precies. Maar ben jij dan als ontwikkelaar, project-leider of wat dan ook tevreden met de kwaliteit van de website ?

[Bosmonster]

m.w schreef op woensdag 20 juli 2005 @ 14:11:
[...]


Precies. Maar ben jij dan als ontwikkelaar, project-leider of wat dan ook tevreden met de kwaliteit van de website ?

Omdat het beetje door de klant ingevoerde dynamische content niet 100% semantisch correct is?

Als je daar van wakker ligt kun je beter een ander beroep zoeken imho Iets waar je 100% controle hebt en niet met derden hoeft te werken die met je systeem aan de slag gaan.

Moet je als developer van een MP3-speler wakker liggen omdat een klant er MP3'tjes in stopt met een afgrijselijke bitrate/kwaliteit?

[m.w]

Bosmonster schreef op woensdag 20 juli 2005 @ 14:15:
[...]


Omdat het beetje door de klant ingevoerde dynamische content niet 100% semantisch correct is?

Als je daar van wakker ligt kun je beter een ander beroep zoeken imho Iets waar je 100% controle hebt en niet met derden hoeft te werken die met je systeem aan de slag gaan.

Moet je als developer van een MP3-speler wakker liggen omdat een klant er MP3'tjes in stopt met een afgrijselijke bitrate/kwaliteit?

Die vergelijking gaat niet echt op, maargoed. Ik wil geen 100% controle. Ik wil een kwaliteits niveau nastreven, en naar mijn mening is dat niet alleen de vormgeving en functionaliteit van de website.

[Bosmonster]

m.w schreef op woensdag 20 juli 2005 @ 14:26:
[...]


Die vergelijking gaat niet echt op, maargoed. Ik wil geen 100% controle. Ik wil een kwaliteits niveau nastreven, en naar mijn mening is dat niet alleen de vormgeving en functionaliteit van de website.

Ik vind de vergelijking wel aardig, maar goed Je hebt maar beperkt de controle over de invoer (opmaak). Met als gevolg dat het resultaat niet altijd is als je als developer hoopt.

Maar wat ik mis in je verhaal is nog steeds, welke onderdelen zijn semantisch niet correct dat je je er zo druk over moet maken? h-tags?

Ik zou me persoonlijk eerder druk maken over hoe wat klanten invoeren eruit ziet en in hoeverre dit het design verneukt, dan hoe de html er op de achtergrond uit ziet. Daar is een oplossing voor, maar die wil je baas weer niet.

En (wederom, nog geen antwoord op gekregen) waarom is semantiek zo belangrijk in dat kleine stukje van de pagina. Is het echt ZO ERG dat daar een span ipv een h2 tag gebruikt wordt?

[ Voor 4% gewijzigd door Bosmonster op 20-07-2005 14:35 ]

[m.w]

En (wederom, nog geen antwoord op gekregen) waarom is semantiek zo belangrijk in dat kleine stukje van de pagina. Is het echt ZO ERG dat daar een span ipv een h2 tag gebruikt wordt?

Het gaat niet om een klein stukje content, het gaat om de hele content in een pagina.

En ja of ik moet gaan 'zeiken' over een span element waar een h2 beter was geweest, daar kun je over discussiëren. Maar wanneer dit meer regel is dan uitzondering dan stoor ik me daar aan ja.
Ook kan het zijn dat h2 elementen vanuit de stylesheet gestyled worden, dit gaan dan weer fout.

Nog een ander voorbeeld: een lijst met links opmaken d.m.v. span en br

Ik wil niet zo doordraven hier, maar je kunt wel begrijpen dat wanneer het ook beter kan er toch niets mee mis is om dat na te streven ?

[Verwijderd]

volgens mij is het onmogelijk met huidige generatie wysiwyg editors helemaal semantische websites te maken...

Of je moet zelf iets heel basic gaan maken, en al die meuk weg gooien en alleen iets voor titel, bold, en mischien nog iets van text align gaan doen

Maar dan gaan klanten weer zeuren, ik kon eerst veel meer in die editor

[ Voor 14% gewijzigd door Verwijderd op 20-07-2005 18:03 ]

[Verwijderd]

lol Word doet bij mij juist altijd net wat ik niet wil

Gunp01nt schreef op woensdag 20 juli 2005 @ 12:17:
[...]


Oefff... dat is nou juist het grootste voordeel van de standaard designmode in IE en FF.
Als developer ben je daar misschien huiverig voor, maar het is zo'n goede toevoeging aan de workflow dat je er eigenlijk niet onderuit kunt. Bovendien, je kunt nog zo'n goede, krachtige en prettige editor maken, je zult nooit kunnen tippen aan Word. Zeker niet omdat mensen daarmee al bekend zijn.

Echter een knopje 'plakken vanuit Word' is ook weer zoiets. Wat als de gebruiker daar nou niet op klikt? Beter is om aan de onkeyup en onmouseup events een functie te hangen die checkt of de tekst bijv. "class=Mso" bevat, dan weet je iig dat er vanuit Word geplakt is. Vervolgens filter je er een hoop zut uit. Dit herhaal je natuurlijk aan de serverkant.

Dat houdt het voor de gebruiker makkelijk en simpel.