Overleg:HyperText Markup Language

Euhm dit is geen zin: "De webserver geeft bestanden met de genoemde extensies .asp en .php krijgen hetzelfde content-type als een 'gewoon' html-bestand, namelijk text/html." Koen

citaat: "Alle moderne browsers voorzien in de weergave van XHTML, maar ook de oudere browsers kunnen vaak het nieuwere formaat nog prima weergeven."

XHTML moetworden verstuurd met contenttype "application/xhtml+xml". Wat er nu gebeurt is dat het in het algemeen wordt verstuurd met contenttype "text/html". In dat laatste geval interpreteert de browser het als HTML, en zijn in feite alle voordelen van XHTML verdwenen, afsluiten van tags is niet meer noodzakelijk etc.

De belangrikste reden dat dit in de praktijk gebeurt is dat Internet Explorer geen XHTML ondersteunt. Onderstaande link wordt door Internet Explorer gedownload, niet getoond: http://devedge.netscape.com/viewsource/2003/xhtml-style-script/examples/example-6.xhtml

XHTML bij XHTML i.p.v. HTML

Ik vraag me af of het nog wel handig is om een onderdeel over XHTML op de HTML-pagina bij te houden. Er bestaat immer ook een XHTML-pagina. Daarnaast zijn HTML en XHTML twee compleet verschillende dingen. XHTML 2.0 zal zo veranderd zijn dat het geenzins meer op HTML zal lijken.

-Lars- 12 feb 2005 12:32 (CET)

Er is nog een HTML pagina

Op HTML-elementen tref ik nog een pagina over HTML aan, deze had ik eerst samengevoegd willen zien, maar ik heb besloten dat niet te laten gebeuren, en om te zetten naar een lijstje. Bas 28 mrt 2005 22:39 (CEST)

Is nu Lijst van HTML-elementen, wat de titel beter dekt, de informatie kan beter in dit artikel. Bas 28 mrt 2005 22:50 (CEST)

Poe

Ik ben voor nu even uitgeschreven. Nog niet helemaal tevreden. Wat ik geprobeerd heb te doen is:

1. tenminste de inleiding moet voor een leek begrijpelijk zijn.
2. het artikel is geen handleiding HTML, maar een artikel over HTML.

Verder heb ik nog deze ideeën:

• een screenshot simpele HTML-code en het resultaat daarvan in de browser.
• DHTML moet nog ergens geplaatst worden in de "Geschiedenis" alinea. Ik wist even niet meer precies waar dat in de tijd zat.
• De verschillende specificaties in een tabel zetten, met jaartal en een paar trefwoorden over wat er nieuw aan is.
• XML-XSL transformatie om HTML te genereren.
• Het Document Object Model noemen/inleiden (daar moet ook nog eens een artikel over komen).

Taka 29 mrt 2005 00:15 (CEST)

Ziet er goed uit! Ik zal het binnenkort wat beter doorlezen, maar mijn eerste snelle indruk is erg goed. Mooi werk Taka! JimmyShelter 29 mrt 2005 23:47 (CEST)

Dank je. Ik begin zelf ook tevreden te worden. De schrijfstijl is hier en daar nog wat stijfjes en misschien nog een plaatje en een tabel. Ik hoop vooral ook dat het leesbaar en begrijpelijk is voor leken. Dat vind ik zelf moeilijk te beoordelen. Taka 30 mrt 2005 08:27 (CEST)

Oke, sorry, ik had die html-codes erin gezet... Ik wist niet dat dat niet moest --Sumurai8 4 dec 2005 09:34 (CET)

Structuur vs. vormgeving

De volgende alinea verwijderd, omdat deze onuist is.

HTML is bedoeld om een document te structureren: met tags wordt de tekst verdeeld in elementen als hoofd- en onderkoppen, alinea's en lijsten. Ook kunnen stukken tekst benadrukt worden. De vormgeving wordt bepaald door middel van CSS, waarin voor de verschillende pagina-elementen de weergavestijl is vastgelegd. In het stijlblad wordt bijvoorbeeld aangegeven hoe benadrukte tekst getoond dient te worden: vet, groter of met een kleur.

Dit is eventueel waar voor in een verouderde visie op HTML-pagina's, maar gaat voorbij aan het Document Object Model, waarin de positie en grootte van elementen door CSS wordt bepaald. Taka 21 mei 2006 16:54 (CEST)

Wat is er dan onjuist volgens jou? En: het DOM is een abstractie, een interface om content, structuur en stijl van een document te benaderen (zie [1]). Positie en grootte van elementen worden niet in het DOM bepaald, hooguit via, en bij mijn weten enkel door een script. Ronald 21 mei 2006 18:57 (CEST)

Ik schrijf ook dat de positie en grootte door CSS worden bepaald (niet door DOM). CSS is veel meer dan alleen vormgeving van elementen, het is ook positionering van elementen. Met "position:absolute", ".pixelLeft" en ".pixelTop" kan de positie van een element worden bepaald. De zIndex bepaalt of een element boven of onder een ander element ligt. Dat kan met of zonder script.

De verschillende stijlen die men voor de wikipedia kan kiezen, zijn CSS stijlen, en de positionering van de diverse elementen in de verschillende stijlen is anders, terwijl het HTML-gedeelte gelijk blijft.

Het is dus precies zoals ik hierboven schrijf: de bewering dat HTML voor de structuur en CSS voor de vormgeving is, gaat uit van een verouderde visie op HTML, ook wel HTML-soep genoemd. Het DOM maakt een object-georiënteerde benadering van HTML mogelijk. Ook de positie en grootte van element wordt via het DOM bepaald door CSS, dat kan met of zonder script: "element.style.width=345px" is een opdracht in script die via CSS gaat (vanwege de style property).

Dat zeg ik: HTML voor de structuur, CSS voor de vormgeving. Voor de duidelijkheid, positionering van elementen zie ik ook als vooral vormgeving. Ronald 22 mei 2006 08:51 (CEST)

> "Positie en grootte van elementen worden niet in het DOM bepaald, hooguit via, en bij mijn weten enkel door een script."

Het kan direct via CSS. Probeer onderstaande maar eens uit:

<html>
<head>

</head>
</body>

<table border="1" style="width:250px;position:absolute;top:150px;left:350px;">
<tr><td>tabel1</td></tr>
</table>

<table border="1" style="width:150px;height:200px;position:absolute;top:50px;left:50px;">
<tr><td>tabel2</td></tr>
</table>


</body>
</html>

Taka 22 mei 2006 07:15 (CEST)

Toevoeging. Tegenwoordig wordt de vormgeving (inclusief positie en grootte) van HTML-elementen uitsluitend door CSS bepaald, en alle moderne browsers werken met het DOM. Je kan het zo zien dat elke browser een standaard ingebouwd stylesheet heeft dat de HTML interpreteert. Daarbij worden default-waarden voor de CSS-eigenschappen van de elementen gebruikt. Oorspronkelijk werd HTML simpelweg serieel geinterpreteerd: een element dat later in de HTML komt, wordt onder of rechts van een eerder element geplaatst, met als enige reden dat het later in de HTML wordt genoemd. HTML was echt tekst-met-opmaaktekens.

Tegenwoordig worden later genoemde HTML-elementen zonder verdere toevoeging ook rechts of onder eerder genoemde elementen geplaatst, maar om een andere reden: elk element heeft als de default-waarde "static" voor de CSS-property "position", wat ongeveer betekent dat de element-volgorde zoals die in HTML voorkomt, wordt gebruikt voor positionering. In de praktijk betekent dat dat "oude" HTML-documenten nog steeds worden weergegeven als oorspronkelijk, en dat is natuurlijk ook de bedoeling. De achterliggende wijze waarop dat gebeurt is echter volstrekt anders. Van elk element is de "currentStyle" op te vragen, en elk element heeft ook voor elke CSS-eigenschap een waarde. Waarden die niet expliciet in het document zijn aangegeven, worden door de browser uit het default-stylesheet gehaald.

Het resultaat van dit alles is dat "oude" HTML nog steeds werkt, maar achter de schermen wordt alles op een volstrekt andere wijze behandeld. Het draait niet meer om tekst die mbv opmaaktekens een lay-out krijgt. Het draait om de elementen zoals die via het DOM worden benaderd. Tekst is slechts één van de vele eigenschappen van een element. Zie ook Document Object Model, en kijk naar het plaatje daar. Probeer zelf ook eens op wat HTML-pagina's de DOM-inspector van Firefox uit. Klik een element aan en kijk naar "computed style": voor elke CSS-eigenschap is een waarde ingevuld. IE heeft geen DOM-inspector, maar ik kan je verzekeren dat ook IE op dezelfde wijze werkt.

(Ik weet het. Google eens op "IE Developer Toolbar", mocht je een DOM-inspector zoeken voor IE.)

Is het zo duidelijker? Taka 22 mei 2006 08:09 (CEST)

Tja, ik kan toch niets anders concluderen dan dat een webauteur HTML dient te gebruiken om z'n tekst te structureren, en CSS om aan de aldus gecreëerde elementen vormgeving te hangen. Nogmaals, het DOM is een interface. De eerste webbouwer die 'iets in DOM schrijft' moet nog geboren woden.

Volgens mij ontken je ook niet dat een webauteur waar mogelijk die scheiding dient aan te brengen. Daarom begrijp ik nog steeds niet waarom je mijn correcte opmerkingen hebt verwijderd.

Overigens, je hebt het over HTML-soep, maar ik neem aan dat je tag soup bedoelt? Helaas is gebruik van CSS bepaald geen garantie voor minder soep. Ronald 22 mei 2006 08:51 (CEST)

Browsers werken met het DOM. Het gebruik van verschillende HTML-tags is wel handig, maar het is mogelijk om bijvoorbeeld uitsluitend "span" tags te gebruiken en om via CSS-classes daar een stijl aan te geven. <span class="b">bold</span> werkt hetzelfde als <b>bold</b> als de CSS-class "b" hetzelfde wordt gedefineerd als "b" in de default stylesheet.

> "Helaas is gebruik van CSS bepaald geen garantie voor minder soep. ". Het gaat er niet om of CSS wordt gebruikt, het gaat er om dat browsers een HTML-document altijd via het DOM interpreteren, en dat browsers altijd CSS gebruiken (via hun default stylesheet). Iemand kan natuurlijk ongeldige HTML schrijven, maar het is aan de browser of deze daar iets van kan bakken in termen van DOM. Een webauteur schrijft natuurlijk niet direct naar de DOM, maar moderne browsers interpreteren een HTML-document altijd via het DOM. Een webauteur schrijft code die via het DOM wordt geinterpreteerd.

Je tekst was "...met tags wordt de tekst verdeeld in elementen als hoofd- en onderkoppen, alinea's en lijsten. Ook kunnen stukken tekst benadrukt worden". Dat is niet correct omdat het primaat hier wordt gelegd bij de tekst die verdeeld wordt in elementen. Het is andersom: er worden elementen gemaakt waaraan eventueel tekst wordt toegewezen en met CSS wordt de stijl van de elementen bepaald, inclusief de grootte en positie van de elementen en inclusief de weergavestijl van de tekst in de elementen. Nou lijkt dat misschien een subtiel verschil, maar het is wel een wezenlijk onderscheid. Het is namelijk het verschil tussen de oude visie op HTML (tekst-met-opmaaktekens, tag soup) en de DOM-benadering. Tag soup bestaat niet meer.

Mijn door jou aangehaalde tekst was wellicht te simpel gesteld, maar elementen maken en daar content aan toewijzen is voor mij de wereld op zijn kop. Ik redeneer daarbij als webauteur, en niet als browser die de boel moet verwerken. Vergeet svp niet dat HTML door beiden wordt gebruikt; beide benaderingen verdienen daarom m.i. ruimte. HTML is een taal: de een spreekt, de ander dient het te begrijpen. Ronald 23 mei 2006 23:15 (CEST)

De begrippen "structuur" en "vormgeving" zijn in HTML niet gebonden aan "broncode" en "CSS" maar aan "DOM-interpretatie " en "CSS". Met een script kunnen elementen aan de DOM-interpretatie van een document worden toegevoegd, zonder dat de broncode veranderd. De DOM-interpretatie van een document in de browser kan zelfs volledig met een script worden opgebouwd, zonder dat de structuur als HTML wordt geschreven. Het gelijkstellen van HTML-broncode en structuur is derhalve onjuist.

En kijk nou eens naar de opbouw van het hele artikel. De opbouw is dat HTML eerst wordt geintroduceerd als tekst-met-opmaaktekens. Er wordt iets gemeld over toevoegingen als CSS en script, en na iets over de geschiedenis en gegenereerde HTML documenten wordt het DOM vermeld. Er staat "HTML is uitgegroeid van opgemaakte tekst met plaatjes tot een object-georiënteerde benadering van een document.". Vervolgens had je er een alinea aan toegevoegd waarin HTML weer wordt gepresenteerd als tekst-met-opmaaktekens, waarin CSS nog wat extra mogelijkheden aan de opmaaktekens toevoegt. Dat is een simplificatie die zeker op dat punt in het artikel niet thuis hoort.

Als ik het hier over opmaak heb gehad, dan was het bedoeld zoals in opmaaktaal, waar uiterst ongelukkig het woord markup is gesneuveld ten gunste van het ambigue woord opmaak.

Het gaat er niet om dat het artikel nu perfect is ofzo, maar de opbouw van het artikel lijkt me nu best duidelijk. Het DOM is een abstractie, en dat is misschien vooral voor ingewijden interessant. Daarom is er ook een apart artikel over.

Taka 22 mei 2006 09:42 (CEST)

In je opmerkingen over de opbouw kan ik me wel vinden. Groet, Ronald 23 mei 2006 23:15 (CEST)

"...elementen maken en daar content aan toewijzen is voor mij de wereld op zijn kop. Ik redeneer daarbij als webauteur, en niet als browser die de boel moet verwerken"

Toch is dat naar mijn idee de essentie van de overgang van tag soup naar een object-georiënteerde benadering van HTML-documenten. Het is inderdaad in zekere zin een omgekeerde wereld: de bestaansreden van een webpagina is doorgaans de inhoud. Het is erg prettig dat de visie van tekst-met-opmaaktekens nog steeds redelijk werkbaar is, maar als webontwikkelaar kom je er niet meer mee weg. Overigens zijn webontwikkelaars niet de leveranciers van content, die wordt (vaak via een CMS) door anderen aangeleverd. Een webontwikkelaar levert in feite een kaal skelet op. Taka 24 mei 2006 00:08 (CEST)

Volgens mij moet je het DOM volledig los zien van HTML. Een HTML document kan je ook prima verwerken met een SAX parser hoor, zonder enige object-georienteerde benadering. HTML doet niks meer dan met behulp van een bepaalde syntax een hierarchische, maar vooral semantische opbouw van het document bepalen. Je kan dan misschien met CSS <span class="b">hallo</span> en <b>hallo</b> hetzelfde eruit laten zien; het zijn verschillende elementen met een verschillende semantische waarde, en daar gaat het om. Tag soup heeft hier helemaal niks mee te maken. Tag soup is een webpagina met geen semantiek en een verkeerde syntax (kijk maar eens op en:Tag soup, de overgang van tag soup naar correcte HTML documenten verandert helemaal niks aan het feit dat HTML voor structuur en semantiek is, en CSS voor opmaak. Kortom: DOM is niks meer dan een bepaalde abstractie/representatie van het HTML document dat niks veranderd aan het feit dat HTML een markup-taal is om documenten met behulp van elementen hierarchisch en semantisch te structureren en dat CSS een taal is om een bepaalde vormgeving aan deze elementen toe te kennen. De manier waarop een HTML document door de browser wordt verwerkt (DOM, SAX) en getoond (met een soort basis CSS) verandert hier niks aan. Cepheus 27 mei 2006 12:06 (CEST)

Tja, je kan HTML ook prima als platte tekst "parsen". Feit is dat browsers het DOM gebruiken om HTML te interpreteren. Overigens gaat het artikel ook over HTML, en wordt het DOM één maal genoemd. Dus daar kan je niet over klagen lijkt me. Of je als webontwikkelaar het DOM wil negeren of niet moet ieder zelf weten. Het lijkt me echter dat het negeren van het DOM (= de manier waarop browsers met HTML omgaan) niet leidt tot briljante webpagina's.

Als met tag soup alleen wordt bedoeld dat het invalid HTML is, dan is het natuurlijk weinig meer dan een lekker bekkende kreet. In de begintijd was een HTML-document echter ook een soort soep: een deel bestond uit objecten die benaderbaar waren (zoals plaatjes, frames en form-elementen), en een deel was ongrijpbare "vloeistof", bijvoorbeeld bestaande uit tekst. Het beeld van soep is daar een zeer plastische beschrijving van.

De vroegere functionaliteit van HTML is opgesplitst. Je ziet tegenwoordig steeds meer HTML-pagina's die nauwelijks meer HTML bevatten. De inhoud wordt er met javascript, XSL(T) en XML ingezet, en javascript gaat dan aan de slag met de DOM-interpretatie van de browser. CSS is er voor positionering en opmaak. Een HTML-document is steeds meer slechts een container waarin inhoud (XML), structuur (XSL) en presentatie (CSS) uit verschillende bronnen worden opgehaald en tot een interactief document worden gesmeed. Taka 26 mei 2006 19:57 (CEST)

Als je met tag soup bedoeld dat sommige elementen onbenaderbaar waren dan verandert dit nog altijd niks aan de functie van HTML en CSS, en dat probeer ik duidelijk te maken. Ook het feit dat inhoude (XML) en structuur (XSLT) achter de schermen worden gescheiden en pas later worden samengevoegd verandert niks aan het feit de HTML voor structuur, semantiek en inhoud is. HTML bevat dan inhoud (oorspronkelijk uit de XML, maar dat maakt niks uit) en structuur en semantiek (uit de XSLT). XML alleen heeft geen enkele semantische waarden, XSLT geen enkele inhoud, HTML is gewoon de versmelting daarvan. De alinea die je hebt weggehaald klopt volgens mij daarom prima:

HTML is bedoeld om een document te structureren: met tags wordt de tekst verdeeld in elementen als hoofd- en onderkoppen, alinea's en lijsten. Ook kunnen stukken tekst benadrukt worden.

Hiermee zeg je gewoon simpel dat HTML voor semantiek en structuur is in de rest van de alinea wordt gezegd dat CSS de vormgeving van elementen bepaald. Of deze vormgeving nou via DOM, SAX of wat dan ook toegepast wordt maakt niks uit. Maar CSS bepaalt zeker de vormgeving van de elementen in een HTML-document. Dus volgens mij klopt deze alinea prima. Cepheus 27 mei 2006 12:06 (CEST)

Lees de hele discussie nou eens goed. Het gaat me erom dat inmiddels het primaat bij de structuur ligt en niet bij de tekst. Het "verdelen van tekst in elementen als hoofd- en onderkoppen" is een benadering van HTML zoals dat in de beginperiode was, en dat staat ook al als zodanig in het artikel, en wel helemaal in het begin: "In de meest basale vorm wordt HTML gebruikt voor indeling van tekst in paragrafen met kopjes en stukjes tekst die nadruk moeten krijgen". Dat men er nog steeds zo naar kan kijken is prettig, en wordt ook niet ontkend in het artikel. Het is wel van belang dat er inmiddels ook op een heel andere manier naar HTML kan worden gekeken, waarbij het primaat ligt bij de elementen, en niet langer bij de tekst. Mijn punt is dat de toegevoeging niet als slotparagraaf van het artikel kan worden geplaatst, waar het als een soort definitieve konklusie zou gelden (afgezien van de paragraaf "zelf HTML schrijven", dat is een compromis omdat mensen voortdurend hun eigen ervaring met HTML hier kwijt wilden, nu linkt die paragraaf naar een artikel in wikibooks. In elk geval voorkomt die paragraaf dat het artikel voortdurend wordt "aangevuld" door mensen die gaan uitleggen wat een <b> in HTML doet).

Overigens ben ik erg benieuwd naar het gebruik van SAX om HTML te parsen. Er is mij niets bekend over een applicatie die dat doet. HTML wordt geschreven om geinterpreteerd te worden door webbrowsers, en moderne webbrowsers werken met het DOM. Taka 27 mei 2006 16:24 (CEST)

Het "verdelen van tekst in elementen als hoofd- en onderkoppen" is volgens mij hetzelfde als structuur in een document vastleggen. Of je dan de indruk legt op de structuur of de inhoud van een document is maar gewoon hoe je er naar kijkt, beide zijn onmisbaar in een HTML document. En of je elementen ziet als een tak in het DOM, of als stukjes tekst die zijn afgebakend met <> en </> maakt daar weinig verschil tussen. Maar laten we deze discussie nu maar afsluiten.

"Structuur in een document vastleggen" is toch wat breder dan "het verdelen van een...". Bij structuur in een document vastleggen kun je ook denken aan de navigatie in een lijst zetten, de functie van een afbeelding in een document aangeven, afijn heel wat meer dingen. Aangezien HTML tegenwoordig voor heel wat meer dan alleen tekstdocumenten wordt gebruikt lijkt het me beter om de brede omschrijving van Taka te gebruiken. Mrbartjens 29 mei 2006 23:39 (CEST)

Het is prima mogelijk om HTML procedureel met SAX te verwerken in plaats van object-georienteerd met het DOM. Het is echter heel erg onpraktisch voor browsers aangezien de hele pagina dan overnieuw moet worden verwerkt als je elementen of attributen verandert (met bv. JavaScript). Maar als je een HTML pagina wilt parsen in je PHP script dan werkt SAX een stuk sneller. Maar ik bedoelde het vooral als voorbeeld dat je HTML en DOM echt volledig los van elkaar moet zien omdat het DOM gewoon een manier is om HTML te verwerken, wat dus ook op andere manieren kan. Cepheus 27 mei 2006 21:24 (CEST)

Het leren van HTML

Ik heb de handleidingen om HTML te leren bij de externe links en de box aan de rechterkant weggehaald. Afgezien van het feit dat er net iemand zijn site bij begon te zetten, lijkt me dit ook niet de plek om HTML te leren. Zoals bekend dient dit een encyclopedisch artikel te zijn en gezien de aard van het onderwerp is er een weelde van informatie te vinden elders op het internet. - Simeon 14 jun 2007 21:05 (CEST)

Opbouw van een HTML-document

Er staat nu: "Een correct HTML-document bestaat meestal naast deze declaratie uit één html-element". Ik zou dat woord 'meestal' weg willen halen, tenzij iemand nu heel hard gaat 'piepen'. Laurier (Overleg) 6 dec 2009 12:33 (CET)

tag = label

"een tag genoemd - er is geen goed Nederlands woord voor." Te dubieuze bewering om in wiki voor te komen. (label is er maar 1 van de vele mogelijkheden) Maar ze worden nu eenmaal "tags" genoemd, dat kan ook vermeld worden zonder de bewering dat er geen goed Nederlands woord voor zou zijn. Deze bewering haalt ook nog eens de lijn uit de tekst.– De voorgaande bijdrage werd geplaatst door 80.100.38.184 (overleg · bijdragen)

Ja, "tag" is in deze context gewoon het Nederlandse woord. --MichielDMN 🐘 (overleg) 6 jun 2013 16:51 (CEST)

Externe links aangepast

Hallo medebewerkers,

Ik heb zojuist 1 externe link(s) gewijzigd op HyperText Markup Language. Neem even een moment om mijn bewerking te beoordelen. Als u nog vragen heeft of u de bot bepaalde links of pagina's wilt laten negeren, raadpleeg dan deze eenvoudige FaQ voor meer informatie. Ik heb de volgende wijzigingen aangebracht:

• Archief https://web.archive.org/web/20070821014820/http://blog.whatwg.org/faq/ toegevoegd aan http://blog.whatwg.org/faq/

Zie de FAQ voor problemen met de bot of met het oplossen van URLs.

Groet.—InternetArchiveBot (Fouten melden) 31 jul 2017 01:11 (CEST)

Externe links aangepast

Hallo medebewerkers,

Ik heb zojuist 1 externe link(s) gewijzigd op HyperText Markup Language. Neem even een moment om mijn bewerking te beoordelen. Als u nog vragen heeft of u de bot bepaalde links of pagina's wilt laten negeren, raadpleeg dan deze eenvoudige FaQ voor meer informatie. Ik heb de volgende wijzigingen aangebracht:

• Archief https://web.archive.org/web/20070609092703/http://dig.csail.mit.edu/breadcrumbs/node/166 toegevoegd aan http://dig.csail.mit.edu/breadcrumbs/node/166

Zie de FAQ voor problemen met de bot of met het oplossen van URLs.

Groet.—InternetArchiveBot (Fouten melden) 16 aug 2017 03:05 (CEST)

Titel

De naam van dit artikel is momenteel HyperText Markup Language, maar het is veel beter bekend als de afkorting, HTML. Op de Engelse Wikipedia heet dit artikel ook zo. Is het een idee om de pagina te hernoemen naar 'HTML' en een doorverwijzing achter te laten met de naam 'HyperText Markup Language'? Luuk Steusfij (overleg) 7 jan 2019 21:32 (CET)

Het beleid is op de Nederlandse Wikipedia anders dan op de Engelse. Hier hanteren we het principe van "geen afkortingen", zie Wikipedia:Benoemen_van_een_pagina#Geen_afkortingen. Aangezien HTML een doorverwijzing is naar deze pagina, maakt dat voor de rest ook maar weinig uit. In artikels kan perfect naar HTML verwezen worden. MichielDMN 🐘 (overleg) 8 jan 2019 10:32 (CET)

Opbouw van artikel

Over de principes van html en de geschiedenis ervan staat van alles verspreid in het artikel.

• De paragraaf Toekomst lijkt mij inmiddels geschiedenis.
• Gedeelten in de paragrafen Opmaaktaal, Aanbeveling versus standaard en Geschiedenis/Toekomst geven dezelfde informatie in andere woorden, dit kan denk ik ingekort.
• De bewering dat W3C niet de "bevoegdheid (heeft) om standaarden vast te stellen" in tegenstelling tot ISO, lijkt me nogal dubieus. Wat is dat voor bevoegdheid? W3C noemt het weliswaar voorzichtigheidshalve een aanbeveling, maar schrijft ook: "W3C publishes Recommendations, which are considered Web standards". En ook een ISO-norm is in feite niet meer dan een aanbeveling; afhankelijk van het belang dat mensen en organisaties eraan hechten, wordt deze wel of niet opgevolgd. Bever (overleg) 11 mrt 2019 03:32 (CET)

Externe links aangepast

Hallo medebewerkers,

Ik heb zojuist 1 externe link(s) gewijzigd op HyperText Markup Language. Neem even een moment om mijn bewerking te beoordelen. Als u nog vragen heeft of u de bot bepaalde links of pagina's wilt laten negeren, raadpleeg dan deze eenvoudige FaQ voor meer informatie. Ik heb de volgende wijzigingen aangebracht:

• Archief https://web.archive.org/web/20050305063804/http://www.ietf.org/rfc/rfc1866.txt toegevoegd aan http://www.ietf.org/rfc/rfc1866.txt

Zie de FAQ voor problemen met de bot of met het oplossen van URLs.

Groet.—InternetArchiveBot (Fouten melden) 17 apr 2019 05:18 (CEST)

Belangrijke elementen toevoegen en bestaande elementen uitbreiden

Misschien kan er wat meer informatie kunnen bijkomen onder "Elementen". Bijvoorbeeld: Bij 'h1' ook toevoegen dat de tekst kleiner wordt elk nummer hoger. Er kunnen ook meer elementen misschien bijkomen. Videominer (overleg) 4 feb 2024 16:34 (CET)

Dat h1 etc. kleiner wordt naarmate het nummer verhoogt, is niet per se waar. Browsers doen dat standaard wel, maar dit kan met CSS wel anders worden ingesteld door een websitebouwer. Dat vermelden zou dus niet geheel correct zijn. MichielDMN 🐘 (overleg) 4 feb 2024 21:03 (CET)

Sterker nog, een user agent is niet eens verplicht om een grafische weergave van de HTML te maken. In principe bepaalt de HTML-code dan ook niet hoe iets eruit moet zien, alleen wat de structuur van een document is. –bdijkstra (overleg) 5 feb 2024 12:25 (CET)