Perché l'analisi rigorosa non è stata scelta per HTML?

Mi sono spesso chiesto perché non sia stato scelto un analisi rigorosa durante la creazione di HTML. Per la maggior parte della storia di Internet, i browser hanno accettato qualsiasi tipo di markup e hanno fatto del loro meglio per analizzarlo. Il processo degrada le prestazioni, consente alle persone di scrivere senza senso e rende difficile interrompere funzionalità obsolete.

C'è un motivo specifico per cui l'HTML non è rigorosamente analizzato?

Il motivo è semplice: al momento dei primi browser grafici, NCSA Mosiac e successivamente Netscape Navigator, quasi tutto l'HTML era scritto a mano. Gli autori del browser (Netscape è stato creato da persone ex-Mosaic) hanno riconosciuto rapidamente che il rifiuto di eseguire il rendering di HTML errato sarebbe stato respinto dagli utenti e voilà!

Perché fare le ipotesi migliori è la cosa giusta da fare, dal punto di vista del browser maker. Considera la situazione: idealmente, l'HTML che ricevi è completamente corretto e su specifica. È fantastico. Ma la parte interessante è cosa succede quando l'HTML non è corretto; poiché abbiamo a che fare con input da una fonte su cui non abbiamo alcuna influenza, in realtà, dobbiamo essere preparati per questo. Ora, quando ciò accade, cosa possiamo fare? Abbiamo due opzioni: a) fallire eb) fare il possibile per recuperare l'errore. Se falliamo, l'utente non ha nient'altro che un messaggio di errore inutile e non c'è nulla che possano fare al riguardo, perché non controllano il server. Se facciamo il massimo sforzo, l'utente ha almeno quello che potremmo fare della pagina, e spesso l'ipotesi è per lo più corretta.

L'unico vero problema con questo è quando hai bisogno dei messaggi di errore, che in genere si trovano in una situazione di sviluppo: vuoi assicurarti che l'HTML che generi sia corretto e dato che "funziona nel browser X" non equivale a "corretto", non possiamo semplicemente eseguirlo attraverso un browser e vedere se funziona: non possiamo dire la differenza tra HTML corretto e HTML errato che il browser ha corretto per te. Questo è un problema risolvibile però; ci sono plugin del browser che segnalano violazioni degli standard, c'è il validatore W3C e molti altri strumenti simili.

Gli autori HTML e gli strumenti di creazione producono markup scadenti. I browser fanno del loro meglio per motivi competitivi: un browser che non riesce a visualizzare la maggior parte delle pagine Web in modo ragionevole sarà rifiutato dagli utenti, a cui non importa minimamente di chi sia la colpa.

È piuttosto diverso da quello che fanno le implementazioni del linguaggio di programmazione. Compilatori e interpreti lavorano su un codice che si può presumere sia stato scritto da un programmatore, mentre tutti e suo fratello possono scrivere HTML con una formazione minima o senza. Il markup HTML è un codice, in un certo senso, ma sono dati piuttosto che istruzioni del linguaggio di programmazione e la (buona) tradizione nel software deve essere tollerante con i dati.

XHTML in linea di principio impone regole di analisi rigorose (XML), in modo tale che un documento XHTML pubblicato con un tipo di contenuto XML venga visualizzato solo se è ben formato in senso XML, altrimenti solo il primo errore viene comunicato all'utente. Questo non è mai diventato popolare nell'authoring web - quasi tutto il "XHTML" in giro è servito come text / html ed elaborato come tag soup tradizionale in un modo molto liberale, solo con alcune nuove eccentricità.

In sostanza, l'HTML si basava su un altro linguaggio di markup non hyperlink chiamato SGML spesso usato per documentazione e manuali e simili.

Da un articolo sulla storia dell'HTML:

Tim aveva menzionato che alcuni dei primi documenti HTML erano basati su un vecchio linguaggio SGML che il CERN stava già utilizzando: - Abbiamo incluso in HTML alcuni tag del tagset SGML utilizzati e una volta supportati al CERN [...] Il parser HTML ignorerà i tag che non comprende e ignorerà gli attributi che non comprende i tag CERN-SGML .

[...] la maggior parte dei primi tag HTML sono stati in realtà presi dal linguaggio SGMLGuid del CERN, che a sua volta era una variante di AAP (un primo linguaggio SGML). Ad esempio, titolo, hn, p, ol e così via sono tutti apparentemente tratti da questa lingua. L'unico cambiamento radicale fu l'aggiunta del collegamento anchor () molto importante, senza il quale il WWW non sarebbe decollato.

Prendendo nota della parte che ho messo in grassetto, in pratica, hanno implementato un sottoinsieme dei tag disponibili nel sistema SGML con cui avevano familiarità, aggiungendo il nuovo tag anchor <a> e scegliendo di ignorare uno dei tanti tag che non avevano non ti interessa o desideri supportarlo per motivi di wahtever (come tag per elenchi bibliografici, xmp per "esempio", tag "box" per disegnare un riquadro attorno a un blocco di testo, ecc.). Quindi il modo più semplice per farlo è quello di perdonare il markup che non è conosciuto dal parser e ignorare il markup sconosciuto nel miglior modo possibile, indipendentemente dal fatto che la causa sia un markup errato digitato dall'utente o il modo più semplice e veloce per convertire documenti esistenti in questo nuovo formato HTML consente di aggiungere alcuni collegamenti ipertestuali ai documenti SGML esistenti e di ignorare qualsiasi tag non supportato o implementato.

Questo è in parte un residuo storico della guerra dei browser

IE e netscape erano in competizione per conquistare il mercato e continuavano a rilasciare nuove funzionalità che continuavano a diventare sempre più "fantastiche", e sono stati costretti ad accettare le pagine progettate per l'altro browser.

Ciò significa che il browser accetta e ignora silenziosamente i tag sconosciuti, dopo che i comitati hanno iniziato a essere coinvolti ... beh, hai un comitato che progetta materiale e di conseguenza molte versioni diverse (con alcune specifiche ambigue) in cui il browser vuole supportare la maggior parte di e la creazione di un parser separato per ogni versione sarebbe enorme. Quindi è (relativamente) più facile usare un singolo parser con diverse modalità.

Da un'altra parte, netscape e IE volevano che HTML fosse accessibile per l'uomo comune (come lo era la moda di quei giorni), il che significa cercare di fare ciò che l'utente voleva fare invece di quello che diceva di fare e inciampare su ogni tag penzolante.

A peggiorare il problema è che ci sono anche diversi siti "tutorial" che insegnano la cosa sbagliata e pensano che siano giusti perché ciò che insegnano funziona.

In definitiva, ciò significa che se ora crei un browser con solo HTML rigoroso che analizza il 99% dei siti, semplicemente non funzionerà.

Bene, abbiamo cercato di stabilire una buona opzione rigorosa negli anni '000, ma non ha funzionato perché le persone che seguivano "le migliori pratiche" alla cieca, incolpavano i browser quando il loro markup errato andava a pezzi in modalità rigorosa. E ai venditori di browser non piaceva essere incolpati.

Sostenevano che fosse perché volevano che il web fosse più accessibile ai non professionisti, ma a nessuno veniva impedito di usare HTML 4 nella sua forma più indulgente.

Detto questo, puoi comunque servire HTML5 come XML se desideri un layout rigoroso. IMO può essere un buon modo per raccogliere i benefici del layout o dell'interfaccia utente in una modalità più rigorosa prima di trasmetterlo ad altre persone che potrebbero o meno volerlo come rigoroso senza rischi reali (escludendoli strappando il doctype perché in realtà favoriscono la modalità stranezze - nel 2017 (il tempo di questa modifica) dovrebbero essere girati. Quindi è ancora lì praticamente ma faccio qualche ricerca. Mi sembra di ricordare che ci sono alcuni avvertimenti che non avevamo con XHTML che non influenzano davvero il lavoro di layout. Basta non spargere la voce che è "l'unico modo per farlo bene" o che gli stupidi che acquistano in quel tipo di chiacchiere accecheranno l'idea, incolperanno di nuovo i browser e si prenderanno i denti dall'unica alternativa rigorosa che ci è rimasta. (modifica del 2017:

http://mathiasbynens.be/notes/xhtml5