forked from zenorocha/diveintohtml5
-
Notifications
You must be signed in to change notification settings - Fork 6
/
past.html
1495 lines (1456 loc) · 66.9 KB
/
past.html
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
125
126
127
128
129
130
131
132
133
134
135
136
137
138
139
140
141
142
143
144
145
146
147
148
149
150
151
152
153
154
155
156
157
158
159
160
161
162
163
164
165
166
167
168
169
170
171
172
173
174
175
176
177
178
179
180
181
182
183
184
185
186
187
188
189
190
191
192
193
194
195
196
197
198
199
200
201
202
203
204
205
206
207
208
209
210
211
212
213
214
215
216
217
218
219
220
221
222
223
224
225
226
227
228
229
230
231
232
233
234
235
236
237
238
239
240
241
242
243
244
245
246
247
248
249
250
251
252
253
254
255
256
257
258
259
260
261
262
263
264
265
266
267
268
269
270
271
272
273
274
275
276
277
278
279
280
281
282
283
284
285
286
287
288
289
290
291
292
293
294
295
296
297
298
299
300
301
302
303
304
305
306
307
308
309
310
311
312
313
314
315
316
317
318
319
320
321
322
323
324
325
326
327
328
329
330
331
332
333
334
335
336
337
338
339
340
341
342
343
344
345
346
347
348
349
350
351
352
353
354
355
356
357
358
359
360
361
362
363
364
365
366
367
368
369
370
371
372
373
374
375
376
377
378
379
380
381
382
383
384
385
386
387
388
389
390
391
392
393
394
395
396
397
398
399
400
401
402
403
404
405
406
407
408
409
410
411
412
413
414
415
416
417
418
419
420
421
422
423
424
425
426
427
428
429
430
431
432
433
434
435
436
437
438
439
440
441
442
443
444
445
446
447
448
449
450
451
452
453
454
455
456
457
458
459
460
461
462
463
464
465
466
467
468
469
470
471
472
473
474
475
476
477
478
479
480
481
482
483
484
485
486
487
488
489
490
491
492
493
494
495
496
497
498
499
500
501
502
503
504
505
506
507
508
509
510
511
512
513
514
515
516
517
518
519
520
521
522
523
524
525
526
527
528
529
530
531
532
533
534
535
536
537
538
539
540
541
542
543
544
545
546
547
548
549
550
551
552
553
554
555
556
557
558
559
560
561
562
563
564
565
566
567
568
569
570
571
572
573
574
575
576
577
578
579
580
581
582
583
584
585
586
587
588
589
590
591
592
593
594
595
596
597
598
599
600
601
602
603
604
605
606
607
608
609
610
611
612
613
614
615
616
617
618
619
620
621
622
623
624
625
626
627
628
629
630
631
632
633
634
635
636
637
638
639
640
641
642
643
644
645
646
647
648
649
650
651
652
653
654
655
656
657
658
659
660
661
662
663
664
665
666
667
668
669
670
671
672
673
674
675
676
677
678
679
680
681
682
683
684
685
686
687
688
689
690
691
692
693
694
695
696
697
698
699
700
701
702
703
704
705
706
707
708
709
710
711
712
713
714
715
716
717
718
719
720
721
722
723
724
725
726
727
728
729
730
731
732
733
734
735
736
737
738
739
740
741
742
743
744
745
746
747
748
749
750
751
752
753
754
755
756
757
758
759
760
761
762
763
764
765
766
767
768
769
770
771
772
773
774
775
776
777
778
779
780
781
782
783
784
785
786
787
788
789
790
791
792
793
794
795
796
797
798
799
800
801
802
803
804
805
806
807
808
809
810
811
812
813
814
815
816
817
818
819
820
821
822
823
824
825
826
827
828
829
830
831
832
833
834
835
836
837
838
839
840
841
842
843
844
845
846
847
848
849
850
851
852
853
854
855
856
857
858
859
860
861
862
863
864
865
866
867
868
869
870
871
872
873
874
875
876
877
878
879
880
881
882
883
884
885
886
887
888
889
890
891
892
893
894
895
896
897
898
899
900
901
902
903
904
905
906
907
908
909
910
911
912
913
914
915
916
917
918
919
920
921
922
923
924
925
926
927
928
929
930
931
932
933
934
935
936
937
938
939
940
941
942
943
944
945
946
947
948
949
950
951
952
953
954
955
956
957
958
959
960
961
962
963
964
965
966
967
968
969
970
971
972
973
974
975
976
977
978
979
980
981
982
983
984
985
986
987
988
989
990
991
992
993
994
995
996
997
998
999
1000
---
title: Como chegamos aqui - Dive Into HTML5
---
<!DOCTYPE html>
<html lang="pt-br">
<head>
<meta charset="utf-8" />
<title>{{ page.title }}</title>
<!--[if lt IE 9]><script src=j/html5.js></script><![endif]-->
<link
rel="alternate"
type="application/atom+xml"
href="https://github.com/webfatorial/diveintohtml5/commits/gh-pages.atom"
/>
<link
rel="alternate"
href="http://diveintohtml5.info/past.html"
hreflang="en"
/>
<link rel="stylesheet" href="screen.css" />
<style>
body {
counter-reset: h1 1;
}
</style>
<link
rel="stylesheet"
media="only screen and (max-device-width: 480px)"
href="mobile.css"
/>
<link rel="prefetch" href="index.html" />
</head>
<body cz-shortcut-listen="true">
{% include fork.html %}
<p>
Você está aqui: <a href="index.html">Home</a> <span class="u">‣</span>
<a href="table-of-contents.html#history">Dive Into <abbr>HTML5</abbr></a>
<span class="u">‣</span>
</p>
<h1><br />Como chegamos aqui?</h1>
<p id="toc"><a href="javascript:showTOC()">exibir índice analítico</a></p>
<p class="a">❧</p>
<h2 id="divingin">Mergulhando</h2>
<p class="f">
<img src="i/aoc-r.png" alt="R" width="107" height="103" />ecentemente, me
deparei com uma citação de um desenvolvedor da Mozilla
<a
href="http://lists.w3.org/Archives/Public/public-html/2010Jan/0107.html"
>sobre a tensão que existe ao criar padrões</a
>:
</p>
<blockquote
cite="http://lists.w3.org/Archives/Public/public-html/2010Jan/0107.html"
>
<p>
Implementações e especificações devem dançar delicadamente juntos. Você
não quer que uma implementação ocorra antes que a especificação esteja
completa, pois as pessoas dependem de detalhes da implementação e isso
faz parte da especificação. Entretanto, você também não quer que a
especificação esteja completa antes da implementação e dos testes feitos
pelo autor com esta implementação, pois você precisa de um feedback. É
inevitável que haja uma tensão aqui, mas isso é só uma pequena confusão.
</p>
</blockquote>
<p>
Mantenha esta citação na sua mente, e me deixe explicar como a
<abbr>HTML5<abbr> surgiu. </abbr></abbr>
</p>
<p class="c">
<img
src="i/openclipart.org_johnny_automatic_animals_on_see_saw.png"
width="526"
height="116"
alt="animals on a seesaw"
/>
</p>
<p class="a">❧</p>
<h2 id="mime-types">MIME types</h2>
<p>
Este livro é sobre <abbr>HTML5</abbr>, não é sobre as versões anteriores
da <abbr>HTML</abbr> e não é sobre qualquer versão de <abbr>XHTML</abbr>.
Mas para entender a história da <abbr>HTML5</abbr> e as motivações por
trás dela, você precisa entender primeiro de alguns detalhes técnicos.
Especificamente, <abbr>MIME</abbr> types.
</p>
<p>
Toda vez que o seu navegador chama uma página, o servidor web envia
“cabeçalhos(headers)” antes de enviar a marcação de página em si. Esses
cabeçalhos normalmente são invisíveis, mas existem ferramentas de
desenvolvimento que os tornam visíveis caso necessário. Estes cabeçalhos
são importantes, pois eles informam ao navegador como interpretar a
marcação da página. A parte mais importante do cabeçalho é chamada de
<code>Content-Type</code>, e se parece com isso:
</p>
<blockquote><pre>Content-Type: text/html</pre></blockquote>
<p>
“<code>text/html</code>” é chamado de “content type” (tipo de conteúdo) ou
“<abbr>MIME</abbr> type” da página. Este cabeçalho é a
<strong>única</strong> coisa que determina o que um recurso realmente é, e
portanto como ele deve ser renderizado. Imagens tem seu próprio
<abbr>MIME</abbr> types (<code>image/jpeg</code> para imagens
<abbr>JPEG</abbr>, <code>image/png</code> para imagens <abbr>PNG</abbr>, e
por ai vai). Arquivos JavaScript tem seu próprio <abbr>MIME</abbr> type.
Folhas de estilo <abbr>CSS</abbr> tem seu próprio <abbr>MIME</abbr> type.
Tudo tem seu próprio <abbr>MIME</abbr> type. A web funciona por causa dos
<abbr>MIME</abbr> types.
</p>
<p>
Claro que a realidade é um pouco mais complicada que apenas isso. A
primeira geração de servidores web (e eu estou falando de servidores web
de 1993) não enviavam o cabeçalho <code>Content-Type</code>, pois ele
ainda não existia. (Ele não foi inventado antes de 1994.) Por causa da
compatibilidade até 1993, alguns dos navegadores populares da época
ignoravam o cabeçalho <code>Content-Type</code> em alguns momentos. (Isto
é chamado de “content sniffing.”) Mas como regra geral, tudo que é
procurado na web — páginas <abbr>HTML</abbr>, imagens, scripts, videos,
PDFs, tudo que tem uma <abbr>URL</abbr> — é exibido com seu
<abbr>MIME</abbr> type específico no cabeçalho <code>Content-Type</code>.
</p>
<p>Guarde isto na sua cartola. Nós voltaremos a esse assunto.</p>
<p class="a">❧</p>
<h2 id="history-of-the-img-element">
Uma longa digressão entre os padrões que foram feitos
</h2>
<p class="ss">
<img
src="i/openclipart.org_johnny_automatic_monkey_reading.png"
width="365"
height="396"
alt="monkey reading a book"
/>
</p>
<p>
Porque existe um elemento <code><img></code>? Esta não é uma
pergunta que você vê todo dia. Obviamente <em> alguém</em> criou ela.
Estas coisas não aparecem do nada. Todo elemento, todo atributo, toda
funcionalidade da <abbr>HTML</abbr> que você já usou alguma vez foi criada
por alguém, que decidiu como ela deveria funcionar, e escreveu todo o
código. Estas pessoas não são deuses ou invencíveis. São apenas pessoas.
Pessoas inteligentes, com certeza. Mas apenas pessoas.
</p>
<p>
Uma das grandes coisas sobre padrões "abertos" é que você pode voltar no
tempo e poder responder esse tipo de perguntas. As discussões ocorrem em
listas de emails, que geralmente são arquivadas e podem ser procuradas
depois. Então eu decidi fazer um pouco de "arqueologia de email" para
tentar responder a seguinte pergunta, "Porque nós temos um elemento
<code><img></code>?" E eu tive que voltar para antes que uma
organização chamada World Wide Web Consortium (<abbr>W3C</abbr>)
existisse. Eu voltei aos primeiros dias da web, quando você ainda podia
contar o número de servidores web com as duas mãos e talvez alguns dedos
do pé.
</p>
<p>
<i
>(Tem alguns erros tipográficos nas citações abaixo. Eu decidi deixar
eles intactos para manter a precisão histórica)</i
>
</p>
<p>
Em 25 de Fevereiro de 1993
<a href="http://1997.webhistory.org/www.lists/www-talk.1993q1/0182.html"
><cite>Marc Andreessen</cite> escreveu</a
>:
</p>
<blockquote
cite="http://1997.webhistory.org/www.lists/www-talk.1993q1/0182.html"
>
<p>Eu gostaria de propor uma nova tag HTML:</p>
<p>IMG</p>
<p>O argumento obrigatório é: <code>SRC="url"</code>.</p>
<p>
Ela serve para apontar um arquivo bitmap ou pixmap para o navegador
interpretar como uma imagem no meio do texto no ponto de ocorrência da
tag.
</p>
<p>Como exemplo temos:</p>
<p><code><IMG SRC="file://foobar.com/foo/bar/blargh.xbm"></code></p>
<p>(Não há uma tag de fechamento; é uma tag standalone.)</p>
<p>
Esta tag pode ser usada como link como qualquer outra coisa; quando isto
acontece, ela vira um ícone sensitivo a ativação exatamente como um
texto de âncora comum.
</p>
<p>
Navegadores devem ter flexibilidade para os formatos de imagem que irão
suportar. Xbm e Xpm são bons para suportar, por exemplo. Se um navegador
não conseguir renderizar o formato dado, ele pode fazer o que quiser (No
X Mosaic irá aparecer um bitmap padrão como substituto da imagem).
</p>
<p>
Isso é uma função necessária no X Mosaic; nós temos isso funcionando, e
nós iremos usar internamente pelo menos. Eu estou bastante aberto a
sugestões de como isso pode ser feito com HTML; se você tem uma ideia
melhor que a minha, por favor me informe. Eu sei que é difícil lidar com
formatos de imagem, mas eu não vejo uma alternativa além da que eu
acabei de falar "deixe o navegador fazer o que ele consegue" e esperar
que a solução perfeita apareça (MIME, um dia, quem sabe)
</p>
</blockquote>
<p>
<a href="http://en.wikipedia.org/wiki/X_BitMap">Xbm</a> e
<a href="http://en.wikipedia.org/wiki/X_PixMap">Xpm</a> eram formatos
gráficos populares no Unix.
</p>
<p>
"Mosaic" foi um dos primeiros navegadores web. ("X Mosaic" era a versão
que rodava no Unix.) Quando ele mandou essa mensagem no início de 1993,
<a href="http://en.wikipedia.org/wiki/Marc_Andreessen">Marc Andreessen</a>
ainda não havia fundado a companhia que fez ele famoso,
<a href="http://en.wikipedia.org/wiki/Mosaic_Communications_Corporation"
>Mosaic Communications Corporation</a
>, nem tinha começado a trabalhar no principal produto da empresa: "Mosaic
Netscape." (Você deve conhecer melhor pelos nomes posteriores, "Netscape
Corporation" e "Netscape Navigator.")
</p>
<p>
“MIME, um dia, quem sabe” é uma referência a
<a href="http://en.wikipedia.org/wiki/Content_negotiation"
>negociação de conteúdo</a
>, que é uma funcionalidade do HTTP onde um cliente (como um navegador
web) diz ao servidor (como um servidor web) qual tipo de recursos ele
suporta (como <code>image/jpeg</code>) para que então o servidor retorne
para o cliente no seu formato preferido
<a href="http://www.w3.org/Protocols/HTTP/AsImplemented.html"
>O protocolo HTTP original foi definido em 1991</a
>
(a única versão que havia implementada em Fevereiro de 1993) não possuía
nenhuma maneira dos clientes dizerem aos servidores que tipo de imagens
eram suportadas, o que levou ao dilema de design que Marc encontrou.
</p>
<p>
Algumas horas depois,
<a href="http://1997.webhistory.org/www.lists/www-talk.1993q1/0183.html"
><cite>Tony Johnson</cite> respondeu</a
>:
</p>
<blockquote
cite="http://1997.webhistory.org/www.lists/www-talk.1993q1/0183.html"
>
<p>
Eu tenho algo bastante similar no Midas 2.0 (em uso aqui no SLAC, e
haverá um release público a qualquer semana), exceto que todos os nomes
são diferentes, e tem um argumento extra <code>NAME="name"</code>. Tem
quase exatamente a mesma funcionalidade que você propôs na tag
<code>IMG</code>, como por exemplo:
</p>
<p>
<code
><ICON name="NoEntry"
href="http://note/foo/bar/NoEntry.xbm"></code
>
</p>
<p>
A ideia do parâmetro name é de permitir ao navegador o uso de imagens
internas. Se o nome for o mesmo que uma imagem interna, ele usará ela ao
invés de buscar a imagem. O nome pode atuar também como uma dica para
quando o navegador rodar no terminal como um tipo de símbolo para
substituir a imagem.
</p>
<p>
Eu não ligo muito sobre os nomes dos parâmetros ou das tags, mas eles
devem ser sensíveis se forem utilizados para mais de uma coisa. Eu não
ligo muito para abreviações, ou seja porque não <code>IMAGE=</code> e
<code>SOURCE=</code>. Eu prefiro <code>ICON</code> uma vez que é menos
que <code>IMAGE</code>, mas talvez <code>ICON</code> seja uma palavra
sobrecarregada, não?
</p>
</blockquote>
<p>
<a href="http://en.wikipedia.org/wiki/MidasWWW">Midas</a> foi um outro dos
primeiros navegadores, contemporâneo ao X Moisac. Ele era multiplataforma;
funcionava tanto no Unix quando no VMS. "SLAC" refere-se ao
<a href="http://en.wikipedia.org/wiki/Stanford_Linear_Accelerator"
>Stanford Linear Accelerator Center</a
>, agora SLAC National Accelerator Laboratory, foi o lugar que hospedou o
primeiro servidor web dos Estados Unidos (na verdade
<a href="http://www.slac.stanford.edu/history/earlyweb/history.shtml">
o primeiro servidor web fora da Europa</a
>). Quando
<a
href="http://www.slac.stanford.edu/history/earlyweb/wizards.shtml#Tony%20Johnson"
>Tony</a
>
escreveu essa mensagem, SLAC era um ancestral da WWW, e hospedava
<a href="http://www.slac.stanford.edu/history/earlyweb/firstpages.shtml">
cinco páginas</a
>
por gritantes 441 dias.
</p>
<p>Tony continuou:</p>
<blockquote>
<p>
Enquanto ainda estamos no assunto de novas tags, eu tenho outra, de
algum modo parecida, tag que eu gostaria de suportar no Midas 2.0. A
princípio ela é:
</p>
<p><code><INCLUDE HREF="..."></code></p>
<p>
A intenção aqui é de poder colocar um segundo documento dentro do
primeiro documento no ponto que a tag aparece. A princípio o documento
referenciado pode ser qualquer coisa, mas o objetivo principal é de
permitir imagens (nesse caso de tamanho arbitrário) para ser incluída
dentro de documentos. Novamente a intenção é de que quando o HTTP2
surgir, o formato do documento incluído possa ser negociado
separadamente.
</p>
</blockquote>
<p>
“HTTP2” é uma referência ao
<a href="http://www.w3.org/Protocols/HTTP/HTTP2.html"
>HTTP básico definido em 1992</a
>. Neste ponto, no início de 1993, ele ainda não estava largamente
implementado. O rascunho conhecido HTTP2 foi eventualmente padronizado e
implementado como "HTTP 1.0" (
<a href="http://www.w3.org/Protocols/HTTP/1.0/spec.html">
embora não por mais três anos </a
>). HTTP 1.0 não incluía a
<a href="http://www.w3.org/Protocols/HTTP/HTRQ_Headers.html#z3">
requisição de cabeçalhos para negociação de conteúdo</a
>, a.k.a. “MIME, um dia, quem sabe.”
</p>
<p>Tony continuou:</p>
<blockquote>
<p>Uma alternativa que considerei foi:</p>
<p><code><A HREF="..." INCLUDE>See photo</A></code></p>
<p>
Eu não gosto muito de colocar mais funcionalidade na tag
<code><A></code>, mas a idéia aqui é de manter a compatibilidade
entre os navegadores que não podem honrar com o parâmetro
<code>INCLUDE</code>. A intenção é que os navegadores que entendam
<code>INCLUDE</code>, alterem o texto do link (nesse caso "See photo")
com o documento incluído (foto), enquanto os navegadores antigos ou
burros ignorem completamente a tag <code>INCLUDE</code>.
</p>
</blockquote>
<p>
Esta proposta nunca foi implementada, no entanto a ideia de colocar um
texto quando a imagem não é encontrada, é uma
<a
href="http://diveintoaccessibility.org/day_23_providing_text_equivalents_for_images.html"
>importante técnica de acessibilidade</a
>
esquecida pela proposta inicial da tag <code><IMG</code> de Marc. Anos
depois esse atributo foi incluído como
<a href="http://www.w3.org/TR/html4/struct/objects.html#h-13.8"
>a tag <code><img alt></code></a
>, que o Netscape mostrava erroneamente
<a href="http://www.cs.tut.fi/~jkorpela/html/alt.html#tooltip">
o nome quando se colocava o mouse em cima da imagem</a
>.
</p>
<p>
Algumas horas depois que Tony enviou aquela mensagem,
<a href="http://1997.webhistory.org/www.lists/www-talk.1993q1/0186.html"
><cite>Tim Berners-Lee</cite> respondeu</a
>:
</p>
<blockquote
cite="http://1997.webhistory.org/www.lists/www-talk.1993q1/0186.html"
>
<p>Eu imaginei que figuras poderiam ser representadas como</p>
<p>
<code
><a name=fig1 href="fghjkdfghj" REL="EMBED, PRESENT">Figure
</a></code
>
</p>
<p>onde a relação entre os valores significaria</p>
<pre>
EMBED Coloque isso quando apresentar
PRESENT Mostre isso sempre que o documento fonte for apresentado</pre
>
<p>
Veja que você pode ter diversas combinações disso, e se um navegador não
suporta nenhuma, ele não quebra
</p>
<p>
[Eu] vejo que usando esse método para ícones selecionáveis significam
links. Hmmm. Mas eu não quero nenhuma tag especial
</p>
</blockquote>
<p>
Esta proposta nunca foi implementada, mas o atributo <code>rel</code>
<a href="https://diveintohtml5.com.br/semantics.html#link">continua por aí</a
>.
</p>
<p>
<a href="http://1997.webhistory.org/www.lists/www-talk.1993q1/0188.html"
><cite>Jim Davis</cite> adicionou</a
>:
</p>
<blockquote
cite="http://1997.webhistory.org/www.lists/www-talk.1993q1/0188.html"
>
<p>Seria legal se houvesse um content type específico, por exemplo:</p>
<p>
<code
><IMG HREF="http://nsa.gov/pub/sounds/gorby.au"
CONTENT-TYPE=audio/basic></code
>
</p>
<p>
Mas eu estou completamente disposto a viver com a necessidade de
especificar o content type pela extensão do arquivo.
</p>
</blockquote>
<p>
Esta proposta nunca foi implementada, mas o Netscape posteriormente
incluiu o suporte de inserir áudio e vídeo com o elemento
<code><embed></code>.
</p>
<p>
<a href="http://1997.webhistory.org/www.lists/www-talk.1993q1/0192.html"
><cite>Jay C. Weber</cite> perguntou</a
>:
</p>
<blockquote
cite="http://1997.webhistory.org/www.lists/www-talk.1993q1/0192.html"
>
<p>
Enquanto imagens estão no topo da minha lista de tipos de mídias num
navegador WWW, eu não acho que nós devemos incluir especificações
idiossincráticas para cada tipo de mídia. O que aconteceu com o
entusiasmo de usar um mecanismo de MIME type?
</p>
</blockquote>
<p>
<a href="http://1997.webhistory.org/www.lists/www-talk.1993q1/0194.html"
><cite>Marc Andreessen</cite> respondeu</a
>:
</p>
<blockquote
cite="http://1997.webhistory.org/www.lists/www-talk.1993q1/0194.html"
>
<p>
Isto não é um substituto para o futuro uso do MIME como um padrão do
mecanismo; Isso apenas dá a implementação necessária e simples da
funcionalidade independente do MIME.
</p>
</blockquote>
<p>
<a href="http://1997.webhistory.org/www.lists/www-talk.1993q1/0198.html"
><cite>Jay C. Weber</cite> respondeu</a
>:
</p>
<blockquote
cite="http://1997.webhistory.org/www.lists/www-talk.1993q1/0198.html"
>
<p>
Vamos temporariamente esquecer do MIME, se é o que está atrapalhando.
Minha objeção é a discussão sobre "como nós iremos incluir o suporte a
imagens" e não sobre "como nós vamos suportar os diversos problemas nas
diversas mídias"
</p>
<p>
De outra maneira, semana que vem alguém vai sugerir ‘vamos colocar uma
nova tag
<code><AUD SRC="file://foobar.com/foo/bar/blargh.snd"></code>‘
para áudio.
</p>
<p>Isto é muito custo no lugar de usar algo que generalize.</p>
</blockquote>
<p>
Com o benefício de termos uma retrospectiva, parece que as preocupações de
Jay estavam bem fundamentadas. Levou mais de uma semana, mas o HTML5
finalmente inclui os novos elementos
<a
href="http://www.whatwg.org/specs/web-apps/current-work/multipage/video.html#video"
><code><video></code></a
>
e
<a
href="http://www.whatwg.org/specs/web-apps/current-work/multipage/video.html#audio"
><code><audio></code></a
>.
</p>
<p>
Respondendo a mensagem original de Jay,
<a href="http://1997.webhistory.org/www.lists/www-talk.1993q1/0204.html"
><cite>Dave Raggett</cite> disse</a
>:
</p>
<blockquote
cite="http://1997.webhistory.org/www.lists/www-talk.1993q1/0204.html"
>
<p>
Verdade! Eu gostaria de considerar toda a gama de possibilidade de tipo
de arte em imagens, além da possibilidade de negociação do formato. A
mensagem de Tim sobre áreas clicáveis nas imagens também são
importantes.
</p>
</blockquote>
<p>
Mais tarde em 1993,
<a href="http://www.w3.org/People/Raggett/">Dave Raggett</a> propôs
<a href="http://www.w3.org/MarkUp/HTMLPlus/htmlplus_1.html">HTML+</a> como
uma evolução do padrão HTML. Esta proposta nunca foi implementada, e foi
substituída pela
<a href="http://www.w3.org/MarkUp/html-spec/html-spec_toc.html"
>HTML 2.0</a
>. HTML 2.0 foi uma "retrospectiva", o que significa que formalizou as
funcionalidades já em uso “<a
href="http://www.w3.org/MarkUp/html-spec/html-spec_1.html#SEC1.1"
>Essa especificação reúne, esclarece e formaliza o conjunto de
funcionalidades</a
>
que grosseiramente corresponde as capacidades do HTML que estavam em uso
em Junho de 1994.”
</p>
<p>
Dave mais tarde escreveu a
<a href="http://www.w3.org/MarkUp/html3/CoverPage.html">HTML 3.0</a>,
baseado no rascunho feito por eles do HTML+. Fora isso existia a
referência da W3C do <a href="http://www.w3.org/Arena/">Arena</a>, HTML
3.0 nunca foi implementado, e foi substituído pelo
<a href="http://www.w3.org/MarkUp/Wilbur/">HTML 3.2</a>, outra
"retrospectiva":“<a href="http://www.w3.org/TR/REC-html32.html#intro"
>HTML 3.2 incluiu largamente outras funcionalidades</a
>
como tabelas, applets e textos ao redor de imagens, enquanto mantinha a
retro-compatibilidade com o padrão existente: HTML 2.0.”
</p>
<p>
Dave mais tarde foi co-autor do desenvolvimento da
<a href="http://www.w3.org/TR/html4">HTML 4.0</a>, desenvolveu a
<a href="http://tidy.sourceforge.net/">HTML Tidy</a>, e ajudou com as
especificações do XHTML, XForms, MathML, e outras especificações modernas
da W3C.
</p>
<p>
Voltando para 1993,
<a href="http://1997.webhistory.org/www.lists/www-talk.1993q1/0209.html"
>Marc respondeu a Dave</a
>:
</p>
<blockquote
cite="http://1997.webhistory.org/www.lists/www-talk.1993q1/0209.html"
>
<p>
Na verdade, talvez nós devêssemos pensar numa linguagem procedural
genérica para gráficos que com ela nós possamos incluir hyperlinks
aleatórios anexados a ícones, imagens, ou texto, ou qualquer coisa.
Alguém vê as capacidades Intermedia disso?
</p>
</blockquote>
<p>
<a href="http://en.wikipedia.org/wiki/Intermedia_(hypertext)"
>Intermedia</a
>
foi um projeto de uso de hipertexto da Brown University. Ela foi
desenvolvida de 1985 até 1991 e rodava no
<a href="http://en.wikipedia.org/wiki/A/UX">A/UX</a>, um sistema
operacional Unix-like utilizado nos primeiros computadores Macintosh.
</p>
<p>
A ideia de "uma linguagem procedural genérica para gráficos" foi
eventualmente implementada. Navegadores modernos suportam tanto
<a href="http://www.w3.org/Graphics/SVG/">SVG</a> (marcação declarativa
com scripts embutidos) e
<a
href="http://www.whatwg.org/specs/web-apps/current-work/multipage/the-canvas-element.html#the-canvas-element"
><code><canvas></code></a
>
(uma API procedural e direta para gráficos), mesmo que
<a href="http://ln.hixie.ch/?start=1089635050&count=1"
>começasse como uma extensão proprietária</a
>
antes de começar a ser "revista" pela
<a href="http://www.whatwg.org/">WHATWG</a>.
</p>
<p>
<a href="http://1997.webhistory.org/www.lists/www-talk.1993q1/0217.html"
><cite>Bill Janssen</cite> respondeu</a
>:
</p>
<blockquote
cite="http://1997.webhistory.org/www.lists/www-talk.1993q1/0217.html"
>
<p>
Outros sistemas para olharmos que tem alguma noção disso (bastante
válida) são Andrew e Slate. Andrew foi feito com _insets_, e cada um
deles tem um tipo interessante, como texto, bitmap, desenhos, animações,
mensagens, planilhas, etc. A noção de inclusão arbitrária e recursiva
está presente, então um inset de qualquer tipo pode ser incluído em
qualquer lugar que suporte incorporação. Por exemplo, um inset pode ser
incluído em qualquer ponto do texto de um widget de texto, ou em
qualquer área retangular de um widget de desenho ou em qualquer célula
de uma planilha.
</p>
</blockquote>
<p>
“Andrew” é uma referência a
<a href="http://www-2.cs.cmu.edu/~AUIS/">Andrew User Interface System</a>
(nessa época era conhecida apenas como
<a href="http://en.wikipedia.org/wiki/Andrew_Project">Andrew Project</a>).
</p>
<p>
Ao mesmo tempo,
<a href="http://1997.webhistory.org/www.lists/www-talk.1993q1/0215.html"
><cite>Thomas Fine</cite> teve uma ideia diferente</a
>:
</p>
<blockquote
cite="http://1997.webhistory.org/www.lists/www-talk.1993q1/0215.html"
>
<p>
Esta é a minha opinião. A melhor maneira de usar imagens na WWW é
utilizando MIME. Eu tenho certeza que postscript é um tipo suportado no
MIME, e que lida tranquilamente com a mistura de texto e imagens.
</p>
<p>
Mas isto ainda não é clicável, você diz? Sim você está certo. Eu
suspeito que já tenha uma resposta para isso ser exibido utilizando
display postscript. Mesmo que incluir isto ao padrão postscript seja
trivial. Definir um comando de âncora que especifica a URL e o uso do
caminho atual como uma região próxima ao botão. Desde que o postscript
lide bem com os caminhos, isto faz com que formatos de botões aleatórios
sejam triviais.
</p>
</blockquote>
<p>
<a href="http://en.wikipedia.org/wiki/Display_PostScript"
>Display Postscript</a
>
era uma tecnologia de renderização na tela co-desenvolvida pela Adobe e
NeXT.
</p>
<p>
Esta proposta nunca foi implementada, mas a idéia de um jeito melhor de
consertar HTML e substituí-lo por algo completamente diferente
<a href="http://dbaron.org/log/20090707-ex-html"
>aparece de tempos em tempos</a
>.
</p>
<p>
<a href="http://1997.webhistory.org/www.lists/www-talk.1993q1/0221.html"
><cite>Tim Berners-Lee</cite>, 2 de Março de 1993</a
>:
</p>
<blockquote
cite="http://1997.webhistory.org/www.lists/www-talk.1993q1/0221.html"
>
<p>
HTTP2 permite que um documento contenha qualquer tipo que o usuário diga
que pode lidar, não apenas os MIME types registrados. Então pode ser
feito um experimento. Sim eu acho que tem algum caso que funciona
postscript com hipertexto, eu não entendo de display postscript o
suficiente. Eu sei que a Adobe está tentando estabelecer seu próprio
tipo de postscript "PDF" que terá links e poderá ser lido pelos leitores
proprietários deles.
</p>
<p>
Eu penso que uma linguagem genérica para links entre camadas (baseados
em Hytime?) pode permitir padrões hipertexto e imagens/video que
envolva-os separadamente, que pode ajudar ambos.
</p>
<p>
Deixem que a tag <code>IMG</code> possa ser
<code>INCLUDE</code> (incluída) e deixe ela se referir a um tipo
arbitrário de documento. Ou <code>EMBED</code> se
<code>INCLUDE</code> parece com um include do cpp e que as pessoas
possam esperar por um código fonte SGML para ser interpretado — o que
não é a intenção.
</p>
</blockquote>
<p>
<a href="http://www.hytime.org/">HyTime</a> foi um dos primeiros sistemas
de documentos hipertexto baseado em SGML. Ele teve uma grande importância
nas primeiras discussões sobre HTML e posteriormente sobre XML.
</p>
<p>
A proposta de Tim para uma tag <code><INCLUDE</code> nunca foi
implementada, no entanto pode-se ver ecos dela nos elementos
<code><object></code>, <code><embed></code>, e
<code><iframe></code>.
</p>
<p>
Finalmente em 12 de Março de 1993,
<a href="http://1997.webhistory.org/www.lists/www-talk.1993q1/0257.html"
>Marc Andreessen revisitou a thread</a
>:
</p>
<blockquote
cite="http://1997.webhistory.org/www.lists/www-talk.1993q1/0257.html"
>
<p>
Voltando a thread sobre inclusão de imagens — eu estou chegando perto de
lançar o Mosaic v0.10, que irá suportar a inclusão de GIF e
imagens/bitmaps XBM, como eu disse anteriormente. ...
</p>
<p>
Nós não estamos preparados para suportar as tags
<code>INCLUDE</code>/<code>EMBED</code> nesse momento. ... Então nós
provavelmente iremos usar as tags
<code><IMG SRC="url"></code> (não a tag <code>ICON</code>, dado
que nem todas as imagens podem ser propriamente chamadas de ícones). Por
enquanto as imagens incluídas não deverão possuir um content-type
específico; futuramente, nós planejamos dar suporte a isto (junto com a
adaptação do MIME). Na verdade, a rotina de leitura de imagens que nós
estamos utilizando lida com o formato da imagem no momento de
renderizar, então a extensão do arquivo não é tão relevante.
</p>
</blockquote>
<p class="a">❧</p>
<h2 id="an-unbroken-line">Uma linha contínua</h2>
<p>
Eu tenho um fascínio incrível por todos os detalhes dessa conversa de
quase 17 anos de idade que levou a criação de um elemento
<abbr>HTML</abbr> que é utilizado em praticamente todas as páginas da
internet. Considere que:
</p>
<p class="ss">
<img
src="i/openclipart.org_johnny_automatic_Corsican_Pine.png"
width="216"
height="405"
alt="árvore do tipo pinheiro"
/>
</p>
<ul>
<li>
HTTP continua existindo. HTTP evolui com sucesso de 0.9 para 1.0 e
posteriormente para 1.1.
<a href="http://www.ietf.org/dyn/wg/charter/httpbis-charter.html"
>E continua evoluindo</a
>.
</li>
<li>
HTML continua existindo. O formato de dados rudimentar — ele sequer
suportava imagens em linha! — evoluiu com sucesso para 2.0, 3.2, 4.0.
HTML é uma linha contínua. Uma linha torcida, cheia de nós, embolada,
com certeza. Existem diversos "branches mortos" na árvore evolutiva,
lugares onde pensamentos estavam a frente das próprias pessoas (e na
frente dos autores e desenvolvedores). Mas continua. Aqui estamos, em
2010, e as
<a href="http://www.w3.org/People/Berners-Lee/FAQ.html#Examples"
>páginas da web de 1990</a
>
continuam sendo exibidas corretamente nos navegadores modernos. Eu
acabei de carregar uma no navegador em estado-da-arte do meu celular
Android e eu nem recebi uma mensagem dizendo “por favor aguarde enquanto
estamos importando formatos legados…”
</li>
<li>
HTML sempre será uma conversa entre marcações de navegadores, autores,
padrões, e outras pessoas que simplesmente apareceram e gostaram de
conversar sobre símbolos de maior e menor. A maioria das versões bem
sucedidas da HTML foram “retrospectivas,” pegando tudo que existia e
tentando empurrar isso para direção certa. Qualquer um que diga a você
que a HTML deveria continuar “pura” (presumivelmente ignorando os
marcadores dos navegadores, ou ignorando os autores ou ambos) está
simplesmente mal informado. A HTML nunca foi pura, e todas as tentativas
de purificá-lo foram falhas incríveis, vistas apenas pelas tentativas de
substituí-lo.
</li>
<li>
Nenhum dos navegadores de 1993 continua existindo de uma forma
reconhecível. O Netscape Navigator foi
<a
href="http://en.wikipedia.org/wiki/History_of_Mozilla_Application_Suite#Open_sourcing_of_Communicator"
>abandonado em 1998</a
>
e
<a
href="http://en.wikipedia.org/wiki/History_of_Mozilla_Application_Suite#Rewriting_from_scratch"
>re-escrito a partir do rascunho</a
>
para criar a Suite Mozilla, que foi
<a href="http://en.wikipedia.org/wiki/History_of_Mozilla_Firefox">
subdivida para criar o Firefox</a
>. O Internet Explorer teve diversos “começos” no “Microsoft Plus! for
Windows 95,” que foi empacotado junto com alguns temas para área de
trabalho e um jogo de pinball. (Mas é claro que também podem ser
encontradas
<a href="http://en.wikipedia.org/wiki/Spyglass_Mosaic"
>referências anteriores</a
>
a este navegador).
</li>
<li>
Alguns dos sistemas operacionais de 1993 continuam existindo, mas nenhum
deles é relevante para internet moderna. A maioria das pessoas que “usa”
a internet faz em um PC rodando Windows 2000 ou superior, um Mac rodando
Mac OS X, um PC rodando algum sabor de Linux, ou um smartphone como um
iPhone. Em 1993, o Windows estava na versão 3.1 (e competindo com OS/2),
Macs rodavam System 7 e o Linux era distribuído pela Usenet. (Quer se
divertir um pouco? Encontre um dinossauro da internet e sussurre
“Trumpet Winsock” ou “MacPPP.”)
</li>
<li>
Algumas das mesmas <em>pessoas</em> continuam por ai e continuam
envolvidas no que nós simplesmente chamamos de “web standards (padrões
da internet).” Isso após quase 20 anos. Alguns destes estavam envolvidos
com os predecessores da HTML, na década de 80 e anteriores.
</li>
<li>
Falando dos antecessores… Com a popularidade adquirida da HTML e da
internet, é fácil esquecer os formatos e sistemas modernos envolvidos na
criação deles. Andrew? Intermedia? HyTime? E o HyTime não foi somente um
projeto de pesquisa acadêmico;
<a href="http://xml.coverpages.org/hytime.html">ele foi um padrão ISO</a
>. Ele foi aprovado para uso militar. Ele era um Grande Negócio. E você
pode ler sobre ele por você mesmo…
<a href="http://www.sgmlsource.com/history/hthist.htm"
>na página HTML dele, no seu navegador</a
>.
</li>
</ul>
<p>
Mas nenhuma dessas coisas responde a pergunta original: por que temos um
elemento <code><img></code>? Por que não um elemento
<code><icon></code>? Ou ainda um elemento
<code><include></code>? Por que não temos um link com um atributo
<code>include</code>, ou alguma combinação de valores em <code>rel</code>?
Por que um elemento <code><img></code>? Simples, porque Marc
Andreessen enviou um código com ele e código enviado ganha.
</p>
<p>
Isso não quer dizer que <em>todos</em> códigos enviados ganham; afinal,
Andrew e Intermedia e HyTime enviaram seus códigos também. Código é
necessário, mas não o suficiente para o sucesso. E eu
<em>com certeza</em> não quis dizer que enviar código antes de um padrão
irá produzir a melhor solução. O elemento <code><img></code> de Marc
não funcionava com diversos formatos comuns de figuras; ele não definia
como o texto ficaria ao redor da imagem; ele não suportava alternativas de
texto ou de substituição de conteúdo em caso de falhas em navegadores
antigos. E 17 anos depois,
<a href="http://tools.ietf.org/html/draft-abarth-mime-sniff"
>continuamos lidando com o sniffing de conteúdo</a
>, e
<a href="http://www.securityfocus.com/archive/1/503867">
continuam existindo diversas vulnerabilidades loucas</a
>. E você tem como voltar atrás 17 anos e ver a
<a href="http://en.wikipedia.org/wiki/Browser_wars"
>Grande Guerra dos navegadores</a
>
e voltar para 25 de Fevereiro de 1993 quando Marc Andreenssen simplesmente
comentou, “MIME, um dia, quem sabe,” e enviou seu código de todo modo.
</p>
<p>Ganha aquele que é enviado.</p>
<p class="a">❧</p>
<h2 id="timeline">
Uma linha do tempo do desenvolvimento da HTML de 1997 à 2004
</h2>
<p>
Em Dezembro de 1997, a World Wide Web Consortium (W3C) publicou a
<a href="http://www.w3.org/TR/REC-html40-971218/"
><abbr>HTML</abbr> 4.0</a
>
e provavelmente fechou o grupo de trabalho da <abbr>HTML</abbr>. Menos de
dois meses depois, um grupo de trabalho separado da
<abbr>W3C</abbr> publicou o
<a href="http://www.w3.org/TR/1998/REC-xml-19980210"
><abbr>XML</abbr> 1.0</a
>. Três meses depois apenas, as pessoas que faziam parte da W3C deram um
workshop chamado: “<a href="http://www.w3.org/MarkUp/future/"
>Moldando o futuro da <abbr>HTML</abbr></a
>” para responder a questão: “A W3C desistiu da HTML?” Esta foi a
resposta:
</p>
<blockquote cite="http://esw.w3.org/topic/HTML/history">
<p>
Nas conversas foi concordado que seria difícil ocorrer uma futura
extensão da <abbr>HTML</abbr>, como a conversão da 4.0 para uma
aplicação <abbr>XML</abbr>. Foi proposto quebrar com estas restrições e
fazer um novo começo para a nova geração da HTML baseada em um conjuto
de tags <abbr>XML</abbr>.
</p>
</blockquote>
<p>
A <abbr>W3C</abbr> recriou o grupo de trabalho da
<abrr
>HTML para criação do seu “conjunto de tags <abbr>XML</abbr>.” O
primeiro passo deles, em dezembro de 1998, foi um rascunho de uma
especificação interna que simplesmente
<a href="http://www.w3.org/TR/1998/WD-html-in-xml-19981205/">
reformulou a <abbr>HTML</abbr> no <abbr>XML</abbr></a
>
sem adicionar nenhum novo elemento ou atributo. Esta especificação
posteriormente ficou conhecida como “<a
href="http://www.w3.org/TR/xhtml1/"
><abbr>XHTML</abbr> 1.0</a
>.” Ela definiu um novo <abbr>MIME</abbr> type para documentos
<abbr>XHTML</abbr>: <code>application/html+xml</code>. Entretando, para
realizar a migração das atuais 4 páginas da
<abbr>HTML</abbr> existentes, segundo o
<a href="http://www.w3.org/TR/xhtml1/#guidelines">Apêndice C</a>, resume
nas “principais guias de design para os autores que desejam processar
documentos <abbr>XHTML</abbr> nos agentes HTML existentes.” O apêndice C
diz também que é permitido ao autor chamar documentos
“<abbr>XHTML</abbr>”, mas utilizar ainda o <abbr>MIME</abbr> type
<code>text/html</code>.
</abrr>
</p>
<p>
O próximo objetivo deles foram os formulários web. Em agosto de 1999, o
mesmo grupo de trabalho da <abbr>HTML</abbr> publicou o primeiro rascunho
da
<a href="http://www.w3.org/TR/1999/WD-xhtml-forms-req-19990830"
><abbr>XHTML</abbr> Extended Forms</a
>. Eles colocaram as expectativas
<a href="http://www.w3.org/TR/1999/WD-xhtml-forms-req-19990830#intro"
>no primeiro parágrafo</a
>:
</p>
<blockquote
cite="http://www.w3.org/TR/1999/WD-xhtml-forms-req-19990830#intro"
>
<p>
Depois de uma cuidadosa consideração, o grupo de trabalho da
<abbr>HTML</abbr> decidiu que as metas para a nova geração dos
formulários são incompatíveis com a retro-compatibilidade com os
navegadores desenvolvidos para suportar as versões antigas da
<abbr>HTML</abbr>. É nosso objetivo criar um novo modelo de formulários
do zero (“<abbr>XHTML</abbr> Extended Forms”) baseado em um conjunto bem
definido de requisitos. Os requisitos descritos nesse documento são
baseados na experiência adquirida com um grande expectro de aplicações
com formulários.
</p>
</blockquote>
<p>
Alguns meses depois, “<abbr>XHTML</abbr> Extended Forms” foi renomeado
para “XForms” e movida para seu próprio
<a href="http://www.w3.org/MarkUp/Forms/2000/Charter.html"
>grupo de trabalho</a
>. Este grupo trabalhou paralelamente com o grupo de trabalho da
<abbr>HTML</abbr> e finalmente publicou em outubro de 2003
<a href="http://www.w3.org/TR/2003/REC-xforms-20031014/"
>a primeira edição do XForms 1.0</a
>.
</p>
<p>
Enquanto isso com a transição para o <abbr>XML</abbr> completa, o grupo de
trabalho da <abbr>HTML</abbr> colocaram seus esforços na “nova geração da
<abbr>HTML</abbr>.” Em maio de 2001 eles publicaram
<a href="http://www.w3.org/TR/2001/REC-xhtml11-20010531/"
>a primeira edição da <abbr>XHTML</abbr> 1.1</a
>, que adicionou
<a
href="http://www.w3.org/TR/2001/REC-xhtml11-20010531/changes.html#a_changes"
>
apenas poucos recursos</a
>
além dos que haviam na <abbr>XHTML</abbr> 1.0, mas também eliminou a
brecha existente no “Apêndice C.” A partir da versão 1.1, todos os
documentos
<abbr
>XHTML passam a funcionar a com o <abbr>MIME</abbr> type
<code>application/html+xml</code>.
</abbr>
</p>
<p class="a">❧</p>
<h2 id="xhtml">Tudo que você sabe sobre XHTML está errado</h2>
<p>
Por que os <abbr>MIME</abbr> types são importantes? Por que eu fico
voltando a eles? Três palavras:
<a href="http://esw.w3.org/topic/HTML/DraconianErrorHandling"
>draconian error handling</a
>
(tratamento de erros draconianos). Navegadores sempre foram “tolerantes”
com a <abbr>HTML</abbr>. Se você criar uma página <abbr>HTML</abbr> mas
esquecer a tag <code></head></code>, os navegadores irão mostrar a
página de todo modo. (Algumas tags implicitamente realizam o fechamando da
tag <code></head></code> e o inicio da tag
<code><body></code>.) Você supostamente aninha as tags de maneira
hierárquica — fechando elas da última para primeira — mas, se você criar
uma marcação como <code><b><i></b></i></code>, os
navegadores simplesmente vão lidar com isso (de algum jeito) sem mostrar
nenhuma mensagem de erro.
</p>
<p style="float:left;margin-right:1.75em">