• User Attivo

    @Vale76 said:

    Allora a questo punto propongo la domanda: vale la pena di passare da un sito validato in HTML 4.01 Strict a Xhtml Transitional, per il mero gusto di dire che si è riusciti a validare le nostre pagine in xhtml? Ha senso passare, comunque sia, da una DTD di tipo Strict, a una di livello Transitional, senza ricavarne dei reali benefici per il sito e per l'utenza? Boh, mi sembrerebbe come di downgradare il livello del codice.. non so, a voi la risposta :mmm:

    Assolutamente no, molto meglio sempre una DTD di tipo strict.
    L' unica che "obbliga" a separare i contenuti dalla presentazione degli stessi.

    @Vale76 said:

    Sul fatto della chiusura dei tag, e sulle reali differenze fra i due ( XML a parte, che però bisogna conoscere.. ), Elvino, ti riferivi al fatto che xhtml esige la chiusura dei cosiddetti tag vuoti ? ( < /> )
    Perché onestamente, lavorando in questa settimana, al sito che sto rifacendo per il mio amico, in xhtml, all'inizio mi sembrava quasi un azzardo, per le mie conoscenze; ma poi, anche per fortuna, avendo avuto da subito una struttura adeguata, non è che sto notando, francamente, tutta questa differenza nel modo di scrivere il codice.

    XHTML 1.x richiede i tag in carattere minuscolo, corretta annidazione es:
    [html]<div><p><strong>Ciao</strong></p></div>[/html]e chiusura anche dei tag "singoli" es:
    [html]
    <br />
    <hr />
    <meta name="" content="" />
    <link rel="" type="" href="" />
    [/html]La realtà è che l' XHTML è un mezzo flop perché viene servito nel 99,99% dei casi come text/html e quindi viene trattato come HTML.
    Se venisse servito come application/xhtml+xml ( IE 6 o 7 non supporta) il minimo errore nella chiusura di un tag bloccherebbe il sito e vedresti un bel messaggio di errore nel browser... quindi questo obbligherebbe a scrivere codice pulito.
    Ovviamente con tutti i problemi che si creerebbero con i messaggi nei commenti di un blog per esempio...

    @Vale76 said:

    Parlavate del rigore del linguaggio: dunque, html non richiede la chiusura dei tag vuoti, ok, ma ai moderni browser fa tutta questa differenza? Correggetemi se sbaglio, ma se fosse proprio così, il 99 per cento dei siti in circolazione, compresi quelli validati al 4.01, sarebbe innavigabili, o no?

    Perché i browser si arrangiano a sistemare i casini...

    @Vale76 said:

    La presentazione, mi pare, che si usi uno o l'altro dei due, è adibita esclusivamente ai CSS, e su questo credo, nessuna obiezione 🙂
    quindi, è possibile benissimo separare completamente il contenuto dalla presentazione in ambedue gli ambienti, quindi continuo a non capire, XML a parte, che cosa aveva che nn andava, html 4.01. Abbiamo imparato per esperienza, che tutto dipende dalla professionalità di chi compila il codice, e che non basta piazzare una bella dtd nel documento, pensando di fare bella figura, se il codice è scritto da cani, magari in visuale :nonono:

    Ti ho risposto sopra... l' XHTML è nato per essere servito come application/xhtml+xml
    Riscrivo il link che avevo scritto in un post precedente:
    http://ceterumcenseo.altervista.org/css-web/index.html#xhtml-harmful

    @Vale76 said:

    Personalmente, mi trovo a un bivio: ho un sito che credo si aggira sulle 6000 pagine, forse anche di più; sfortunatamente per me, non so nulla di XML, e sicuramente non sarei in grado di rivalidare tutto il sito a xhtml 1.0 Strict. Quindi, essendo validato in 4.01 Strict, ne vale la pena che lo smonti da capo per passare al xhtml transitional?
    No. O passi a XHTML 1.0 Strict o XHTML 1.1 servito come application/xhtml+xml se il browser lo supporta.
    O meglio e meno dispendioso, lasci HTML 4.01 Strict, in attesa di veder HTML 5 e XHTML 2...

    Ciau


  • Bannato User Attivo

    @Elvino said:

    Assolutamente no, molto meglio sempre una DTD di tipo strict. L' unica che "obbliga" a separare i contenuti dalla presentazione degli stessi.

    caro Elvino, qui mi dai una buona notizia, molto defatigante per me!! ghghg 😄

    @Elvino said:

    XHTML 1.x richiede i tag in carattere minuscolo, corretta annidazione es:
    [html]<div><p><strong>Ciao</strong></p></div>[/html]e chiusura anche dei tag "singoli" es:
    [html]
    <br />
    <hr />
    <meta name="" content="" />
    <link rel="" type="" href="" />

    ma l'annidazione deve essere corretta anche in hml, o la pagina non funziona e dubito che, se inserisco un div dentro a un p (cosa che non vedo neanche come sia possibile) e dubito che il validatore lo passi :mmm:

    @Elvino said:

    La realtà è che l' XHTML è un mezzo flop perché viene servito nel 99,99% dei casi come text/html e quindi viene trattato come HTML.
    Se venisse servito come application/xhtml+xml ( IE 6 o 7 non supporta) il minimo errore nella chiusura di un tag bloccherebbe il sito e vedresti un bel messaggio di errore nel browser... quindi questo obbligherebbe a scrivere codice pulito.
    Ovviamente con tutti i problemi che si creerebbero con i messaggi nei commenti di un blog per esempio...

    Riscrivo il link che avevo scritto in un post precedente:
    http://ceterumcenseo.altervista.org/css-web/index.html#xhtml-harmful

    siiiiiiii interessantissime letture, e ne avevo già sentito un pò parlare di questa cosa, anche sul forum di html.it
    Certo che è un bel problema... non è molto positiva la prospettiva per il futuro.. con questo pericolo di "guerra" tra i due possibili nuovi standard, non è che, oltre che fare parecchia confusione, rischiamo di ritrovarci indietro?

    @Elvino said:

    No. O passi a XHTML 1.0 Strict o XHTML 1.1 servito come application/xhtml+xml se il browser lo supporta.
    O meglio e meno dispendioso, lasci HTML 4.01 Strict, in attesa di veder HTML 5 e XHTML 2...

    Ciau

    e misa anche a me che mi conviene aspettare... tra quanto tempo si saprà quale dei due l'avrà spuntata come definitivo successore del 4.01 e dell'attuale 1.0 ?


  • Bannato User Attivo

    ah, ripensando ai blog, ovviamente l'esempio che facevi tu calza a pennello, ma questo problema non si potrebbe risolvere usando un CMS?


  • Bannato User Attivo

    riprendo questa discussione perché vi chiedo se ci sono novità in vista, almeno in tempi brevi, sulla questione HTML 5 o XHTML 2.
    Come già detto, il mio sito è attualmente scritto in html4, e a lungo andare mi sto stufando dei limiti strutturali del layout che ho, che non mi consente determinate espandibilità rispetto ai più attuali layout fluidi e a colonne.

    Sarebbe determinante sapere quale sarà il linguaggio del futuro, perché, mi spiego, se veramente HTML 5 sarà sviluppato, allora mi prenderà la botta di matto veramente di rifarlo daccapo con un layout nuovo.

    Qualcuno ha notizie più fresche? 🙂


  • Moderatore

    si il W3C ha deciso di terminare lo sviluppo di html 5 e di proporlo come successore del 4

    il motivo è ovviamente lo scarso successo di xhtml nell'ambito web


  • Bannato User Attivo

    @paolino said:

    si il W3C ha deciso di terminare lo sviluppo di html 5 e di proporlo come successore del 4

    il motivo è ovviamente lo scarso successo di xhtml nell'ambito web

    acciiiiii veramente!! e si sa quando usciranno le specifiche?? cosa pensi che cambierà a livello di marcatura?

    ****** Update post ******

    Ovviamente ora mi son scatenata nella zuppa di ricerche forniti da google!

    Ma HTML5 non abolisce l’uso di XHTML. Infatti la specifica porta avanti parallelamente due linguaggi: HTML5, e il corrispondente XHTML5. Chi vorrà potrà ancora utilizzare XHTML.

    fonte: http://www.ecologiadeisitiweb.net/blog/domande-e-risposte-sullhtml5

    Quindi? In pratica, cosa significa? Che tra qualche mese i siti fatti con il vecchio 4.01 saranno vecchi, non più validi e obbligatoriamente da rifare? Aiuto mi sto sentendo male..

    ***** Altro Update *****

    Gli autori prevedono che lo sviluppo completo occuperà i prossimi 15 anni, dunque hanno preso le cose seriamente…

    o Gesùùùùùùùùùù ma è possibile veramente una cosa del genere??? 😮


  • Moderatore

    no i siti fatti con html 4 sono validissimi e il supporto credo che durerà almeno altri 10 anni, senza contare che html 4 e 5 hanno molte cose in comune....è chiaro che nel momento in cui html 5 diviene ufficiale è meglio iniziare ad usarlo

    ad ogni c'è un'ottima introduzione della IBM su html 5 http://www.ibm.com/developerworks/library/x-html5/

    ad ogni modo non è il caso di preoccuparsi visto che quest'anno hanno deciso di riprendere lo sviluppo di html 5, quindi penso che impiegheranno almeno un paio d'anni anche se alcuni browser supportano già i costrutti più importanti di html 5


  • Bannato User Attivo

    @paolino said:

    è chiaro che nel momento in cui html 5 diviene ufficiale è meglio iniziare ad usarlo

    Quindi, quando? Veramente tra 15 anni?

    Domanda interessata: io che in questi giorni ho la testa in subbuglio perché vorrei rifare il mio mastodontico sito di 7000 pagine, adottando un layout più attuale, che mi conviene fare a sto punto? rifarlo e buonasera, o aspettare che il 5 diventi ufficiale, ma con la certezza che a quel punto il sito sarà diventato ancora più grande? 😞

    @paolino said:

    ad ogni modo non è il caso di preoccuparsi visto che quest'anno hanno deciso di riprendere lo sviluppo di html 5, quindi penso che impiegheranno almeno un paio d'anni anche se alcuni browser supportano già i costrutti più importanti di html 5

    si infatti questo l'ho letto, in quell'articolo "domande e risposte". Una cosa che mi lascia perplessa è questa: in un punto dell'articolo l'autore scriveva chiaramente che nel momento in cui sarà necessario passare dal 4 al 5, basterà cambiare la doctype. Nella mia inesperienza, mi suona un pò troppo facile sta cosa.. tu che dici?


  • Moderatore

    per quanto riguarda i siti dipende da come vengono fatti....

    per esempio l'approccio adottato dai CMS è il migliore, in quanto puoi cambiare l'intero codice html conservando però tutti i dati che compongono il sito stesso....in questo caso si può operare al meglio seguendo gli standard attuali e poi aggiornare quando sarà

    per quanto riguarda la retrocompatibilità, direi, che al 90% html 5 è retrocompatibile con html 4, quindi moltissima roba rimarrà identica.....effettivamente html 5 aggiunge alla lista dei deprecati alcuni costrutti inutili e assurdi e aggiunge tutta una serie di costrutti pensati per il web 2

    sostanzialmente non c'è necessità di temere html 5, primo perchè mancano anni prima che venga reso di uso comune, secondo perchè in ogni caso i browser continueranno a supportare html 4, xhtml e compagnia


  • Bannato User Attivo

    @paolino said:

    per quanto riguarda i siti dipende da come vengono fatti....

    per esempio l'approccio adottato dai CMS è il migliore, in quanto puoi cambiare l'intero codice html conservando però tutti i dati che compongono il sito stesso....in questo caso si può operare al meglio seguendo gli standard attuali e poi aggiornare quando sarà

    quindi suggeriresti di rifare il sito in CMS ( anche li, con quale doctype? ) e poi stare a vedere?...mmm..


  • Moderatore

    @Vale76 said:

    quindi suggeriresti di rifare il sito in CMS ( anche li, con quale doctype? ) e poi stare a vedere?...mmm..

    beh i CMS servono a tante cose legate al web 2.0, un sito moderno dovrebbe prendere in considerazione qualcosa tipo Drupal, Joomla, Wordpress, E107


  • Bannato User Attivo

    ho scaricato diversi layout, e sto tentando degli abbozzi, perché l'istinto mi dice di raccogliere la sfida anche se onerosa, ma non è facile trovare un layout veramente adatto alle mie esigenze.

    Ecco un primo stub veramente minimale al volo:

    [url=http://www.paroledautore.net/test/zenlike/zenlike/prova.htm]prova layout 1

    mi pare un pò una roba da blog, più che sito.. che dite? :mmm:


  • Moderatore

    su oswd.org si trova parecchia roba interessante

    inoltre i template di Drupal sono molto ben fatti....per Joomla c'è molto di più però, sia free che a pagamento


  • Super User

    Dura la vita per chi ama xhtml come me 😞


  • Bannato User Attivo

    @pikadilly said:

    Dura la vita per chi ama xhtml come me 😞

    cmq sinceramente questa non è una bella situazione. A mio avviso sarebbe stato più logico sceglierne uno e basta..


  • Super User

    @Vale76 said:

    cmq sinceramente questa non è una bella situazione. A mio avviso sarebbe stato più logico sceglierne uno e basta..

    Concordo, non solo per i webmaster ma soprattutto per chi si affaccia a questo mondo non per lavoro ma per puro divertimento, ma che nonostante ciò non vuole rinunciare agli standard.
    Poi non capisco...xhtml è perfetto, non fa una piega, mette un pò d'ordine nei documenti html...forse lo strict alle volte è un pò duro però nulla di infattibile.
    Non esiste cambiare una cosa perchè nessuno la utilizza...che poi non è assolutamente vero...tuttavia invece di fare le lotte per renderci la vita difficile sarebbe meglio che qualcuno impedisse a certe case proprietarie di browser di interpretare ancora il codice come gli pare!!!


  • Bannato User Attivo

    @pikadilly said:

    invece di fare le lotte per renderci la vita difficile sarebbe meglio che qualcuno impedisse a certe case proprietarie di browser di interpretare ancora il codice come gli pare!!!

    concordo assoluamente. Però credo anche che non sia vero che anche html non possa essere scritto in maniera rigorosa, e che non possa garantire la totale separazione del contenuto dalla presentazione, specie con una dtd strict 🙂


  • Moderatore

    @Vale76 said:

    concordo assoluamente. Però credo anche che non sia vero che anche html non possa essere scritto in maniera rigorosa, e che non possa garantire la totale separazione del contenuto dalla presentazione, specie con una dtd strict 🙂

    il problema non è la separazione del contenuto dalla presentazione, quanto piuttosto la differenza che passa tra XHTML e HTML a livello di parsing da parte degli user agent e a livello validazione

    per definizione HTML è un linguaggio di markup e come tale può contenere errori non terminali che possono essere corretti.....tutti i linguaggi più diffusi sono così....il C ammette i warning, il Pascal lo stesso....

    XHTML invece derivando da XML è un linguaggio che non ammette errori, ovvero se il codice viene trovato errato o ci sono anche solo delle condizioni che generano più interpretazioni, il codice è considerato non validato e in teoria gli user agent dovrebbero rigettarlo

    inutile dire che nessun browser ad oggi ha mai ragionato così....fatto XHTML cominciarono a spuntare come funghi le varie euristiche per correggere errori più o meno gravi, il che ha trasformato XHTML in un fratello quasi gemello di HTML

    le euristiche per inciso sono responsabili del perchè i nostri browser sono dei grassi esegubili mangia-RAM....nel caso dei cellulari per esempio dove la memoria è poca ci si avvale proprio dell'assioma che il codice XML dev'essere corretto per eliminare le euristiche...inutile dire che non tutti agiscono così, un nome caso è MS con il suo windows mobile e IE

    il punto è che allo stato attuale delle cose XHTML e HTML sono dei duplicati, sono di fatto identici se non per cose strane tipo <br/> al posto di <br> e altre amenità insignificanti del genere, ma certamente il motivo per cui XHTML è nato è venuto meno ed è per questo che il W3C ha preferito migliorare HTML proponendo la versione 5


  • Bannato User Attivo

    @paolino said:

    XHTML invece derivando da XML è un linguaggio che non ammette errori, ovvero se il codice viene trovato errato o ci sono anche solo delle condizioni che generano più interpretazioni, il codice è considerato non validato e in teoria gli user agent dovrebbero rigettarlo

    si, l'ho letta anche io da più parti questa cosa, però, sinceramente mi sembra eccessivo: ha veramente senso questa rigidezza tecnica? Il codice dovrebbe essere regolato sempre e formale, ok, ma ha senso un linguaggio che per un solo errore rimanda una pagina bianca all'utente? scusate ma sta cosa per me non ha molto senso. La ricchezza del Web è la fruibilità a un numero immenso di contenuti, e io da utente, sinceramente, mi sentirei un pò gabbata se stessi cercando un'informazione urgente e cliccando su un sito in cui penso di trovare quello che cerco, mi si aprisse una pagina vuota.. Non è meglio un minimo di flessibilità, non dico tanto, ma mica tutti gli errori sono da ritenersi della stessa gravità, o no?


  • Moderatore

    non devi ragionare dal punto di vista del linguaggio nè da quello del browser, ma da quello dello sviluppatore di siti web....

    le varie incompatibilità che vediamo tra i browser dipendono in buona parte proprio dalle euristiche, che sono differenti dall'uno all'altro, e che sono la diretta conseguenza di un linguaggio che ammette l'esistenza di errori nel codice....

    nel mondo perfetto di XML, tutti gli sviluppatori dovrebbero obbligatoriamente rendere i loro siti web validati, i browser dovrebbero visualizzare una finestra di errore nel caso si imbattano in una pagina non validata e i crawler dei motori di ricerca dovrebbero scartare a priori tutti i siti non validati....

    da un lato questo implica un mucchio di lavoro, dall'altro però implica una migliore fruibilità da parte di tutti gli utenti e di tutte le piattaforme

    il problema è che la maggior parte dei web developer non prestano nessuna attenzione alla validazione e moltissimi usano strumenti wysiwyg che in quanto a correttezza formale lasciano molto a desiderare

    il bello è che con gli anni la situazione è peggiorata e si trovano pagine web in giro che sono letteralmente non parsabili senza usare euristiche pesanti....roba che se la parsi tramite un banale parser SGML o anche tramite un tool sofisticato come BeautifulSoup, alla fine ti ritrovi con pezzi di markup tra le stringhe di testo e via dicendo....

    XML impone solo un pò più di lavoro in fase progettuale, per esempio i siti Wordpress e Drupal spessissimo riescono ad essere validati senza problemi ( eccezzion fatta per cose davvero inutili tipo l'obbligo dell'attributo alt nelle immagini e altre cose simili )

    praticamente XHTML è impossibile da imporre, perchè nel campo dei web developer c'è molta inerzia e poca attenzione alla correttezza del codice