W3Schools.com

Dzisiaj nieco złamię zasadę działania WebKrytyka i napiszę o stronie, która nie jest polska, niemniej jest u nas niezwykle popularna. Mowa oczywiście o W3Schools. Poruszałem już ten temat, ale dzisiaj go nieco rozwinę i przedstawię w mniej emocjonalnej formie.

Artykuł opisuje stan zasobów W3Schools na dzień 29 października 2017 roku. Od tego dnia w zasobach W3Schools mogły zajść zmiany, które można prześledzić przy pomocy Internet Archive Wayback Machine.

Aktualizacja 2022-10-30: uaktualniłem linki do standardu HTML. Gdy w artykule jest wspominany HTML5, chodzi o specyfikację od WHATWG.

Uwagi wstępne

• Zacznijmy od jednego z najczęściej powtarzanych mitów, jakoby W3Schools było powiązane w jakikolwiek sposób z W3C, a zatem – organizacją ustalającą standardy dla otwartej Sieci. Jest to nieprawda, wynikająca z podobieństwa nazw.

  W3, występujące w obu nazwach, to numeronim, który rozwija się do World Wide Web (czyli „oficjalnej” nazwy Internetu). Tylko tyle i aż tyle. Ten skrót użyty w nazwie W3C wskazuje na to, że to organ zajmujący się standaryzacją tejże Sieci, podczas gdy użycie go w nazwie W3Schools może wskazywać, że są to materiały edukacyjne przeznaczone dla Internetu.

  Wszelkie wątpliwości rozwiewa podstrona About W3Schools, na której czytamy wprost:

  The site derives its name from the World Wide Web (W3), but is not affiliated with the W3C.

  [Strona bierze swoją nazwę od World Wide Web (W3), ale nie jest w żaden sposób powiązana z W3C.]

• Inną, bardzo ciekawą, informację o zawartości strony podaje nam jej stopka:

  W3Schools is optimized for learning, testing, and training. Examples might be simplified to improve reading and basic understanding. Tutorials, references, and examples are constantly reviewed to avoid errors, but we cannot warrant full correctness of all content.

  [W3Schools jest zoptymalizowane pod proces uczenia się, testowania i ćwiczenia. Przykłady mogą być uproszczone, by ułatwić czytanie i rozumienie. Tutoriale, odniesienia do źródeł i przykłady są nieustannie sprawdzane, by uniknąć błędów, lecz nie możemy zagwarantować pełnej poprawności całej treści.]

  Z jednej strony widzimy, że rzeczy mogą się różnić od tych opisanych w standardzie (co jest tłumaczone chęcią uproszczenia ich), z drugiej – zostajemy zapewnieni, że treść jest nieustannie poprawiana. Niemniej patrząc, ile błędów zgłoszonych przez W3Fools.com wciąż jest niepoprawionych, osobiście śmiem wątpić w ostatnią część stopki.

• Jednym z powodów, dla których W3Schools jest tak często polecane, jest fakt, że przy większości przykładów znajduje się edytor do samodzielnego eksperymentowania. Faktycznie, byłaby to jakaś przewaga… gdyby MDN nie oferowało własnego edytora zintegrowanego z CodePenem i JSFiddle.

Przejdźmy zatem do mięska, czyli sprawdzenia, czy faktycznie zasoby W3Schools są tylko uproszczone, czy może po prostu niepoprawne. Pozwolę sobie wybrać kilka podstron z tego serwisu i o każdej co nieco powiedzieć.

HTML Element Reference
[Spis elementów HTML]

• Nie da się spieprzyć spisu elementów HTML, prawda? A jednak… Przy niektórych znacznikach widać enigmatyczny tekst Not supported in HTML5 [Niewspierane w HTML5]. Nie jest to jednak prawda. Słowo „niewspierane” sugerowałoby bowiem, że przeglądarki osługujące HTML5 nie rozumieją tych znaczników lub je po prostu ignorują. Niemniej gdybyśmy użyli tak oznaczonego center, zauważylibyśmy, że działa tak, jak powinno. Co zatem stało się z tymi znacznikami w HTML5? Trafiły do sekcji Obsolete features [Przestarzałe właściwości]. To oznacza, że na razie będą działać, ale walidator będzie przed nimi ostrzegał, a w przyszłości mogą zostać usunięte z przeglądarek. Mogą, ale nie muszą. Proces usuwania czegokolwiek z Sieci jest dość zagmatwany i obowiązuje w nim jedna, podstawowa zasada: nie można zepsuć istniejących stron WWW. Dlatego byłbym spokojny o „przyszłość” center.

• To niejedyny problem tej listy elementów. Mieszane są też definicje z HTML5 z wcześniejszymi wersjami, np. znacznik u ma podaną definicję z HTML5 (Defines text that should be stylistically different from normal text [Definiuje tekst, który powinien być stylistycznie inny od reszty tekstu]), podczas gdy znacznik b – z HTML4 (Defines bold text [Definiuje pogrubiony tekst]).

• Jeszcze inny problem to fakt, że część definicji nie ma najmniejszego sensu, np. ta dla figure (Specifies self-contained content [Definiuje samodzielną część treści]). Ta definicja jest zbyt ogólna i równie dobrze pasuje do chociażby article.

HTML figure tag
[Znacznik figure]

• Sama definicja tego elementu nieco odbiega od definicji zawartej w specyfikacji:

  The figure tag specifies self-contained content, like illustrations, diagrams, photos, code listings, etc.

  [Znacznik figure zawiera samodzielną część treści, taką jak ilustracje, diagramy, zdjęcia, listingi kodu itp.]

  Nie ma tu dodatkowych obostrzeń, jakie znajdują się w specyfikacji, co powoduje, że zgodnie z definicją na W3Schools praktycznie każdy obrazek pasowałby do figure. Niemniej, zgodnie z definicją ze standardu, figure służy do oznaczania tych elementów, które można przenieść na osobną stronę bez uszczerbku dla treści. Mówiąc inaczej: figure to wszystkie te elementy, które można przenieść do wszelkiego rodzaju indeksów i spisów na końcu książki, np. do spisu ilustracji czy cytatów.

  Jest to co prawda lekko zaznaczone w kolejnym zdaniu:

  While the content of the figure element is related to the main flow, its position is independent of the main flow, and if removed it should not affect the flow of the document.

  [Mimo że zawartość znacznika figure jest powiązana z główną treścią, jego pozycja jest od niej niezależna, a jego usunięcie nie powinno mieć wpływu na zrozumienie dokumentu.]

  ale całkowicie podważane przez przykład na samej górze:

  Use a figure element to mark up a photo in a document:

  [Użyj znacznika figure, by oznaczyć zdjęcie w dokumencie:]

  <figure>
  	<img src="img_pulpit.jpg" alt="The Pulpit Rock" width="304" height="228">
  </figure>

  Takie przedstawienie sprawy i odarcie figure z szerszego kontekstu sprawia, że informacja z uproszczonej staje się po prostu nieprawdziwa. Zwłaszcza, że najprostszy przykład użycia figure w specyfikacji wygląda tak:

  <p>Na <a href="#l4">listingu 4</a> widzimy deklarację API podstawowego jadra.</p>
  <figure id="l4">
  	<figcaption>Listing 4. Deklaracja API podstawowego jądra.</figcaption>
  	<pre><code>interface PrimaryCore {
  		boolean verifyDataLine();
  		void sendData(in sequence<byte> data);
  		void initSelfDestruct();
  	}</code></pre>
  </figure>
  <p>API jest zaprojektowane do użytku z UTF-8.</p>

• Kolejny problem stanowi opis domyślnych stylów, które wg W3Schools dla figure prezentują się następująco:

  figure {
  	display: block;
  	margin-top: 1em;
  	margin-bottom: 1em;
  	margin-left: 40px;
  	margin-right: 40px;
  }

  Problem polega na tym, że już w Chrome te style są inne, gdyż Blink zamiast normalnych marginesów używa własności -webkit-margin. To samo można powiedzieć o Firefoksie, który używa również niestandardowych własności (np. margin-block-start). Choć w większości przypadków te style dadzą ten sam efekt, to nie można ich ze sobą zrównywać.

  Pomijam przy tym fakt, że przykład mający pokazywać domyślne style ma… ustawione na sztywno powyższe style.

• Warto też pochylić się nad kwestią wsparcia przeglądarek. Pokazana na podstronie tabelka twierdzi, że zawiera wersje przeglądarek, ktore mają pełne wsparcie dla znacznika figure. Nie mogę się z tym jednak zgodzić. By mówić o pełnym wsparciu dla danego znacznika, przeglądarka musi spełniać kilka warunków:

  • Znacznik musi być możliwy do stylowania.
  • Znacznik nie może być rozpoznawany jako nieznany (HTMLUnknownElement).
  • Reprezentacja danego znacznika w drzewie DOM powinna zawierać wszystkie specyficzne właściwości tego elementu opisane w specyfikacji; w większości przypadków sprowadza się to do implementacji odpowiedniej podklasy HTMLElement.
  • Znacznik musi być poprawnie reprezentowany w drzewku dostepności strony.

  Śmiem twierdzić, że żadna z przeglądarek wymienionych w tabelce nie spełnia ostatniego warunku. A już na pewno nie spełnia go Internet Explorer. Obecne wsparcie można zobaczyć na stronie HTML5 Accessibility.

  Strona ta też pokazuje, jak dużym nieporozumieniem jest łączenie IE i Edge jako jednej przeglądarki, ponieważ w wielu aspektach (np. wsparciu dla dostępności) są całkowicie różne.

HTML DOM Figure Object
[Obiekt Figure z HTML DOM]

Ta podstrona to jedna, wielka bzdura. Coś takiego jak „obiekt Figure” nie istnieje. Każdy element HTML jest reprezentowany w DOM jako instancja „interfejsu” HTMLElement. Niektóre elementy mają swoje podklasy, jak np. HTMLVideoElement, które zawierają dodatkowe własności, niemniej duża liczba elementów (w tym i figure) korzystają bezpośrednio z HTMLElement.

var figure = document.createElement( 'figure' );
figure.constructor; // HTMLElement

HTML Audio/Video DOM play() Method
[Metoda play z HTML Audio/Video DOM]

Przedstawiona wersja metody play jest wersją starszą, która została zmodyfikowana z dobre pół roku temu. Obecna wersja metody play jest bowiem asynchroniczna i zwraca Promise. MDN już zaktualizowało tę informację.

HTML5 Video

Strona ta twierdzi, że w HTML5 wspierane są 3 formaty video:

In HTML5, there are 3 supported video formats: MP4, WebM, and Ogg.

[W HTML5 są 3 wspierane formaty video: MP4, WebM i Ogg.]

Jest to z gruntu nieprawda, ponieważ specyfikacje HTML – zarówno w wersji od WHATWG, jak i W3C – nie definiują żadnego wspieranego formatu, przerzucając tę odpowiedzialność na przeglądarkę.

Co więcej, wszystkie trzy wymienione formaty nie są homogeniczne. Istnieją w wielu różnych wariantach, zależnych od użytych kodeków, a wsparcie dla tych wariantów jest różne pomiędzy różnymi przeglądarkami. I tak MP4 może być zarówno zakodowane przy pomocy H.264, jak przy pomocy nowszego H.265, WebM – przy pomocy VP8 lub VP9, które dodatkowo mogą się łączyć z różnymi kodekami audio (np. Vorbis czy Opus). Ogg posiada jeszcze więcej kombinacji. Nie można przy tym zapominać, że istnieją jeszcze kodeki systemowe, które pozwalają Internet Explorerowi/Edge czy też Safari (przy pomocy QuickTime) wspierać niemal wszystkie możliwe formaty. Jak bardzo sytuacja jest skomplikowana, przedstawia tabela kompatybilności na MDN.

Tak duże uproszczenie ze strony W3Schools sprawia, że informacja jest nieprawdziwa i mylna – zwłaszcza, że przy Safari nie jest wspomniana możliwość wspierania kodeków ze strony QuickTime.

HTML !DOCTYPE Declaration

Większość informacji na tej stronie jest nieprawdziwa.

The !DOCTYPE declaration is not an HTML tag; it is an instruction to the web browser about what version of HTML the page is written in.

In HTML 4.01, the !DOCTYPE declaration refers to a DTD, because HTML 4.01 was based on SGML. The DTD specifies the rules for the markup language, so that the browsers render the content correctly.

HTML5 is not based on SGML, and therefore does not require a reference to a DTD.

[Deklaracja DOCTYPE nie jest tagiem HTML; to instrukcja dla przeglądarki o wersji HTML, której użyto do stworzenia danej strony.

W HTML 4.01 deklaracja DOCTYPE odwoływała się do DTD, ponieważ HTML 4.01 był oparty na SGML-u. DTD definiuje zasady gramatyki języka, tak, by przeglądarka była w stanie wyświetlić poprawnie treść.

HTML5 nie jest oparte na SGML, dlatego nie potrzebuje odwołania do DTD.]

Może i składnia starszych wersji HTML-a faktycznie była wzorowana na składni SGML-a, ale poziom skomplikowania zasad gramatyki HTML-a już bardzo dawno przekroczył możliwości opisania go przy pomocy DTD. Warto choćby spojrzeć na oficjalne zasady parsowania HTML-a. HTML5 został niemal w całości oparty na standaryzacji już istniejących mechanizmów – zatem oczywistym jest wniosek, że HTML 4.01 również musiał być parsowany przy pomocy tych samych lub podobnych zasad.

Oznacza to tyle, że DTD nigdy nie miało zastosowania. Przeglądarki posługiwały się swoimi wewnętrznymi zasadami, nie zważając w ogóle na ten plik – zwłaszcza, że opisywał on wyłącznie podzbiór całej gramatyki HTML-a, nie zawierając choćby relacji pomiędzy znacznikami HTML a obiektami w DOM.

Co więcej, DOCTYPE w żaden sposób nie przełączał pomiędzy trybem HTML 4 i HTML5. Jedyne istniejące tryby to tryb zgodności ze standardami i tryb quirks. Ten drugi był włączany, gdy DOCTYPE pominięto. I tylko i wyłącznie po to, by ten tryb nie był używany, HTML5 zawiera wymóg używania DOCTYPE, co jest nawet napisane wprost w specyfikacji:

DOCTYPEs are required for legacy reasons. When omitted, browsers tend to use a different rendering mode that is incompatible with some specifications. Including the DOCTYPE in a document ensures that the browser makes a best-effort attempt at following the relevant specifications.

[DOCTYPE jest wymagany z powodu kompatybilności wstecznej. Jeśli się go pominie, przeglądarki mogą przełączyć się w inny tryb renderowania, który jest niezgodny z niektórymi specyfikacjami. Dołączenie DOCTYPE do dokumentu gwarantuje, że przeglądarka dołoży wszelkich starań, by renderować zgodnie ze specyfikacjami.]

Co więcej, specyfikacja HTML dopuszcza wyłącznie nowy DOCTYPE, równocześnie oznaczając wszelkie inne jako przestarzałe.

HTML Elements and Valid DOCTYPES
[Elementy HTML oraz prawidłowe DOCTYPE]

Stwierdzenie:

The table below lists all HTML elements, and shows what !DOCTYPE each element appears in.

[Tabela poniżej pokazuje wszystkie elementy HTML oraz !DOCTYPE, w którym każdy element się pojawia.]

jest nieścisłe. Nie dość, że niektóre elementy są źle dopasowane (np. menu istnieje wyłącznie w HTML Living Standard, ale już nie w HTML5; a te standardy należy traktować rozdzielnie), to dodatkowo pojęcie DOCTYPE zostało zrównane z poszczególnymi specyfikacjami i standardami.

HTML section tag
[Znacznik HTML section]

Definicja elementu jest niepoprawna.

The section tag defines sections in a document, such as chapters, headers, footers, or any other sections of the document.

[Znacznik section definiuje sekcje w dokumencie, takie jak rozdziały, nagłówki, stopki lub wszelkie inne sekcje.]

Definicja jest niepotrzebnie rozszerzona, a włączenie w nią nagłówków i stopek podważa sens istnienia znaczników header i footer. Co więcej sformułowanie wszelkie inne sekcje dodatkowo podważa sens istnienia nav (sekcji nawigacyjnej) oraz aside (sekcji treści pobocznej).

Porównajmy powyższą definicję z definicją section na MDN:

The HTML section element represents a standalone section of functionality contained within an HTML document, typically with a heading, which doesn’t have a more specific semantic element to represent it.

[Element section reprezentuje samodzielną sekcję funkcjonalności zawartą wewnątrz dokumentu HTML, najczęściej z nagłówkiem, która nie posiada bardziej precyzyjnego znacznika służącego do jej oznaczenia.]

Ta definicja nie dość, że zwraca uwagę na charakter sekcji (samodzielna), to dodatkowo zaznacza, że sekcja powinna mieć nagłówek, a także, że nie należy używać section jeśli istnieją bardziej precyzyne znaczniki (jak choćby wspomniany nav). Różnica pomiędzy tymi dwoma definicjami jest na tyle duża, że można stwierdzić, że dotyczą one dwóch różnych elementów.

Oczywiście definicja section w specyfikacji HTML5 jest zgodna z opisem na MDN:

The section element represents a generic section of a document or application. A section, in this context, is a thematic grouping of content, typically with a heading.

[Element section reprezentuje generyczną sekcję dokumentu lub aplikacji. Sekcja w tym kontekście oznacza tematyczną grupę treści, najczęściej zawierającą nagłówek.]

HTML Editors
[Edytory HTML]

Polecanie Notatnika do pisania HTML w dobie darmowych edytorów pokroju Atoma jest po prostu śmieszne.

HTML Elements
[Elementy HTML]

The HTML5 standard does not require lowercase tags, but W3C recommends lowercase in HTML, and demands lowercase for stricter document types like XHTML.

[Standard HTML5 nie wymaga pisania znaczników małymi literami, ale W3C rekomenduje małe litery w HTML i wymaga ich dla ściślejszych typów dokumentów, takich jak XHTML.]

Całe powyższe sformułowanie to jedna, wielka bzdura. W3C nigdzie nie rekomenduje pisania znaczników małymi literami – HTML nie zważa na wielkość znaków. Ba, specyfikacja HTML 4.01 zawiera praktycznie wyłącznie kod HTML napisany dużymi literami. Nietrudno też takie przykłady znaleźć w specyfikacji HTML5.

Co więcej, sam „typ dokumentu XHTML” nie wymaga znaczników pisanych małymi literami. XHTML bez odpowiedniego typu MIME to HTML z błędami. Jest to na tyle ważne rozróżnienie, że termin XHTML został usunięty ze standardu, który obecnie nazywa takie dokumenty po prostu XML-em.

PHP 5 Form Validation
[Walidacja formularza w PHP 5]

• PHP 7.0 zostało wydane 5 grudnia 2015 roku – niemal pełne 2 lata temu. Wydaje mi się, że 2 lata to wystarczająco długo, by W3Schools zdążyło zaktualizować swoje materiały o PHP.
• Kod HTML formularza woła o pomstę do nieba. Brakuje w nim label – i to nawet dla pól wyboru.

• <form method="post" action="<?php echo htmlspecialchars($_SERVER["PHP_SELF"]);?>">

  Ta porada jest niepoprawna. Zmienna $_SERVER['PHP_SELF'] zawsze zwraca nazwę pliku, który obsługuje dane żądanie. Nawet jeśli adres będzie wyglądał np. https://domena.pl/kontakt, ta zmienna zwróci index.php (lub inną nazwę pliku, w zależności od architektury aplikacji). Tego typu rada miałaby sens w chwili, gdy aplikacja składałaby się z wielu pojedynczych plików PHP, co w dzisiejszych czasach zostaje wyparte przez aplikacje sterowane routerem (a zatem: mające jeden plik).

  Większy sens miałoby tu użycie $_SERVER['REQUEST_URI'], chociaż najbezpieczniej użyć po prostu sztywno wpisanej ścieżki.

  Dodatkowo htmlspecialchars nie chroni przed wszystkimi atakami XSS. Inna rzecz jest taka, że to, co trafia do URL-a, powinno być dodatkowo potraktowane choćby przez urlencode.

• Dodatkowo ta podstrona opisuje atak XSS poprzez ścieżkę do pliku PHP: http://www.example.com/test_form.php/%22%3E%3Cscript%3Ealert('hacked')%3C/script%3E. Jest to napisane w taki sposób, że sugeruje, że to całkowicie normalne zachowanie serwera WWW. Niemniej jest to konfigurowalne i właśnie poprawna konfiguracja tego rozwiązania powinna być przedstawiona zamiast prób obejścia problemu.

• Pokazana funkcja test_input na dobrą sprawę nie robi nic sensownego. Użycie stripslashes sugeruje wręcz zakladanie, że włączone są magiczne cudzysłowy, które zostały usunięte w PHP 5.4.0 (przypominam, że od dwóch lat mamy PHP 7.0+, a ostatnią gałęzią PHP 5 jest PHP 5.6+). Cała ta funkcja mogłaby być zamieniona na filter_var.

JavaScript Tutorial
[Kurs JS]

JavaScript is the programming language of HTML and the Web.

[JavaScript to język programowania HTML-a i Sieci.]

JavaScript to język programowania ogólnego przeznaczenia, a HTML, który jest językiem opisowym, nie posiada swojego własnego języka programowania.

JavaScript Versions
[Wersje JS]

• Większość informacji na tej stronie jest niekompletna lub totalnie wyssana z palca. Już samo podsumowanie ES6 jako wersji, która wprowadziła klasy i moduły, bez wspomnienia czegokolwiek innego, jest po prostu żenujące. ES6 zmieniło niemal wszystkie mechanizmy języka i wprowadziło choćby tak potężne mechanizmy jak Proxy czy Reflect czy ustandaryzowało de facto standardy, jak Promise. Pomijam fakt, że moduły to akurat ta jedna rzecz, której ES6 na dobrą sprawę nie wprowadziło, definiując jedynie samą składnię, bez całej infrastruktury potrzebnej do faktycznego wczytywania modułów.

• ECMAScript 6 is partially supported in all modern browsers.

  ECMAScript 7 is poorly supported in all browsers.

  [ECMAScript 6 jest częściowo wspierany przez wszystkie nowoczesne przeglądarki.

  ECMAScript 7 jest słabo wspierany przez wszystkie przeglądarki.]

  Nie dość, że W3Schools nie może się zdecydować, co jest nowoczesną przeglądarką, a co nie, to dodatkowo obydwa stwierdzenia są fałszywe. ES6 ma wsparcie na poziomie 95%+ w każdej nowoczesnej przeglądarce, a jedyna brakująca rzecz to tail call optimization, które powoduje sporo problemów. ES7 ma wsparcie na poziomie 100% w nowoczesnych przeglądarkach i 91% w Edge.

• Tabelka pokazująca implementacje ES w silnikach jest bez sensu. Nie dość, że nie wiadomo, w której wersji silnika wprowadzono konkretne ficzery, to dodatkowo na liście pojawia się „JavaScript 1.8.5”, który nie jest silnikiem a wewnętrzną wersją JS w Mozilli.

JavaScript JSON

• Sama nazwa tej podstrony jest bzdurna, bo JSON w swojej nazwie już zawiera „JS”. Dodatkowo jest to format danych niezależny od języka programowania.

• The JSON format is syntactically identical to the code for creating JavaScript objects.

  [Format JSON jest skladniowo identyczny, jak kod do tworzenia obiektów w JS.]

  Nie jest.

JavaScript Window – The Browser Object Model
[JavaScript Window – Przeglądarkowy Model Obiektowy]

There are no official standards for the Browser Object Model (BOM).

[Nie istnieją oficjalne standardy dla BOM.]

To nieprawda, bo jest to część standardu HTML oraz wielu innych standardów (np. CSSOM). Dodatkowo samo pojęcie globalnego obiektu jest częścią specyfikacji ECMAScript.

JavaScript Global Reference
[Spis właściwości globalnych w JS]

• Lista jest niekompletna, np. znajduje się na niej String, ale nie ma żadnego innego typu.
• Stwierdzenie, że konstruktor String jest wyłącznie funkcją do konwersji zmiennych na zmienne tekstowe, jest tak uproszczone, że nieprawdziwe.

• Twierdzenie, że escape zostało zdeprecjonowane w wersji 1.5, jest nieprawdziwe. Mimo że w wersji ES5 ta funkcja faktycznie była niestandardowa, to wersja ES6 przywraca escape jako metodę definiowaną wewnątrz środowiska JS przeglądarek.

  Co więcej, W3Schools nie posługuje się tutaj numerem wersji standardu ES, lecz wewnętrznym numerem wersji JS Mozilli.

CSS3 Box Sizing

The CSS3 box-sizing property allows us to include the padding and border in an element’s total width and height.

[Własność CSS3 box-sizing pozwala nam wliczyć wewnętrzny margines i obramowanie elementu do jego całkowitej szerokości i wysokości.]

Ta definicja jest nieprawdziwa. Własność box-sizing służy do przełączania obowiązującego modelu pudełkowego i ma 2 możliwe wartości (nie 1 – border-box – jak twierdzi W3Schools). Opisanie tej własności bez wspomnienia o modelu pudełkowym po prostu zabija sens tej własności.

Node.js NPM

To npm, nie NPM.

---

Myślę, że nie ma sensu głębiej zanurzać się w otchłaniach zawartości W3Schools, bo przedstawione przykłady dobitnie pokazują, że jest to strona, na której najbardziej podstawowe rzeczy są opisane w sposób całkowicie niepoprawny, by nie powiedzieć – bzdurny. Z tego też powodu polecanie W3Schools jako źródła jakiejkolwiek wiedzy jest szkodliwe. Istnieją o wiele lepsze źrodła, jak np. MDN, które stało się teraz oficjalną dokumentacją otwartej Sieci.

Stop W3Schools, niech żyje MDN!