2010-07-27 22 views
0

J'ai eu une pensée plus tôt aujourd'hui au sujet des balises HTML imbriquées et comment les navigateurs les render:Combien de balises imbriquées en HTML pouvez-vous avoir avant de bloquer un navigateur?

<html xmlns="http://www.w3.org/1999/xhtml" {or whichever html version} xml:lang="en" lang="en"> 
<head> 
</head> 
<body> 

let n = 1

<div> 

récursion div n fois jusqu'à un maximum (navigateur échoue)

</div> 
</body> 
</html> 

que sera n quand le navigateur ne peut plus gérer la récursivité?

Je pense que ce serait différent pour chaque navigateur, et différent pour les applications mobiles. Existe-t-il une norme Web, telle que la longueur maximale de 127 caractères pour les noms de domaine?

Je n'ai jamais rencontré ce problème, mais je suis curieux quand il le ferait.

Répondre

3

Il n'y a pas de standard nécessitant une imbrication maximale, donc ce sera entièrement spécifique à l'implémentation.

Il y a des chances que le navigateur devienne inutilisable avant le plantage (ralentissements, etc.).

Si vous êtes curieux, vous pouvez référence ce - le code d'une application qui génère des balises imbriquées et voir quand chaque navigateur se bloque sur vous :)

+0

Je peux essayer juste cela. Mais je voulais voir si quelqu'un le savait déjà ou l'avait déjà rencontré. –

0

vous inquiétez pas trop. Ou vous prévoyez une mise en page trop compliquée waaay. Et même dans ce cas, il est très improbable que vous atteigniez une telle limite avec du code HTML non délibérément créé pour le faire.

Si l'analyseur HTML du navigateur est récursif, il risque de se bloquer s'il est alimenté par des balises profondément imbriquées simplement parce que la pile déborde. Mais sur les systèmes/systèmes d'exploitation modernes, la pile est par défaut assez grande pour supporter une centaine de niveaux de récursion, selon la taille des variables allouées par la pile.

Si l'analyseur est pas récursive, mon prochain pari serait un OutOfMemoryError quand donné un document extrêmement complexe (incroyablement grand incroyablement profondément imbriqué et).

+0

pas inquiet. l'idée était hypothétique. –

+1

Dans mon expérience, il s'agissait de grandes tables complexes et profondément imbriquées qui posaient des problèmes. Principalement à faire avec le moteur de mise en page, pas l'analyseur. – Oded

+0

@Oded: N'a pas pensé à cela, mais maintenant vous le mentionnez, est plus probable (au moins, plus probable que de souffler l'analyseur) – delnan