J'ai une idée, mais qui existe sans doute déjà, tellement elle est simple.
 
Plutôt que de transférer des pages html en toutes lettres, avec des balises représentées par des mots, puis parsées par le navigateur, pourquoi ne pas coder les balises en binaire, par exemple sur 8 bits.
 
exemple actuel :
< body > = 6 caractères => 6o = 48bits
< form > = 48bits
< img > = 40bits
 
exemple codé en binaire :
< body > = 00000001 => 8 bits
< form > = 00001010 => 8 bilts
< img > = 00000100 => 8bits
 
On y gagnerait pas mal niveau temps de transfert. Et puis plus besoin de parsing. Le navigateur sait exactement quoi faire.
Ca ressemblerait un peu à de l'assembleur, niveau codage des instructions et des paramètres.
 
Question : est-ce que ca existe ? Pourquoi n'est-ce pas utilisé comme ça, outre la facilité d'édition ?
 
Merci d'avance    

tu trouves que c'est deja pas assez le bordel pour générer un code correct ?

outre le fait que c'est completement con, comment tu mets du texte dedans sans le confondre avec tes balises ?

Est-ce que les pages sont vraiment transférées en toutes lettres ? Il me semblait qu'elles étaient compressées à l'émission et décompressées à la réception par les matériels de télécommunication.

Rhôôôô, quel bande de pisses-froid
 
Ça existe déjà avec EBML, et c'est usité par le container Matroska

C'est optionnel, et c'est pas fait par les matériels mais par les serveurs et les navigateurs.

Justement, l'amélioration de versions en version est un tel bordel qu'il serait interessant de repartir à neuf...
 
 

Je pensais pas à un mode d'édition au notepad comme actuellement, mais à des pages compilées. Comme en assembleur, tu écris MOVE.L et l'assembleur te pond un binaire.
 
 
C'est marrant comme la plupart des gens se sentent agressés par une idée extérieure...  
C'était qu'une idée hein, déserrez les fesses. On peut en discuter...

tu n'as pas compris ma question.
 
une page web, c'est des balises, mais aussi du texte.
comment représente tu ce texte, les attributs des balises, le contenu de ta page ?

mod_gzip t'explose à l'aise.

Je n'ai pas encore inventé de nouveau langage hein, je me renseignais...
C'est juste que je remarque que l'on perd de l'efficacité en gardant les instructions standard en toutes lettres.

Donnerait (binaire, hexadécimal et ascii en vrac, au final, ca fait du binaire)
 

00000000 = < html>
10000000 = </ html>
00000001 = < head>
10000001 = </head>
etc...
 
Ajout d'attribut dans la balise body :
 
 
00000011 --------  0001 --------  0001 -------- AAAAAA
code_body nbre_attributs type_1er_attribut valeur_attribut
 
avec 0001 qui correspond à bgcolor.
le navigateur voit que c'est l'attribut bgcolor et donc sait qu'il doit lire 6x4 bits après les 4 bits du type.
 
Pour le contenu, il suffit, comme en C, d'arreter le texte dès qu'on rencontre un "/0"
 
PS : /0 représente le backslash-zero.

Hypothèse appuyée par ?

Comment tu fais la différence entre un tag et un caractère ???
Ca n'a aucun sens. On est sur un langage extensible, au contenu de taille variable. Pour en faire un mode binaire, la seule solution, c'est tout prefixé avec la taille de ce qui suit pour pouvoir le comprendre. Ou d'utiliser des détrompeurs/caractères d'échappement à tout va. Au final, on en revient à: extensible ? taille variable ? mais c'est du format texte !

Ouais en fait ton truc c'est de l'XML avec le nom des tags limités à un seul caractère

+1
Plus sérieusement, je pense que la compression à la 'mod_gzip' (qui existe déjà et fonctionne très bien) par les serveurs et les navigateurs réponds largement au problème de taille des flux à transférer ...
Si tu veux ré-inventer un nouveau langage 'from scratch', pk pas ?, mais bon, est-ce que ça vaut réellement le coup ?
Et puis mélanger du binaire pour représenter tes balises et du texte pour le contenu, c'est HYPER risqué (source de bugs, de failles dans les navigateurs, ...), au final, ça ne sera pas plus simple que l'HTML qui est quand même plutôt stable comme langage ...
 

Et puis un rappel tout bête, ce qui prend le plus de temps à transférer, c'est pas tellement le code html de quelques ko, mais toutes les ressources de la page web : images, javascript, css, animations flash...
Donc y'a bien plus à gagner en optimisant la taille de ces ressources que le code html.
ex : pour les images, j'ai fait un test en redimensionnant une image avec Ms Photo Editor en jpg puis le même redimensionnement avec photoshop 6 et son "enregistré sous optimisé pour le web". Ben y'a pas photo, avec photoshop, j'avais une meilleure qualité visuelle (pas d'effet escalier dû au redimensionnement) et une image 3 fois plus petite!

Dépend des pages, et quand tu ajoutes html + JS + CSS, un bon coup de mod_gzip ou mod_deflate par dessus ça fait quand même pas gagner.

Après, clairement les optimisations de médias sont d'une grande importance, d'autant plus quand ce sont des trucs facilement optimisables (PNGs 8, 24 ou 32, GIFs, CSS sprites, ...)

Exactement. C'est pour ca que l'on envoie le code du body, ensuite le nombre d'attributs, et enfin la liste des attributs et de leur valeur.
Dans tous les langages, quand ya du texte, c'est forcément à la suite du binaire. On préfixe simplement la taille, ou alors on utilise un caractère de fin.
Cette technique est déjà utilisée partout, pourquoi pas sur le web.
 
Mais en effet, je reconnais qu'on peut optimiser de facon plus conséquente en compressant les ressources web.

Double post.

Pour quel intérêt ? Le binaire c'est bien quand tu peux gagner beaucoup en taille. Ici, remplacé <head></head> par quelques autre octets sur une pages de 90Ko, ça vaut pas la complexification. Avoir une représentation plus compacte des noms de tags, ça ne constitue pas en soit une binairafication, c'est juste de la compression.Et vu la taille que ça représente les tags, ça n'a aucun intérêt si au final, il s'agit simplement de choisir des noms plus courts au tags.
 
Si tu voulais vraiment faire un format binaire, il te faudrait une entêtre, avec dedans les offsets des différents paragraphes, tags, attributs, une nomenclature définissant les tags, c'est à dire un format fixe.

surtout que tu gagne rien sur la page trivial avec les 6 balises strictement necessaire et 1Mo de texte :€ la ou gzip va compresser le tout :€