HTML aanpassingen server-side ipv client-side; nadelen?

[chem]

Bij onze klanten gebruiken we een gelaagd template-systeem. Er is een basis-laag voor component A, daaorp een basis-laag voor component B, gevolgd door meerdere lagen voor een klant en zijn/haar sub-projecten.

Bij het zoeken naar bestanden gaan we van boven naar beneden; dit heeft als voordeel dat bestanden die niet gewijzigd zijn voor een project (maw gedefinieerd zijn in de klant-laag) bij een update automatisch meegaan.

Nu zijn er vaak wijzigingen die de klant op grote schaal wil doorvoeren. Denk aan submit-buttons met fancy randjes, andere teksten, radicaal andere layout etc - dat zou betekenen dat we alle templates moeten overzetten wat bij updates een tijdrovende klus is om weer bij te werken.

De teksten lossen we op met (wederom) gelaagde vertalingsbestanden. De fancy submit buttons,waar extra HTML voor nodig is (hulp-divjes) doen we door midel van JavaScript; we zoeken bv alle input[type=submit] en gooien extra hulp-divjes in de parentNode.

Dit laatste zie ik steeds meer gepromoot worden; denk aan de vele jQuery plugins en drop-in scripts, maar ook banners etc.

Het voordeel is duidelijk: kant en klare componenten, erin gooien en klaar. Het nadeel is dat de browser steeds meer voor zijn kiezen krijgt.
Dit geldt des te meer voor IE6, die geen first/last-child, multiple classes, direct-sibling selectors, attribute selectors etc. kent - om met generieke HTML de layout toch voor elkaar te krijgen wordt er voor IE6 een aantal hulp-scriptjes client-side gedraaid die die zaken dmv cssQuery (oid) uitzoekt en handmatig classes toevoegt, zodat een iefix.css dit weer recht kan trekken.

We merken dat de grafisch zware websites die we bouwen een bovengemiddelde last op de browser leggen. Daarbij worden de compenseer-de-css-tekortkomingen/vul-de-dom-aan etc. pas afgevuurd als de DOMContentLoaded is. IE kent dit niet, en we hebben nog geen oplossing gevonden om bij IE6 en banners (die weer in iframes draaien) de events vroeger af te vuren. Resultaat: onjuiste layout totdat de banner (of een andere externe resource) binnen is.

De laatste tijd zijn we aan het experimenten om dit server-side af te handelen. Met http://nl3.php.net/manual/en/class.domdocument.php en http://nl3.php.net/domdoc...ual/en/class.domxpath.php kan je al deze zaken oplossen vóór ze naar de browser gaan.

We zijn op dit moment de laatste problemen hierbij aan het oplossen; denk aan invalid html in/invalid uit, en dat als je content dmv ajax binnenhaalt de context vaak ontbreekt, waardoor selectors niet werken.

Zijn er andere mensen die op deze manier werken? Hoe bevalt het client-side laten afhandelen van dit soort problemen? Hoe werken jullie om de CSS-tekortkomingen van IE6 heen; wijzigen jullie per project de HTML om IE te helpen?

[_Thanatos_]

IE kent dit niet, en we hebben nog geen oplossing gevonden om bij IE6 en banners (die weer in iframes draaien) de events vroeger af te vuren. Resultaat: onjuiste layout totdat de banner (of een andere externe resource) binnen is.

IE kent inderdaad geen DOMContentLoaded, maar dat wil niet zeggen dat script pas uitgevoerd worden zodra je pagina ingeladen is. Als je pagina werkelijk op externe resources aan het wachten is, is dát het probleem dat je eerst moet aanpakken. Dat kan bijvoorbeeld door zulke scripts niet inline te zetten, of als het flash is, ze asynchroon te laden.

Je zult er dus achter moeten komen waarom je script te laat wordt uitgevoerd. Want als je het mij vraagt, dan heb ik er nooit last van gehad dat bijv jQuery's $(document).ready event te laat afgevuurd wordt in IE6. Waarschijnlijk dus iets in de pagina dat de boel ophoudt. Cuzillion is een handige tool om dat te onderzoeken en direct te kunnen experimenteren door dingen te verschuiven. De "Net" tab van Firebug helpt ook veel en geeft een realistisch beeld van wat wanneer wordt uitgevoerd.

Hoe werken jullie om de CSS-tekortkomingen van IE6 heen; wijzigen jullie per project de HTML om IE te helpen?

Javascript gebruiken om CSS-tekortkomingen te omzeilen smaakt wat zuur. Ik vind het voor IE6 gedoogd, maar alleen als de site nog werkbaar is wanneer javascript uit staat. Dus navigatie en links en forms enzo moeten dan nog wel gewoon werken.

Iets als dit vind ik bijvoorbeeld een prima manier van werken:

JavaScript:

$("tbody > tr:nth-child(even)").addClass("zebra");

[ Voor 8% gewijzigd door _Thanatos_ op 15-02-2009 14:15 ]

[chem]

_Thanatos_ schreef op zondag 15 februari 2009 @ 14:13:
[...]

IE kent inderdaad geen DOMContentLoaded, maar dat wil niet zeggen dat script pas uitgevoerd worden zodra je pagina ingeladen is. Als je pagina werkelijk op externe resources aan het wachten is, is dát het probleem dat je eerst moet aanpakken. Dat kan bijvoorbeeld door zulke scripts niet inline te zetten, of als het flash is, ze asynchroon te laden.

Als er banner-scripts aangeleverd worden zit je vast aan inline scripts; weinig tot geen bannerboeren leveren fatsoenlijke code aan. Vrijwel altijd zijn het veel te complexe document.write()'s van iframes met javascript die iframes schrijven die...
Als daar vervolgens 1 trage host tussen zit, dan blijft IE maar wachten op die ene hosts voordat de pagina klaar is.

Daarbij kan het ook gebeuren dat je zélf langzaam bent, wat meer problemen geeft voor de gebruiker dan een 'trage' site.

Je zult er dus achter moeten komen waarom je script te laat wordt uitgevoerd. Want als je het mij vraagt, dan heb ik er nooit last van gehad dat bijv jQuery's $(document).ready event te laat afgevuurd wordt in IE6. Waarschijnlijk dus iets in de pagina dat de boel ophoudt. Cuzillion is een handige tool om dat te onderzoeken en direct te kunnen experimenteren door dingen te verschuiven. De "Net" tab van Firebug helpt ook veel en geeft een realistisch beeld van wat wanneer wordt uitgevoerd.

Helaas werkt de laatste uiteraard niet in IE6, maar er zijn andere tools.

Het is echter niet alleen het punt dat het te laat gebeurd; het is ook de vraag of je wel wil dat de browser nog zoveel aan de DOM moet rommelen.

[...]
Javascript gebruiken om CSS-tekortkomingen te omzeilen smaakt wat zuur. Ik vind het voor IE6 gedoogd, maar alleen als de site nog werkbaar is wanneer javascript uit staat. Dus navigatie en links en forms enzo moeten dan nog wel gewoon werken.

Uiteraard; we bouwen in eerste instantie zonder JS, maar uiteindelijk klaagt de klant (terecht) dat de site 'verspringt' na een paar seconden indien externe resources de boel tot een stilstand brengen.

_Thanatos_ schreef op zondag 15 februari 2009 @ 14:13:
Iets als dit vind ik bijvoorbeeld een prima manier van werken:

JavaScript:

$("tbody > tr:nth-child(even)").addClass("zebra");

Klopt, maar die gaat toch in IE6 een knipper-effect geven. Daarbij heb je het bij grootschalige complexen al snel over een hele waslijst van dit soort 'addClass' calls. En als je dan ook nog met de DOM elementen moet schuiven...

[ Voor 10% gewijzigd door chem op 15-02-2009 14:25 ]

[_Thanatos_]

Als er banner-scripts aangeleverd worden zit je vast aan inline scripts; weinig tot geen bannerboeren leveren fatsoenlijke code aan. Vrijwel altijd zijn het veel te complexe document.write()'s van iframes met javascript die iframes schrijven die...

Die kun je dus op een later moment in de pagina schuiven, mocht dat de oplossing zijn.

Helaas werkt de laatste [Firebug] uiteraard niet in IE6, maar er zijn andere tools.

Als het goed is, zijn de geserveerde bestanden in FF en IE gelijk, anders moet je die maar ff tijdelijk gelijktrekken. Firebug is dan gewoon m.i. de beste tool om de timings van je files te bekijken. Voor IE (alle browsers eigenlijk) bestaat er overigens ook Fiddler, maar die geeft minder info wat betreft timings.

Klopt, maar die gaat toch in IE6 een knipper-effect geven. Daarbij heb je het bij grootschalige complexen al snel over een hele waslijst van dit soort 'addClass' calls.

Dan kun je proberen die calls onderaan de pagina te zetten, ipv in document/ready of onload. Dus jQuery (of je favo framework) in de head en de addClass calls onderaan de pagina (maar nog steeds wel in een extern script) en niet in eoa load-event.

[chem]

Je hebt wel gelijk dat er het een en ander in IE verbeterd kan worden wbt de banners; maar eigenlijk is dat niet zozeer mijn vraag.

offtopic:
daarbij kan je de banners niet verschuiven aangezien de code behoorlijk pauper is opgezet met document.write()'s

Mijn vraag is vooral: zijn er andere mensen die ook deze verschuiving hebben gedaan?

[Pkunk]

chem schreef op zondag 15 februari 2009 @ 13:06:
Zijn er andere mensen die op deze manier werken? Hoe bevalt het client-side laten afhandelen van dit soort problemen? Hoe werken jullie om de CSS-tekortkomingen van IE6 heen; wijzigen jullie per project de HTML om IE te helpen?

Wij doen dingen zoals mooie knopjes e.d. allemaal server side. Je genereerd daar de html m.b.v. een template. In ons geval doen we dat met xslt. Dan krijg je bijvoorbeeld zo'n soort constructie:

HTML:

<div>
Shizzle
<mooie-knop>Doe!</mooie-knop>
</div>

i.c.m.

HTML:

<xsl:template match="mooie-knop">
 <div>
  <div class="bovenkant"/>
  <div class="inhoud" onclick="form.submit();"><xsl:value-of select="."/></div>
  <div class="onderkant"/>
 </div>
</xsl:template/>

Hierdoor zit je sowiso al niet met ie6 problemen m.b.t. de DOM. Deze manier zal je niet snel gebruiken denk ik gezien het een vrij specifieke setup vereist, maar het gaat natuurlijk om het idee.

Daarbij zijn er volgens mij zat alternatieven zoals .net web user controls en in spring zitten ook een hoop van dit soort constructies.

Alle css problemen die je dan overhoud.. sja.. daar zijn genoeg topics over te vinden zegmaar

[ Voor 5% gewijzigd door Pkunk op 16-02-2009 15:27 ]

[chem]

Afgezien van de meest ranzig submitknop code ever vraag ik me af hoe je dit in de praktijk doet.

Je zegt nu als ik het goed zie dat jullie in een soort tussentaal (eigen DTD) geen echte/volledige html maar een structuur definieeren, en die via xslt omzetten.

Maar, hoe doe je dit dan in de praktijk - waarom voldoet standaard HTML niet en verzin je nieuwe tags/structuren om dit duidelijk te maken? Wat is de meerwaarde van "mooie-knop" tegen "<input type="submit" class="mooie-knop" />" ?

[Pkunk]

chem schreef op dinsdag 17 februari 2009 @ 09:53:
Afgezien van de meest ranzig submitknop code ever vraag ik me af hoe je dit in de praktijk doet.

Je zegt nu als ik het goed zie dat jullie in een soort tussentaal (eigen DTD) geen echte/volledige html maar een structuur definieeren, en die via xslt omzetten.

Maar, hoe doe je dit dan in de praktijk - waarom voldoet standaard HTML niet en verzin je nieuwe tags/structuren om dit duidelijk te maken? Wat is de meerwaarde van "mooie-knop" tegen "<input type="submit" class="mooie-knop" />" ?

Ik dacht uit je verhaal op te maken dat jullie zelf hulp elementen toevoegen m.b.v. javascript. Zoals die top,bottom en content divjes. Het enige verschil is dat wij dit dus server side doen. Het nadeel is inderdaad wel dat je altijd vieze(re) html hebt. Maar je hebt geen gezeur met javascript (ie en performance).

[chem]

Maar waarom hebben jullie gekozen om nieuwe tags te bedenken en die om te zetten op een latere fase? Waarom geen bestaande elementen (server-side) omzetten?

En ik zou ook graag willen weten hoe je dit per project oplost; of hergebruiken jullie weinig html?

[BtM909]

DOMContentLoaded voor IE / Safari is trouwens ook te workarounden.

Vroegah gebruikte je vieze workaround met document.writes en script tags met defer. Tegenwoordig check je Safari met document.readyState en IE met Element.doScroll.

Volgens MSDN is het een fool-proof methode:

http://msdn.microsoft.com/en-us/library/ms531426.aspx
“… A few methods, such as doScroll, require the primary document to be completely loaded. If these methods are part of an initialization function, they should be handled when the ondocumentready event fires. …”

Of nog beter (voor IE):

http://groups.google.com/...d/thread/517dd87b61515162
I have another technique that I posted to the list a while back, that I'll be switching jQuery to. If you attempt to insert into the document.body before the document is fully loaded, an exception is thrown. I take advantage of that to determine when the document is fully loaded. I like that particular technique better because it actually tells you when you can manipulate the DOM - as opposed to this scroll thing which may, or may not, correspond to the document being loaded.

[ Voor 31% gewijzigd door BtM909 op 17-02-2009 10:55 ]

[Pkunk]

chem schreef op dinsdag 17 februari 2009 @ 10:27:
Maar waarom hebben jullie gekozen om nieuwe tags te bedenken en die om te zetten op een latere fase? Waarom geen bestaande elementen (server-side) omzetten?

En ik zou ook graag willen weten hoe je dit per project oplost; of hergebruiken jullie weinig html?

Ik snap niet helemaal wat je bedoeld. De latere fase is nog steeds server side. Hoe kan ik server side alle elementen uit de dom verzamelen die nog nieteens getekend zijn? Het maakt niks uit of het bestaande elementen zijn of niet, want er wordt vervolgens toch mee gedaan wat we willen.

Op het moment dat ik bijvoorbeeld een formuliertje maak waarvan ik weet dat ik net zo'n vieze knop nodig heb als bij dat andere formuliertje dan moet ik op de een of andere manier kenbaar maken waar die code staat.

Voor de duidelijkheid. Wat we dus uiteindelijk als html uitpoepen is:

HTML:

<div>
Shizzle
  <div>
    <div class="bovenkant"/>
    <div class="inhoud" onclick="form.submit();">Doe!</div>
    <div class="onderkant"/>
  </div>
</div>

Daarnaast hergebruiken we eigenlijk nooit html per project.

[chem]

Timlog schreef op dinsdag 17 februari 2009 @ 12:21:
[...]

Ik snap niet helemaal wat je bedoeld. De latere fase is nog steeds server side. Hoe kan ik server side alle elementen uit de dom verzamelen die nog nieteens getekend zijn? Het maakt niks uit of het bestaande elementen zijn of niet, want er wordt vervolgens toch mee gedaan wat we willen.

Op het moment dat ik bijvoorbeeld een formuliertje maak waarvan ik weet dat ik net zo'n vieze knop nodig heb als bij dat andere formuliertje dan moet ik op de een of andere manier kenbaar maken waar die code staat.

Nou mijn vraag is, al is het wat offtopic, waarom je een 'mooie-knop' tag definieert ipv een 'input type="submit" class="mooie-knop"' ?

Voor de duidelijkheid. Wat we dus uiteindelijk als html uitpoepen is:

HTML:

<div>
Shizzle
  <div>
    <div class="bovenkant"/>
    <div class="inhoud" onclick="form.submit();">Doe!</div>
    <div class="onderkant"/>
  </div>
</div>

Daarnaast hergebruiken we eigenlijk nooit html per project.

Aha, ja dat bepaalt wel dat er een aanzienlijk andere workflow ontstaat wbt herbruikbaarheid.

Volgens mij zijn we een van de weinige partijen die onze templates hergebruiken; alhoewel het me ondoenlijk lijk om alles maar per klant opnieuw te schrijven.

[Pkunk]

chem schreef op dinsdag 17 februari 2009 @ 12:37:
[...]
Nou mijn vraag is, al is het wat offtopic, waarom je een 'mooie-knop' tag definieert ipv een 'input type="submit" class="mooie-knop"' ?

Ten eerste omdat het een stuk moeilijker matchen is op input type en classname. Dan krijg je iets van:

HTML:

<xsl:template match="input[@type='submit' and @classname='noemeensiets']"/>

tegenover:

HTML:

<xsl:template match="knoppie"/>

Daarbij maakt het helemaal niets uit. Of ik nou op een <input /> match of een <whatever/>. Ik doe er vervolgens toch iets mee wat compleet onafhankelijk is van waarop gematched wordt.

[ Voor 15% gewijzigd door Pkunk op 17-02-2009 12:59 ]

[chem]

Het voordeel van de eerste situatie, bij het herbruiken van templates, is dat je met een beetje mazzel de oude templates helemaal niet hoeft te voorzien van een 'mooie-knop' tag

[Pkunk]

chem schreef op dinsdag 17 februari 2009 @ 13:02:
Het voordeel van de eerste situatie, bij het herbruiken van templates, is dat je met een beetje mazzel de oude templates helemaal niet hoeft te voorzien van een 'mooie-knop' tag

haha ja da's waar natuurlijk

[_Thanatos_]

Dan mag ik alleen wel hopen dat je <button type="submit"> gebruikt? Daar mag ook html in staan (sterker nog, dat is de bedoeling) en werkt ook nog es zonder javascript en met het toetsenbord

Over die XSLT, je kunt het natuurlijk ook combineren. Dat je dus <mooi-knopje/> kunt gebruiken, maar dat je em backwards compatible met <input type="submit".../> maakt.

HTML:

<xsl:template match="mooi-knopje | input[@type=submit]">
  <button type="submit">
    <div class="bovenkant"></div>
    <div><xsl:value-of select="."/><xsl:value-of select="@value"/></div>
    <div class="bovenkant"></div>
  </button>
</xsl:template>