genest of genesteld?
David Valera
is <b> dan genesteld of genest in <p>?
--
David Valera
Sanne van den Eijnde
> Als je bijvoorbeeld kijkt naar html: <p><b>test</b></p>
>
> is <b> dan genesteld of genest in <p>?
>
Genest. Nestelen doen vogels.
Sanne
J1
*grinnik* Waar denk je dat de term vandaan komt?
J1
Sanne van den Eijnde
Ik heb geen flauw idee. *knipoog*
nest
Pronunciation: 'nest
Function: noun
Etymology: Middle English, from Old English; akin
to Old High
German nest nest, Latin nidus
Date: before 12th century
1 a : a bed or receptacle prepared by an animal
and especially a
bird for its eggs and young b : a place or
specially modified
structure serving as an abode of animals and
especially of their
immature stages <an ants' nest> c : a receptacle
resembling a
bird's nest
2 a : a place of rest, retreat, or lodging : HOME
<grown children who
have left the nest> b : DEN, HANGOUT
3 : the occupants or frequenters of a nest
4 a : a group of similar things <a nest of giant
mountains -- Helen
MacInnes> b : HOTBED 2 <a nest of rebellion>
5 : a group of objects made to fit close together
or one within
another
6 : an emplaced group of weapons
nest
Date: 13th century
intransitive senses
1 : to build or occupy a nest : settle in or as
if in a nest
2 : to fit compactly together or within one
another : EMBED
transitive senses
1 : to form a nest for
2 : to pack compactly together
3 : to form a hierarchy, series, or sequence of
with each member,
element, or set contained in or containing the
next
Sanne
Ben Muller
>Sanne van den Eijnde wrote:
>> David Valera wrote:
>>
>> > Als je bijvoorbeeld kijkt naar html: <p><b>test</b></p>
>> >
>> > is <b> dan genesteld of genest in <p>?
>>
>> Genest. Nestelen doen vogels.
>
>*grinnik* Waar denk je dat de term vandaan komt?
>
>J1
Net als "Een nest schalen". Een in elkaar passende (elkaar omvattende)
set schalen. Dit zal ongetwijfeld weer afgeleid zijn van de
gelijkvormigheid met een vogelnest maar het nesten van HTML-tag's is
m.i. analoog aan die tussenstap.
Ben.
J1
>
> > Sanne van den Eijnde wrote:
> > > David Valera wrote:
> > >
> > > > Als je bijvoorbeeld kijkt naar html: <p><b>test</b></p>
> > > >
> > > > is <b> dan genesteld of genest in <p>?
> > >
> > > Genest. Nestelen doen vogels.
> >
> > *grinnik* Waar denk je dat de term vandaan komt?
>
[snip volledige historie]
Pietje precies ;)
Wat ik dus bedoelde aan te geven is dat de betekenis van nesten,
`omvatten' van regels, waarschijnlijk (IMHO) rechtstreeks is
afgeleid van het feit dat een (vogel)nest een omvatting voor iets
is. Maar dat had jij vast ook al gezien...
J1
Ruud Harmsen
Eijnde <sa...@nl.uu.net> in nl.taal:
>> Als je bijvoorbeeld kijkt naar html: <p><b>test</b></p>
>> is <b> dan genesteld of genest in <p>?
>Genest. Nestelen doen vogels.
Ja. Goed Nederlands, bestond al lang voor de geneste if en loops en
wat al niet meer: een nest pannen: van die kampeerpannen die in elkaar
passen.
Overigens vind ik dat <b><p>test</b></p> ook gewoon goed zou moeten
zijn. In veel browsers werkt dat ook, maar officieel schijnt het fout
te zijn. Waarom niet gewoon "als het aan is blijft het aan tot het
uitgezet wordt"? Maar dat was te moeilijk om in een syntaxis te
gieten zeker.
--
Ruud Harmsen - http://utopia.knoware.nl/~rharmsen/
Dik T. Winter
> Overigens vind ik dat <b><p>test</b></p> ook gewoon goed zou moeten
> zijn. In veel browsers werkt dat ook, maar officieel schijnt het fout
> te zijn. Waarom niet gewoon "als het aan is blijft het aan tot het
> uitgezet wordt"?
We worden wel heel erg off-topic, maar goed. <xxx> betekent niet dat
"xxx" wordt aangezet. Zo betekent <p>: "dit is het begin van een
paragraaf", en niet: "hier wordt paragraaf aangezet".
--
dik t. winter, cwi, kruislaan 413, 1098 sj amsterdam, nederland, +31205924131
home: bovenover 215, 1025 jn amsterdam, nederland; http://www.cwi.nl/~dik/
Frits Zandveld
Ruud Harmsen heeft geschreven in bericht
<39f04d75...@news.knoware.nl>...
>Op Fri, 20 Oct 2000 11:58:21 +0200 schreef of citeerde Sanne van den
>Eijnde <sa...@nl.uu.net> in nl.taal:
>
>>> Als je bijvoorbeeld kijkt naar html: <p><b>test</b></p>
>>> is <b> dan genesteld of genest in <p>?
>>Genest. Nestelen doen vogels.
>
>Ja. Goed Nederlands, bestond al lang voor de geneste if en loops en
>wat al niet meer: een nest pannen: van die kampeerpannen die in elkaar
>passen.
>
>zijn. In veel browsers werkt dat ook, maar officieel schijnt het fout
>te zijn. Waarom niet gewoon "als het aan is blijft het aan tot het
>gieten zeker.
>
Als je dan <p> niet binnen <b> weer uit zet dan zijn er twee mogelijkheden.
1. <p> wordt automatisch uigezet bij einde <b>
2. <p> wordt niet automatisch uitgezet, maar dan zit je met een <\p> in een
omgeving waar dat onzin is.
We kiezen dus voor 1?
Tja, dat zou kunnen. Maar de meeste programmeurs vinden het best fijn dat de
compiler ze waarschuwt als ze iets vergeten. Vaak gaat daar een zwaardere
fout achter schuil.
Geef mij maar de verplichting om zelf te juister tijd <p> af te zetten.
Frits
Ruud Harmsen
<Dik.W...@cwi.nl> in nl.taal:
>In article <39f04d75...@news.knoware.nl> rhar...@knoware.nl (Ruud Harmsen) writes:
> > Overigens vind ik dat <b><p>test</b></p> ook gewoon goed zou moeten
> > zijn. In veel browsers werkt dat ook, maar officieel schijnt het fout
> > te zijn. Waarom niet gewoon "als het aan is blijft het aan tot het
> > uitgezet wordt"?
>
>We worden wel heel erg off-topic, maar goed. <xxx> betekent niet dat
>"xxx" wordt aangezet. Zo betekent <p>: "dit is het begin van een
>paragraaf", en niet: "hier wordt paragraaf aangezet".
Inderdaad, maar ik blijf van mening dat HTML dan veel handiger en
efficienter zou zijn geweest. Veel browsers (IE en Netscape, maar
Opera minder, die is dus stricter) interpreteren het stiekum ook wel
een beetje zo, al hoort dat officieel niet.
Maar ondanks mijn eigenwijsheid pas ik me wel aan. Gisteravond na wat
tobben vijf grote HTML-bestanden door de validator op
http://validator.w3.org/ heen weten te slepen. Trots het merkje
geplaatst. Dat is toch ook wel weer een prettig gevoel.
Maar ondanks de tientallen fouten werkten ze voor de correcties in
drie genoemde browser ook al goed, dus hoe belangrijk het allemaal is
weet ik niet.
Ruud Harmsen
Zandveld" <frits.z...@consunet.nl> in nl.taal:
>Veronderstel dat <p> slechts in een <b> omgeving gedefinieerd is.
>Als je dan <p> niet binnen <b> weer uit zet dan zijn er twee mogelijkheden.
>1. <p> wordt automatisch uigezet bij einde <b>
>2. <p> wordt niet automatisch uitgezet, maar dan zit je met een <\p> in een
>omgeving waar dat onzin is.
>
>We kiezen dus voor 1?
>Tja, dat zou kunnen. Maar de meeste programmeurs vinden het best fijn dat de
>compiler ze waarschuwt als ze iets vergeten. Vaak gaat daar een zwaardere
>fout achter schuil.
>
>Geef mij maar de verplichting om zelf te juister tijd <p> af te zetten.
Klinkt plausibel, maar kanttekeningen:
- Officieel werkt het als 1, maar in de browserpraktijk als 2. Blijkt
vrijwel nooit problemen te geven, en anders zie je het gauw genoeg.
(Maar volgens de guru's is HTML niet bedoeld om het uiterlijk aan te
geven, maar om structuur aan de betekenis te geven. O.a. daarom zijn
frames nu opeens weer af te raden, net nu ik ze een beetje snap. Ik
haak dan even af, persoonlijk).
Dat die browsers zo vergeeflijk zijn is een van de redenen waarom HTML
makkelijk te leren is: je hebt al snel iets wat er best leuk uitziet,
ook al klopt er eigenlijk niks van. Bij mij heeft die fase dus al een
jaar of drie geduurd, en is gisteren afgesloten. Ik word nu zuiver in
de leer, en moet daarvoor mijn hele website gaan na-vlooien met de
valída-tor.
- Bij <p> is de eindtag </p> nou net weer optioneel, lees ik net in de
specs van HTML4.0 (die ik nu eindelijk eens compleet op mijn computer
heb; tot nu toe ging ik uit van een paar vage cursusjes, spieken bij
anderen, en gewoon proberen). Heb ik daarvoor nou zo ijverig alle
</p>'tjes op de goede plekken zitten zetten?!
Reinier Post
>David Valera wrote:
>
>> Als je bijvoorbeeld kijkt naar html: <p><b>test</b></p>
>>
>> is <b> dan genesteld of genest in <p>?
>Genest. Nestelen doen vogels.
Was 'nesten' dat een bestaand Nederlands werkwoord, of is het
als taaltechnische term uit het Engels gekomen?
>Sanne
--
Reinier
Dik T. Winter
...
> Maar ondanks mijn eigenwijsheid pas ik me wel aan. Gisteravond na wat
> tobben vijf grote HTML-bestanden door de validator op
> http://validator.w3.org/ heen weten te slepen. Trots het merkje
> geplaatst. Dat is toch ook wel weer een prettig gevoel.
> Maar ondanks de tientallen fouten werkten ze voor de correcties in
> drie genoemde browser ook al goed, dus hoe belangrijk het allemaal is
> weet ik niet.
Het kan belangrijk zijn omdat je niet weet of toekomstige versies van de
browsers het wel doen zoals je wilt. Een bekend voorbeeld hiervan is:
<a href="filetje>
dat bij alle browsers werkte zoals je wilde; tot ze de browsers verbeterden.
Dik T. Winter
> (Maar volgens de guru's is HTML niet bedoeld om het uiterlijk aan te
> geven, maar om structuur aan de betekenis te geven. O.a. daarom zijn
> frames nu opeens weer af te raden, net nu ik ze een beetje snap. Ik
> haak dan even af, persoonlijk).
Inderdaad. Frames zijn nooit onderdeel geweest van HTML, het was een
Netscape uitbreiding.
> - Bij <p> is de eindtag </p> nou net weer optioneel, lees ik net in de
> specs van HTML4.0 (die ik nu eindelijk eens compleet op mijn computer
> heb; tot nu toe ging ik uit van een paar vage cursusjes, spieken bij
> anderen, en gewoon proberen). Heb ik daarvoor nou zo ijverig alle
> </p>'tjes op de goede plekken zitten zetten?!
Niet echt. In een volgende versie zal je vinden dat <xxx> *altijd*
gevolgd moet worden door </xxx>. Daarnaast krijg je <\xxx> die geen
afsluiter nodig heeft (XML?). Verder is het voor programma's die proberen
de structuur van je pagina te begrijpen wat moeilijk als <p> niet af
gesloten wordt met </p>. Is <p>...<p> de aanduiding van een geneste
paragraaf of een nieuwe paragraaf?
Sanne van den Eijnde
Reinier Post wrote:
Dat weet ik niet. Ik zat op mijn werk toen ik deze vraag beantwoordde en
ik had geen Nederlandse etymologische werken bij de hand.
Ik denk dat het uit het Engels komt. Dat denk ik ook gezien de vorm va
het werkwoord. In het Nederlands 'nestelen' in het Engels 'to nest'.
Groet,
Sanne
Peter Elderson
> Was 'nesten' dat een bestaand Nederlands werkwoord, of is het
> als taaltechnische term uit het Engels gekomen?
Ik ken het uitsluitend als jatw^H^H^H^Htaaltechnische term uit het
Engels: "geneste IFs".
pe
Reinier Post
>NESTEN, onz. en soms bedr. ww. Mnl. nesten en nisten (VERDAM 4, 2361):
>[...] Thans in N.-N. verouderd, men gebruikt nu altijd nestelen. Een
>nest maken. [...]
Heel mooi. We kunnen, getuige de andere reacties, nu aanvullen:
Thans opnieuw ontstaan als ontlening uit het Engels, als term in de
beschrijving van kunstmatige of natuurlijke talen, in de betekenis
'ingebed'.
--
Reinier
Peter Elderson
Uitstekend! (Afgezien van "thans", dat vind ik archaďsch.)
pe
Reinier Post
>In article <39f1b4f3...@news.knoware.nl> rhar...@knoware.nl (Ruud
>Harmsen) writes:
> > (Maar volgens de guru's is HTML niet bedoeld om het uiterlijk aan te
> > geven, maar om structuur aan de betekenis te geven. O.a. daarom zijn
> > frames nu opeens weer af te raden, net nu ik ze een beetje snap. Ik
> > haak dan even af, persoonlijk).
>
>Inderdaad. Frames zijn nooit onderdeel geweest van HTML, het was een
>Netscape uitbreiding.
<LEZING>
Netscape verzon wat, de mensen die graag een HTML-standaarden hadden
probeerden dan een nette specificatie op te schrijven die zo dicht
mogelijk in de buurt kwam van wat de Netscape-browser leek te doen.
Zo zijn ook <FRAME>s in de standaard opgenomen.
> > - Bij <p> is de eindtag </p> nou net weer optioneel, lees ik net in de
> > specs van HTML4.0 (die ik nu eindelijk eens compleet op mijn computer
> > heb;
www.w3.org heeft er inderdaad een mooie, leesbare, maar wel erg
lange specificatie van staan.
>Niet echt. In een volgende versie zal je vinden dat <xxx> *altijd*
>gevolgd moet worden door </xxx>. Daarnaast krijg je <\xxx> die geen
>afsluiter nodig heeft (XML?).
Um, niet <\xxx> maar </xxx/>. Dit is inderdaad de voornaamste stap
naar een XML-versie van HTML; zo'n versie is er al en heet XHTML.
>Verder is het voor programma's die proberen
>de structuur van je pagina te begrijpen wat moeilijk als <p> niet af
>gesloten wordt met </p>. Is <p>...<p> de aanduiding van een geneste
>paragraaf of een nieuwe paragraaf?
Er is een verschil tussen 'moeilijk' en 'onmogelijk'. De officiele
standaarddefinities van HTML hebben voor het weglaten van 'sluithaken'
zoals </p> altijd nette SGML-specificaties gegeven die precies weergaven
wanneer je waar een weggelaten </p> moet lezen. Het correct toepassen
van die regels is lastig voor schrijvers van HTML-verwerkende
software en ook voor schrijvers van HTML, maar het kan.
Lastiger is wat je moet doen met niet-HTML: iets wat lijkt op HTML maar
niet aan de regels voldoet. Bijvoorbeeld, een <p> met een </b> beeindigen
in plaats van met een </p> (wat mag) of helemaal niet (wat ook mag).
In de HTML-standaard heeft altijd gestaan dat HTML-verwerkende software
zoveel mogelijk moet proberen om niet-correcte HTML zoveel mogelijk nog
te interpreteren. In XML (en dus ook in XHTML) is dit anders: als een
document niet aan de welgevormdheidsregels voldoet moet de software
weigeren er nog wat mee te doen.
Er is nog weer een heel ander punt, namelijk dat er twee filosofieen
over de structuur van HTML-documenten naast elkaar kwamen te staan.
De Netscape-mensen en de meeste leken zagen HTML-tags als 'toggles',
dingen die eigenschappen van de tekst aan- en uitzetten. Je verwacht
dan dingen als
gewone tekst <b> vetgedrukte tekst <i> vet en schuingedrukt <i> deze
is overbodig, we waren al schuin </b> alleen nog schuingedukte tekst
<p> hee dat was een horizontale verspringing </i> weer normale tekst
De ontwerpers van standaard-HTML vinden daarentegen dat HTML-documenten,
net zoals zinnen in natuurlijke taal en zinnen in fatsoenlijke
programmeertalen, boomstructuren moeten zijn: je moet er een ontleedboom
van kunnen maken. Dit is van belang als je, jawel, geneste structuren
wilt kunnen uitdrukken. In HTML bijvoorbeeld: een tabel in een tabel
in een puntenlijst in een tabel in een puntenlijst. Je kunt dit niet doen
als je tags alleen maar eigenschappen aan en uit kunnen zetten, want dan
kun je die 'nesting' niet opschrijven.
Volgens zulke 'structurele' HTML zijn volgordes als <b> <i> </b> </i>
onmogelijk; je kunt er geen ontleedboom van tekenen. Het zal zoiets
als <b> <i> vet en schuin </i> </b> moeten worden.
Het is alleen de vraag of het dogma 'alles moet in een boom te ontleden
zijn' voor HTML wel zo'n goed idee zijn; de HTML die Jan met de editor
opschrijft voldoet er in elk geval meestal niet aan.
Dit staat technisch gezien los van het debat of HTML opmaak of inhoud
beschrijft, maar die discussie komt er altijd bij kijken.
Taalspecialisten die om ontleedboompjes roepen zijn namelijk gewend om
de structuur van een taal gescheiden te houden van de betekenis en
van de weergave. Ze vinden dat je in een HTML-document eigenlijk
alleen maar zou moeten aangeven wat de inhoudelijke elementen zijn,
waarna je in een aparte specificatie opschrijft hoe die elementen
moeten worden weergegeven. Dat is erg zinnig omdat het vaak beter
klopt met wat de auteur bedoelt; die bedoelt meestal niet 'deze tekst
moet vet', maar 'deze tekst is een definitie, en definities doe ik
vet'. Als je nu in HTML niet zou opschrijven <B>aardbeiensaus is saus
van aardbeien</B> maar in plaats daarvan <DEF>aardbeiensaus is saus
van aardbeien</DEF>, en ergens anders dat <DEF> vet moet worden
weergegeven, kun je die beslissing nog eens achteraf veranderen, of kun
je bijvoorbeeld nog eens een een lijstje laten maken van alle
definities in je documenten. Zo iets kan tegenwoordig in beperkte
mate: met een CSS-document kun je de weergave van elementen in een
HTML-document specificeren los van de HTML-documenten zelf. Maar het
feit blijft dat je in HTML niet zelf een <DEF>-tag kan definieren. In
XML kan dat wel; dat is in feite de nette manier om dit te doen.
</LEZING>
>dik t. winter, cwi, kruislaan 413, 1098 sj amsterdam, nederland, +31205924131
>home: bovenover 215, 1025 jn amsterdam, nederland; http://www.cwi.nl/~dik/
--
Reinier
David Valera
> Overigens vind ik dat <b><p>test</b></p> ook gewoon goed zou moeten
> zijn. In veel browsers werkt dat ook, maar officieel schijnt het fout
> te zijn. Waarom niet gewoon "als het aan is blijft het aan tot het
> gieten zeker.
De opvolger van HTML, XHTML laat niet goed _geneste_ structuren niet toe.
zoals je al aangeeft is het behoorlijk ingewikkeld om HTML in een syntax
te gieten. Er zijn teveel mogelijkheden en opties. XHTML is veel
stricter, en het schrijven van XHTML wordt dan veel eenvoudiger voor de
beginner.
mijn 2 centen.
--
David Valera
David Valera
> >Niet echt. In een volgende versie zal je vinden dat <xxx> *altijd*
> >gevolgd moet worden door </xxx>. Daarnaast krijg je <\xxx> die geen
> >afsluiter nodig heeft (XML?).
>
> Um, niet <\xxx> maar </xxx/>. Dit is inderdaad de voornaamste stap
> naar een XML-versie van HTML; zo'n versie is er al en heet XHTML.
laten we het houden op <xxx/> :-)
Bovenstaande element heeft geen afsluiter nodig, het mag alleen bij
_lege_ elementen.
bron: http://www.w3.org/TR/xhtml1/#diffs
<knip>
> te interpreteren. In XML (en dus ook in XHTML) is dit anders: als een
> document niet aan de welgevormdheidsregels voldoet moet de software
> weigeren er nog wat mee te doen.
Dat is het fijne van XHTML. Je hebt heel weinig regels, en dus is het
eenvoudig te leren.
<knip>
> Het is alleen de vraag of het dogma 'alles moet in een boom te ontleden
> zijn' voor HTML wel zo'n goed idee zijn; de HTML die Jan met de editor
> opschrijft voldoet er in elk geval meestal niet aan.
Het zal niet lang duren voordat je XHTML editors hebt. Je kan in ieder
geval alvast XML notepad uitproberen :-)
> Dit staat technisch gezien los van het debat of HTML opmaak of inhoud
> beschrijft, maar die discussie komt er altijd bij kijken.
HTML was bedoeld voor beschrijving van inhoud. Helaas (gelukkig?) is HTML
het tegenovergestelde geworden, een opmaaktaal waar weinig wordt
beschreven.
SGML, de metataal waar HTML uit is ontwikkeld, heeft als doel het
scheiden van opmaak en inhoud. Bij HTML is dat niet gelukt.
followup gezet naar nl.internet.www.ontwerp
--
David Valera
Ruud Harmsen
Post) in nl.taal:
>>NESTEN, onz. en soms bedr. ww. Mnl. nesten en nisten (VERDAM 4, 2361):
>>[...] Thans in N.-N. verouderd, men gebruikt nu altijd nestelen. Een
>>nest maken. [...]
>
>Heel mooi. We kunnen, getuige de andere reacties, nu aanvullen:
>
>Thans opnieuw ontstaan als ontlening uit het Engels, als term in de
>beschrijving van kunstmatige of natuurlijke talen, in de betekenis
>'ingebed'.
Wat is "thans" in dit verband? Een "nest pannen" bestond denk ik al
lang voor iemand van programmeertalen had gehoord. Ook rond 1930 werd
al gekampeerd. Hoe noemen padvinders dit eigenlijk, en sinds wanneer?
En is dat wel een Engelse ontlening?
Hebben die Babuschka-poppetjes (of hoe heten ze ook weer) in Rusland
er ook iets mee te maken?
Ruud Harmsen
Post) in nl.taal:
>>Inderdaad. Frames zijn nooit onderdeel geweest van HTML, het was een
>>Netscape uitbreiding.
>
><LEZING>
>
>Netscape verzon wat, de mensen die graag een HTML-standaarden hadden
>probeerden dan een nette specificatie op te schrijven die zo dicht
>mogelijk in de buurt kwam van wat de Netscape-browser leek te doen.
>Zo zijn ook <FRAME>s in de standaard opgenomen.
Ja, maar vervolgens weer "deprecated" gemaakt. (HTML 4.0)
Zo is ook het element <xmp> (example, waarbinnen eventuele tags niet
meer herkend worden, handig voor teksten _over_ HTML en tevens _in_
HTML) kennelijk weer fout. Geen idee wat ik dan in de plaats ervan
moet gebruiken.
Dit doet me toch een beetje denken aan de mentaliteit van Microsoft:
Als die iets invoeren, en het wordt massaal nagevolgd, dan gaan zij
(hun?!) weer over op iets anders. Zo was F3 algemeen zoeken, maar Word
heeft nu Shift-F4 (hoe verzin je het?), Ctrl-PageDown was einde
huidige pagina (hoewel Borland Ctrl-End/Home en Ctrl-PageUp/Down in
dat opzicht omwisselde), de nieuwste Word'en beginnen bij
Ctrl-PageDown te zeuren over iets met zoeken waar ik helemaal niet om
gevraagd heb. Alleen concurrentjepesten als je het mij vraagt, tegen
het gebruikersbelang in.
De HTML guru's verdenk ik niet van dezelfde opzet, maar het effect
gaat soms wel in de richting.
Ik vind FRAMESET erg handig, en helder van opzet, en of het syntaxisch
fraai is interesseert me niks. Afraden zonder een alternatief te geven
vind ik afkeurenswaardig.
>>Verder is het voor programma's die proberen
>>de structuur van je pagina te begrijpen wat moeilijk als <p> niet af
>>gesloten wordt met </p>. Is <p>...<p> de aanduiding van een geneste
>>paragraaf of een nieuwe paragraaf?
Als geneste alinea's (Engels paragraph en Nederlands paragrafen zijn
"faux amis"!) niet bestaan (en waar zouden die voor kunnen dienen?)
dan is het geen probleem.
>Er is nog weer een heel ander punt, namelijk dat er twee filosofieen
>over de structuur van HTML-documenten naast elkaar kwamen te staan.
>De Netscape-mensen en de meeste leken zagen HTML-tags als 'toggles',
>dingen die eigenschappen van de tekst aan- en uitzetten. Je verwacht
>dan dingen als
>
> gewone tekst <b> vetgedrukte tekst <i> vet en schuingedrukt <i> deze
> is overbodig, we waren al schuin </b> alleen nog schuingedukte tekst
> <p> hee dat was een horizontale verspringing </i> weer normale tekst
Precies. Heel slim en bruikbaar, en zo hadden ze door moeten gaan,
vind ik. Jammer dat zoveel dingen waar ik besluit fan van te worden na
een tijdje weer in de verkeerde richting moeten worden gemanouvreerd.
>De ontwerpers van standaard-HTML vinden daarentegen dat HTML-documenten,
>net zoals zinnen in natuurlijke taal en zinnen in fatsoenlijke
>programmeertalen, boomstructuren moeten zijn: je moet er een ontleedboom
>van kunnen maken.
Voor een programmeertaal handig, voor HTML onnodig.
>Dit is van belang als je, jawel, geneste structuren
>wilt kunnen uitdrukken. In HTML bijvoorbeeld: een tabel in een tabel
>in een puntenlijst in een tabel in een puntenlijst. Je kunt dit niet doen
>als je tags alleen maar eigenschappen aan en uit kunnen zetten, want dan
>kun je die 'nesting' niet opschrijven.
Volgens mij wel, en zo gebeurt het ook: <ol> en <ul> en dergelijke
(ordered list, unordered list) zetten een lijstniveau aan, doe je dat
nog eens zonder de vorige af te sluiten, dan zit je een niveau dieper.
Zo simpel als wat. Afsluiten is dan verplicht, maar je merkt gauw
genoeg als dat niet klopt: regelmatig even kijken hoe het er in de
browser uitziet.
Deze "level toggle"-opzet is ook browsertechnisch makkelijk te
interpreteren: de tag togglet niet, maar verhoogt resp. verlaagt een
niveau (in C-operatoren: ! versus ++/--).
>Volgens zulke 'structurele' HTML zijn volgordes als <b> <i> </b> </i>
>onmogelijk; je kunt er geen ontleedboom van tekenen. Het zal zoiets
>als <b> <i> vet en schuin </i> </b> moeten worden.
Academisch gemuggezift. Praktisch versus theoretisch.
>Dit staat technisch gezien los van het debat of HTML opmaak of inhoud
>beschrijft, maar die discussie komt er altijd bij kijken.
Ik hou het op opmaakstructuur: in een lijst leg ik vast welke niveau's
er zijn en welke punten, maar niet de precieze breedte van de
inspringing en de regelafstanden.
Tegelijk zie je steeds meer sites die "geoptimeerd" zijn voor een of
twee browsers, en die dan alleen goed werken met 800x600. Waar
bemoeien ze zich mee? Dat maak ik zelf wel uit.
J1
[snip]
> > gewone tekst <b> vetgedrukte tekst <i> vet en schuingedrukt
> > <i> deze is overbodig, we waren al schuin </b> alleen nog
> > schuingedukte tekst <p> hee dat was een horizontale
> > verspringing </i> weer normale tekst
>
> Precies. Heel slim en bruikbaar, en zo hadden ze door moeten
> gaan, vind ik. Jammer dat zoveel dingen waar ik besluit fan van
> te worden na een tijdje weer in de verkeerde richting moeten
> worden gemanouvreerd.
Je keert het om: oorspronkelijk was HTML een boom. Toen bedachten
allerlei mensen dat bepaalde sluit-tags voor elementen optioneel
moesten worden, wat tot gevolg had dat niemand die
sluit-elementen meer gebruikte. Dit zorgde er weer voor dat veel
mensen het als een toggle-model gingen interpreteren, terwijl
eigenlijk nog steeds het boom-model gehanteerd werd. Alleen:
omdat er geen standaard-interpretatie was, deed elke browser het
anders. In het bovenstaande voorbeeld: browser X zou bij het
lezen van de </i> kunnen besluiten dat ook de <b> is afgelopen,
een ander geeft een error, weer een andere besluit dat de bold
nog aan staat (en gaat dus tegen het parse-model in), etc.
> >De ontwerpers van standaard-HTML vinden daarentegen dat
> >HTML-documenten, net zoals zinnen in natuurlijke taal en
> >zinnen in fatsoenlijke programmeertalen, boomstructuren moeten
> >zijn: je moet er een ontleedboom van kunnen maken.
>
> Voor een programmeertaal handig, voor HTML onnodig.
Sorry, maar dat klopt niet. De reden dat voor HTML een
boomstructuur geprefereerd wordt is dat dit veel prettiger te
parsen is. De voornaamste reden dat zo'n beetje elke parser
(lees: browser) zich anders gedraagt op hetzelfde stukje HTML is
dan ook dat men later bedacht heeft dat allerlei zooi optioneel
is. Het gevolg is dat er een ambigue parse-boom onstaat.
Het is dus wel degelijk handig, _en_ nodig, om HTML documenten
als boomstructuur te interpreteren. Ambiguiteit wordt vermeden,
en er is een consensus over de interpretatie, wat weer tot gevolg
zou hebben dat elke browser dezelfde HTML pagina hetzelfde
interpreteert.
> Volgens mij wel, en zo gebeurt het ook: <ol> en <ul> en
> dergelijke (ordered list, unordered list) zetten een
> lijstniveau aan, doe je dat nog eens zonder de vorige af te
> sluiten, dan zit je een niveau dieper. Zo simpel als wat.
> Afsluiten is dan verplicht, maar je merkt gauw genoeg als dat
> niet klopt: regelmatig even kijken hoe het er in de browser
> uitziet.
Welke browser? Doen ze dat allemaal hetzelfde? Ja? Nee? Hoe weet
je dat? Hoe zit dat met andere tags die je niet afsluit? Waarom
bij <ul> wel en bij <p> niet?
[snip]
> >Volgens zulke 'structurele' HTML zijn volgordes als <b> <i>
> ></b> </i> onmogelijk; je kunt er geen ontleedboom van tekenen.
> >Het zal zoiets als <b> <i> vet en schuin </i> </b> moeten
> >worden.
>
> Academisch gemuggezift. Praktisch versus theoretisch.
Als je een standaard-taal wilt definieren, MOET je academisch
muggeziften, en niet zelf iets gaan bedenken. Het feit dat HTML
een boom representeert is gegeven, daar _mag_ je niet aan
rommelen. Klaar. Helaas is dat toch gebeurd, en dat veroorzaakt
de huidige ellende met browsers.
Maar we krijgen nog een kans: XML komt eraan. Hiep hoi.
[snip]
> Tegelijk zie je steeds meer sites die "geoptimeerd" zijn voor
> een of twee browsers, en die dan alleen goed werken met
> 800x600.
ObMuggezift: geoptimaliseerd.
> Waar bemoeien ze zich mee? Dat maak ik zelf wel uit.
In een ideale HTML standaard interpretatie wel ja.
J1
Frans E. Boone
> HTML was bedoeld voor beschrijving van inhoud. Helaas (gelukkig?) is HTML
> het tegenovergestelde geworden, een opmaaktaal waar weinig wordt
> beschreven.
>
Bij mijn weten staat HTML voor HyperText Markup Language. Dat geeft toch
duidelijk het doel als opmaaktaal weer, dunkt me. Ik weet dus niet waarop de
stelling dat HTML was bedoeld voor inhoud is gestoeld.
Het leuke is dat, vooral in het begin, her en der artikelen verschenen waar
XML werd omschreven als de vervanger van HTML. Onzin, m.i. .
Overigens heeft XML inmiddels wel zoveel functionaliteit, met zijn extensies,
dat het het "klassieke" HTML vrijwel kan vervangen. Nu de applicaties nog.
--
Frans Boone
Dik T. Winter
> Tegelijk zie je steeds meer sites die "geoptimeerd" zijn voor een of
> twee browsers, en die dan alleen goed werken met 800x600.
En die dan scrolbars uitzetten zodat je met een lagere resulutie sommige
knoppen niet meer kan zien. Zoals de bestel knop van de KLM.
--
David Valera
> David Valera wrote:
>
> > HTML was bedoeld voor beschrijving van inhoud. Helaas (gelukkig?) is HTML
> > het tegenovergestelde geworden, een opmaaktaal waar weinig wordt
> > beschreven.
> >
>
> Bij mijn weten staat HTML voor HyperText Markup Language. Dat geeft toch
> duidelijk het doel als opmaaktaal weer, dunkt me. Ik weet dus niet waarop de
> stelling dat HTML was bedoeld voor inhoud is gestoeld.
Jouw vertaling van Markup naar opmaak is niet geheel juist. Wat heeft
markup (een manier om tekst te markeren) te maken met presentatie?
> Het leuke is dat, vooral in het begin, her en der artikelen verschenen waar
> XML werd omschreven als de vervanger van HTML. Onzin, m.i. .
Je hebt gelijk, onzin. XML is een metataal, en geen taal zoals HTML. De
opvolger van HTML is officeel XHTML (zie http://www.w3c.org), welke een
XML taal is.
Je hebt wel enige tegenstrijdigheid omdat XML, net zoals SGML (de
metataal waaruit HTML is ontstaan) als doel hebben het scheiden van data
en visuele opmaak.
Er wordt nu een poging gedaan om de wildgroei van HTML tags en opties
binnen HTML een halt toe te roepen.
XML talen gebruik je voor het beschrijven van data, HTML voor de
presentatie van die data. Zo genereert de combinatie XML en XSL een HTML
pagina welke door een browser getoond kan worden.
> Overigens heeft XML inmiddels wel zoveel functionaliteit, met zijn extensies,
> dat het het "klassieke" HTML vrijwel kan vervangen. Nu de applicaties nog.
XML heeft geen extensies. De aanbeveling staat vast sinds 1998 en zal ook
zo blijven. De talen die met XML worden gedefinieerd kunnen echter wel
worden uitgebreid, maar dan op een geordende manier, niet zoals dat het
geval was bij HTML.
De XML aplicaties bestaan overigens al. Neem bijvoorbeeld WAP, die maakt
gebruik van WML, een taal volgens de XML specs.
--
David Valera
Frans E. Boone
> Frans E. Boone says...
> > Bij mijn weten staat HTML voor HyperText Markup Language. Dat geeft toch
> > duidelijk het doel als opmaaktaal weer, dunkt me. Ik weet dus niet waarop de
> > stelling dat HTML was bedoeld voor inhoud is gestoeld.
>
> Jouw vertaling van Markup naar opmaak is niet geheel juist. Wat heeft
> markup (een manier om tekst te markeren) te maken met presentatie?
Ik denk dat ik jouw formulering nu snap. De functionaliteit binnen HTML om
documentinhoud te ordenen en markeren zoals bedoeld voordat het een webnorm werd is
teloorgegaan.
nl.talisten: Het hierna volgende is puur softwaretechnisch. Boeit dat je niet, dan
heeft het geen zin om door te lezen.
> Je hebt wel enige tegenstrijdigheid omdat XML, net zoals SGML (de
> metataal waaruit HTML is ontstaan) als doel hebben het scheiden van data
> en visuele opmaak.
>
Als men XSL en CSS gaat gebruiken kan dat alsnog lukken. Helaas wil de programmeur
nog wel eens kort door de bocht gaan. :(
>
> Er wordt nu een poging gedaan om de wildgroei van HTML tags en opties
> binnen HTML een halt toe te roepen.
Is XHTML dan wel een logische stap? Ik zou zeggen dat dat het tegenovergestelde
bewerkstelligt, gezien de eerdere ervaringen. Je zou eens moeten zien welke
nachtmerries her en der gekweekt worden door het ad-hoc creeeren van
XML-oplossingen.
> XML heeft geen extensies. De aanbeveling staat vast sinds 1998 en zal ook
> zo blijven. De talen die met XML worden gedefinieerd kunnen echter wel
> worden uitgebreid, maar dan op een geordende manier, niet zoals dat het
> geval was bij HTML.
Ik doelde op XSL en CSS. Bureaucratisch gesproken geen extensies, maar
programmeertechnisch zie ik ze wel als zodanig. Hangt er gewoon vanaf hoe je ernaar
kijkt.
>
> De XML aplicaties bestaan overigens al. Neem bijvoorbeeld WAP, die maakt
> gebruik van WML, een taal volgens de XML specs.
Ze zijn er wel, maar beperkt en matig. De XML-implementatie in Office 2000 is
bijvoorbeeld matig en ook de MSIE6-implementatie krijgt veel kritiek.
Desalniettemin denk ik wel dat XML een toekomst heeft. Tegenovergesteld aan de
historie van HTML zie ik die echter eerder in intranet/extranet dan op internet.
--
Frans Boone
David Valera
> > De XML aplicaties bestaan overigens al. Neem bijvoorbeeld WAP, die maakt
> > gebruik van WML, een taal volgens de XML specs.
>
> Ze zijn er wel, maar beperkt en matig. De XML-implementatie in Office 2000 is
> bijvoorbeeld matig en ook de MSIE6-implementatie krijgt veel kritiek.
XML implementatie in Office zal waarschijnlijk in een volgende versie
goed tot zijn recht komen. Wat betreft MSIE6, het is nog niet perfect,
maar het gaat wel die kant op. De conformance van de parser die eind
oktober uit komt zal rond de 99% zijn, hopelijk 100%.
> Desalniettemin denk ik wel dat XML een toekomst heeft. Tegenovergesteld aan de
> historie van HTML zie ik die echter eerder in intranet/extranet dan op internet.
Als het aan mij ligt niet :-)
--
David Valera
Ruud Harmsen
>> >HTML-documenten, net zoals zinnen in natuurlijke taal en
>> >zinnen in fatsoenlijke programmeertalen, boomstructuren moeten
>> >zijn: je moet er een ontleedboom van kunnen maken.
Dat lukt bij natuurlijke talen al helemaal van geen kanten. Een van de
redenen dat automatische (ver)taalsystemen zo beroerd presteren. Men
pakt het principieel verkeerd aan. (Los daarvan is automatisch
vertalen ook nog ondoenlijk, maar dat is iets anders).
>> Voor een programmeertaal handig, voor HTML onnodig.
jbr...@not4mail.cs.vu.nl (J1) :
>Sorry, maar dat klopt niet. De reden dat voor HTML een
>boomstructuur geprefereerd wordt is dat dit veel prettiger te
>parsen is.
Vind ik een zwak argument. Er zijn veel meer HTML-schrijvers dan
browser-schrijvers, en de laatsten zijn ook nog handiger met
computereske zaken. Alle reden om het de HTML-schrijvers makkelijk te
maken, ook als het dat de toolbouwers iets moeilijker maakt.
Bovendien lijkt het toggle-model mij ook voor de browser-bouwer veel
makkelijker te implementeren dan een boommodel.
Ik heb zelf wel eens een beautifer gebouwd (voor een inmiddels ter
ziele gegane programmeertaal), alleen met lex, zonder yacc, en dat
ging best handig.
>> Volgens mij wel, en zo gebeurt het ook: <ol> en <ul> en
>> dergelijke (ordered list, unordered list) zetten een
>> lijstniveau aan, doe je dat nog eens zonder de vorige af te
>> sluiten, dan zit je een niveau dieper. Zo simpel als wat.
>> Afsluiten is dan verplicht, maar je merkt gauw genoeg als dat
>> niet klopt: regelmatig even kijken hoe het er in de browser
>> uitziet.
>
>Welke browser? Doen ze dat allemaal hetzelfde? Ja? Nee? Hoe weet
>je dat?
Door een paar jaar HTML te schrijven zonder ooit een fatsoenlijke
syntaxisbeschrijving gezien te hebben. (Wel naar gezocht, maar ze
hielden ze geheim of zo). Zoals ik eerder zei, op basis van
beginnerscursusjes, spieken bij anderen, en trial-en-error met drie
browsers (IE5, NN3, O3 en O4).
Pas recentelijk een paar pagina's gevalideerd, bergen fouten gevonden,
maar die browsers hadden er al die tijd totaal geen moeite mee. Ik ook
niet.
>Hoe zit dat met andere tags die je niet afsluit? Waarom
>bij <ul> wel en bij <p> niet?
Omdat geneste alinea's niet zinvol zijn, en geneste opsommingen wel.
Ik ga uit van de logica van de praktische toepassing, niet van
theoretische overwegingen. Syntaxis staat voor mij in dienst van de
semantiek, niet andersom.
>Als je een standaard-taal wilt definieren, MOET je academisch
>muggeziften, en niet zelf iets gaan bedenken.
Boomsyntaxissen (wat is eigenlijk het juiste meervoud?) zijn een goed
theoretisch onderbouwd en praktisch bruikbaar hulpmiddel, een
denkmodel. Dat betekent niet dat elke andere aanpak niet goed kan
zijn.
>Het feit dat HTML
>een boom representeert is gegeven, daar _mag_ je niet aan
>rommelen. Klaar.
Dat is een dogma. Onwetenschappelijk.
>Maar we krijgen nog een kans: XML komt eraan. Hiep hoi.
Ik vond het mooi, maar waar ik bang voor was is al gebeurd: het wordt
misbruikt, en er ontstaat een enorme wildgroei. Bij HTML kan dat
moeilijker omdat het minder flexibel is. Vandaar het grote succes van
HTML, vandaar ook dat XML een enorme rotzooi zal worden. (niet XML
zelf, maar wat er in gemaakt wordt).
Voorbeeld van misbruik: Microsoft email opgemaakt met Word2000 levert
bij elk bericht, ook van één regel, 9 kilobyte aan XML-rommel mee.
Info over fonts en opmaakprofielen.
Als iemand mij een email stuurt (ik krijg er soms 300 per dag) wil ik
NIET, herhaal: NIET weten dat de afzender, net als honderden miljoenen
anderen, ook Arial, Courier New, New Times Roman en Tahoma op zijn
computer heeft staan, en dat zhij opmaakprofielen hanteert waarvan er
diverse een inspringing vertonen met ene halve inch, en een
regelafstand van 6 punten. En toch vertelt Microsoft je dat elke keer,
straks over de hele wereld gerekend miljarden keren per dag. En daarna
gaan we weer klagen dat de lijnen zo traag zijn.
Niet de schuld van XML weliswaar, maar wel een voorbeeld van hoe het
misbruikt kan en zal worden.
David Valera
> >> >De ontwerpers van standaard-HTML vinden daarentegen dat
> >> >HTML-documenten, net zoals zinnen in natuurlijke taal en
> >> >zinnen in fatsoenlijke programmeertalen, boomstructuren moeten
> >> >zijn: je moet er een ontleedboom van kunnen maken.
>
> redenen dat automatische (ver)taalsystemen zo beroerd presteren. Men
> pakt het principieel verkeerd aan. (Los daarvan is automatisch
> vertalen ook nog ondoenlijk, maar dat is iets anders).
Het probleem is dat HTML door een browsersysteem wel getoond moet worden
op je scherm. Het maken van boomstructuren met HTML is dan bijna een
noodzaak, anders krijg je wildgroei...
> jbr...@not4mail.cs.vu.nl (J1) :
> >Sorry, maar dat klopt niet. De reden dat voor HTML een
> >boomstructuur geprefereerd wordt is dat dit veel prettiger te
> >parsen is.
>
> Vind ik een zwak argument. Er zijn veel meer HTML-schrijvers dan
> browser-schrijvers, en de laatsten zijn ook nog handiger met
> computereske zaken. Alle reden om het de HTML-schrijvers makkelijk te
> maken, ook als het dat de toolbouwers iets moeilijker maakt.
Dus HTML schrijvers mogen maar wat prutsen en toolbouwers moeten het maar
oplossen? sorry, maar als ik met een programmeertaal werk, dan heb ik een
tool die controleerd of ik de syntax wel goed gebruik. Er is geen enkele
programmeertaal die dat niet heeft.
Bij HTML had je door de vele mogelijkheden geen tools meer voor het
controleren van de syntax. De browsers die gingen echter wel mee verder,
de ene net iets anders dan de andere...
> Bovendien lijkt het toggle-model mij ook voor de browser-bouwer veel
> makkelijker te implementeren dan een boommodel.
Nee, dat kan ik je verzekeren.
> Door een paar jaar HTML te schrijven zonder ooit een fatsoenlijke
> syntaxisbeschrijving gezien te hebben. (Wel naar gezocht, maar ze
> hielden ze geheim of zo). Zoals ik eerder zei, op basis van
> beginnerscursusjes, spieken bij anderen, en trial-en-error met drie
> browsers (IE5, NN3, O3 en O4).
Dus jij schrijft HTML zonder ooit naar de beschrijving van HTML te
kijken. Je zegt dat je gezocht hebt. Blijkbaar heb je dat niet goed
gedaan want het is vrij simpel te vinden:
Het is natuurlijk leuk dat iedereen zijn eigen pagina's gaat bouwen
zonder de specs van HTML gelezen te hebben. Dat heb ik ook gedaan. Maar
op het moment dat jij gaat zeggen dat de ontwerpers van tools zich moeten
aanpassen aan jouw schrijfwijze dan maak je een fout.
> Pas recentelijk een paar pagina's gevalideerd, bergen fouten gevonden,
> maar die browsers hadden er al die tijd totaal geen moeite mee. Ik ook
> niet.
Als jij wilt dat jouw pagina over 2 jaar nog gezien kan worden door een
browser zou ik toch even de fouten eruit halen.
> >Hoe zit dat met andere tags die je niet afsluit? Waarom
> >bij <ul> wel en bij <p> niet?
>
> Omdat geneste alinea's niet zinvol zijn, en geneste opsommingen wel.
> Ik ga uit van de logica van de praktische toepassing, niet van
> theoretische overwegingen. Syntaxis staat voor mij in dienst van de
> semantiek, niet andersom.
Juist omdat de praktische toepassingen problemen geven wordt nu een
andere manier van werken voorgesteld. Eentje die veel eenvoudiger is, met
veel minder regels dan HTML maar wel veel stricter. Het is voor jezelf en
voor de browser dan veel eenvoudiger om met markup te werken.
<knip>
> >Maar we krijgen nog een kans: XML komt eraan. Hiep hoi.
>
> Ik vond het mooi, maar waar ik bang voor was is al gebeurd: het wordt
> misbruikt, en er ontstaat een enorme wildgroei. Bij HTML kan dat
> moeilijker omdat het minder flexibel is. Vandaar het grote succes van
> HTML, vandaar ook dat XML een enorme rotzooi zal worden. (niet XML
> zelf, maar wat er in gemaakt wordt).
Je moet nodig eens naar de specificaties van XML kijken.
> Voorbeeld van misbruik: Microsoft email opgemaakt met Word2000 levert
> bij elk bericht, ook van één regel, 9 kilobyte aan XML-rommel mee.
een word document met één letter wordt opgeslagen als een 19Kbyte
bestand. Een verbetering als je aan mij vraagt.
> Info over fonts en opmaakprofielen.
> Als iemand mij een email stuurt (ik krijg er soms 300 per dag) wil ik
> NIET, herhaal: NIET weten dat de afzender, net als honderden miljoenen
> anderen, ook Arial, Courier New, New Times Roman en Tahoma op zijn
> computer heeft staan, en dat zhij opmaakprofielen hanteert waarvan er
> diverse een inspringing vertonen met ene halve inch, en een
> regelafstand van 6 punten. En toch vertelt Microsoft je dat elke keer,
> straks over de hele wereld gerekend miljarden keren per dag. En daarna
> gaan we weer klagen dat de lijnen zo traag zijn.
Email ondersteunt 7 bit encoding, geen XML en/of word/html formaten, maar
dat is een andere discussie :-)
> Niet de schuld van XML weliswaar, maar wel een voorbeeld van hoe het
> misbruikt kan en zal worden.
Ik zie hier wel enige analogie tussen SGML en HTML, jij niet?
--
David Valera
Reinier Post
>> Um, niet <\xxx> maar </xxx/>. Dit is inderdaad de voornaamste stap
>> naar een XML-versie van HTML; zo'n versie is er al en heet XHTML.
>
>laten we het houden op <xxx/> :-)
>
>Bovenstaande element heeft geen afsluiter nodig, het mag alleen bij
>_lege_ elementen.
Auw, typo, excuus. Dat bedoelde ik.
>bron: http://www.w3.org/TR/xhtml1/#diffs
Dank.
>Het zal niet lang duren voordat je XHTML editors hebt. Je kan in ieder
>geval alvast XML notepad uitproberen :-)
Ik wil eigenlijk generieke XML-editors, maar goed.
>HTML was bedoeld voor beschrijving van inhoud. Helaas (gelukkig?) is HTML
>het tegenovergestelde geworden, een opmaaktaal waar weinig wordt
>beschreven.
>
>SGML, de metataal waar HTML uit is ontwikkeld, heeft als doel het
>scheiden van opmaak en inhoud. Bij HTML is dat niet gelukt.
SGMl is een taal voor bureaucraten met bergen geld;
HTML voor doe het zelvers met een toetsenbord.
>followup gezet naar nl.internet.www.ontwerp
De reden dat ik hier in nl.taal over begon was dat deze dogma's van
'geneste structuren' en 'scheiding van zinsbouw en betekenis' eigenlijk
uit de beschrijving van natuurlijke taal afkomstig zijn. Ze hebben zich
in de praktijk wel bewezen, trouwens.
>--
>David Valera
--
Reinier Post
Reinier Post
>> Het leuke is dat, vooral in het begin, her en der artikelen verschenen waar
>> XML werd omschreven als de vervanger van HTML. Onzin, m.i. .
>
>Je hebt gelijk, onzin. XML is een metataal, en geen taal zoals HTML. De
>opvolger van HTML is officeel XHTML (zie http://www.w3c.org), welke een
>XML taal is.
Nou, onzin ... HTML-gebruikers, in de eerste plaats Tim Berners-Lee zelf,
hebben vanaf het begin HTML willen gebruiken om 'semantische' markering te
doen, bijvoorbeeld door extra, applicatiespecifieke elementen toe te staan,
of speciaal voor dit doel ontworpen elementen zoals <LINK> en <META>,
of bv. met CLASS te werken. Met XML kun je dit echt goed doen.
>Je hebt wel enige tegenstrijdigheid omdat XML, net zoals SGML (de
>metataal waaruit HTML is ontstaan)
Hm. HTML is begonnen als een kort lijstje tags met de vorm van
SGML-tags. Later is er pas echte SGML van gemaakt, en dan alleen nog
in standaarden, nauwelijks in HTML-verwerkende software.
>XML talen gebruik je voor het beschrijven van data, HTML voor de
>presentatie van die data. Zo genereert de combinatie XML en XSL een HTML
>pagina welke door een browser getoond kan worden.
Je hoeft met XSL trouwens geen HTML te genereren.
>XML heeft geen extensies. De aanbeveling staat vast sinds 1998 en zal ook
>zo blijven. De talen die met XML worden gedefinieerd kunnen echter wel
>worden uitgebreid, maar dan op een geordende manier, niet zoals dat het
>geval was bij HTML.
Maar XSL is nog in ontwikkeling.
--
Reinier Post
Reinier Post
>Ik vind FRAMESET erg handig, en helder van opzet, en of het syntaxisch
>fraai is interesseert me niks. Afraden zonder een alternatief te geven
>vind ik afkeurenswaardig.
FRAMEs zijn fundamenteel rot: je kunt een verzameling frames die
op het scherm kan staan niet adresseren, en je kunt aan een FRAME
niet zien *dat* het een FRAME is, laat staan in welk document.
Er *was* al een alternatief voor frames, <OBJECT>, netjes opgeschreven
en met een werkende implementatie, voordat Netscape met zijn rotzooi
kwam aanzetten.
>>>Verder is het voor programma's die proberen
>>>de structuur van je pagina te begrijpen wat moeilijk als <p> niet af
>>>gesloten wordt met </p>. Is <p>...<p> de aanduiding van een geneste
>>>paragraaf of een nieuwe paragraaf?
>
>Als geneste alinea's (Engels paragraph en Nederlands paragrafen zijn
>"faux amis"!) niet bestaan (en waar zouden die voor kunnen dienen?)
>dan is het geen probleem.
Dat klopt, <p> en veel andere elementen kunnen dan ook niet genest worden
volgens de HTML-grammatica. Maar voor <ul>, <table>, enz. is het nodig.
>> gewone tekst <b> vetgedrukte tekst <i> vet en schuingedrukt <i> deze
>> is overbodig, we waren al schuin </b> alleen nog schuingedukte tekst
>> <p> hee dat was een horizontale verspringing </i> weer normale tekst
>
>Precies. Heel slim en bruikbaar, en zo hadden ze door moeten gaan,
>vind ik. Jammer dat zoveel dingen waar ik besluit fan van te worden na
>een tijdje weer in de verkeerde richting moeten worden gemanouvreerd.
>
>>De ontwerpers van standaard-HTML vinden daarentegen dat HTML-documenten,
>>net zoals zinnen in natuurlijke taal en zinnen in fatsoenlijke
>>programmeertalen, boomstructuren moeten zijn: je moet er een ontleedboom
>>van kunnen maken.
>
>Voor een programmeertaal handig, voor HTML onnodig.
Hier ben ik het mee eens. Overigens wordt wel eens beweerd dat
overlappende zinsdelen ook in natuurlijke taal voorkomen:
Ze hebben een ingewikkelde taal verzonnen met overlappende zinsdelen
\ \ \ | / / \ | /
\ \ +------+-------+ / +------+--------+
\ \ \ / /
\ \ +---+----] / [---------------+
\ \ \ /
\ \ \ /
\ \ \/
\ +-------+-------+
\ /
+-------+
>[...] <ol> en <ul> en dergelijke
>(ordered list, unordered list) zetten een lijstniveau aan, doe je dat
>nog eens zonder de vorige af te sluiten, dan zit je een niveau dieper.
>Zo simpel als wat.
Dit is hetzelfde als eisen dat het een boom vormt.
>Afsluiten is dan verplicht, maar je merkt gauw
>genoeg als dat niet klopt: regelmatig even kijken hoe het er in de
>browser uitziet.
Lang niet alle HTML wordt met een browser voor de neus met de hand gemaakt.
>Deze "level toggle"-opzet is ook browsertechnisch makkelijk te
>interpreteren: de tag togglet niet, maar verhoogt resp. verlaagt een
>niveau (in C-operatoren: ! versus ++/--).
Dar is waar, maar het is niet erg robuust: de gebruiker zal vaak zo'n
niveauverandering willen laten samenvallen met andere eigenschappen.
Bv. als er ergens binnen een <TABLE> of <UL> een <B> wordt aangezet
die nooit meer met </B> wordt uitgezet, is het redelijk om die </B. maar
voor het einde van het niveau (voor de </UL> resp. </TABLE> dus)
impliciet te lezen; de kans is klein dat de gebruiker de <B> werkelijk
uit het niveau door wilde laten lopen.
>>Volgens zulke 'structurele' HTML zijn volgordes als <b> <i> </b> </i>
>>onmogelijk; je kunt er geen ontleedboom van tekenen. Het zal zoiets
>>als <b> <i> vet en schuin </i> </b> moeten worden.
>
>Academisch gemuggezift. Praktisch versus theoretisch.
Niet waar, dus: het heeft consequenties voor de manier waarop je
weggelaten eindtags interpreteert.
>--
>Ruud Harmsen - http://utopia.knoware.nl/~rharmsen/
--
Reinier Post
Reinier Post
>Wat is "thans" in dit verband? Een "nest pannen" bestond denk ik al
>lang voor iemand van programmeertalen had gehoord. Ook rond 1930 werd
>al gekampeerd. Hoe noemen padvinders dit eigenlijk, en sinds wanneer?
>En is dat wel een Engelse ontlening?
Je let niet goed op. Het ging over het *werkwoord* 'nesten'.
--
Reinier
Ruud Harmsen
Post) in nl.taal:
>rhar...@knoware.nl (Ruud Harmsen) schrijft:
Maar ik denk dat dat is afgeleid van zelfstandig naamwoord "nest" in
die speciale betekenis. De vraag blijft dus wanneer "nest" in die
betekenis, en "nesten" voor het eerst in het Nederlands gesignaleerd
zijn. Voor of na de If's?
Peter Elderson
In mijn keukenkastje staan geneste pannen.
pe
Ruud Harmsen
<elde...@xs4all.nl> in nl.taal:
>> >Je let niet goed op. Het ging over het *werkwoord* 'nesten'.
>>
>> Maar ik denk dat dat is afgeleid van zelfstandig naamwoord "nest" in
>> die speciale betekenis. De vraag blijft dus wanneer "nest" in die
>> betekenis, en "nesten" voor het eerst in het Nederlands gesignaleerd
>> zijn. Voor of na de If's?
>
>In mijn keukenkastje staan geneste pannen.
Precies. En genesteld zijn of hebben die niet.
Reinier Post
Je hebt gelijk. Toch denk ik dat het 'nesten' van IFs een ontlening
uit het Engels is; ik heb het namelijk nog nooit iemand over een 'nest'
in deze betekenis zien of horen hebben, eerder dan Peter hierboven. En
al helemaal niet bij de beschrijving van (computer)taal; daarbij komt
'een nest IFs' niet voor.
>Ruud Harmsen - http://utopia.knoware.nl/~rharmsen/
--
Reinier
Peter Elderson
Je hebt helemaal gelijk, VZIW.
pe
Karel Adams
"Peter Elderson" <elde...@xs4all.nl> schreef in bericht
news:39F878FB...@xs4all.nl...
Ja ik voel het ook zo. Als ik zeg 'dat zijn dan VIER geneste lussen in uw
programma' dan proeft dat 'genest' Engels, net zoals 'printer' of
'directory' of 'CPU' of ga zo maar door...
Karel (probeert zijn code simpeler te houden).
Frans E. Boone
<trim>
> Als ik zeg 'dat zijn dan VIER geneste lussen in uw
> programma' dan proeft dat 'genest' Engels, net zoals 'printer' of
> 'directory' of 'CPU' of ga zo maar door...
>
> Karel (probeert zijn code simpeler te houden).
Wie weet komt er ooit nog een amendement op de etymologie van "zich in de nesten
werken", aangaande procedureel programmeren. :^)
--
Frans Boone
Ruud Harmsen
volgens een toggle-model had kunnen werken]
>> > gewone tekst <b> vetgedrukte tekst <i> vet en schuingedrukt
>> > <i> deze is overbodig, we waren al schuin </b> alleen nog
>> > schuingedukte tekst <p> hee dat was een horizontale
>> > verspringing </i> weer normale tekst
>>
>> Precies. Heel slim en bruikbaar, en zo hadden ze door moeten
>> gaan, vind ik. Jammer dat zoveel dingen waar ik besluit fan van
>> te worden na een tijdje weer in de verkeerde richting moeten
>> worden gemanouvreerd.
>
>Je keert het om: oorspronkelijk was HTML een boom. Toen bedachten
>allerlei mensen dat bepaalde sluit-tags voor elementen optioneel
>moesten worden, wat tot gevolg had dat niemand die
>sluit-elementen meer gebruikte. Dit zorgde er weer voor dat veel
>mensen het als een toggle-model gingen interpreteren, terwijl
>eigenlijk nog steeds het boom-model gehanteerd werd. Alleen:
>omdat er geen standaard-interpretatie was, deed elke browser het
>anders. In het bovenstaande voorbeeld: browser X zou bij het
>lezen van de </i> kunnen besluiten dat ook de <b> is afgelopen,
>een ander geeft een error, weer een andere besluit dat de bold
>nog aan staat (en gaat dus tegen het parse-model in), etc.
Ik wil nog iets aan de orde stellen om te laten zien dat HTML helaas
gewoon niet slim in elkaar zit. Hierna een stukje uit een
websitepoging van mijn inmiddels 12-jarige dochter, gemaakt door een
Word-document te saven.
Ik wil het even niet hebben over de goede of slechte kwaliteit van
door Word gegenereerde HTML-code, of over in hoeverre het hier, nu of
oorspronkelijk, om niet-standaard extensies gaat. Ook niet over de
vraag of presentatie of structuur beschreven had moeten worden.
<FONT FACE="Algerian" COLOR="#0000ff"><P>Ik hou ook wel van
</FONT><FONT FACE="Algerian" SIZE=6 COLOR="#0000ff">lezen.</P>
</FONT><FONT FACE="Algerian" COLOR="#0000ff"><P>Ik lees vooral
</FONT><FONT FACE="Algerian" SIZE=6 COLOR="#0000ff">griezel
boeken</FONT><FONT FACE="Algerian" COLOR="#0000ff"> van </FONT><FONT
FACE="Algerian" SIZE=6 COLOR="#0000ff">Paul v. Loon.</P>
De bedoeling is dat hier de tekst:
"Ik hou ook wel van lezen. Ik lees vooral griezel boeken van Paul v.
Loon." staat, met de woorden "lezen" "griezel boeken" en de
auteursnaam in een groter font. OK, slechte stijl misschien, maar dat
doet er even niet toe.
Het blijkt nu nodig elke keer de fontnaam en de kleur te herhalen,
alleen om de corpsgrootte te kunnen varieren. Met weggelaten
niet-veranderende elementen werkt het niet meer, font en kleur vallen
dan terug naar defaultwaarden.
Met een toggle-model, waarin alles wat niet genoemd wordt bij afspraak
ongewijzigd blijft, had dit veel netter, overzichtelijker en
efficienter genoteerd kunnen worden.
Dit mag dan een kinderverhaaltje zijn, dit soort HTML komt
miljardvoudig voor op het web, omdat mensen nou eenmaal iets met fonts
en groottes blijken te willen.
(Ikzelf minder, maar mensen vinden mijn site dan ook vaak lelijk,
ouderwets, saai en spartaans).
Is dit met CSS (Cascading Style Sheets) beter op te lossen? Ik heb ze
onvoldoende bestudeerd om het te beoordelen, maar ik vermoed dat ze
eenzelfde systematiek volgens als de (overigens zeer nuttige)
styles/opmaakprofielen van Word: je zet een aantal opmaakeigenschappen
bij elkaar, geeft er een naam aan, en spreekt niet de eigenschappen
zelf, maar die symbolische naam aan. Een soort opmaaksubroutines dus.
Voor het varieren van een enkele eigenschappen onder handhaving van
alle andere moet je dan, onder handhaving van het anti-toggle
boommodel, waarschijnlijk nog steeds steeds alles wat niet wijzigt
herhalen. Of zie ik dat verkeerd?
--
Reinier Post
>[uit een discussie of en waarom HTML een boomstructuur heeft, of beter
>volgens een toggle-model had kunnen werken]
><FONT FACE="Algerian" COLOR="#0000ff"><P>Ik hou ook wel van
></FONT><FONT FACE="Algerian" SIZE=6 COLOR="#0000ff">lezen.</P>
></FONT><FONT FACE="Algerian" COLOR="#0000ff"><P>Ik lees vooral
></FONT><FONT FACE="Algerian" SIZE=6 COLOR="#0000ff">griezel
>boeken</FONT><FONT FACE="Algerian" COLOR="#0000ff"> van </FONT><FONT
>FACE="Algerian" SIZE=6 COLOR="#0000ff">Paul v. Loon.</P>
[...]
Ik heb het getest en zie de grootte niet veranderen, of ik nu
de FACE opnieuw herhaal of niet.
>Het blijkt nu nodig elke keer de fontnaam en de kleur te herhalen,
>alleen om de corpsgrootte te kunnen varieren.
[...]
>Met een toggle-model, waarin alles wat niet genoemd wordt bij afspraak
>ongewijzigd blijft, had dit veel netter, overzichtelijker en
>efficienter genoteerd kunnen worden.
Of het nu wel zo werkt of niet, het is geen intrinsieke eigenschap van
een 'boomgerichte' zinsbouw. Met CSS (een andere manier om 'fonts'
in HTML aan te geven) worden eigenschappen bijvoorbeeld overgeerfd van
omsluitende componenten (al wordt hier niet de structuur van de HTML
voor gebruikt, maar de visuele structuur op het scherm).
>Is dit met CSS (Cascading Style Sheets) beter op te lossen?
Jawel, maar Netscape 4 ondersteunt dat nog maar erg gebrekkig.
>Ik heb ze
>onvoldoende bestudeerd om het te beoordelen, maar ik vermoed dat ze
>eenzelfde systematiek volgens als de (overigens zeer nuttige)
>styles/opmaakprofielen van Word: je zet een aantal opmaakeigenschappen
>bij elkaar, geeft er een naam aan, en spreekt niet de eigenschappen
>zelf, maar die symbolische naam aan. Een soort opmaaksubroutines dus.
Dat is het idee, ja. Alleen staan er geen routines in de code;
voor een dergelijke uitgebreide faciliteit moet je bij XML/XSL wezen.
>Voor het varieren van een enkele eigenschappen onder handhaving van
>alle andere moet je dan, onder handhaving van het anti-toggle
>boommodel, waarschijnlijk nog steeds steeds alles wat niet wijzigt
>herhalen. Of zie ik dat verkeerd?
Zoals ik boven al zei; dat zie je verkeerd: eigenschappen worden
overgeerfd.
Overigens, wat de relevantie voor nl.taal betreft, er zijn computertalen
die zich een stuk beter met het Nederlands laten vergelijken dan HTML ...
--
Reinier