HTML: keep the legacy of toch naar XHTML?

quote:

crisp schreef op dinsdag 10 april 2007 @ 22:20:
[...]
HTML:

1	<input type="number" min="1" max="10">

WebForms 2.0

En vanaf wanneer -realistisch gezien- is dat een optie?
Het rendeert nu wel, maar dat komt omdat elk input element naar een input type="text" rendeert als er geen type -of een foutieve- gegeven wordt.

ik wil kunnen valideren

quote:

Not Pingu schreef op dinsdag 10 april 2007 @ 22:29:
En sowieso is het grootste doel van XHTML de uitbreidbaarheid. Zolang je dat niet gebruikt mag je jezelf best afvragen waarom je XHTML dan gebruikt.

Ik gebruik XHTML (strict) eigenlijk om (samen met CSS) netjes een website op te bouwen.
Nadat dit door de validator is gekomen, is het eenvoudig om te zetten naar HTML 4.01.
Meestal laat ik het dan in XHTML staan omdat hij door de meest gebruikte browsers (inclusief IE6+7) correct wordt weergegeven....

Misschien in de toekomst wat meer experimenteren met XML, AJAX e.d.....

quote:

Ook onbekend schreef op dinsdag 10 april 2007 @ 22:43:
[...]

Ik gebruik XHTML (strict) eigenlijk om (samen met CSS) netjes een website op te bouwen.
Nadat dit door de validator is gekomen, is het eenvoudig om te zetten naar HTML 4.01.
Meestal laat ik het dan in XHTML staan omdat hij door de meest gebruikte browsers (inclusief IE6+7) correct wordt weergegeven....

Misschien in de toekomst wat meer experimenteren met XML, AJAX e.d.....

Netjes opbouwen kan in zowel XHTML als HTML. Als je XHTML door IE6+7 goed weergegeven wordt, verstuur je het als text/html en juist niet als XML. Het wordt dan ook behandeld als HTML.

Verstuur je wel als XML, dan zorgt een niet ge-escaped karakter ervoor dat er een error op het scherm getoond wordt in plaats van een error correctie.

quote:

orf schreef op dinsdag 10 april 2007 @ 22:35:
[...]

En vanaf wanneer -realistisch gezien- is dat een optie?

In Opera al een tijdje native, verder bestaan er javascript libraries die support bieden in overige browsers (inclusief IE).

quote:

Het rendeert nu wel, maar dat komt omdat elk input element naar een input type="text" rendeert als er geen type -of een foutieve- gegeven wordt.

Het is inderdaad backwards-compatible met oudere UA's wat dat betreft.

quote:

ik wil kunnen valideren

Validatie is niet de heilige graal

Maar WF is inderdaad nog maar draft en de implementatie in Opera is experimenteel. Let's hope dat de W3 HTML WG het overneemt zodat we op termijn meer implementaties kunnen verwachten

Voor nu zou ik zelf toch opteren voor een class, bijvoorbeeld class="numberRangeSmall" oid

quote:

crisp schreef op dinsdag 10 april 2007 @ 21:48:
[...]
In XHTML is je DOM-tree ook anders als je TBODY weglaat, en zo zijn er nog veel meer zaken die toch net even anders zijn in XHTML (met XHTML mimetype) ivt HTML en waar menig 'slap-on-that-XHTML-DTD-because-it-is-newer-and-better' amateur geen weet van heeft ( XHTML is not for Beginners ) - dat is uiteindelijk ook een reden waarom XHTML nooit goed van de grond is gekomen: iedereen is HTML gewend en XHTML blijkt dan toch net te ingewikkeld te zijn (ja, niet simpeler maar juist ingewikkelder).

HTML of XHTML, beide zijn even ongeschikt voor beginners. Een gladde leercurve willen we allemaal, maar het moet niet afzakken tot het niveau van speelgoed - dat is het namelijk niet. Er mogen best eisen gesteld worden aan de gebruikers van de taal.

quote:

Ik vint dat ook wel wat ja, d of t is ook maar lastig dus doen we alles maar +t - dat went ook wel

Wat je hier doet is de boel juist weer complexer maken. Overigens maak je idd nogal wat d/t fouten. Een computer-parser zou dan denken "wat doet dat voltooid deelwoord hier??". Dat maakt het er niet makkelijker op.

quote:

Ik ben het met je eens dat een aantal zaken in de huidige specificaties best wel het predikaat 'deprecated' mogen krijgen (inline style en eventhandlers bijvoorbeeld), maar an sich is dat een algemene kwestie, namelijk die van good vs bad practices, en dat is niet iets dat XHTML echt afdwingt of onmogelijk is in HTML.

True, maar mijn punt is waarom je dan zou stoppen bij SGML. XML is niet voor niets populair geworden.

quote:

Toch knap dat jij weet dat het nooit zo ontworpen is, ik denk namelijk dat javascript juist wel ontworpen is om een flexibele en bijzonder expressieve taal te zijn.

Ja mindfuck is ook flexibel. Maar expressief? No way.

quote:

Ja, JS2 geeft je straks bijvoorbeeld 'private' en 'public' maar dat is uiteindelijk enkel syntax suiker. Ik zou zeggen: geef eens wat concrete voorbeelden van wat jij beperkend en omslachtig vindt, wellicht kan ik er dan meer over zeggen.

Weak typing, afwezigheid van string formatters (a la printf), de work-arounds die je moet maken om protected variabelen/methodes te definieren met de mogelijkheid tot overerving, de onmogelijkheid om een klasse-definitie in 1 compound statement te groeperen (kan wel, maar geeft performance issues), de combinatie van timers en objecten (weer een work-around voor), geen namespaces, geen directe mogelijkheid om andere javascriptbestanden te includen/importeren, etc etc.

quote:

Ik werk zelf al aardig component-based, maar dan in javascript welke ik unobtrusive koppel aan een stukje markup. Hoe is dat anders dan wat jij voor ogen hebt dan?

Een tijd geleden heb ik in Java een tool gemaakt a la 'curves' van Photoshop en the Gimp. Ipv een standaard jPanel gebruik je dan de jCurvePanel in de code die de GUI definieert. Iets dergelijks moet gewoon native vanuit HTML kunnen. En dat kan nu niet.

quote:

Daarom is ook de WHATWG uiteindelijk opgezet en heeft op eigen initiatief drafts opgesteld voor een opvolger van HTML (en vergeet ook WebForms niet) en is W3 nu eindelijk ook wakker geschud. Er wordt dus wel degelijk aan gewerkt.

Eraan gewerkt ja, maar de kant die het op gaat stelt mij toch teleur. Zaken als
HTML:

1	<input type="number" min="1" max="10">

zijn prachtig, maar zolang je niet (ook) zelf eenvoudig en gestructureerd widgets kunt toevoegen of de bestaande kunt uitbreiden blijft het in veel situaties behelpen.

quote:

Wat wellicht iets voor jou is is misschien wel Google Web Toolkit - ideaal voor serverside programmeurs die liever niet hun vingers vies maken aan simpele clientside zaken

Die GWT moet ik idd nog eens verder bestuderen. Toch zou, in het ideale geval, de vertaalslag van Java naar Javascript overbodig mogen zijn. Het online voorbeeld dat ze daar hebben staan werkt toch ook nog lang niet zoals een desktop-app, laat staan dat het uitziet als een normale desktop-app.

Microsoft's XAML met C# als client-side(!) taal komt misschien bijzonder ver in de buurt met wat ik bedoel. Thin (or thick, als je wilt) clients maken die zich gedragen en uitzien als elke andere desktop-app, in de theme van je OS/Windows manager. Maar of dat ook geschikt is als vervanging van traditionele webpagina's met informatie betwijfel ik dan weer sterk, hoewel namespaces daar een prima oplossing voor kunnen bieden.

En dan is er nog, zoals hier al aangegeven, de vraag van ALS er dan een mooie nieuwe opvolger van HTML is gekomen (in welke vorm dan ook), het zal nog zeker jaren duren voordat we daar gebruik van kunnen maken en de browsers echt op 1 lijn zitten. Alternatieven zoals Java en Flash zijn er NU al.

Overigens, wat kunstjes die met een krachtigere taal mogelijk zijn: een 360-graden viewer en een MPEG4/AAC videoplayer als Java-applet. Vanuit de browser kun je m.b.v. LiveConnect ook nog eens prima babbelen met die applets. Techniek uit wat, 1995? Waarom zien we daar niet veel meer van? Ipv daarvan zitten we nu veelvuldig te kijken naar crappy (Flash 7) video, omdat de Flash 8/9 userbase nog te klein is ofzo.

quote:

Fuzzillogic schreef op dinsdag 10 april 2007 @ 23:49:
[...]

HTML of XHTML, beide zijn even ongeschikt voor beginners. Een gladde leercurve willen we allemaal, maar het moet niet afzakken tot het niveau van speelgoed - dat is het namelijk niet. Er mogen best eisen gesteld worden aan de gebruikers van de taal.

De vraag is: hoe hoog stel je die eisen?

quote:

[...]

Wat je hier doet is de boel juist weer complexer maken. Overigens maak je idd nogal wat d/t fouten. Een computer-parser zou dan denken "wat doet dat voltooid deelwoord hier??". Dat maakt het er niet makkelijker op.

Nederlands was inderdaad niet mijn sterkste vak, maar moet een simpele d/t-fout dan maar afgestraft worden met een orange-screen-of-death? Volgens mij begrijpt iedereen me prima zo

quote:

[...]

True, maar mijn punt is waarom je dan zou stoppen bij SGML. XML is niet voor niets populair geworden.

Ik denk ook wel dat het tijd is om af te stappen van SGML, per slot van rekening is er ook nog geen enkele browser die wat dat betreft HTML correct als SGML-applicatie heeft geimplementeerd. XML als data-interchange format is prima, als opmaak-taal vind ik de syntax te strict en beperkend.

quote:

[...]

Ja mindfuck is ook flexibel. Maar expressief? No way.

[...]

Weak typing, afwezigheid van string formatters (a la printf), de work-arounds die je moet maken om protected variabelen/methodes te definieren met de mogelijkheid tot overerving, de onmogelijkheid om een klasse-definitie in 1 compound statement te groeperen (kan wel, maar geeft performance issues), de combinatie van timers en objecten (weer een work-around voor), geen namespaces, geen directe mogelijkheid om andere javascriptbestanden te includen/importeren, etc etc.

Nog steeds geen concreet voorbeeld maar enkel wat loze kreten, jammer. Weak typing heeft zo z'n voordelen imho, string formatting is puur suiker, en dat en de rest is op zich prima te doen in javascript maar inderdaad niet op een manier zoals je gewend bent in andere talen. Maakt dat javascript tot een minderwaardige taal? Nee, alleen anders. Het is niet gek of vreemd om je coding-style aan te passen aan wat een taal je biedt, maar je moet je er wel voor open stellen. Vasthouden aan 'ja maar in taal X kan ik dit-of-dat zo-en-zo doen' is niet echt productief, er valt vast ook wel eea op te merken aan diezelfde taal X.

quote:

[...]

Een tijd geleden heb ik in Java een tool gemaakt a la 'curves' van Photoshop en the Gimp. Ipv een standaard jPanel gebruik je dan de jCurvePanel in de code die de GUI definieert. Iets dergelijks moet gewoon native vanuit HTML kunnen. En dat kan nu niet.

Misschien komt <canvas> in de buurt?

quote:

[...]

Eraan gewerkt ja, maar de kant die het op gaat stelt mij toch teleur. Zaken als
HTML:

1	<input type="number" min="1" max="10">

zijn prachtig, maar zolang je niet (ook) zelf eenvoudig en gestructureerd widgets kunt toevoegen of de bestaande kunt uitbreiden blijft het in veel situaties behelpen.

Waarom zou je niet zelf 'widgets' kunnen toevoegen? Genoeg 'hooks' die je aan markup kunt toevoegen en daar je eigen behavior-sausje overheen kan gooien lijkt me...

quote:

[...]

Die GWT moet ik idd nog eens verder bestuderen. Toch zou, in het ideale geval, de vertaalslag van Java naar Javascript overbodig mogen zijn. Het online voorbeeld dat ze daar hebben staan werkt toch ook nog lang niet zoals een desktop-app, laat staan dat het uitziet als een normale desktop-app.

Is dat uiteindelijk wel het doel dan?

quote:

Microsoft's XAML met C# als client-side(!) taal komt misschien bijzonder ver in de buurt met wat ik bedoel. Thin (or thick, als je wilt) clients maken die zich gedragen en uitzien als elke andere desktop-app, in de theme van je OS/Windows manager. Maar of dat ook geschikt is als vervanging van traditionele webpagina's met informatie betwijfel ik dan weer sterk, hoewel namespaces daar een prima oplossing voor kunnen bieden.

En dan is er nog, zoals hier al aangegeven, de vraag van ALS er dan een mooie nieuwe opvolger van HTML is gekomen (in welke vorm dan ook), het zal nog zeker jaren duren voordat we daar gebruik van kunnen maken en de browsers echt op 1 lijn zitten. Alternatieven zoals Java en Flash zijn er NU al.

Overigens, wat kunstjes die met een krachtigere taal mogelijk zijn: een 360-graden viewer en een MPEG4/AAC videoplayer als Java-applet. Vanuit de browser kun je m.b.v. LiveConnect ook nog eens prima babbelen met die applets. Techniek uit wat, 1995? Waarom zien we daar niet veel meer van? Ipv daarvan zitten we nu veelvuldig te kijken naar crappy (Flash 7) video, omdat de Flash 8/9 userbase nog te klein is ofzo.

En in hoeverre praat je dan nog over markup? Je gaat hier van een content-based format ineens over op full-fledged applications. Ik zie weinig relevantie mbt deze discussie.

quote:

Fuzzillogic schreef op dinsdag 10 april 2007 @ 23:49:
...geen directe mogelijkheid om andere javascriptbestanden te includen/importeren,...

Excuses voor het onderbreken van jullie discussie, maar is includen/importeren niet een serverside gebeuren mbt internet-talen? Vergeten we dan niet dat JS clientside is?

Javascript includen kan wel, middels de <script>-tag. Mocht je het dynamisch willen doen:
JavaScript:

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18

function createJS(source) {   if(source != "")   {     var elmJS = document.createElement("script");     elmJS.type = "text/javascript";     elmJS.src = source;     var elmHead = document.getElementsByTagName("head")[0];     elmHead.appendChild(elmJS);          return true;   }   else   {     return false;   } }

En dan verderop:
JavaScript:

1 2 3 4 5 6 7 8 9 10 11 12

<script type="text/javascript"> ... if( createJS("bla.js") ) {   alert('Aanmaken geslaagd'); } else {   alert('Kon object niet maken - geen bron opgegeven'); } ... </script>

Maargoed, we dwalen af... mijn standpunt is gelijk aan dat van crisp: HTML is prima, en xHTML is - vooral voor beginners - veel lastiger dan 'plain old' HTML, zelfs strict HTML is eenvoudiger dan strict xHTML.

Over <br> vs. <br />: <br> is veel makkelijker ingetypt dan <br />, en is ook logischer imho.
Een line-break is slechts één teken wat aangeeft dat er een nieuwe regel komt terwijl een paragraaf of vette tekst een begin en een einde kent. <strong> sluit je af met </strong> omdat je anders de rest van je pagina dikgedrukt maakt, <p> sluit je af met </p> (al hoeft dat vreemdgenoeg niet) puur voor het overzicht. Maar dit:
HTML:

1	<p>Lorem ipsum dolor <br></br> sit amet <br></br> consectetur adisciping elit.</p>

staat voor geen meter, er is ook geen opmaak. <br /> is een vervanger voor <br></br>, dus ik schrijf dat ook gewoon voluit.

Ook die draconische () errorhandling vind ik vreselijk: je kunt niet zien hoe je website eruitziet zolang er een fout inzit, terwijl je anders misschien een heel andere fout zou hebben opgelost en de globale foutfixronde (voor kleine foutjes als een ontbrekende /) pas naderhand zou doen. Draconische errorhandling bespaart geen tijd maar kost juist tijd.

quote:

Fuzzillogic schreef op dinsdag 10 april 2007 @ 23:49:
Weak typing, afwezigheid van string formatters (a la printf), de work-arounds die je moet maken om protected variabelen/methodes te definieren met de mogelijkheid tot overerving, de onmogelijkheid om een klasse-definitie in 1 compound statement te groeperen (kan wel, maar geeft performance issues), de combinatie van timers en objecten (weer een work-around voor), geen namespaces, geen directe mogelijkheid om andere javascriptbestanden te includen/importeren, etc etc.


[...]

Een tijd geleden heb ik in Java een tool gemaakt a la 'curves' van Photoshop en the Gimp. Ipv een standaard jPanel gebruik je dan de jCurvePanel in de code die de GUI definieert. Iets dergelijks moet gewoon native vanuit HTML kunnen. En dat kan nu niet.

Ik denk dat je nu een beetje te overtrokken reageert. Het is niet standaard, maar toch redelijk triviaal om een java-achtig systeem in javascript te bouwen. Met behulp van een aantal goede libraries kom je al een heel eind. Ik bedoel trouwens niet dingen als prototype, maar je eigen libraries. Het model van JS is anders, prototype-gebaseerd. Dat betekent imho niet dat het "slechter" is dan Java, je moet alleen wel wat werk doen om het java-like te maken. Bijna alle taal-features van java zijn na te bouwen in JS, maar in Java is het een stuk moeilijker om JS na te doen (met name dingen als first-order functions).

Heb je al eens naar JS2 gekeken? Die lost een aantal van jouw issues met Javascript op.

Ik denk niet dat de ene taal beter is dan de ander. The right tool for the right job. Ik zou het wel erg fijn vinden als er een generiek, goed geimplementeerd en open browser-assembly formaat komt, zodat iedereen z'n eigen favoriete taal kan compileren voor browser-gebruik.

quote:

Ook onbekend schreef op dinsdag 10 april 2007 @ 22:43:
[...]

Ik gebruik XHTML (strict) eigenlijk om (samen met CSS) netjes een website op te bouwen.
Nadat dit door de validator is gekomen, is het eenvoudig om te zetten naar HTML 4.01.
Meestal laat ik het dan in XHTML staan omdat hij door de meest gebruikte browsers (inclusief IE6+7) correct wordt weergegeven....

Misschien in de toekomst wat meer experimenteren met XML, AJAX e.d.....

En waarom, als je het toch als html gaat versturen, begin je gewoon niet met HTML en CSS? Waarom XHTML gebruiken als je er toch niks mee gaat doen, lees: als HTML gaat versturen? Je kan prima met HTML 'netjes' je website bouwen, net zo netjes als met XHTML. Ik zie IE echt niet in de komende 5 jaar opeens wel correct XHTML te kunnen afhandelen. Kortom, geef eens 1 goede rede waarom je XHTML boven HTML verkiest, terwijl het andersom in jouw situatie juist veel logischer is naar mijn mening

We Are Borg wijzigde dit bericht 11-04-2007 05:21 (72%)

Gewoon experimenteren.
Eerst heb ik de basis van HTML geleerd, daarna een beetje opmaak erbij.
Vervolgens kwam ik er achter dat er een validator voor bestond. (en alle fouten en waarschuwingen dus aangepast)

Daarna heb ik hem strict proberen te krijgen i.c.m. CSS. En vervolgens in XHTML omdat je meer in je CSS moet zetten. Het leert je dan ook om gestructureerder te werken.
Sindsdien ontwikkel ik eigenlijk volgens de XHTML specs, maar voor de rest doe ik niets met XML structuur.
Ik verstuur hem daarom inderdaad als text/html en niet als xml.

quote:

Ook onbekend schreef op woensdag 11 april 2007 @ 08:12:
Gewoon experimenteren.
[...]

Daarna heb ik hem strict proberen te krijgen i.c.m. CSS. En vervolgens in XHTML omdat je meer in je CSS moet zetten. Het leert je dan ook om gestructureerder te werken.
[..]

Leg mij eens uit waarom XHTML je wel gestructureerder leert werken (meer in CSS stoppen ) terwijl HTML strict dat niet kan?

Pff, deze discussie... De web equivalent van Windows vs Linux

Maar goed: als developer zeg ik: XHTML (application/xhtml+xml). Waarom? Omdat het moeilijker is (het vereist kennis van zaken). Het forceert kwaliteit in je code en bovendien vind ik (let op, mening!) XML prettig werken. Ik kan er met XPath en XSLT op los, ik kan namespaces gebruiken, heerlijk.

Echter, er ziijn te veel invloeden van buiten af die je code kunnen verzieken, om te kunnen werken met de strikte error handling van XML. In de praktijk is het voorlopig niet bruikbaar.

quote:

King_Louie schreef op woensdag 11 april 2007 @ 09:31:
Pff, deze discussie... De web equivalent van Windows vs Linux

Maar goed: als developer zeg ik: XHTML (application/xhtml+xml). Waarom? Omdat het moeilijker is (het vereist kennis van zaken).[/knip]

Het is beter omdat het moeilijker is? Dat is nog eens een vreemd argument

quote:

posttoast schreef op woensdag 11 april 2007 @ 09:38:
[...]

Het is beter omdat het moeilijker is? Dat is nog eens een vreemd argument

Ik ben van de vreemde argumenten

Het voordeel is dat je op deze manier van een zekere kwaliteit verzekerd bent. De developer moet weten waar ie mee bezig is, om er goed gebruik van te maken. De code zal dus van hogere kwaliteit zijn, wat weer onderhoudbaarheid ten goede komt, etc.

Door het corrigerende gedrag van HTML (of eigenlijk de parsers daarvan), is het veel makkelijker om daar een zooitje van te maken en het toch te laten werken. Dan heb ik toch liever een nette codebase

quote:

Alex) schreef op woensdag 11 april 2007 @ 00:55:
Javascript includen kan wel, middels de <script>-tag. Mocht je het dynamisch willen doen:
code:

lap code

En dan verderop:
code:

lapje code
</script>

Je slaat de spijker op zijn kop. Dit is een hack. En Javascript zit vol met dit soort gedrochten. (nofi, Alex, het gaat me om het idee)

quote:

Maargoed, we dwalen af... mijn standpunt is gelijk aan dat van crisp: HTML is prima, en xHTML is - vooral voor beginners - veel lastiger dan 'plain old' HTML, zelfs strict HTML is eenvoudiger dan strict xHTML.

[knip verhaal over <br />]

Je vindt XHTML dus prima, maar alleen <br /> val je over?

quote:

Ook die draconische () errorhandling vind ik vreselijk: je kunt niet zien hoe je website eruitziet zolang er een fout inzit, terwijl je anders misschien een heel andere fout zou hebben opgelost en de globale foutfixronde (voor kleine foutjes als een ontbrekende /) pas naderhand zou doen. Draconische errorhandling bespaart geen tijd maar kost juist tijd.

Dan moet je betere tools gebruiken. Maar zelfs als ik het met de hand type, maak ik nooit dit soort fouten, juist omdat ik gewoon alles afsluit. Gaat gewoon op de automaat.

Ach het gaat er niet eens om wat makkelijker is, HTML en XHTML liggen veel te dicht bij elkaar in de buurt om daar over te bekvechten.

Mijn punten (en ik zal ze maar eens puntgewijs neerzetten):

• XML is de logische stap voor de volgende HTML-specs
• HTML moet eindelijk eens ontdaan worden van alle deprecated zooi
• HTML voor webapps is te beperkt. Een gerichte mark-up voor webapps (XUL, XAML, you name it) zou hier uitkomst kunnen bieden. Met namespaces kun je ze door elkaar gebruiken en toch gescheiden houden.
• JavaScript is een leuk en aardig, maar niet voor de applicaties die er nu op gebouwd worden. En dat kun je niet 'fixen' door weer allerlei extra features aan de taal toe te voegen. m.i. zou het gewoon vervangen moeten worden, of een extra taal erbij. Ik zie uitbreiding met Java, middels LiveConnect-achtige zaken best wel zitten.

quote:

Fuzzillogic schreef op woensdag 11 april 2007 @ 10:20:
Je slaat de spijker op zijn kop. Dit is een hack. En Javascript zit vol met dit soort gedrochten. (nofi, Alex, het gaat me om het idee)

nofi, maar wtf is hier een hack aan? Je gebruikt de features van een taal om een functionaliteit te realiseren.

quote:

Blues schreef op woensdag 11 april 2007 @ 11:07:
[...]

nofi, maar wtf is hier een hack aan? Je gebruikt de features van een taal om een functionaliteit te realiseren.

Iets basaals als een include/import dient gewoon native in de taal te zitten. Nu gebruik je een omweg via HTML/de DOM om het doel te bereiken. In mijn boekje is dat een hack.

Ik wil Javascript niet afkraken of onderuithalen, want voor veel dingen is het prima geschikt. Alleen niet voor het bouwen van volledige, grote applicaties. Dat het kán betekent niet dat het ook handig is. Met een zaag kun je ook best een schroef de muur in draaien..

quote:

Fuzzillogic schreef op woensdag 11 april 2007 @ 11:24:
[...]
Ik wil Javascript niet afkraken of onderuithalen, want voor veel dingen is het prima geschikt. Alleen niet voor het bouwen van volledige, grote applicaties. Dat het kán betekent niet dat het ook handig is. Met een zaag kun je ook best een schroef de muur in draaien..

Mwa, je zou je kunnen afvragen of het web an sich wel geschikt is voor grote applicaties; je zit immers nog altijd met een onderliggend stateless protocol en dat is iets wat je niet zo makkelijk oplost door voor een andere taal te kiezen.

Ik denk dat je wat dat betreft ook eea moet nuanceren en zal moeten vaststellen wanneer een bepaalde technologie wel geschikt is en wanneer niet meer (en het volgens jou dus een 'hack' wordt). Wat is in jouw ogen bijvoorbeeld een 'grote applicatie'? Als ik via javascript de mogelijkheid toevoeg op dit forum om inline je reply te editten (unobtrusive offcourse) gebruik ik dan al een verkeerde technologie volgens jou? En wat is dan op dit moment of in de nabije toekomst wel een geschikt en volwaardig alternatief?

Ik heb een beetje het idee dat jij meer kijkt naar hoe iets zou moeten zijn en daarbij voorbij gaat aan de huidige praktijksituatie. Een beetje een utopie dus, eigenlijk net zoiets als XHTML2

Overigens las ik zojuist dit interessante artikel wat ook wel een beetje mijn mening weerspiegeld: http://www.digital-web.co...nd_the_future_of_the_web/

quote:

crisp schreef op woensdag 11 april 2007 @ 11:43:
Mwa, je zou je kunnen afvragen of het web an sich wel geschikt is voor grote applicaties; je zit immers nog altijd met een onderliggend stateless protocol en dat is iets wat je niet zo makkelijk oplost door voor een andere taal te kiezen.

Ik denk dat je wat dat betreft ook eea moet nuanceren en zal moeten vaststellen wanneer een bepaalde technologie wel geschikt is en wanneer niet meer (en het volgens jou dus een 'hack' wordt). Wat is in jouw ogen bijvoorbeeld een 'grote applicatie'? Als ik via javascript de mogelijkheid toevoeg op dit forum om inline je reply te editten (unobtrusive offcourse) gebruik ik dan al een verkeerde technologie volgens jou? En wat is dan op dit moment of in de nabije toekomst wel een geschikt en volwaardig alternatief?

Nee het web is helemaal niet geschikt voor grote applicaties. Bij de "online office applications" zoals Google ze aanbiedt zet ik dan ook grote vraagtekens. Maar dat zet ik ook al bij zaken als gmail. Imo is een webclient een matige vervanger voor een desktopclient. Jouw voorbeeld van inline editing is prima iets waar webtechnologie geschikt voor is. Imo moeten webapps niet krampachtig proberen om de desktopapps te evenaren. Dat is wat Google et all. wel doen. Maar inderdaad, het is subjectief.

quote:

Ik heb een beetje het idee dat jij meer kijkt naar hoe iets zou moeten zijn en daarbij voorbij gaat aan de huidige praktijksituatie. Een beetje een utopie dus, eigenlijk net zoiets als XHTML2

De praktijk is gmail. Er zijn alternatieven: een mailclients in de vorm van Java applets/WebStart. En wat is er mis met een utopie? (niets, duh). Dat we nooit daar zullen komen is logisch, maar om daarom dan alles maar bij het oude te laten?.. Ik krijg de indruk dat het vooral de browserbouwers zijn die niet willen meewerken, en hooguit aan de evolutie van de technieken willen meewerken, ipv revolutie. Developers volgen vanzelf wel, zodra nieuwe technieken goed beschikbaar zijn in de grote browsers. (een killer-app kan dan wel helpen, natuurlijk)

quote:

Overigens las ik zojuist dit interessante artikel wat ook wel een beetje mijn mening weerspiegeld: http://www.digital-web.co...nd_the_future_of_the_web/

Zal het straks eens lezen.

Het internet is groot en log. Browserbouwers willen backwards compatible zijn, webmasters willen dat browsers hun sites goed weergegeven, bezoekers willen dat hun favoriete sites het doen. Dat valt niet te rijmen met revolutionaire veranderingen.

Je kan wel allemaal dingen willen en fijn dromen, maar de werkelijkheid is anders.

quote:

King_Louie schreef op woensdag 11 april 2007 @ 09:57:
Het voordeel is dat je op deze manier van een zekere kwaliteit verzekerd bent. De developer moet weten waar ie mee bezig is, om er goed gebruik van te maken. De code zal dus van hogere kwaliteit zijn, wat weer onderhoudbaarheid ten goede komt, etc.

Dat vind ik een nogal vreemd argument. Goed werk wordt niet afgedwongen door een taal of platform. De kwaliteit van het werk is afhankelijk van de kwaliteit van de developer.
Je zou juist andersom verwachten dat een minder strikte taal (HTML/SGML) meer mensen in staat stelt om er goed mee te werken, dan een 'elitaire' taal als XHTML strict.

Het 'gevaar' van XHTML is juist dat prutsdevelopers niet ineens beter worden door het introduceren van een striktere standaard. Dus krijg je sites met nonvalide zaken waardoor de XML-wellformedness regels worden geschonden en het geen geldige XML/XHTML meer is. Dus krijgen die developers bij het bekijken van hun site een leuke parser error in beeld ipv. een site gerenderd volgens onduidelijke strategie en zullen ze binnen no time terug stappen op HTML omdat het ze daarin wel lukte. En de baas wil de nieuwe site over 2 dagen online zien, je kent dat wel.

En wat nou als HTML niet meer de features biedt die nodig zijn voor de site, omdat de opvolger waarin die features zitten alleen in XML-vorm is?

Dat XHTML leidt tot betere sites betwijfel ik ook. Een pagina well-formed krijgen is niet moeilijk, maar dat voorkomt niet dat er prutsende harries zijn die er een div-soep van gaan maken en met id's en classes gaan strooien als ware het snoepgoed uit de zak van Sinterklaas...

quote:

Fuzzillogic schreef op woensdag 11 april 2007 @ 15:49:
En wat nou als HTML niet meer de features biedt die nodig zijn voor de site, omdat de opvolger waarin die features zitten alleen in XML-vorm is?

zo ver is het nog lang niet, als het ueberhaupt zal gaan gebeuren...

quote:

Dat XHTML leidt tot betere sites betwijfel ik ook. Een pagina well-formed krijgen is niet moeilijk

Dat is wel moeilijk, zeker als je werkt met non-XML based authoring tools en/of je te maken hebt met 3rd party content die niet gegarandeerd well-formed is.

Als je echt XML-based bezig wil zijn dan zal alles daarop ingericht moeten zijn, van content-validation tot en met markup-generation. IRL zie je dat bijna nooit en wordt er nog veel string-handling gedaan (biedt dus geen garantie), en ad-providers gebruiken zelfs meestal nog script-injection met document.write().

quote:

, maar dat voorkomt niet dat er prutsende harries zijn die er een div-soep van gaan maken en met id's en classes gaan strooien als ware het snoepgoed uit de zak van Sinterklaas...

prutsende harries zal je altijd blijven houden; elke techniek kan je op goede en op slechte manieren gebruiken.

quote:

Not Pingu schreef op woensdag 11 april 2007 @ 15:23:
[...]


Dat vind ik een nogal vreemd argument. Goed werk wordt niet afgedwongen door een taal of platform. De kwaliteit van het werk is afhankelijk van de kwaliteit van de developer.

Dat ben ik volledig met je eens. Maar we weten allemaal dat iedere lolbroek met Frontpage en wat copy/paste skills zichzelf tegenwoordig web developer kan noemen. Ik wens die mensen veel succes om een goede XHTML pagina neer te zetten.

quote:

Je zou juist andersom verwachten dat een minder strikte taal (HTML/SGML) meer mensen in staat stelt om er goed mee te werken, dan een 'elitaire' taal als XHTML strict.

Juist dat soepele biedt meer ruimte voor prutswerk (maar een volledig well formed, XHTML 1.1 validerende pagina kan nog steeds een bende zijn).

quote:

Het 'gevaar' van XHTML is juist dat prutsdevelopers niet ineens beter worden door het introduceren van een striktere standaard. Dus krijg je sites met nonvalide zaken waardoor de XML-wellformedness regels worden geschonden en het geen geldige XML/XHTML meer is. Dus krijgen die developers bij het bekijken van hun site een leuke parser error in beeld ipv. een site gerenderd volgens onduidelijke strategie en zullen ze binnen no time terug stappen op HTML omdat het ze daarin wel lukte. En de baas wil de nieuwe site over 2 dagen online zien, je kent dat wel.

Het is ook hoe ik het graag zou zien, ik heb nooit gezegd dat het haalbaar is

Overigens is goed XML gebruik op zich nog een utopie, want veel developers hebben er niets tot weinig van begrepen.

Victor wijzigde dit bericht 11-04-2007 17:50 (3%)