---

.... for det er velsagtens en M$-ting - men hvorfor er den ikke tilladt, er
det fordi w3c er bagud eller er det fordi det opfattes som noget ligegyldigt
pjat?

--
Med venlig hilsen Poul Erik Jensen
www.genealog.dk www.skolekammeraten.dk
Subj. må tilføjes [1234] ved direkte svar

---

Den 05-09-05 19.24 skrev Poul Erik Jensen følgende:
> ... for det er velsagtens en M$-ting

Nemlig!

> - men hvorfor er den ikke tilladt, er
> det fordi w3c er bagud eller er det fordi det opfattes som noget ligegyldigt
> pjat?

Jeg må indrømme, at jeg ikke ved, om W3C har overvejet at medtage
ændring af rullebjælken i standarderne. Jeg håber, de har overvejet det,
og at de derefter har forkastet ideen - jeg vil blive meget ked af det,
hvis den slags skulle blive accepteret. Mest af alt fordi min browser så
ville begynde at understøtte det.

Efter min mening skal webdesigneren holde sig til at lave hjemmesider.
Han skal ikke ændre størrelse, placering eller udseende på min browser.

Men man skal selvfølgelig heller ikke være religiøs, og der er
vitterligt nogle, som godt kan lide, at rullebjælken smelter sammen med
hjemmesiden, selvom den så er sværere at finde. Løsningen kan være at
tilbyde den besøgende et alternativt stilark, som han selv kan skifte
til. Koden kan ikke validere og den virker ikke i alle browsere, men som
nævnt skal man heller ikke være religiøs. Og med et alternativt stilark,
undgår man at genere dem, der ikke bryder sig om den slags.

--
Mvh. Kim Ludvigsen
Har du fortalt din far og mor om Ludvigs Hjørne?
http://kimludvigsen.dk

---

Kim Ludvigsen skrev:

> Efter min mening skal webdesigneren holde sig til at lave
> hjemmesider. Han skal ikke ændre størrelse, placering eller
> udseende på min browser.

Jeg er principielt enig - men jeg synes dog ikke at scrollbar-
farvning er det værste der kunne slippe ind i en ny css-standard.
Operas løsning - hvor man kan slå understøttelsen af egenskaberne
fra i indstillingerne er ganske smart. Hvis Firefox skulle begynde
at understøtte scrollbar-egenskaberne, vil man givetvis også kunne
slå det fra i browseren.

> Koden kan ikke validere

- men den kan skjules for såvel validator som ikke-IE-browsere (med
en conditional comment). Det betyder dog også at nogle browsere der
ellers godt kan vise stylede scrollbars (Opera, Konqueror), ikke
får noget ud af koden.
--
Jens Gyldenkærne Clausen
Svar venligst under det du citerer, og citer kun det der er
nødvendigt for at forstå dit svar i sammenhængen. Se hvorfor og
hvordan på http://usenet.dk/netikette/citatteknik.html

---

Jens Gyldenkærne Clausen <jens@gyros.invalid> skrev:

> - men den kan skjules for såvel validator som ikke-IE-
> browsere (med en conditional comment).

Er det ikke et skråplan at komme ud i? På den måde
kan man jo blive ved med at "skjule" ting for validatoren
der ikke er helt rene i kanten - bare for at kunne kalde
sin side "valid"

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

---

Jens Gyldenkærne Clausen wrote:

>> Efter min mening skal webdesigneren holde sig til at lave
>> hjemmesider. Han skal ikke ændre størrelse, placering eller
>> udseende på min browser.
>
> Jeg er principielt enig - men jeg synes dog ikke at scrollbar-
> farvning er det værste der kunne slippe ind i en ny css-standard.

Der er jeg til gengæld dybt uenig med dig.

Scrollbaren i min browser er mit værktøj, som diverse webdesignere værsågod
har at holde nallerne fra - også på sider som tvinger mig til at bruge IE,
der som bekendt ikke kan blokere for den slags narrestreger.

Det irriterer mig grusomt, når jeg skal sidde og lede efter en scrollbar,
fordi den er blevet indfarvet, så den falder i et med siden.

--
Med venlig hilsen
Erik Ginnerskov
http://hjemmesideskolen.dk - http://ginnerskov.dk
http://html-faq.dk/

---

Erik Ginnerskov wrote:

> Det irriterer mig grusomt, når jeg skal sidde og lede efter en
> scrollbar, fordi den er blevet indfarvet, så den falder i et med
> siden.

Et andet skrækeksempel: På www.it-jobbank.dk har webmaster (direktøren)
lavet siden i bredden 1024px, men han har med noget javascript-halløj
fjernet vandret scroll. Desværre virker det script også i min FF, så jeg er
tvunget til at maksimere min browser for at få adgang til nogle funktioner,
som ligger mere end 800px fra venstre sidekant.

Jeg har prøvet at argumentere for ikke at lave det sådan, men han mener at
vide bedre.

--
Med venlig hilsen
Erik Ginnerskov
http://hjemmesideskolen.dk - http://ginnerskov.dk
http://html-faq.dk/

---

Hej Erik!
"Erik Ginnerskov" <erik@donotspammmeplease.invalid> skrev i en meddelelse
news:431cd19f$0$18638$14726298@news.sunsite.dk...
> Et andet skrækeksempel: På www.it-jobbank.dk har webmaster (direktøren)
> lavet siden i bredden 1024px, men han har med noget javascript-halløj
> fjernet vandret scroll. Desværre virker det script også i min FF, så jeg
> er
> tvunget til at maksimere min browser for at få adgang til nogle
> funktioner,
> som ligger mere end 800px fra venstre sidekant.

Siden er hermed tilføjet til min "sorte liste"! Selvom jeg satte min
skærmopløsning til 1024x768px, kunne jeg stadig ikke se hele indholdet på
den midterste kolonne - billederne af (undskyld udtrykket!) fjolset dækkede
det!

> Jeg har prøvet at argumentere for ikke at lave det sådan, men han mener at
> vide bedre.

Han ligner også den type - han ville højst sandsynligvis tage det som et
nederlag, hvis der var nogen, som kunne lære ham noget - hvilket der nok er
mange, som kan! (Ikke jeg - men mange af læserne/brugerne her kunne!)


Med venlig hilsen
--
Dennis Munding
Web-master
http://www.skovaa-munding.dk/, http://www-mundings-memorial.dk/
http://www.cantica.dk/, http://www.eds-denmark.dk/

---

Kim Ludvigsen <usenet@kimludvigsen.dk> skrev:

> Efter min mening skal webdesigneren holde sig til
> at lave hjemmesider. Han skal ikke ændre størrelse,
> placering eller udseende på min browser.

Jeg er helt af samme holdning. Det samme gælder med
tekst i statuslinien. Webdesigneren har et stort felt at
boltre sig på - hvorfor skal det så gå ud over statuslinie,
højrekliksmenu og meget andet uden for dette felt?

> med et alternativt stilark, undgår man at genere dem,
> der ikke bryder sig om den slags.

:o]

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

---

Allan Vebel skrev:

> Er det ikke et skråplan at komme ud i? På den måde
> kan man jo blive ved med at "skjule" ting for validatoren
> der ikke er helt rene i kanten - bare for at kunne kalde
> sin side "valid"

For mig afhænger det meget af hvad det er man skjuler - og hvorfor
det skjules.

Jeg har mange gange været ude for at skulle lave tilpasningskode
til IE - primært til IE5.x som jo forstår css noget anderledes end
moderne browsere, men også til IE6 i de tilfælde hvor standardkode
ikke er nok til at få ensartet visning.

Denne type "reparationskode" lægger jeg altid som en conditional
comment - af flere grunde. Først og fremmest er metoden stabil -
den er uafhængig af eventuelle opdateringer af IE (hvis man bruger
den fornuftigt), og den er uafhængig af hvilke IE-særheder andre
browsere måtte vælge at implementere.

Det giver i mine øjne en langt bedre sikkerhed for et godt resultat
i forhold til andre typer af css-hacks. Det har også den store
fordel at det kun er de browsere der har behov for reparationskoden
der skal bruge tid på at fortolke den - alle andre ser det bare som
en html-kommentar.

I forhold til validering, er det selvfølgelig også rart at man
slipper for de til tider mærkelige advarsler og fejl der kan komme
med andre css-hacks.


Sagen er lidt anderledes når det er "pyntekode" man skjuler i
stedet for reparationskode - altså fx de klassiske scrollbar-
egenskaber. Teknisk er der ingen forskel, men når det eneste formål
med at bruge gemmeteknikken er at kunne opnå en fejlfri validering,
kan man med rette argumentere for at det er en omgåelse af
reglerne.
--
Jens Gyldenkærne Clausen
Svar venligst under det du citerer, og citer kun det der er
nødvendigt for at forstå dit svar i sammenhængen. Se hvorfor og
hvordan på http://usenet.dk/netikette/citatteknik.html

---

Jens Gyldenkærne Clausen <jens@gyros.invalid> skrev:

> Jeg har mange gange været ude for at skulle lave
> tilpasningskode til IE - primært til IE5.x

Det er heller ikke der jeg vil hen - det er jo fint nok.

> Sagen er lidt anderledes når det er "pyntekode"
> man skjuler i stedet for reparationskode - altså fx
> de klassiske scrollbar-egenskaber.

Det var det jeg mente. Jeg har også set forslag til at
"gemme" ikke-valid kode i javascript. Jamen, så kan
min side "validere", siger de

> når det eneste formål med at bruge gemmeteknikken
> er at kunne opnå en fejlfri validering, kan man med
> rette argumentere for at det er en omgåelse af reglerne.

Så er vi jo helt enige.

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

---

In news:<431cc75e$0$18640$14726298@news.sunsite.dk>
Allan Vebel typed:
> Jens Gyldenkærne Clausen <jens@gyros.invalid> skrev:
>
>> når det eneste formål med at bruge gemmeteknikken
>> er at kunne opnå en fejlfri validering, kan man med
>> rette argumentere for at det er en omgåelse af reglerne.
>
> Så er vi jo helt enige.

Lidt malurt i bægret. Conditionals gør samme det som som et Script der
ud fra browsertype viser bestemte elementer på en bestemt måde, så man
"omgår" standarden for at kunne validere. Om det er pakket ind i en
kommentar som den enkelte browser selv afkoder eller i et script der
pakker speciel kode ind for hver browser er groft sagt lige galt. At
bege dele kan validere, gør ikke den samlede kode valid. Pt. betyder der
måske ikke så meget for browser addons, men tingene går rigtigt stærkt,
så hvis f.eks talesyntese ikke længere udvikles til en bestemt browser,
men til valid kode i stedet. Så bliver det et meget synligt problem, for
så holder siderne simpelthen op med at virke, også i IE.

IE får tit på ørene for at være forældet, men at bruge IE specifik kode
kan ikke være værre, end at bruge script baseret kode.

Her kan man man med rette spørge hvor validt er validt? Til det er mit
svar, at enten validerer det eller også gør det ikke.

Hvis man går op i pixelstyrrani, så må det være lige så godt at skrive
nederst på siden, denne side validerer _ikke_ fordi jeg har brugt både
et CSS hack for IE og et for OP, men ellers er det valid *html/css.

Alt andet er svindel, det mindste man kan gøre er at være ærlig om at
man snyder på vægten.

Med venlig hilsen
Johnny Winther Ronnenberg

--
Internettet er for alle!
http://80.62.61.212/webuseability/index.asp

---

"Jens Gyldenkærne Clausen" <jens@gyros.invalid> skrev i en meddelelse
news:Xns96C8F05ABC98Ajcdmfdk@gyrosmod.cybercity.dk...
> For mig afhænger det meget af hvad det er man skjuler
> - og hvorfor det skjules.

Det er dog en holdning der kan accepteres i modsætning til de eller ret
bastante meninger om hvem der "ejer" browserværktøjet )

Jeg vil dog acceptere, at når vi taler om den til vinduet tilhørende, at den
kan styres af "ejeren", men hvad med den der befinder sig i billedfladen? Er
det da ikke rimeligt at en sådan kan afstemmes farven til det øvrige der
præsenteres?

Det er meget muligt at der er nogen der foretrækker dokument-udseende à la
w3c-manual, helst uden farver - men det er da vist de færreste der er så
vindtørre )

Dertil kommer der jo meget an på det stof der præsenteres og det publikum
det målrettes til.

Nå, men der blev omtalt en metode til at komme ud over det problem - men der
var ingen der afslørede metodikken eller (link til) beskrivelsen heraf.

--
Med venlig hilsen Poul Erik Jensen
www.genealog.dk www.skolekammeraten.dk
Subj. må tilføjes [1234] ved direkte svar

---

Den 06-09-05 01.07 skrev Poul Erik Jensen følgende:

> Nå, men der blev omtalt en metode til at komme ud over det problem - men der
> var ingen der afslørede metodikken eller (link til) beskrivelsen heraf.

Hvilket problem? Hvordan man skjuler koden, så siden kan validere, eller
brugen af alternativt stilark, så kun dem der selv vælger det får
farvede rullebjælker, eller noget helt tredie som jeg har overset?

--
Mvh. Kim Ludvigsen
Læs hvorfor bliver spammerne ved med at spamme dig, og hvordan du
minimerer spammængden.
http://kimludvigsen.dk

---

"Kim Ludvigsen" <usenet@kimludvigsen.dk> skrev i en meddelelse
news:431cd892$0$170$edfadb0f@dtext02.news.tele.dk...
> Hvilket problem?

> Hvordan man skjuler koden, så siden kan validere

Ja.

> brugen af alternativt stilark, så kun dem der selv
> vælger det får farvede rullebjælker

Ja.

> eller noget helt tredie som jeg har overset?

Det tror jeg ikke.

--
Med venlig hilsen Poul Erik Jensen
www.genealog.dk www.skolekammeraten.dk
Subj. må tilføjes [1234] ved direkte svar

---

Den 06-09-05 02.01 skrev Poul Erik Jensen følgende:

>>Hvordan man skjuler koden, så siden kan validere
> Ja.

Jeg ved ikke hvordan, så det må andre hjælpe dig med.

>>brugen af alternativt stilark, så kun dem der selv
>>vælger det får farvede rullebjælker
>
> Ja.

Jeg er ved at lave noget til min hjemmeside om webredigeringsprogrammet
Nvu, og i den forbindelse har jeg samlet lidt tips og tricks, der blandt
andet inkluderer lidt om alternative stilark og den nødvendige kode.
Tipsene skulle egentlig ikke offentliggøres, før det hele er færdig, men
du kan få et smugkig:
http://kimludvigsen.dk/tips-internet-websnedker.html
Siden fjernes igen i løbet af et par dage. Den er ikke helt færdig, og
kommentarer samt forslag til flere tips er velkomne.

--
Mvh. Kim Ludvigsen
Få styr på nettrafikken med det gratis program Down2Home.
http://kimludvigsen.dk

---

Kim Ludvigsen wrote:
> Tipsene skulle egentlig ikke offentliggøres, før det hele er færdig, men
> du kan få et smugkig:
> http://kimludvigsen.dk/tips-internet-websnedker.html

De sider vil jeg glæde mig til, for jeg er netop ved at afprøve Nvu som
alternativ til Stone's WebWriter.

Mikkel

---

"Kim Ludvigsen" <usenet@kimludvigsen.dk> skrev i en meddelelse
news:431ce498$0$168$edfadb0f@dtext02.news.tele.dk...
> du kan få et smugkig:

Tak - jeg har fotograferet siderne ned på min HD

> kommentarer samt forslag til flere tips er velkomne.

For mig ser den rimelig færdig ud. Nå, ja, når man surfer lidt mangler der
sider, der formentlig ikke er færdigskrevne, men ellers ser det bestemt ud
til at være vedkommende. God beskrivelse af brugervalgt stilark.

Med doctype HTML 4.01 loose ignorerer IE også scroll-farverne - har jeg lige
konstateret.

Nvu er jo et udmærket program, men når man som jeg bruger psp og sql du'r
det jo kun til forstudier )
--
Med venlig hilsen Poul Erik Jensen
www.genealog.dk www.skolekammeraten.dk
Subj. må tilføjes [1234] ved direkte svar

---

Kim Ludvigsen skrev:

>>>Hvordan man skjuler koden, så siden kan validere

> Jeg ved ikke hvordan, så det må andre hjælpe dig med.

Du kan starte her:
<http://www.hintzmann.dk/articles/skjulecss/conditionalcomments/>
--
Jens Gyldenkærne Clausen
Svar venligst under det du citerer, og citer kun det der er
nødvendigt for at forstå dit svar i sammenhængen. Se hvorfor og
hvordan på http://usenet.dk/netikette/citatteknik.html

---

Poul Erik Jensen skrev:

> Med doctype HTML 4.01 loose ignorerer IE også scroll-farverne
> - har jeg lige konstateret.

Prøv at sætte dem på html i stedet for på body (eller også er det
omvendt). Så vidt jeg husker virker scrollbar-farverne uanset
hvilken visningsmåde siden er i, men hvor man i quirksmode skal
definere farverne på body, er det i standardmode html-elementet der
skal påvirkes.

Man kan evt. helgardere og definere for begge:

html, body{
   scrollbar-....
}
--
Jens Gyldenkærne Clausen
Svar venligst under det du citerer, og citer kun det der er
nødvendigt for at forstå dit svar i sammenhængen. Se hvorfor og
hvordan på http://usenet.dk/netikette/citatteknik.html

---

"Jens Gyldenkærne Clausen" <jens@gyros.invalid> skrev i en meddelelse
news:Xns96C971792CB48jcdmfdk@gyrosmod.cybercity.dk...
> Prøv at sætte dem på html i stedet for på body

Jo, tak, det virker )

Havde såmænd ikke skænket html-tag'et en tanke - slet ikke at det kunne
styles )

--
Med venlig hilsen Poul Erik Jensen
www.genealog.dk www.skolekammeraten.dk
Subj. må tilføjes [1234] ved direkte svar

---

Johnny Winther Ronnenberg skrev:

> Lidt malurt i bægret. Conditionals gør samme det som som et
> Script der ud fra browsertype viser bestemte elementer på en
> bestemt måde,

I princippet ja - men conditionals har flere fordele sammenlignet
med den type scripts. De er dels upåvirkede af om browseren har
slået javascript fra, og dels har man meget større sikkerhed for at
man rammer de browsere man forsøger at ramme med en conditional.

Specielt det sidste er væsentligt - et script kan aldrig vide
præcis hvilken browser der behandler scriptet. Det kan kun aflæse
userAgent og afprøve forskellige objektegenskaber.

UserAgent kan sættes helt frit af browseren, og det bruges i stor
stil til at lade non-IE-browsere foregive sig for IE.

Objekt-snifning er fint hvis det bruges for at undersøge om en
browser vitterlig understøtter en given metode, men det er meget
usikkert at bruge som browserdetektion (fx bruges document.all af
nogle til at tjekke om det er IE - men egenskaben understøttes også
af Opera m.fl.)


> så man "omgår" standarden for at kunne validere.

Som det har været nævnt før i tråden, er der to vidt forskellige
måder at bruge browserdifferentierende kode på - enten til
fejlretning eller til at skjule ikke-valid kode.

Fejlrettende kode vil ofte godt kunne valideres (et typisk eksempel
kan være en ændret angivelse af bredde til ældre IE-udgaver, der
ikke forstår boksmodellen korrekt) - men den skal stadig skjules,
sådan at det kun er de gamle IE-browsere der ser koden.


> Pt. betyder der måske ikke så meget for browser addons, men
> tingene går rigtigt stærkt, så hvis f.eks talesyntese ikke
> længere udvikles til en bestemt browser, men til valid kode i
> stedet. Så bliver det et meget synligt problem, for så holder
> siderne simpelthen op med at virke, også i IE.

Det afsnit forstår jeg ikke. Den browserdifferentiering der har
været oppe i tråden her, har ikke noget at gøre med understøttelse
af udvidede ting i html (uanset om det er fejlretning eller
specialstyling, drejer det sig kun om css - hvad talesyntese bør
være temmelig ligeglad med).


> Hvis man går op i pixelstyrrani, så må det være lige så godt
> at skrive nederst på siden, denne side validerer _ikke_ fordi
> jeg har brugt både et CSS hack for IE og et for OP, men ellers
> er det valid *html/css.

Som nævnt før - fejlrettende css-kode kan sagtens være valid kode.
Når det skjules, er det ikke fordi validatoren ikke må se koden,
men fordi koden for at virke korrekt kun skal læses af bestemte
browsere.
--
Jens Gyldenkærne Clausen
Svar venligst under det du citerer, og citer kun det der er
nødvendigt for at forstå dit svar i sammenhængen. Se hvorfor og
hvordan på http://usenet.dk/netikette/citatteknik.html

---

In news:<Xns96CB6D29FE5F9jcdmfdk@gyrosmod.dtext.news.tele.dk>
Jens Gyldenkærne Clausen typed:
> I princippet ja - men conditionals har flere fordele sammenlignet
> med den type scripts. De er dels upåvirkede af om browseren har
> slået javascript fra, og dels har man meget større sikkerhed for at
> man rammer de browsere man forsøger at ramme med en conditional.
>

Det er vi grundlæggende ret enige i og conditionals er markant bedre end
scripts fordi man kan versionere til en given browser.

> Fejlrettende kode vil ofte godt kunne valideres (et typisk eksempel
> kan være en ændret angivelse af bredde til ældre IE-udgaver, der
> ikke forstår boksmodellen korrekt) - men den skal stadig skjules,
> sådan at det kun er de gamle IE-browsere der ser koden.
>

Du har grundlæggende ret, men alligevel falder kæden af her, både i
traditionel HTML og i rene CSS løsninger placeres elementer "dynamisk"
via attributter. Hvilket betyder at elementerne ikke står i den orden de
forventes læst. En overskrift kan placeres nederst på en side og via
absolut positionering alligevel være sidens første element i en
almindelig browser. Mens det rent faktisk står nederst på siden.

>
>> Pt. betyder der måske ikke så meget for browser addons, men
>> tingene går rigtigt stærkt, så hvis f.eks talesyntese ikke
>> længere udvikles til en bestemt browser, men til valid kode i
>> stedet. Så bliver det et meget synligt problem, for så holder
>> siderne simpelthen op med at virke, også i IE.
>
> Det afsnit forstår jeg ikke. Den browserdifferentiering der har
> været oppe i tråden her, har ikke noget at gøre med understøttelse
> af udvidede ting i html (uanset om det er fejlretning eller
> specialstyling, drejer det sig kun om css - hvad talesyntese bør
> være temmelig ligeglad med).
>

Som nævnt det er her kæden falder af, for talesyntese er indtil videre
baseret på at ligge oven på på en browser (IE) ligesom nogle af de
webudviklings toolbars gør, de fleste af os her bruger. Indtil nu har IE
været udviklernes foretrukne browser og man bruger derfor IE's parser og
aflæser dokumentstrømmen som IE vil præsentere den.

Mens den næste generation som er godt på vej, understøttet af store
forskningsmidler i USA og UK, som skal kunne læse og fortolke koden uden
brug af browserne. Her vil nøglen blive valid HTML og CSS (på grund af
positionering af elementer). Denne udfordring er langt over, hvad
browserproducenterne normalt står over for, for de kan vælge at ignorere
dele af standarden eller fortolke den på sin egen måde, hvilket de så
gør.

Vi er på vej mod en brat opvågning, hvor alle vores små tricks pludselig
mister deres værdi, hvis vi skal leve af det. Af den simple grund, at vi
skal til at overholde standarder, de fleste af os ikke rigtigt forstår
eller mestrer. Lad os bare være ærlige, det er ikke et spørgsmål om,
hvor tit vi slår op i standarderne. Men det er et spørgsmål om hvorledes
vi fortolker dem. Og hvis den nuværende udvikling inden for brugbarhed
og tilgængelighed fortsætter, så er det ikke et spørgsmål om tolkning,
men udelukkende om korrekt brug. Men vi skal næppe forvente os ret meget
hjælp fra browserproducenterne. Det eneste der vil få dem til at flytte
sig er direkte lovkrav, om hvad de skal kunne og disse krav er på
vej,sammen med kravene til designere / udviklere.

Personligt syntes jeg man går for langt, men politikere der kan se
billige points i tilgængeliglighed, har det med at skippe den praktiske
realitet, når de lovgiver, nøjagtig som de gør i alle mulige andre
sammenhænge ;-(

Med venlig hilsen
Johnny Winther Ronnenberg

--
Internettet er for alle!
http://80.62.61.212/webuseability/index.asp

---

Johnny Winther Ronnenberg skrev:

> Du har grundlæggende ret, men alligevel falder kæden af her,
> både i traditionel HTML og i rene CSS løsninger placeres
> elementer "dynamisk" via attributter. Hvilket betyder at
> elementerne ikke står i den orden de forventes læst.

Jeg tror vi taler forbi hinanden nu. Når jeg taler om at
skjule/vise fejlrettende kode, er det alene css-kode der er tale
om. Og der er kun tale om justeringer - fx at ændre en bredde fra
200px til 220px eller at definere margen til 2px i stedet for 0px.
Ingen af disse justeringen påvirker den rækkefølge elementerne
bliver præsenteret i.

I øvrigt er jeg ikke enig i din præmis - altså at elementer
placeres dynamisk. Det er muligt at placere elementer dynamisk ved
at bruge positionering i css, men det er bestemt ikke
standardopførslen i hverken html eller css. Hvis man laver sin
html-kode fornuftigt, så skal den kunne læses (i en fornuftig
rækkefølge) helt uden css.


> Som nævnt det er her kæden falder af, for talesyntese er
> indtil videre baseret på at ligge oven på på en browser (IE)
> ligesom nogle af de webudviklings toolbars gør, de fleste af
> os her bruger. Indtil nu har IE været udviklernes foretrukne
> browser og man bruger derfor IE's parser og aflæser
> dokumentstrømmen som IE vil præsentere den.

Det lyder også som et rimeligt fornuftigt valg - eftersom praktisk
taget alle websider fungerer som de skal i IE, vil IE's visning
være et godt sted at starte hvis man skal tilføje talesyntese.

Jeg kan bare stadig ikke se relevansen i forhold til denne tråd -
altså hvordan fejlrettende kode placeret i conditionals eller
script-blokke kan påvirke et talemodul.


> Mens den næste generation som er godt på vej, understøttet af
> store forskningsmidler i USA og UK, som skal kunne læse og
> fortolke koden uden brug af browserne. Her vil nøglen blive
> valid HTML og CSS (på grund af positionering af elementer).

Hvis næste generation af talemodulerne ikke kan arbejde med html-
kode som den ser ud i dag (generelt ikke-valid kode), så er den
ikke ret anvendelig.
--
Jens Gyldenkærne Clausen
Svar venligst under det du citerer, og citer kun det der er
nødvendigt for at forstå dit svar i sammenhængen. Se hvorfor og
hvordan på http://usenet.dk/netikette/citatteknik.html

---

In news:<Xns96CBE01CB921Djcdmfdk@gyrosmod.cybercity.dk>
Jens Gyldenkærne Clausen typed:
> Johnny Winther Ronnenberg skrev:
>
>> Du har grundlæggende ret, men alligevel falder kæden af her,
>> både i traditionel HTML og i rene CSS løsninger placeres
>> elementer "dynamisk" via attributter. Hvilket betyder at
>> elementerne ikke står i den orden de forventes læst.
>
> Jeg tror vi taler forbi hinanden nu. Når jeg taler om at
> skjule/vise fejlrettende kode, er det alene css-kode der er tale
> om. Og der er kun tale om justeringer - fx at ændre en bredde fra
> 200px til 220px eller at definere margen til 2px i stedet for 0px.
> Ingen af disse justeringen påvirker den rækkefølge elementerne
> bliver præsenteret i.
>

Det har du ret i og pt er det specielt bredder og højder og margener der
er den hyppigste problemstilling. Set i forhold talesyntese er det intet
problem. Min indvending går først og fremmest på at koden regulært ikke
er valid.

> I øvrigt er jeg ikke enig i din præmis - altså at elementer
> placeres dynamisk. Det er muligt at placere elementer dynamisk ved
> at bruge positionering i css, men det er bestemt ikke
> standardopførslen i hverken html eller css. Hvis man laver sin
> html-kode fornuftigt, så skal den kunne læses (i en fornuftig
> rækkefølge) helt uden css.
>

Men nu er det så lige, at der mange steder anbefales div løsninger der
både i fikseret og i flydende form ændrer dokumentets logiske struktur.
Jørgen Farum har en række skabelon modeller hvor det sker for at skabe
et "moderne" 1-3-1 og 1-2-1 layout. For at det skal virke bytter man
nemlig blokkene om rent fysisk i dokumentet. Det ændrer ret væsentlig i
hvorledes dokumentet læses uden CSS, specielt ved flydende layout hvor
også sidens hoved elementer opdeles i flydende blokke.

>
>> Som nævnt det er her kæden falder af, for talesyntese er
>> indtil videre baseret på at ligge oven på på en browser (IE)
>> ligesom nogle af de webudviklings toolbars gør, de fleste af
>> os her bruger. Indtil nu har IE været udviklernes foretrukne
>> browser og man bruger derfor IE's parser og aflæser
>> dokumentstrømmen som IE vil præsentere den.
>
> Det lyder også som et rimeligt fornuftigt valg - eftersom praktisk
> taget alle websider fungerer som de skal i IE, vil IE's visning
> være et godt sted at starte hvis man skal tilføje talesyntese.
>
> Jeg kan bare stadig ikke se relevansen i forhold til denne tråd -
> altså hvordan fejlrettende kode placeret i conditionals eller
> script-blokke kan påvirke et talemodul.
>

Stadig et spørgsmål om validitet og at det næste udviklingstrin ikke
bruger browserens parser men har sin egen.

>
>> Mens den næste generation som er godt på vej, understøttet af
>> store forskningsmidler i USA og UK, som skal kunne læse og
>> fortolke koden uden brug af browserne. Her vil nøglen blive
>> valid HTML og CSS (på grund af positionering af elementer).
>
> Hvis næste generation af talemodulerne ikke kan arbejde med html-
> kode som den ser ud i dag (generelt ikke-valid kode), så er den
> ikke ret anvendelig.

Det kan vi kun være enige om. Personligt forstår jeg ikke hvorfor man
vil lægge en browser oven på en browser. Men der må være nogle
problemer, med de eksisterende programmer som er usynlige for seende
Jeg har simpelt hen ingen ide overhovedet om, hvorfor man vil lave noget
sådant. De sider jeg besøgte var ikke specielt oplysende om grundene,
måske det blot er en politisk gestus uden egentlig indhold. Politikere
bruger regelmæssigt mange penge, på ting der ikke fører nogen steder
hen, at mange interesse organisationer er med i arbejdet, er vist ingen
garanti for success.

Med venlig hilsen
Johnny Winther Ronnenberg

--
Internettet er for alle!
http://80.62.61.212/webuseability/index.asp