Wiem, że document.write
jest uważane za złą praktykę; i mam nadzieję, że opracuję listę powodów, aby przesłać do zewnętrznego dostawcy, dlaczego nie powinni używać document.write
w implementacjach swojego kodu analitycznego.
Podaj document.write
poniżej powód zgłoszenia złej praktyki.
źródło
document.write
wywoływane jest po zakończeniu ładowania dokumentuWłaściwie nie ma w tym nic złego
document.write
. Problem polega na tym, że naprawdę łatwo go niewłaściwie użyć. Nawet rażąco.Jeśli chodzi o dostawców dostarczających kod analityczny (np. Google Analytics), jest to w rzeczywistości najłatwiejszy sposób na rozpowszechnianie takich fragmentów
Tak długo, jak długo nie próbujesz go używać po załadowaniu dokumentu ,
document.write
nie jest on z natury zły, moim skromnym zdaniem.źródło
addEventListener
?document.write
wywołań, które wstawią skrypt, jeśli zostaną spełnione określone warunki.Kolejne uzasadnione użycie
document.write
pochodzi z przykładu HTML5 Boilerplate index.html .Widziałem również tę samą technikę korzystania z wypełniania JSON json2.js funkcji parsowania / łączenia w polifill ( potrzebne dla IE7 i niższych ).
źródło
script
element za pomocą manipulacji DOM, czy jest on ładowany synchronicznie? O ile nie jest, nie jest to zamiennik.onload
zdarzenia DOM można określić, kiedy asynchronicznie załadowany skrypt jest dostępny do użycia.src
) . W przeciwnym razie zostanie on wykonany asynchronicznie „jak najszybciej”.document.write
połączeń, które wstawiają<script>
tagi, jeśli użytkownik ma połączenie 2G. Zobacz developers.google.com/web/updates/2016/08/…Może zablokować twoją stronę
document.write
działa tylko podczas ładowania strony; Jeśli zadzwonisz po załadowaniu strony, zastąpi ona całą stronę.Oznacza to, że musisz wywołać go z wbudowanego bloku skryptu - a to uniemożliwi przeglądarce przetwarzanie części następnej strony. Skrypty i obrazy nie zostaną pobrane, dopóki blok zapisu nie zostanie ukończony.
źródło
Zawodowiec:
Kon:
źródło
document.write
który tworzy<script>
tag. developers.google.com/web/updates/2016/08/…Oto moja wartość podwójna, na ogół nie powinieneś używać
document.write
do podnoszenia ciężkich przedmiotów, ale jest jeden przypadek, w którym jest to zdecydowanie przydatne:http://www.quirksmode.org/blog/archives/2005/06/three_javascrip_1.html
Odkryłem to niedawno próbując stworzyć galerię suwaków AJAX. Stworzyłem dwa zagnieżdżone div i zastosowałem
width
/height
ioverflow: hidden
na zewnętrz<div>
pomocą JS. Było tak, że w przypadku, gdy przeglądarka wyłączyła JS, div będzie unosić się, aby pomieścić obrazy w galerii - trochę miłej wdzięcznej degradacji.Chodzi o to, jak w powyższym artykule, to przejęcie CSS przez JS nie rozpoczęło się, dopóki strona się nie załadowała, powodując chwilowe flashowanie podczas ładowania div. Musiałem więc napisać regułę CSS lub dołączyć arkusz podczas ładowania strony.
Oczywiście nie będzie to działać w XHTML, ale ponieważ XHTML wydaje się być czymś w rodzaju martwej kaczki (i renderuje się jako zupa tag w IE), warto ponownie rozważyć wybór DOCTYPE ...
źródło
Zastępuje treść na stronie, co jest najbardziej oczywistym powodem, ale nie nazwałbym tego „złym”.
Po prostu nie ma większego zastosowania, chyba że tworzysz cały dokument za pomocą JavaScript, w takim przypadku możesz zacząć od document.write.
Mimo to, tak naprawdę nie używasz DOM, gdy używasz document.write - po prostu zrzucasz kroplę tekstu do dokumentu, więc powiedziałbym, że to zła forma.
źródło
div.innerHTML = "<label for='MySelect'>Choose One</label><select id='MySelect'><option value='foo' selected=''>foo</option><option value='bar'>bar</option></select>";
? Wydaje się, że spowodowałoby to powstanie wielu niepotrzebnych i mniej czytelnych kodów. Jest to również dokładne przeciwieństwo podejścia, które popiera John Resig i inni programiści JS.Łamie strony przy użyciu renderowania XML (podobnie jak strony XHTML).
Najlepsze : niektóre przeglądarki przełączają się z powrotem na renderowanie HTML i wszystko działa dobrze.
Prawdopodobne : niektóre przeglądarki wyłączają funkcję document.write () w trybie renderowania XML.
Najgorsze : niektóre przeglądarki wywołują błąd XML przy każdym użyciu funkcji document.write ().
źródło
Z czubka mojej głowy:
document.write
musi być używany do ładowania strony lub treści. Więc jeśli chcesz użyć skryptu w dowolnym momencie, aby zaktualizować zawartość strony document.write jest prawie bezużyteczne.Technicznie
document.write
zaktualizuje tylko strony HTML, a nie XHTML / XML. IE wydaje się dość wybaczać temu faktowi, ale inne przeglądarki tak nie będą.http://www.w3.org/MarkUp/2004/xhtml-faq#docwrite
źródło
document.write
W niektórych przypadkach Chrome może blokować wstawianie skryptu. Gdy tak się stanie, wyświetli to ostrzeżenie w konsoli:Bibliografia:
źródło
Naruszenie przeglądarki
.write
jest uważane za naruszenie przeglądarki, ponieważ powstrzymuje parser przed renderowaniem strony. Analizator składni otrzymuje komunikat, że dokument jest modyfikowany; dlatego zostaje zablokowany, dopóki JS nie zakończy procesu. Tylko w tym momencie parser zostanie wznowiony.Wydajność
Największą konsekwencją zastosowania takiej metody jest obniżona wydajność. Wczytywanie zawartości strony potrwa dłużej. Niekorzystna reakcja na czas ładowania zależy od tego, co jest zapisywane w dokumencie. Nie zobaczysz dużej różnicy, jeśli dodasz
<p>
znacznik do DOM w przeciwieństwie do przekazywania tablicy 50-niektórych odniesień do bibliotek JavaScript (coś, co widziałem w działającym kodzie i spowodowało 11-sekundowe opóźnienie - oczywiście zależy to również od sprzętu).Podsumowując, najlepiej jest unikać tej metody, jeśli możesz jej pomóc.
Aby uzyskać więcej informacji, zobacz interweniowanie przeciwko document.write ()
źródło
Na podstawie analizy przeprowadzonej przez Google-Chrome Dev Tools Audit Lighthouse Audit ,
źródło
document.write
złej praktyki jest to, że nie można wymyślić scenariusza, w którym nie można znaleźć lepszej alternatywy.źródło
document.write
.Można myśleć o document.write () (i .innerHTML) jako o ocenie ciągu kodu źródłowego. Może to być bardzo przydatne w wielu aplikacjach. Na przykład, jeśli otrzymujesz kod HTML jako ciąg znaków z jakiegoś źródła, dobrze jest po prostu go „ocenić”.
W kontekście Lisp manipulowanie DOM byłoby jak manipulowanie strukturą listy, np. Tworzenie listy (pomarańczowy) poprzez:
A document.write () byłoby jak ocena łańcucha, np. Utwórz listę, oceniając łańcuch kodu źródłowego w następujący sposób:
Lisp ma również bardzo przydatną zdolność do tworzenia kodu przy użyciu manipulacji listami (np. Przy użyciu „stylu DOM” do utworzenia drzewa parsowania JS). Oznacza to, że możesz zbudować strukturę listy za pomocą „stylu DOM”, a nie „stylu ciągu”, a następnie uruchomić ten kod, np. W następujący sposób:
Jeśli zaimplementujesz narzędzia do kodowania, takie jak proste edytory na żywo, bardzo przydatna jest możliwość szybkiej oceny ciągu, na przykład za pomocą document.write () lub .innerHTML. Lisp jest w tym sensie idealny, ale możesz robić bardzo fajne rzeczy również w JS, a wiele osób to robi, np. Http://jsbin.com/
źródło
Wady document.write zależą głównie od 3 czynników:
a) Wdrożenie
Document.write () jest najczęściej używany do zapisywania zawartości na ekranie, gdy tylko ta zawartość jest potrzebna. Oznacza to, że dzieje się to w dowolnym miejscu, w pliku JavaScript lub w znaczniku skryptu w pliku HTML. Umieszczenie znacznika skryptu w dowolnym miejscu takiego pliku HTML jest złym pomysłem, aby mieć instrukcje document.write () w blokach skryptu, które są powiązane z HTML wewnątrz strony internetowej.
b) Rendering
Dobrze zaprojektowany kod ogólnie bierze każdą dynamicznie generowaną zawartość, przechowuje ją w pamięci, ciągle manipuluje nią, gdy przechodzi przez kod, zanim w końcu zostanie wyrzucony na ekran. Aby powtórzyć ostatni punkt w poprzedniej sekcji, renderowanie zawartości w miejscu może być renderowane szybciej niż w przypadku innych treści, na których można polegać, ale może nie być dostępne dla innego kodu, który z kolei wymaga renderowania treści do przetworzenia. Aby rozwiązać ten dylemat, musimy pozbyć się document.write () i zaimplementować go we właściwy sposób.
c) Niemożliwa manipulacja
Po napisaniu jest skończone. Nie możemy wrócić, aby nim manipulować bez dotykania DOM.
źródło
Nie sądzę, aby korzystanie z document.write w ogóle było złą praktyką. Krótko mówiąc, jest to wysokie napięcie dla niedoświadczonych ludzi. Jeśli użyjesz go w niewłaściwy sposób, zostaniesz ugotowany. Jest wielu programistów, którzy przynajmniej raz zastosowali tę i inne niebezpieczne metody i nigdy tak naprawdę nie zagłębili się w swoje niepowodzenia. Zamiast tego, gdy coś pójdzie nie tak, po prostu ratują i używają czegoś bezpieczniejszego. To oni wypowiadają się na temat tego, co uważa się za „złą praktykę”.
To jak formatowanie dysku twardego, kiedy trzeba usunąć tylko kilka plików, a następnie powiedzieć „formatowanie dysku to zła praktyka”.
źródło
Myślę, że największym problemem jest to, że wszelkie elementy napisane przez document.write są dodawane na końcu elementów strony. Rzadko jest to pożądany efekt w przypadku nowoczesnych układów stron i AJAX. (należy pamiętać, że elementy w DOM są tymczasowe, a uruchomienie skryptu może wpłynąć na jego zachowanie).
O wiele lepiej jest ustawić element zastępczy na stronie, a następnie manipulować jego innerHTML.
źródło