---

http://webdesign101.dk/html5/skabelon.php

er layoutet med de nye semantiske markører
header, hgroup, section, article, nav, aside
og footer.

Hos mig ser det ud som det skal i Opera,
Safari, Firefox, Chrome og IE9. Layoutet
er ok i IE8 og IE7 (IEtester). Der er visse
problemer med skriftstørrelse i de to
sidstnævnte og i Opera, men det vender jeg evt.
tilbage til.

Visningen skal være som i figuren
http://webdesign101.dk/html5/skabelon.jpg

Jeg er meget interesseret i at høre om
layoutmæssige afvigelser fra figuren.

Jeg har nu - tror jeg - identificeret
og rettet det problem der blev rapporteret
om i mit tidligere eksperiment.

--
Jørgen Farum Jensen
http://webdesign101.dk
..

---

Jørgen Farum Jensen skrev:

> http://webdesign101.dk/html5/skabelon.php

Ser fint ud i forskellige browsere nu, tjekker lige
i en ægte IE 7 senere.

Validatoren brokker sig over:

<meta charset="iso-8859-15">

Hvorfor bruger du ikke den normale

<meta charset="iso-8859-1">?

--
Allan Vebel
http://vebel.dk | http://html-faq.dk

---

Allan Vebel skrev:

> Ser fint ud i forskellige browsere nu, tjekker lige
> i en ægte IE 7 senere.

Layoutet fungerer, men menuer skranter lidt.

Kører jeg musen over menupunkterne, bliver
undermenuen hængende.

Man kan sagtens navigere, men der ser helt
kikset ud.

Fejlen opstår kun i IE 7, alle andre steder kører
det fint.

Der kan sikkert laves et IE7-fix, når du finder
årsagen


--
Allan Vebel
http://vebel.dk | http://html-faq.dk

---

Den 22-06-2011 00:19, Allan Vebel skrev:
> Allan Vebel skrev:
>
>> Ser fint ud i forskellige browsere nu, tjekker lige
>> i en ægte IE 7 senere.
>
> Layoutet fungerer, men menuer skranter lidt.
>
> Kører jeg musen over menupunkterne, bliver
> undermenuen hængende.
>
> Man kan sagtens navigere, men der ser helt
> kikset ud.
>
> Fejlen opstår kun i IE 7, alle andre steder kører
> det fint.
>
> Der kan sikkert laves et IE7-fix, når du finder
> årsagen

Tak til Allan og alle andre for input i denne
sag.

1) Det oprindelige layoutproblemer skyldtes, at
jeg ikke havde tænkt på, at man eksplicit skal skal
sætte display-værdi på alle elementer, der er
"ukendte" i en browser, således

header, hgroup, section, article, aside, nav,
footer {display:block;}

2) Problemet med at undermenuerne hænger i IE<8
har jeg ikke kunnet løse endnu. Jeg har udviklet
lidt på denne dropdown-menu uden at teste den
ordentligt i IE<8. Tilbage til tegnebrættet.

3) Tak for inputtet omkring tegnsæt. Meget af
det går hen over hovedet på mig. Hotelplads er
noget man køber - eller får forærende, hvilket
er tilfældet for webdesign101.dk.

a)
Validatoren køber ikke hverken
<meta charset="iso-8859-1"> eller
<meta charset="iso-8859-15">
på en side på webdesign101.dk.

b)
Det gør den derimod på
http://farumjensen.dk/html5/skabelon.php
som ligger på et andet webhotel.

c)
Hvorfor ikke utf-8? Fordi jeg først i dag
har fundet ud af, at min foretrukne editor
sagtens kan gemme filer i utf-8 formatet.

Min eneste undskyldning er at jeg ligesom
alle andre forfalder til at gøre "som jeg
altid har gjort". Så er det jo rart med et
wakeup call.

PS. For HTML5/CSS3 interesserede kan jeg
anbefale "HTML5 & CSS 3 for the Real World",
http://www.sitepoint.com/books/htmlcss1/

--
Jørgen Farum Jensen
http://webdesign101.dk
..

---

On 23-06-2011 13:50, Jørgen Farum Jensen wrote:

> 1) Det oprindelige layoutproblemer skyldtes, at
> jeg ikke havde tænkt på, at man eksplicit skal skal
> sætte display-værdi på alle elementer, der er
> "ukendte" i en browser, således
>
> header, hgroup, section, article, aside, nav,
> footer {display:block;}

Fænomenet løses sikkert med tiden. Nogle browsere er klar over at nogle
af de nye tags er blok-elementer. Chrome f.eks. ved det, medens bla. FF
endnu ikke er udstyret med denne viden.

> 3) Tak for inputtet omkring tegnsæt. Meget af
> det går hen over hovedet på mig. Hotelplads er
> noget man køber - eller får forærende, hvilket
> er tilfældet for webdesign101.dk.

Jeg lavede engang denne side om at gemme rigtigt:
http://webdesign.ranunkelvej.com/tegnsaet/gem.php

Karl Erik.

---

Den 23-06-2011 15:37, Karl Erik Christensen skrev:
> On 23-06-2011 13:50, Jørgen Farum Jensen wrote:
>
>> 1) Det oprindelige layoutproblemer skyldtes, at
>> jeg ikke havde tænkt på, at man eksplicit skal skal
>> sætte display-værdi på alle elementer, der er
>> "ukendte" i en browser, således
>>
>> header, hgroup, section, article, aside, nav,
>> footer {display:block;}
>
> Fænomenet løses sikkert med tiden. Nogle browsere er klar
> over at nogle af de nye tags er blok-elementer. Chrome
> f.eks. ved det, medens bla. FF endnu ikke er udstyret med
> denne viden.

Det er nu bagud-kompatibiliteten der er det største
som vi så i mine første eksempler.

>> 3) Tak for inputtet omkring tegnsæt. Meget af
>> det går hen over hovedet på mig. Hotelplads er
>> noget man køber - eller får forærende, hvilket
>> er tilfældet for webdesign101.dk.
>
> Jeg lavede engang denne side om at gemme rigtigt:
> http://webdesign.ranunkelvej.com/tegnsaet/gem.php

Jeg husker siden, men har åbenbart ikke lagt mig
budskabet på sinde. Og som sagt - ANSI har været
godt nok i mange år.

--
Jørgen Farum Jensen
http://webdesign101.dk
..

---

On 23-06-2011 17:58, Jørgen Farum Jensen wrote:

> Det er nu bagud-kompatibiliteten der er det største
> som vi så i mine første eksempler.

Ja det er rigtigt, men tiden løser nu også mange problemer.

Jeg husker f.eks. Windows 95, som jeg installerede på en masse pc'er i
1995-97.
Når man efter installationen ville opdatere Windows, blev man mødt med
beskeden: "Din browser understøtter ikke frames"

Karl Erik.

---

On 22-06-2011 00:06, Allan Vebel wrote:
> Jørgen Farum Jensen skrev:
>
>> http://webdesign101.dk/html5/skabelon.php
>
> Ser fint ud i forskellige browsere nu, tjekker lige
> i en ægte IE 7 senere.
>
> Validatoren brokker sig over:
>
> <meta charset="iso-8859-15">
>
> Hvorfor bruger du ikke den normale
>
> <meta charset="iso-8859-1">?
>

Jørgen Farum Jensen fortæller med meta charset at dokumentet er skrevet
med iso-8859-15, men det er i virkeligheden skrevet med windows-1252.

Vigtigste forskel på 8859-1 og 8859-15 er at 8859-15 har € (euro) tegnet.

Med iso-8859-1 er der problemer med især finske og franske tegn, men det
er der ikke med 8859-15, som så til gengæld viser forkerte
spørgsmålstegn og apostroffer.

Jeg tror at fremtiden især sammen med html5, er utf-8.

Karl Erik.

---

On 22-06-2011 02:32, Karl Erik Christensen wrote:

> Jørgen Farum Jensen fortæller med meta charset at dokumentet er skrevet
> med iso-8859-15, men det er i virkeligheden skrevet med windows-1252.

Med override in effect encoding windows-1252 fås:
Tentatively (forsøgsvis) passed, 3 warning(s)

Karl Erik.

---

Karl Erik Christensen wrote:

> Jeg tror at fremtiden især sammen med html5, er utf-8.

Jeg tror fremtiden er enten utf-8 eller win-1252.

SVJH fandt Jens Peter en artikel, hvor man fremover ændrer default (iso
8859-1) til Win-1252 (sikkert i forbindelse med HTML 5).
Dvs hvor serveren ikke sender noget charset i sin header.

Utf-8 som 'wiredata' er perfekt til unicode, da det fylder mindst, men vi
skal også huske at MS bruger Utf-16, der har den fordel, at de første 256
codepoints = Win-1252 så man undgår en egentlig konvertering af encoding
(aka performancetab).

Tiden må vise hvad der sker, men historisk startede det her:
http://www.w3.org/Protocols/rfc2616/rfc2616-sec3.html#sec3.4.1
<quote>
Some HTTP/1.0 software has interpreted a Content-Type header without charset
parameter incorrectly to mean "recipient should guess."
</quote>
samt
http://www.w3.org/Protocols/rfc2616/rfc2616-sec3.html#sec3.7.1
<quote>
When no explicit charset parameter is provided by the sender, media subtypes
of the "text" type are defined to have a default charset value of
"ISO-8859-1" when received via HTTP.
</quote>

Det er sikkert ændring af diusse regler, der trigger en 'valideringsfejl'.

--
Med venlig hilsen
Stig Johansen

---

On 22-06-2011 12:07, Stig Johansen wrote:
> Karl Erik Christensen wrote:
>
>> Jeg tror at fremtiden især sammen med html5, er utf-8.
>
> Jeg tror fremtiden er enten utf-8 eller win-1252.
>
> SVJH fandt Jens Peter en artikel, hvor man fremover ændrer default (iso
> 8859-1) til Win-1252 (sikkert i forbindelse med HTML 5).
> Dvs hvor serveren ikke sender noget charset i sin header.
>
> Utf-8 som 'wiredata' er perfekt til unicode, da det fylder mindst, men vi
> skal også huske at MS bruger Utf-16, der har den fordel, at de første 256
> codepoints = Win-1252 så man undgår en egentlig konvertering af encoding
> (aka performancetab).
>
> Tiden må vise hvad der sker, men historisk startede det her:
> http://www.w3.org/Protocols/rfc2616/rfc2616-sec3.html#sec3.4.1
> <quote>
> Some HTTP/1.0 software has interpreted a Content-Type header without charset
> parameter incorrectly to mean "recipient should guess."
> </quote>

På en 100% standard Apache webserver indstillinger er der IKKE sat noget
charset overhovedet - så hvis man ikke sætter det på via enten headers
(for ajax output fx) eller meta tags, så er det browseren der gætter -
Chrome og Firefox (på Windows UK 7 med danske/engelske* browser
installations filer) bliver iso-8859-1 valgt som default kodningstype.


* Dansk = Chrome 12, engelsk = Firefox 5

---

On 22-06-2011 12:07, Stig Johansen wrote:
>
> Det er sikkert ændring af diusse regler, der trigger en 'valideringsfejl'.
>

Hej Stig.

Ikke uden grund at en engang sagde: "Det er svært at spå - især om
fremtiden"

Jeg er ikke stødt på servere der bestemmer tegnsæt endnu.
Tror dog ikke nye standarter vil bruge fallback til windows-1252, for MS
vedbliver med at tabe terræn, både browser og OS mæssigt.

Jørgen Farum Jensen har gemt sit dokument med windows-1252 encoding.
Hvis det gemmes med iso-8859-1, eller iso-8859-15 (hvilket måske ikke er
muligt i den anvendte editor), forsvinder fejlen hos W3C:

Validation Output: 1 Error

1. Warning Using windows-1252 instead of the declared encoding
iso-8859-1.

2. Error Line 5, Column 28: Internal encoding declaration
iso-8859-15 disagrees with the actual encoding of the document
(windows-1252).
<meta charset="iso-8859-15">

Karl Erik.

---

Karl Erik Christensen wrote:

> Hej Stig.
>
> Ikke uden grund at en engang sagde: "Det er svært at spå - især om
> fremtiden"
>
> Jeg er ikke stødt på servere der bestemmer tegnsæt endnu.

Jo Karl, Jørgen's gør.
<telnet session>
sj@lwork1> telnet webdesign101.dk 80
Trying 92.246.23.233...
Connected to webdesign101.dk.
Escape character is '^]'.
GET /html5/skabelon.php HTTP/1.1
Host: webdesign101.dk
Connection: close


HTTP/1.1 200 OK
Date: Wed, 22 Jun 2011 11:11:07 GMT
Server: Apache/1.3.34 (Debian) PHP/4.3.10-22
X-Powered-By: PHP/4.3.10-22
Connection: close
Transfer-Encoding: chunked
Content-Type: text/html; charset=iso-8859-1
....
</telnet session>

Dvs. Jørgen sender explicit iso-8859-1 til klienterne, og enhver anden
'meta' vil være invalid.

> Tror dog ikke nye standarter vil bruge fallback til windows-1252, for MS
> vedbliver med at tabe terræn, både browser og OS mæssigt.

Nu er det vist ikke MS specifikt som sådan, for iso-8859-1 og win-1252 er
vist meget ens.

Men bortset fra det så viser browsere det samme (dvs. mine browsere aka FF
Konqueror/IE6(+))

> 2. Error Line 5, Column 28: Internal encoding declaration
> iso-8859-15 disagrees with the actual encoding of the document
> (windows-1252).
> <meta charset="iso-8859-15">

Jeg gider ikke rigtig de forp*lede charsets mere, da det har været årsag til
adskillige grå hår de sidste 30 år

MEN forskellen skal ses i området med 'control codes', der ligger i området
0-31, og af hensyn til paritetsbit i fortiden i samme område med første bit
sat.

Dvs. 128..128+31

Browserene er ligeglade, men validatoren har åbenbart strammet op.

--
Med venlig hilsen
Stig Johansen

---

On 22-06-2011 13:54, Stig Johansen wrote:

> Jo Karl, Jørgen's gør.

Ja ok, det ser jeg nu.

Ikke for at tærske langhalm, men hvis serveren _vil_ sende iso-8859-1,
og dokumentet er encoded med windows-1252, sker der vel også en
kollision, som validatoren gør opmærksom på?

Så vidt jeg også forstår, er iso-8859-1 og windows-1252 ens, på nær de
forhold med control karakterer, som du påpeger.

Jeg mener dog at hvis dokumentet hives ind i editoren, og derefter
gemmes som iso-8859-1(15) i stedet for windows-1252, vil dette
tilfredsstille validatoren.

I linux som jeg bruger er det så nemt, for her er utf-8 standart hele
vejen i gennem. Men hvis serveren insisterer på 8859-1, skal man
selvfølgelig efterkomme dette.

Karl Erik.

---

Karl Erik Christensen wrote:

> On 22-06-2011 13:54, Stig Johansen wrote:
>
>> Jo Karl, Jørgen's gør.
>
> Ja ok, det ser jeg nu.
>
> Ikke for at tærske langhalm, men hvis serveren _vil_ sende iso-8859-1,

Ikke _vil_, men _gør_.

Det er 'Jørgens' server, så den eneste der kan forklare adfærden er Jørgen
selv.

Vi andre kan kun se resultatet.

> og dokumentet er encoded med windows-1252, sker der vel også en
> kollision, som validatoren gør opmærksom på?

Lige præcis, og det var det jeg mente med 'strammere regler' i forhold til
HTML5/Doctype/indhold.

Bemærk også at der tilsyneladende er en BOM, jfr. telnet session:
<udpluk>
de2
<!DOCTYPE html>
<html lang="da">
<head>
........
</udpluk>

Jeg har ikke lige mine værktøjer tilgængelige, så jeg ikke afgøre hvilken
BOM der er tale om.

Efter flere forsøg ser det ud som om Jørgens server returnerer:
2E 0D 0A

Så mon ikke det bare er et punktum, der driller?

> Så vidt jeg også forstår, er iso-8859-1 og windows-1252 ens, på nær de
> forhold med control karakterer, som du påpeger.

Njaaah...
Det er nok nærmere ISO 8859-15 og Win-1252, der er ens.
Det jeg (som dansker) husker mest var indførsel af Euro-tegnet, som ikke
eksisterer i iso-8859-1.

Men 'allerede' med Win95 R2, gik 'man' fra UCS-2 til UTF-16 og indførte også
eurotegnet.

> Jeg mener dog at hvis dokumentet hives ind i editoren, og derefter
> gemmes som iso-8859-1(15) i stedet for windows-1252, vil dette
> tilfredsstille validatoren.

I Windows kan man ikke angive de 'gamle' codepages, så man kan ikke afgøre
hvilken codepage, der er brugt (med mindre der er en BOM).

http://en.wikipedia.org/wiki/Byte_order_mark

> I linux som jeg bruger er det så nemt, for her er utf-8 standart hele
> vejen i gennem.

_Din_ Linux, Karl, for på min Linux er det 'singlebyte', der er standard
hele vejen igennem

Da jeg ikke henvender mig til, eller har brug for, 'eksotiske' tegnsæt, ser
jeg ingen begrundelse for at bevæge mig ud over de første 256 codepoints ;)

> Men hvis serveren insisterer på 8859-1, skal man
> selvfølgelig efterkomme dette.

Jørgens gør, og hvis Jørgen ikke kan vælge, må han naturligvis leve med
iso-8859-1.

(Hvis man ikke kan få den man elsker, må man elske den man kan få ;)

Kun Jørgen kender mulighederne for hans 'egen' server.

--
Med venlig hilsen
Stig Johansen