Mi sono spesso chiesto perché non è stato scelto un parsing rigoroso 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 le funzionalità obsolete.
C'è una ragione specifica per cui HTML non viene analizzato rigorosamente?
Il motivo è semplice: al momento dei primi browser grafici, NCSA Mosiac e in seguito Netscape Navigator, quasi tutto l'HTML era scritto a mano. Gli autori del browser (Netscape è stato creato da ex membri di Mosaic) hanno riconosciuto rapidamente che rifiutare di rendere l'HTML non corretto sarebbe stato tenuto contro di loro dagli utenti, e voilà!
Perché fare le ipotesi migliori è la cosa giusta da fare, dal punto di vista del produttore di browser. Considera la situazione: idealmente, l'HTML che ricevi è completamente corretto e specifico. È fantastico. Ma la parte interessante è che cosa succede quando l'HTML è non corretto; dal momento che abbiamo a che fare con input da una fonte su cui non abbiamo alcuna influenza, in realtà, dobbiamo essere preparati a questo. Ora quando ciò accade, cosa potremmo fare? Abbiamo due opzioni: a) fallire e b) fare il miglior sforzo per recuperare dall'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ù giusta.
L'unico vero problema con questo è quando hai bisogno dei messaggi di errore, che di solito è in una situazione di sviluppo - vuoi assicurarti che l'HTML che generi sia corretto, e dal momento che "funziona nel browser X "non è equivalente a" corretto ", non possiamo semplicemente eseguirlo attraverso un browser e vedere se funziona: non possiamo dire la differenza tra HTML corretto e HTML non corretto che il browser ha corretto per te. Questo è un problema risolvibile però; ci sono plug-in del browser che segnalano violazioni degli standard, c'è il validatore del W3C e molti altri strumenti simili.
Gli autori HTML e gli strumenti di authoring generano markup scadente. I browser fanno del loro meglio per motivi di concorrenza: un browser che non riesce a rendere la maggior parte delle pagine Web in modo ragionevole verrà rifiutato dagli utenti, che non si preoccuperanno minimamente di chi sia il difetto.
È piuttosto diverso da ciò che fanno le implementazioni del linguaggio di programmazione. I compilatori e gli interpreti lavorano sul codice che si può presumere essere scritto da un programmatore, mentre tutti e suo fratello possono scrivere HTML con una formazione minima, o senza. Il codice HTML è un codice, in un certo senso, ma è dati piuttosto che istruzioni di linguaggio di programmazione e la (buona) tradizione del software è di essere tollerante con i dati.
XHTML impone in linea di principio regole di analisi rigorose (XML), in modo 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 al utente. Questo non è mai diventato popolare nell'authoring del Web: quasi tutto il "XHTML" in giro è servito come text / html e processato come zuppa di tag tradizionale in un modo molto liberale, solo con alcune nuove eccentricità.
In breve, l'HTML sarebbe basato su un altro linguaggio di marcatura non hyperlink chiamato SGML, spesso usato per documentazione e manuali e simili.
Da un articolo sulla storia dell'HTML:
Tim had mentioned that some of the early HTML documents were based on an old SGML language that CERN was already using:- We have included in HTML some tags from the SGML tagset used at and once supported at CERN [...] The HTML parser will ignore tags which it does not understand, and will ignore attributes which it does not understand of CERN-SGML tags.
[...] most of the early HTML tags were actually taken from the CERN SGMLGuid language, which itself was a variant of AAP (an early SGML language). For example, title, hn, p, ol and so on are all apparently taken from this language. The only radical change was the addition of the all important anchor () link, without which the WWW wouldn't have taken off.
Prendendo nota della parte che ho messo in evidenza, in pratica, hanno implementato un sottoinsieme dei tag disponibili nel sistema SGML a loro familiare, aggiungendo il nuovo ancoraggio < a > tag, e scegliendo di ignorare uno dei molti tag che non gli interessa o che desiderano supportare per il motivo wahtever (come i tag per gli elenchi di bibliografia, xmp per il tag "example", "box" per disegnare una casella attorno a un blocco di testo, ecc.). Quindi il modo più semplice per farlo è perdonare il markup che non è noto al parser e ignorare il markup sconosciuto nel miglior modo possibile, indipendentemente dal fatto che la causa sia il markup errato dall'utente o il modo più semplice per convertire i documenti esistenti in questo nuovo formato HTML consiste nell'aggiungere alcuni collegamenti ipertestuali ai documenti SGML esistenti e ignorare tutti i tag non supportati o implementati.
Questo è parzialmente un residuo storico della guerra dei browser
IE e netscape erano in competizione per conquistare il mercato e hanno continuato a rilasciare nuove funzionalità che diventavano sempre più "fantastiche", ed erano forzate 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 cose e di conseguenza un sacco di versioni diverse (con alcune speci con parole ambigue) in cui il browser vuole supportare la maggior parte di esse e la creazione di un parser separato per ciascuna versione sarebbe enorme. Quindi è (relativamente) più facile usare un singolo parser con diverse modalità.
Per un'altra parte netscape e IE volevano che html fosse accessibile per l'uomo comune (come era la moda in quei giorni) il che significava cercare di fare ciò che l'utente voleva essere fatto invece di quello che diceva di fare e inciampare su ogni penzoloni tag.
Il problema peggiore è che ci sono anche diversi siti "tutorial" che insegnano la cosa sbagliata e pensano di avere ragione perché ciò che insegnano funziona.
In definitiva questo significa che se ora crei un browser con solo un html rigoroso che analizza il 99% dei siti non funzionerà.
Bene, abbiamo tentato di stabilire una buona opzione rigorosa negli anni '000 ma non è andata a buon fine perché le persone che seguivano le "best practice" ciecamente, incolpavano i browser quando il loro codice errato andava in pezzi in modalità rigorosa. E ai venditori di browser non piaceva essere accusati.
Hanno affermato che era perché volevano che il web fosse più accessibile ai non professionisti, ma a nessuno veniva impedito di usare l'HTML 4 nella sua forma più indulgente.
Detto questo, puoi ancora pubblicare HTML5 come XML se desideri un layout in stile rigoroso. IMO può essere un buon modo per trarre vantaggio dal fatto che il layout o l'interfaccia utente funzionano in una modalità più rigida prima di trasmetterli ad altre persone che potrebbero o meno volere che siano rigorose senza rischi reali (escludendo la possibilità di estrarre il doctype perché in realtà preferiscono la modalità quirks - nel 2017 (il tempo di questa modifica) dovrebbero essere girati, quindi è ancora lì fondamentalmente ma fai qualche ricerca. Mi sembra di ricordare che ci sono alcune avvertenze che non abbiamo avuto con XHTML che non Impatto davvero sul lavoro di impaginazione, ma non spargere la voce che è "l'unico modo per farlo nel modo giusto" oi twit che comprano quel tipo di discorsi daranno credito all'idea, incolperanno di nuovo i browser e prenderanno i denti dall'unica alternativa restrittiva che ci è rimasta. (2017 modifica: non ho idea se questo funzioni ancora - rinunciato)