Dlaczego żaden tag HTML po stronie klienta nie zawiera tagu?

18

Pewnego dnia miałem inne pytanie od innego programisty. Pamiętam (bardzo dawno temu) zastanawianie się nad tym samym. Dlaczego nigdy nie uwzględniono tagu dołączanego po stronie przeglądarki? A może to było?

W szczególności z tagiem, który poinstruował przeglądarkę, aby zawierała dodatkowy kod HTML z innych źródeł. np <include src="http://server/foo/bar.html">. Wielu ludzi będzie wykonywać wywołania javascript i wypełniać je, innerHTMLaby osiągnąć to samo, gdy przeglądarka może to zrobić poza silnikiem javascript.

Zagnieżdżenie <HTML>s <BODY>(tj.) Byłoby bolesne, ale i tak musimy rozważyć ten aspekt gdziekolwiek.

history html Jé Queue
źródło
Czy podmioty zewnętrzne już tego nie dają?
Peter Taylor
Transkluzję uważano za podstawową cechę hipertekstu nawet od jego wynalezienia w latach 60. Więc jestem pewien, że to zostało rozważone ...
Alex Feinman

Odpowiedzi:

12

Czy jestem ostatnią osobą na ziemi, która pamięta (tylko Netscape 4 ) layeri ilayertagi?

Netscape 4 pozwoliło równieżdiv tag mieć srcatrybut, który osiągnąłem samo.

Netscape przesłał je do W3C, który postanowił ich nie uwzględniać - iframezamiast tego użyj .

Dori
źródło
Rzeczywiście pamiętam NS4, ale nie pamiętam tych funkcji. Szkoda, wciąż się cieszę, że zaoszczędziłoby to dużo javascript BS między przeglądarkami.
Jé Queue
Pamiętam, jak nienawidziłem NS4 z taką pasją, że jednym z moich pierwszych adresów e-mail spoza ISP było bezpłatne konto na ihatenetscape.com. Ach, dobre czasy: D
dzikie szczyty
Warstwy notatek nie były całkiem po stronie klienta, ponieważ wciąż miały osobny documentobiekt podlegający Zasadom Same Origin; były efektywnie pozycjonowane iframe.
bobince
14

Dlaczego nigdy nie uwzględniono tagu dołączanego po stronie przeglądarki? A może to było?

Z pewnością poprosił o to każdy początkujący autor stron internetowych, który jeszcze nie opracował dołączeń po stronie serwera, już na początku listy www-html. Ale w tamtych czasach W3 z przyjemnością całkowicie ignorowały presję autora.

Gdyby zezwolono na włączenie do innej witryny, byłaby to katastrofa bezpieczeństwa. Możesz pobrać stronę z banku użytkownika i odczytać z niej treść. (Początkowo skrypty DOM były ograniczone, ale nadal można było z nich czytać document.links, document.imagesfunkcje skryptowe upuszczane przez stronę docelową itp. Od tego czasu możesz robić, co chcesz, z importowanej zawartości).

Gdyby włączenie między witrynami nie było dozwolone ... cóż, ta funkcja nie miałaby żadnej przewagi nad włączeniami na serwerze. Byłoby więcej, wolniej pracować dla klienta, aby serwer mógł sobie poradzić lepiej. W przeciwieństwie <iframe>do tego dołączenie musiałoby blokować ładowanie strony. SSI byłyby pod każdym względem lepsze.

Bobin
źródło
5
W rzeczywistości klient (lub serwer proxy) mógłby buforować bardziej efektywnie, ponieważ szablony (lub nagłówek / stopka) nie zmieniają się ze strony na stronę, co oznacza, że ​​użytkownik może przynajmniej widzieć część strony, podczas gdy niektóre trwa przetwarzanie po stronie serwera.
Alan Pearce,
1
Zrobiłoby to znacznie więcej niż serwer. Nie jestem pewien, dlaczego musiałoby blokować ładowanie strony, mogło pozwolić na pełne ładowanie strony z asynchronicznym wypełnianiem zawartości. Oczywiście przeglądarki mogą ograniczać tylko pobieranie danych z serwerów pochodzących lub domenie DOM.
Jé Queue,
Nie rozumiem, jak to jest katastrofa bezpieczeństwa. Mogę teraz przeczytać stronę banku po stronie serwera i wypluć ją na innej stronie - czy to katastrofa? Może, ale na pewno nie związany z bezpieczeństwem. Awarią bezpieczeństwa byłoby odczytanie plików cookie z innej domeny. Bez tej strony uwzględnienie byłoby dokładnie takie samo jak po stronie serwera. Nie widzę tutaj żadnego problemu.
serg
Możesz spróbować pobrać stronę banku po stronie serwera, ale Twoje żądanie nie zostanie uwierzytelnione, więc nie możesz pobrać żadnych soczystych informacji. Żądanie ze strony klienta zawiera pliki cookie i tokeny uwierzytelniające HTTP; jeśli potrafisz odczytać odpowiedź z takiego żądania, możesz w pełni podszyć się pod użytkownika.
bobince
@ bobince: Czy jest jakiś powód, dla którego żądanie po stronie klienta musiałoby zawierać pliki cookie i tokeny uwierzytelniające HTTP? Podstawowym scenariuszem użytkowania, który widziałbym po stronie klienta, byłoby ulepszenie buforowania statycznej zawartości strony. Jeśli wszystkie szesnaście stron zawiera ten sam nagłówek i stopkę, użycie dołączenia po stronie klienta wydłużyłoby czas wymagany do załadowania pierwszej, ale skróciło czas ładowania pozostałych piętnastu. Przypadki użycia gdzie include byłoby najbardziej przydatne byłoby dokładnie takie, w których dane mają być „włączone” będzie statyczny, a więc nie trzeba ...
SuperCat
10

Oni zrobili. Stało się <frameset>tagiem. Niedługo potem dodali <iframe>tag.

Większość wczesnych serwerów obsługiwanych po stronie serwera zawiera, więc prawdopodobnie uwzględnienie tekstu po stronie klienta było niepotrzebne, biorąc pod uwagę, że ta sama funkcjonalność była dostępna również z ramkami.

greyfade
źródło
4
Naprawdę ramki nie służą zupełnie innemu celowi niż włączenie. Poza tym ograniczenia dotyczące ramek iframe, zwłaszcza w rozmiarze zestawu obiektów, z pewnością nie mogły pomyśleć o jego zastąpieniu.
Jé Queue,
5
Nie zgadzam się - myślę, że to właśnie robią ramki. Do czego jeszcze służą ramki oprócz dołączenia większej ilości HTML?
Jaco Pretorius
5
Ramki zawierają HTML w ramkach, a nie bezpośrednio - to jest różnica.
mbq
4
@Xepoch: ... With an <iframe>. To co to za . To naprawdę niewiele różni się od <div>zoverflow:auto;
greyfade
3
Element <iframe> w zasadzie mówi „załaduj określony dokument HTML i przyklej go tutaj”. Wybrałbyś go zamiast ajax, jeśli chcesz, aby dokument został załadowany natychmiast, a nie w wywołaniu javascript ... Ramki NIE są okienkowym układem HTML. Div, p, br - są to wszystkie elementy użyte do układu. Nie używasz ram do układania (ani nie powinieneś i tak).
Jaco Pretorius
3

Obiekt nadal renderuje się w ramce i nie masz dostępu DOM do „danych”. To, co programiści powinni byli podać lata temu, to sposób na włączenie fragmentów kodu z prostym znacznikiem. Nawet jeśli ten tag ma ograniczenia piaskownicy domen, przydatne byłoby podzielenie funkcji na części, poprawienie konserwacji i wykorzystanie buforowania przeglądarki.

Wiem, że istnieje wiele dobrych wtyczek jquery, które to robią, i wiele skryptów po stronie serwera, ale nie ma dobrego powodu, aby nie obsługiwać takiego tagu. IMO to dobre pytanie „Dlaczego po stronie klienta nie ma tagu?”

Jeśli podoba Ci się jquery, dobra strona zawiera skrypt: inc: Super-mała strona klienta zawiera wtyczkę JavaScript jQuery

Jonas
źródło
Twoja odpowiedź jest jedyną, która zdaje się uderzyć w gwóźdź. Czy myślisz o czymś takim jak #include w C? Jest to dla mnie dokładnie to, co „obejmuje po stronie klienta” - możliwość dołączania dowolnych fragmentów HTML (zamiast całych dokumentów HTML) w dokumencie HTML jako integralnej zawartości dokumentu. Chociaż można go zaprojektować jako integralną funkcję HTML, a nie jako etap wstępnej analizy, sugerowana przez pytającego sugerowana składnia <include src = "..."> pasuje do tego.
Stewart
Problem z dodaniem go teraz polegałby na kompatybilności wstecznej. Oczywiście nie wyjaśnia to, dlaczego nie zostało uwzględnione w oryginalnym projekcie HTML.
Stewart
Alternatywnie można go zaprojektować jako funkcję SGML / XML bardziej ogólnie ...
Stewart
2

Czy próbowałeś

<object  type="text/html" data="page.html" height="500" width="500">
What I see if that didn't work 
</object>

Myślę, że jest to zaimplementowane w większości przeglądarek.

Peter Turner
źródło
Będę musiał spróbować.
Jé Queue
2

Warianty <include>znacznika były rzeczywiście brane pod uwagę we wczesnej historii HTML , ale nigdy nie zaszły zbyt daleko.

Wymuskany
źródło
1
Jednak semantyka tego znacznika <include> była podobna do dzisiejszej ramki / ramki iframe / obiektu - zawierałby on dokument HTML , a nie tylko fragmenty tekstu / kodu lub losowe znaczniki, jak zrobiłby to C #include.
Tomáš Pospíšek