---

Som Rune, kunne jeg ikke slippe tanken fremsat af Kent, om at CSS er
meget bedre til at styre visningen end javascripts events.
Midt i middagsmaden slog det mig så, at selvom man ikke kan få CSS til
at aktivere AJAX og hente indholdet, er der ingen grund til ikke at
gøre begge dele. Altså styre visningen med CSS, samtidig med at
mouseover aktiverer AJAX.

Så her er den - visningen styret af CSS, og indholdet hentes af AJAX.
Det var nødvendigt med nogle ændringer.
Div'en der viser forklaringen, er stadig absolut positioneret - men den
indsættes i et link (hvor den før flød frit), og det må man vist ikke,
hvis det skal validere rigtigt - og derfor er det stadig nødvendigt at
korrigere positionen.
Der sker også et eller andet forkert, når div'en vises. Eftersom det er
CSS der faktisk viser div'en, er det ikke enkelt at detektere. Derfor
disables hentning, hvis der aktiveres samme link to gange (hvos
forklaringen har samme ord som parent).
Ellers er resten det samme, bortset fra, at tabbing gennem links ikke
længere kan vise forklaringen.

http://bbsorensen.com/test/ordbog/index_css.html

Birger

--
http://varmeretter.dk - billig, sund og hurtig mad
http://bbsorensen.dk

---

On 19 Maj, 20:52, Birger Sørensen <s...@bbsorensen.com> wrote:
> Som Rune, kunne jeg ikke slippe tanken fremsat af Kent, om at CSS er
> meget bedre til at styre visningen end javascripts events.
> Midt i middagsmaden slog det mig så, at selvom man ikke kan få CSS til
> at aktivere AJAX og hente indholdet, er der ingen grund til ikke at
> gøre begge dele. Altså styre visningen med CSS, samtidig med at
> mouseover aktiverer AJAX.
>
> Så her er den - visningen styret af CSS, og indholdet hentes af AJAX.
> Det var nødvendigt med nogle ændringer.
> Div'en der viser forklaringen, er stadig absolut positioneret - men den
> indsættes i et link (hvor den før flød frit), og det må man vist ikke,
> hvis det skal validere rigtigt - og derfor er det stadig nødvendigt at
> korrigere positionen.
> Der sker også et eller andet forkert, når div'en vises. Eftersom det er
> CSS der faktisk viser div'en, er det ikke enkelt at detektere. Derfor
> disables hentning, hvis der aktiveres samme link to gange (hvos
> forklaringen har samme ord som parent).
> Ellers er resten det samme, bortset fra, at tabbing gennem links ikke
> længere kan vise forklaringen.
>
> http://bbsorensen.com/test/ordbog/index_css.html
>
> Birger
>
> --http://varmeretter.dk- billig, sund og hurtig madhttp://bbsorensen.dk

..ord:hover > #forklaring, #forklaring:hover {
   display : block;
   }

Det er den, som sørger for popup ved hover...?

mmm.. kunne man måske indsætte f.eks. noget a la

..ord:hover > #forklaring, #forklaring:hover,.ord:focus > #forklaring,
#forklaring:focus {
   display : block;
   }

....problemet er, den følger ikke med i FF4.0 nu, når man bruger
taster. Ved brug af mus, der er den perfekt - jeg kan ikke se direkte,
det er AJAX, og ikke "in-codeing". Og fallbacken virker også
fortrintligt. Så mit spørgsmål er mere af nysgerrighed.


MVH
Rune Jensen

---

runeofdenmark@hotmail.com har bragt dette til os:
> On 19 Maj, 20:52, Birger Sørensen <s...@bbsorensen.com> wrote:
>> Som Rune, kunne jeg ikke slippe tanken fremsat af Kent, om at CSS er
>> meget bedre til at styre visningen end javascripts events.
>> Midt i middagsmaden slog det mig så, at selvom man ikke kan få CSS til
>> at aktivere AJAX og hente indholdet, er der ingen grund til ikke at
>> gøre begge dele. Altså styre visningen med CSS, samtidig med at
>> mouseover aktiverer AJAX.
>>
>> Så her er den - visningen styret af CSS, og indholdet hentes af AJAX.
>> Det var nødvendigt med nogle ændringer.
>> Div'en der viser forklaringen, er stadig absolut positioneret - men den
>> indsættes i et link (hvor den før flød frit), og det må man vist ikke,
>> hvis det skal validere rigtigt - og derfor er det stadig nødvendigt at
>> korrigere positionen.
>> Der sker også et eller andet forkert, når div'en vises. Eftersom det er
>> CSS der faktisk viser div'en, er det ikke enkelt at detektere. Derfor
>> disables hentning, hvis der aktiveres samme link to gange (hvos
>> forklaringen har samme ord som parent).
>> Ellers er resten det samme, bortset fra, at tabbing gennem links ikke
>> længere kan vise forklaringen.
>>
>> http://bbsorensen.com/test/ordbog/index_css.html
>>
>> Birger
>>
>> --http://varmeretter.dk- billig, sund og hurtig madhttp://bbsorensen.dk
>
> .ord:hover > #forklaring, #forklaring:hover {
>    display : block;
>    }
>
> Det er den, som sørger for popup ved hover...?
>
> mmm.. kunne man måske indsætte f.eks. noget a la
>
> .ord:hover > #forklaring, #forklaring:hover,.ord:focus > #forklaring,
> #forklaring:focus {
>    display : block;
>    }
>
> ...problemet er, den følger ikke med i FF4.0 nu, når man bruger
> taster. Ved brug af mus, der er den perfekt - jeg kan ikke se direkte,
> det er AJAX, og ikke "in-codeing". Og fallbacken virker også
> fortrintligt. Så mit spørgsmål er mere af nysgerrighed.


Problem solved...
Kan godt være jeg ikke havde fået opdateret online - har haft lidt bøvl
med Servage og FTP i dag...
Men den følger fint med tab i FF4 her på XP.

IE8 gør knuder.
kan ikke assigne til innerHTML - ukendt kørselsfejl. Den kender både
elementet og Teksten der assignes.
Gid fanden havde IE - eller gid han ikke havde opfundet den...

Birger

--
http://varmeretter.dk - billig, sund og hurtig mad
http://bbsorensen.dk

---

On 19 Maj, 20:52, Birger Sørensen <s...@bbsorensen.com> wrote:

> http://bbsorensen.com/test/ordbog/index_css.html

Hej, Birger... Jeg ved ikke, om du har lavet noget om, men nu ser det
ud til at virke for både mus, tastatur og skærmlæser - så vent lige
med at lave flere ændringer :)

Jeg laver lige den endelige test (håber jeg)


MVH
Rune Jensen

---

Rune Jensen formulerede torsdag:
> On 19 Maj, 20:52, Birger Sørensen <s...@bbsorensen.com> wrote:
>
>> http://bbsorensen.com/test/ordbog/index_css.html
>
> Hej, Birger... Jeg ved ikke, om du har lavet noget om, men nu ser det
> ud til at virke for både mus, tastatur og skærmlæser - så vent lige
> med at lave flere ændringer :)
>
> Jeg laver lige den endelige test (håber jeg)

Undskyld - havde ikke set din post.
Jeg lavede faktisk lige et par ændringer.
Forklaringen vises nu i en span i stedet for en div - validerer nu også
efter kørsel af js.
Rettede event handling til IE. Så nu virker det i IE8.
Selve teksten er nu blevet link til det der engang vil blive ordbogen
hos Preben.
IE8 i kompatibilitetsmode har lidt svært ved placeringen.
Den endelige udgave skal nok have
<span class="ord"><a href="...">...</a></span>
for at undgå de problemer i IE - og at selve popup'en virker som link.
Skal nok rette demoen - men det bliver ikke lige nu...

Birger

--
http://varmeretter.dk - billig, sund og hurtig mad
http://bbsorensen.dk

---

On 19 Maj, 23:18, Rune Jensen <runeofdenm...@gmail.com> wrote:

> Jeg laver lige den endelige test (håber jeg)


For observationer i Firefox med skærmlæseren Orca:
----------------------------------------------------------------------------

Mus: OK


Tastatur: Når der TABbes, læses anchor-teksten. Man får læst indholdet
af pop-uppen ved CRSR-ned. Det samme, hvis man tager det "linjevis"
eller "sætnimgsvis", så læses ordet med oplysning om, det er et link,
som man så kan få læst op ved et tastetryk.
OK


Automatisk oplæsning: Her "skaber" den sig lidt. Men jeg kan ikke se
nogen måde at afhjælpe det på. Årsagen er, at de elementer, som kan få
fokus, de får fokus under oplæsningen, efterhånden som skærmlæseren
læser teksten. Og så læser den pop-up-teksten i sammenhæng med det
egentlige indhold.

Problemet her er, man kan ikke rigtigt gøre noget ved det uden at
ødelægge det for tastaturbrugeren. Desuden, så kan man stadig nå
linksne uden pop-up-kommentar via minimum to andre genveje (bl.a. kan
man gøre det ved at cykle igennem linksne med TAB eller med anchor-
tasten), så om det er et problem... havde der været blinde her i
gruppen, ville de nok kunne fortælle det.


Umiddelbart har jeg svært ved at se, hvordan det kan gøres anderledes
- med det lille issue, og de mulige løsninger på det, der nu engang
er. Ikke alt kan jo blive perfekt, så kan man blive gammel før tid,
hvis man forsøger.


Nogle Noter:
Man kunne prøve at give ordet "client-side scripting" en lang="en".
Det lyder sjovt på dansk, men forståeligt, men jeg kunne godt tænke
mig at vide, om denne skærmlæser forstår lang.

Det er en god idé at lave overskrifter til lister, når man bruger
skærmlæser. Her kan jeg godt forstå hvad de vil i HTML5, hvor dette
netop er muligt.


MVH
Rune Jensen

---

Den 20-05-2011, skrev Rune Jensen:
> On 19 Maj, 23:18, Rune Jensen <runeofdenm...@gmail.com> wrote:
>
>> Jeg laver lige den endelige test (håber jeg)
>
>
> For observationer i Firefox med skærmlæseren Orca:
> ----------------------------------------------------------------------------
>
> Mus: OK
>
>
> Tastatur: Når der TABbes, læses anchor-teksten. Man får læst indholdet
> af pop-uppen ved CRSR-ned. Det samme, hvis man tager det "linjevis"
> eller "sætnimgsvis", så læses ordet med oplysning om, det er et link,
> som man så kan få læst op ved et tastetryk.
> OK
>
>
> Automatisk oplæsning: Her "skaber" den sig lidt. Men jeg kan ikke se
> nogen måde at afhjælpe det på. Årsagen er, at de elementer, som kan få
> fokus, de får fokus under oplæsningen, efterhånden som skærmlæseren
> læser teksten. Og så læser den pop-up-teksten i sammenhæng med det
> egentlige indhold.
>
> Problemet her er, man kan ikke rigtigt gøre noget ved det uden at
> ødelægge det for tastaturbrugeren. Desuden, så kan man stadig nå
> linksne uden pop-up-kommentar via minimum to andre genveje (bl.a. kan
> man gøre det ved at cykle igennem linksne med TAB eller med anchor-
> tasten), så om det er et problem... havde der været blinde her i
> gruppen, ville de nok kunne fortælle det.
>
>
> Umiddelbart har jeg svært ved at se, hvordan det kan gøres anderledes
> - med det lille issue, og de mulige løsninger på det, der nu engang
> er. Ikke alt kan jo blive perfekt, så kan man blive gammel før tid,
> hvis man forsøger.
>
>
> Nogle Noter:
> Man kunne prøve at give ordet "client-side scripting" en lang="en".
> Det lyder sjovt på dansk, men forståeligt, men jeg kunne godt tænke
> mig at vide, om denne skærmlæser forstår lang.
>
> Det er en god idé at lave overskrifter til lister, når man bruger
> skærmlæser. Her kan jeg godt forstå hvad de vil i HTML5, hvor dette
> netop er muligt.
>
>
> MVH
> Rune Jensen

Det ser da ellers OK ud ...
Har sat <span lang="en">clientside scripting</span> til ære for din
oplæser ^^

Og ellers - hvis ikke jeg var gråhåret i forvejen ville jeg helt klart
være blevet det, af det her... 8-o

Jeg har eksperimenteret en del (og noget af det bør nok fjernes igen..)
link til ord i ordbogen er nu lagt i en span, som bruges til at
indsætte forklaringen - og den skal indsættes, for at få CSS til at
styre visningen, men kan ikke indsættes i linket, fordi hele
forklaringen så kommer til at virke som link. Og den del af det virker
som det skal.
Tænkte, at for at besøgende, der bruger musen som pegepind, skal blive
generet mindst muligt af popops, flytter vi den over ord-elementet, så
kan både den oprindelige tekst og forklaringen læses. Også så man kan
tabbe sig gennem links, og se forklaringerne, efterhånden som man
læser.
Og også det virker efter hensigten - i FF.

Forklaringen positioneres, med disse linier:

forkl_elm.style.top = ord_element.parentNode.offsetTop -
forkl_elm.offsetHeight+'px';
forkl_elm.style.left = ord_element.parentNode.offsetLeft-15+'px';

I IE8 bliver forklaringne ikke løftet op, men godt nok flyttet de 15 px
til venstre, når man hover med musen, men den bliver det, når man
tabber sig gennem linkene!
Så forkl_elm - som er en absolut positioneret span - har ingen højde,
når man holder musen over et link, men har det, når linket er
fokuseret.
Ud over at optræde i samme script, har de to elementer intet med
hinanden at gøre.
Men det bliver sjovere endnu!
Chrome opfører sig lige modsat IE8: tabber man gennem links, vises
forklaringerne så de dækker ordet - men bruger man musen, vises de
ovenover som de skal.
Opera...
For det første, skal man åbenbart foretage sig et eller andet, for at
få lov at tabbe sig gennem links. Det kan ikke lade sig gøre her.
Men det virker ved mouseover - undtagen første gang for hvert link. Jeg
ved ikke hvad der foregår, men det er i hvert fald ikke efter hverken
standarder eller det script, der ligger på siden. Men når man først har
fået den overtalt til at gøre noget ved mouseover, gør den faktisk
rigtigt.
(Har ikke testet i Safari - har prøvet og får besked på at
geninstallere. Det er fordi der mangler et resident program, som jeg
fjerner efter installation af Safari. Jeg bruger Safari max. en gang om
måneden, så der er ingen grund til at det skal køre 10-12 timer om
dagligt. Men det er åbenbart så vigtigt for Apple at udspinoere sine
kunder, at deres programmer ikke kan køre uden. Og så må de jo lade
være med at køre...)
http://bbsorensen.com/test/ordbog/index_css_1.html
Hvis nogen skulle kunne gennemskue, hvorfor størrelsen af elementer (i
IE og Chrome) et sted i dokumentet er afhængig af hvad der sker med
andre elementer (mouseoveer eller focus) et andet sted i dokumentet,
vil en forklaring være velkommen. Jeg fatter det ikke.


I mellemtiden, har jeg så ændret positioneringen til

forkl_elm.style.top = ord_element.parentNode.offsetTop +
ord_element.parentNode.offsetHeight + 'px';
forkl_elm.style.left = ord_element.parentNode.offsetLeft - 15 + 'px';

hvilket positionerer forklaringen *under* ordet. Og det virker hele
vejen rundt (man kan stadig ikke tabbe i Opera, og man skal stadig
mouseover elementet mindst to gange, for at Opera gider reagere).
Personligt ville jeg hellere have haft forklaringen over - det er imø
meget mere brugervenligt. Men det spænde IE8 og Chrome altså ben for.
At have den under ordet, er i det mindste bedre end at den dækker ordet
- og dele af den sætning man er ved at læse.
Og i FF4, IE8 og Chrome er resultatet som forventet.
IE8 i kompatibilitetsmode, har problemer med at placere elementet i
alle tilfælde, og tabbing viser ikke popop'en.
Ved ikke hvorfor, men det er formentlig noget med at span slet ikke har
udstrækning, og måske hænger den for langt bag efter med CSS.

http://bbsorensen.com/test/ordbog/index_css.html

Birger

--
http://varmeretter.dk - billig, sund og hurtig mad
http://bbsorensen.dk

---

On 19 Maj, 23:58, Birger Sørensen <s...@bbsorensen.com> wrote:

> Undskyld - havde ikke set din post.
> Jeg lavede faktisk lige et par ændringer.
> Forklaringen vises nu i en span i stedet for en div - validerer nu også
> efter kørsel af js.
> Rettede event handling til IE. Så nu virker det i IE8.
> Selve teksten er nu blevet link til det der engang vil blive ordbogen
> hos Preben.
> IE8 i kompatibilitetsmode har lidt svært ved placeringen.
> Den endelige udgave skal nok have
> <span class="ord"><a href="...">...</a></span>
> for at undgå de problemer i IE - og at selve popup'en virker som link.
> Skal nok rette demoen - men det bliver ikke lige nu...

Nåhja, men det var jo rettelser, som skulle laves.

Desuden er der fejl i mine argumenter (mit forrige indlæg om TAB-
tasten), men foreløbig skulle selve konklusionen stadig være den
samme.

Laver lige en test mere, men jeg tror ikke, der er så meget mere at
gøre, med mindre der kommer nogen ind med forstand på skærmlæsere.


MVH
Rune Jensen

---

On 20 Maj, 00:17, Rune Jensen <runeofdenm...@gmail.com> wrote:

> Laver lige en test mere, men jeg tror ikke, der er så meget mere at
> gøre, med mindre der kommer nogen ind med forstand på skærmlæsere..

OK, lavede så den sidste test, og der er ikke ændret i konklusionen.
Tror kun der forestår evt. fejlrettelser til andre browsere. Det lader
ikke til at være det store. Der er en enkelt ting i Opera, hvor det
lader til, den først indlæser forklaringen anden gang, man hover over
et ord. Men det er sådan lidt en bagatel. Ellers virker det fint i
både Opera og Chrome, samt FF.

Jeg skriver ikke mere om det nu, med mindre der kommer mere nyt i
sagen fra anden side.


MVH
Rune Jensen

---

On 20 Maj, 17:52, Birger Sørensen <s...@bbsorensen.com> wrote:

> Opera...
> For det første, skal man åbenbart foretage sig et eller andet, for at
> få lov at tabbe sig gennem links. Det kan ikke lade sig gøre her.
> Men det virker ved mouseover - undtagen første gang for hvert link. Jeg
> ved ikke hvad der foregår, men det er i hvert fald ikke efter hverken
> standarder eller det script, der ligger på siden. Men når man først har
> fået den overtalt til at gøre noget ved mouseover, gør den faktisk
> rigtigt.

Det er heldigvis ikke stort problem. Opera er nemlig mere sofistikeret
end som så... Du bruger SHIFT+CRSR til at bevæge dig hvorsomhelst på
siden. Prøv at navigere en menu sat på lister, så vil du værdsætte
Operas måde at gøre det på. TAB mener jeg kun er til forme, men ikke
helt sikker.

Så det virker i Opera - bare, så kan popuppen altså også få fokus.. Og
det kan man næppe gøre noget ved uden at pille ved :hover, hvilket for
mig at se vil blive ret kompliceret.

Jeg synes ikke, det er noget stort problem, men man kan jo overveje
indsatsen i tid for at rette det, imod, om det er nødvendigt.. Ved
press på retur når man lander på en pop up, så virker linket
selvfølgelig ikke, så principielt bør man ikke kunne lande på en popup
(give focus). Men ... alternativt, så skriv den på "To do when feeling
like it"-listen.


MVH
Rune Jensen

---

On 20 Maj, 19:26, Rune Jensen <runeofdenm...@gmail.com> wrote:

> Det er heldigvis ikke stort problem.

OK jeg talte her om tastenavigering.

Musenavigerngen forstår jeg ikke helt, hvad den brokker sig over, men
mener at huske, at der er nogle ting, som ikke hedder det samme i
Opera som i andre i forb. med AJAX. Om det er resultatet af
Readystate, som er noget andet, eller om den trigger på 3 i stedet for
4. Det er noget i den dur.


MVH
Rune Jensen

---

Rune Jensen kom med denne ide:
> On 20 Maj, 19:26, Rune Jensen <runeofdenm...@gmail.com> wrote:
>
>> Det er heldigvis ikke stort problem.
>
> OK jeg talte her om tastenavigering.
>
> Musenavigerngen forstår jeg ikke helt, hvad den brokker sig over, men
> mener at huske, at der er nogle ting, som ikke hedder det samme i
> Opera som i andre i forb. med AJAX. Om det er resultatet af
> Readystate, som er noget andet, eller om den trigger på 3 i stedet for
> 4. Det er noget i den dur.
>
>
> MVH
> Rune Jensen

Keyboard navigering i Opera.
OK. Fikst når man ved det. Har ellers prøvet mange kombinationer med
tab...
Men det virker så der også. Ikke sikker på jeg forstår, hvorfor den
fokuserer forklarings-span'en. Må være fordi den er absolut
positioneret, for der kan absolut ingenting gøres der.
Men jeg skriver det på listen ^^ Tror nu ikke det kan klares med hover
- det har ikke rigtigt noget med focus at gøre. Måske kan man
viderdirigere focus på forklaringen (noget a.la. det en label gør), men
jeg er bange for at man riskikerer at fange brugeren i noget hyn ikke
kan komme ud af - links amn ikke kan komme videre fra.

Birger

--
http://varmeretter.dk - billig, sund og hurtig mad
http://bbsorensen.dk

---

On 20 Maj, 19:30, Rune Jensen <runeofdenm...@gmail.com> wrote:

> Musenavigerngen forstår jeg ikke helt, hvad den brokker sig over, men
> mener at huske, at der er nogle ting, som ikke hedder det samme i
> Opera som i andre i forb. med AJAX. Om det er resultatet af
> Readystate, som er noget andet, eller om den trigger på 3 i stedet for
> 4. Det er noget i den dur.

Lyder som om, den virker, når den tages fra cashe. Lidt underligt. Når
den tages fra cashen, bør retursvarret været 304 når dokumentet er
helt indlæst SVJH, og når den downloader fra selve siden, 200 OK.

Men jeg kan ikke greje den.

Tester du for 200 | 304 noget sted?

Skal lige sige, jeg er som sagt ikke ekspert. Men det at den vil hente
ved 304 og ikke ved 200, kunne måske være problemet.

Man kan nok teste ved at cleare cashen.


MVH
Rune Jensen

---

Følgende er skrevet af Rune Jensen:
> On 20 Maj, 19:30, Rune Jensen <runeofdenm...@gmail.com> wrote:
>
>> Musenavigerngen forstår jeg ikke helt, hvad den brokker sig over, men
>> mener at huske, at der er nogle ting, som ikke hedder det samme i
>> Opera som i andre i forb. med AJAX. Om det er resultatet af
>> Readystate, som er noget andet, eller om den trigger på 3 i stedet for
>> 4. Det er noget i den dur.
>
> Lyder som om, den virker, når den tages fra cashe. Lidt underligt. Når
> den tages fra cashen, bør retursvarret været 304 når dokumentet er
> helt indlæst SVJH, og når den downloader fra selve siden, 200 OK.
>
> Men jeg kan ikke greje den.
>
> Tester du for 200 | 304 noget sted?
>
> Skal lige sige, jeg er som sagt ikke ekspert. Men det at den vil hente
> ved 304 og ikke ved 200, kunne måske være problemet.
>
> Man kan nok teste ved at cleare cashen.
>
>
> MVH
> Rune Jensen

En mulighed jeg ikke havde overvejet. Men programmering har pt. slet
ikke check på status - tester kun på readystate. Og det skal helst ikke
være anderledes, end at 4 er at kommunikationen færdig, og det er det
der trigger det videre forløb. Hvis det var anderledes i Opera, ville
den aldrig komme videre - og eftersom den gør det anden gang, kan det
ikke være derfor.
Ellers skal Opera have udviklet deres eget object, der opfører sig
anderledes end de andres (og W3C recommandations, selvom det kun er
draft). Det skal jeg ikke forsværge - men man må vel antage at de vil
blive på markedet?
Der er en mulighed for at readystate change skal gøres anderledes -
skal se på det, men igen, når den gør rigtigt anden gang, er det næppe
det, der er problemet....

Birger

--
http://varmeretter.dk - billig, sund og hurtig mad
http://bbsorensen.dk

---

On 20 Maj, 21:49, Birger Sørensen <s...@bbsorensen.com> wrote:

> En mulighed jeg ikke havde overvejet. Men programmering har pt. slet
> ikke check p status - tester kun p readystate. Og det skal helst ikke
> v re anderledes, end at 4 er at kommunikationen f rdig, og det er det
> der trigger det videre forl b. Hvis det var anderledes i Opera, ville
> den aldrig komme videre - og eftersom den g r det anden gang, kan det
> ikke v re derfor.

OK. Jeg kan ikke få vist headerne i Opera. Dens muligheder for noget a
la LiveHTTPHeaders eller Tamper Data er nul.

Så...

Jeg kan se i den indbyggede netkommunikanovervåger (og den er ikke
særlig god ifht. Chromes), at der kommer en 404 på fav.icon. Under
alle omstændigheder, prøv at lave et sådant icon. Det har nok ikke
andet at sige end at så forsvinder den 404, men så er det jo klaret.

Denne netværksovervåger giver en 200 OK lige meget om forklaringen
tages fra cashen eller ej. Lidt underligt. Eller også kan jeg ikke
finde ud af at tolke HTTP headers.

Måske er du bedre til det. Prøv Menu > Side > Udviklingsværktøjer >
Opera Dragonfly.


MVH
Rune Jensen

---

On 20 Maj, 21:49, Birger Sørensen <s...@bbsorensen.com> wrote:

> En mulighed jeg ikke havde overvejet. Men programmering har pt. slet
> ikke check p status - tester kun p readystate. Og det skal helst ikke

Opfølgning...

Hvis jeg genindlæser siden, så starter det forfra med, man skal hover
over ordet to gange. Så det er ikke cashen på HDen.

Jeg ved ikke helt, hvad det betyder. Har JS en midlertidig cashe til
JS, kun for selve den aktive side?


MVH
Rune Jensen

---

Rune Jensen forklarede den 20-05-2011:
> On 20 Maj, 21:49, Birger Sørensen <s...@bbsorensen.com> wrote:
>
>> En mulighed jeg ikke havde overvejet. Men programmering har pt. slet
>> ikke check p status - tester kun p readystate. Og det skal helst ikke
>
> Opfølgning...
>
> Hvis jeg genindlæser siden, så starter det forfra med, man skal hover
> over ordet to gange. Så det er ikke cashen på HDen.
>
> Jeg ved ikke helt, hvad det betyder. Har JS en midlertidig cashe til
> JS, kun for selve den aktive side?
>
>
> MVH
> Rune Jensen

Det er et PHP script der kaldes. Så der bør ikke blive returneret andet
end 200. Selv med de samme parametre som et tidligere kald, kan svaret
være anderledes.
I øvrigt er både kald og svar ens første og efterfølgende gange - så
forskellen må ligge i JS et eller andet sted. Vist ikke første gang jeg
oplever Operas emca fortolkning som havende specielle "features"...

Der er svjv ikke nogen cashe for js.

Birger

--
http://varmeretter.dk - billig, sund og hurtig mad
http://bbsorensen.dk

---

Birger Sørensen har bragt dette til os:
> Rune Jensen forklarede den 20-05-2011:
>> On 20 Maj, 21:49, Birger Sørensen <s...@bbsorensen.com> wrote:
>>
>>> En mulighed jeg ikke havde overvejet. Men programmering har pt. slet
>>> ikke check p status - tester kun p readystate. Og det skal helst ikke
>>
>> Opfølgning...
>>
>> Hvis jeg genindlæser siden, så starter det forfra med, man skal hover
>> over ordet to gange. Så det er ikke cashen på HDen.
>>
>> Jeg ved ikke helt, hvad det betyder. Har JS en midlertidig cashe til
>> JS, kun for selve den aktive side?
>>
>>
>> MVH
>> Rune Jensen
>
> Det er et PHP script der kaldes. Så der bør ikke blive returneret andet end
> 200. Selv med de samme parametre som et tidligere kald, kan svaret være
> anderledes.
> I øvrigt er både kald og svar ens første og efterfølgende gange - så
> forskellen må ligge i JS et eller andet sted. Vist ikke første gang jeg
> oplever Operas emca fortolkning som havende specielle "features"...
>
> Der er svjv ikke nogen cashe for js.
>
> Birger

Kaldene sker rigtigt, og js gør også som det skal. Det er Operas
forståelse af absolut positionerede elementer og tilknyttede CSS, der
har et problem. Jeg har oplevet at Opera ikke gentegner absolut
positionerede som de skal. (Kan ikke huske præcist - men det står på
min liste at checke om det stadig er sådan - har vist noget omkring
det).

Birger

--
http://varmeretter.dk - billig, sund og hurtig mad
http://bbsorensen.dk

---

On 20 Maj, 22:03, Birger Sørensen <s...@bbsorensen.com> wrote:

> Men jeg skriver det p listen ^^ Tror nu ikke det kan klares med hover

Du gav mig en idé.

Opera forstår jo :not

Kan man ikke sige

..ref_ord:focus:not(:active) + #forklaring, .ord:hover #forklaring,
#forklaring:hover {
   display : block;
   }

eller

..ref_ord:focus + #forklaring:not(:focus), .ord:hover #forklaring,
#forklaring:hover {
   display : block;
   }

Det er ikke helt gennmtænkt, kun en vag idé om, det er noget i den
retning. Men jeg har brugt den før, når jeg ville adskille tingene.



MVH
Rune Jensen

---

On 20 Maj, 22:27, Birger Sørensen <s...@bbsorensen.com> wrote:

> Kaldene sker rigtigt, og js g r ogs som det skal. Det er Operas
> forst else af absolut positionerede elementer og tilknyttede CSS, der
> har et problem. Jeg har oplevet at Opera ikke gentegner absolut
> positionerede som de skal. (Kan ikke huske pr cist - men det st r p
> min liste at checke om det stadig er s dan - har vist noget omkring
> det).

Det ved jeg ikke så. Jeg er blank for idéer til løsninger.

Men jeg har en idé om, hvorfor det ikke cashes. Det må være fordi du
bruger POST i AJAX-kaldet, for POST må SVJV ikke cashes.

Men hvordan i alverden kan den så skelne imellem første og anden +
gang du bruger det?

Det lyder som en indbygget fejl, som du skriver.

Men man kan måske prøve at ændre til GET i stedet?

Man kan så risikere, at man skal til at lege lidt med at sætte
svarheaderen selv også, men ved det ikke helt.


MVH
Rune Jensen

---

Hej Birger,

"Birger Sørensen" skrev i meddelelsen...

[SNIP]

> Så her er den - visningen styret af CSS, og indholdet hentes af AJAX.
> Det var nødvendigt med nogle ændringer.
> Div'en der viser forklaringen, er stadig absolut positioneret - men den
> indsættes i et link (hvor den før flød frit), og det må man vist ikke,
> hvis det skal validere rigtigt - og derfor er det stadig nødvendigt at
> korrigere positionen.
> Der sker også et eller andet forkert, når div'en vises. Eftersom det er
> CSS der faktisk viser div'en, er det ikke enkelt at detektere. Derfor
> disables hentning, hvis der aktiveres samme link to gange (hvos
> forklaringen har samme ord som parent).
> Ellers er resten det samme, bortset fra, at tabbing gennem links ikke
> længere kan vise forklaringen.
>
> http://bbsorensen.com/test/ordbog/index_css.html

Det ser godt og funktionelt ud, men...
Vil lige give dig en lille udfordring:
Jeg ville placere boksen med den forklarende tekst til højre for ordet
istedet.
Det giver hurtig adgang til næste ord.


Med venlig hilsen
--
Dennis Munding
a.k.a. The Eye - Member of the PosseGrim Squad
http://pgsquad.com/
"When you hear the wind - you're already dead..."

---

Dennis Munding:
> Hej Birger,
>
> "Birger Sørensen" skrev i meddelelsen...
>
> [SNIP]
>
>> Så her er den - visningen styret af CSS, og indholdet hentes af AJAX.
>> Det var nødvendigt med nogle ændringer.
>> Div'en der viser forklaringen, er stadig absolut positioneret - men den
>> indsættes i et link (hvor den før flød frit), og det må man vist ikke, hvis
>> det skal validere rigtigt - og derfor er det stadig nødvendigt at korrigere
>> positionen.
>> Der sker også et eller andet forkert, når div'en vises. Eftersom det er CSS
>> der faktisk viser div'en, er det ikke enkelt at detektere. Derfor disables
>> hentning, hvis der aktiveres samme link to gange (hvos forklaringen har
>> samme ord som parent).
>> Ellers er resten det samme, bortset fra, at tabbing gennem links ikke
>> længere kan vise forklaringen.
>>
>> http://bbsorensen.com/test/ordbog/index_css.html
>
> Det ser godt og funktionelt ud, men...
> Vil lige give dig en lille udfordring:
> Jeg ville placere boksen med den forklarende tekst til højre for ordet
> istedet.
> Det giver hurtig adgang til næste ord.
>
>
> Med venlig hilsen

Det er der nu ikke meget udfordring i.
Ikke sikker på at det vil være smart heller - et smalt vindue, og et
ord sidst på linien - så er forklaringen offscreen, og man skal
scrolle. Med lidt held fjerner det så forklaringen og scrollbaren - men
så har den besøgende selvfølgelig noget at foretage sig.. :/ ^^
Jeg siger ikke, det ikke kan ske med det nuværende - men risikoen er
mindre...

Birger

--
http://varmeretter.dk - billig, sund og hurtig mad
http://bbsorensen.dk

---

"Birger Sørensen" skrev...
> Det er der nu ikke meget udfordring i.

Nu skrev jeg jo osse "en lille udfordring"...

> Ikke sikker på at det vil være smart heller - et smalt vindue, og et ord
> sidst på linien - så er forklaringen offscreen, og man skal scrolle.

Kan vi ikke meget hurtig blive enige om, at det ikke har noget med vinduets
bredde at gøre - men derimod sidens opbygning..?
Hvis du har en bred side (kant til kant) og placerer dine links helt højre,
og samtidig placerer boksene til højre for dine links, så giver det samme
effekt...
Men nu er det jo heldigvis stadig tilladt at tænke/tage skyklapperne af - så
_kunne_ man jo placere boksene til venstre istedet....!
Mit forslag var udelukkende baseret på din eksempelside...

> Med lidt held fjerner det så forklaringen og scrollbaren - men så har den
> besøgende selvfølgelig noget at foretage sig.. :/ ^^

Hvem har osse sagt, at det skal være nemt at surfe...
(Kender til flere webbureauer som gør det til en udfordring...)

> Jeg siger ikke, det ikke kan ske med det nuværende - men risikoen er
> mindre...

Risikoen for hvad??
Man styler selvfølgelig(?!) indholdet efter sidens opbygning - eller hva'?!?


Med venlig hilsen
--
Dennis Munding
a.k.a. The Eye - Member of the PosseGrim Squad
http://pgsquad.com/
"When you hear the wind - you're already dead..."

---

Dennis Munding sendte dette med sin computer:
> "Birger Sørensen" skrev...
>> Det er der nu ikke meget udfordring i.
>
> Nu skrev jeg jo osse "en lille udfordring"...
>
>> Ikke sikker på at det vil være smart heller - et smalt vindue, og et ord
>> sidst på linien - så er forklaringen offscreen, og man skal scrolle.
>
> Kan vi ikke meget hurtig blive enige om, at det ikke har noget med vinduets
> bredde at gøre - men derimod sidens opbygning..?
> Hvis du har en bred side (kant til kant) og placerer dine links helt højre,
> og samtidig placerer boksene til højre for dine links, så giver det samme
> effekt...
> Men nu er det jo heldigvis stadig tilladt at tænke/tage skyklapperne af - så
> _kunne_ man jo placere boksene til venstre istedet....!
> Mit forslag var udelukkende baseret på din eksempelside...
>
>> Med lidt held fjerner det så forklaringen og scrollbaren - men så har den
>> besøgende selvfølgelig noget at foretage sig.. :/ ^^
>
> Hvem har osse sagt, at det skal være nemt at surfe...
> (Kender til flere webbureauer som gør det til en udfordring...)
>
>> Jeg siger ikke, det ikke kan ske med det nuværende - men risikoen er
>> mindre...
>
> Risikoen for hvad??
> Man styler selvfølgelig(?!) indholdet efter sidens opbygning - eller hva'?!?
>
>
> Med venlig hilsen

Nu er der jo det, at i den endelige udformning, vil linkene kommer til
at stå der hvor de er dikteret af teksten - og det er ikke umiddelbart
til at vide hvordan - ligesom jeg på nuværende tidspunkt måske har en
ide om det endelige design, men jeg ved ikke noget med sikkerhed. Så
jeg har ikke gjort noget for at forhindre situationen.
Men klart nok - der skal være ryk til højre/venstre, hvis grænser
overskrides - evt også op/ned. (som så nok kun bliver op, eftersom IE
og Chrome, tilsyneladende ikke forstår at regne med de rigtige
værdier).

Birger


--
http://varmeretter.dk - billig, sund og hurtig mad
http://bbsorensen.dk

---

Thu, 19 May 2011 20:52:36 +0200 skrev Birger Sørensen:

>Som Rune, kunne jeg ikke slippe tanken fremsat af Kent, om at CSS er
>meget bedre til at styre visningen end javascripts events.
>Midt i middagsmaden slog det mig så, at selvom man ikke kan få CSS til
>at aktivere AJAX og hente indholdet, er der ingen grund til ikke at
>gøre begge dele. Altså styre visningen med CSS, samtidig med at
>mouseover aktiverer AJAX.

Man kan vel se Ajax som en mulighed - brug det, eller lad være. For
mig er det blot med til at øge forvirringen over alle de "sprog" og
standarder, der efterhånden inficerer hjemmesidestrikning. Jeg ved
godt, at man sagtens kan lave en hjemmeside i ren HTML og slippe
afsted med at anvende forældede tags og alligevel vil få det vist, men
brug af CSS er dog anbefalelsesværdigt og så er Hr. og Fru.
Schaffalitzky de Muckadell godt og rigeligt kørende.

Jeg vil bestemt ikke lege politibetjent her i gruppen, men hører Ajax
ikke til i serverside/clientside?

Jeg fatter ikke en dyt af Birger og Runes udvekslinger. Teknikken ser
da fascinerende ud, omend det ikke er gået op for mig, hvad JEG kan
bruge det til. Reload af en hel side på 200 kb bør vel ikke være et
problem nu om dage?
--
Venlig hilsen
Kurt Hansen

Søges: En person der kan passe heste, som ikke ryger eller drikker.

---

Efter mange tanker skrev Kurt Hansen:
> Thu, 19 May 2011 20:52:36 +0200 skrev Birger Sørensen:
>
>> Som Rune, kunne jeg ikke slippe tanken fremsat af Kent, om at CSS er
>> meget bedre til at styre visningen end javascripts events.
>> Midt i middagsmaden slog det mig så, at selvom man ikke kan få CSS til
>> at aktivere AJAX og hente indholdet, er der ingen grund til ikke at
>> gøre begge dele. Altså styre visningen med CSS, samtidig med at
>> mouseover aktiverer AJAX.
>
> Man kan vel se Ajax som en mulighed - brug det, eller lad være. For
> mig er det blot med til at øge forvirringen over alle de "sprog" og
> standarder, der efterhånden inficerer hjemmesidestrikning. Jeg ved
> godt, at man sagtens kan lave en hjemmeside i ren HTML og slippe
> afsted med at anvende forældede tags og alligevel vil få det vist, men
> brug af CSS er dog anbefalelsesværdigt og så er Hr. og Fru.
> Schaffalitzky de Muckadell godt og rigeligt kørende.
>
> Jeg vil bestemt ikke lege politibetjent her i gruppen, men hører Ajax
> ikke til i serverside/clientside?
>
> Jeg fatter ikke en dyt af Birger og Runes udvekslinger. Teknikken ser
> da fascinerende ud, omend det ikke er gået op for mig, hvad JEG kan
> bruge det til. Reload af en hel side på 200 kb bør vel ikke være et
> problem nu om dage?

Jeg er enig med dig - at det er muligt, er ikke en god begundelse for
at gøre det sådan -, og jeg forstår din forvirring.

De 200Kb er ikke en side. Det er en ordbog, der fylder 200Kb, og som -
principielt, i hvert fald - skal hentes sammen med hver eneste side på
Prebens site om vin - som i forvejen fylder ret godt i sig selv. Og
vendt på hovedet, er 200Kb en god sjat at spare på hver side.

Men det er ikke det, der er det største perspektiv.
Som det er nu, skal Preben manuelt markere de ord på siderne, der
findes i ordbogen.
Så hvis han ændrer en tekst på siden, er der en masse ekstra
vedligeholdelses arbejde. Eller værre endnu - hvis han tilføjer et ord
i ordbogen, skal han alle sine sider igennem, og oprette et nyt link
til ordbogen.
Visionen er, at Preben ændrer sin tekst, og serverside programmering
tilføjer automatisk det nødvendige, for at hans tekst får de
ordforklaringer der hører til i den. Eller når Preben tilføjer et ord i
sin ordbog, så bliver dette ord automatisk markeret på alle siderne.
Så det er ikke kun et spørgsmål om at spare båndbredde - det er også et
spørgsmål om at gøre hele sitet væsentligt nemmere at vedligeholde.

Fra starten er HTML *statisk*. Altså når brugerens browser har hentet
indholdet, kan det ikke ændres. Det er jo lidt kedeligt, og der har
været mange og forskelligartede (ActiveX, iframe, frames, flash) forsøg
på at ændre på den kendsgerning. Det første AJAX var et ActiveX object
i IE5 - fra 1996 vist. Så det kan vel næppe høre under "ny teknologi".
Den ringe udbredelse af AJAX, skyldes vel netop forvirring om hvad det
er - og så måske at der hører en (minimal) forståelse for (objekt
orienteret) programmering til at kunne realisere og implementere
brugen.
AJAX er scripting (programmering) i modsætning til HTML der er tekst
markup. Og det er væsentligt sværere at "låne" et script og tilpasse
det til eget behov, end det er at gøre noget tilsvarende med HTML. Bla.
fordi browserne er utroligt eftergivende overfor HTML fejl - det er en
frihed, der ikke findes i scripting/programmering.
Og så vel også den kendsgerning, at AJAX arbejder sammen med serverside
programmering - der skal hentes eller aflevers data fra/til serveren.
Og det er nok det, der er den største hæmsko for AJAX'es udbredelse.
Hele tanken med AJAX er, at man henter nyt indhold til en eksisterende
side, i stedet for at hente en hel ny side.
Derved bliver siden *dynamisk* - dens indhold kan ændres *efter* den er
hentet fra serveren.
Man siger jo at det er fantasien der sætter grænser. En forudsætning
for at bruge AJAX, er vel at man forstår hvad AJAX er og kan gøre.
Derfor ovenstående.
Så gang i fantasien Kurt. Der er sikkert noget du kan finde på at bruge
det til. ^^

Prebens opgave kan godt løses uden brug af AJAX, og der er andre
forslag der gør det. Jeg har bare (på opfordring) lavet en lidt mere
udførlig demo.
Uden AJAX, vil HTML'en skulle indholde alle de forklaringer der
optræder på siden. Det vil fylde mere, og gøre kildekoden mindre
læsbar, og vel egentlig være en mindre generel løsning. På den anden
side, kan disse løsninger anvendes uden javascript.
Hvilken der vælges, må vel være op til Preben - der er helt sikkert
andre overvejelser ind over.

Det kan da godt være, at diskussionen hører til i clientside.
For mig er der nu mange andre aspecter end lige javascriptet/AJAX. Det
handler også om opbygningen af HTML, definering af tilhørende CSS
klasser og der har været skærmlæsere ind over. Så en generel NG er vel
passende - og endelig var det jo her spørgsmålet blev stillet.

Birger

--
http://varmeretter.dk - billig, sund og hurtig mad
http://bbsorensen.dk

---

On 21 Maj, 07:47, Kurt Hansen <k...@ugyldig.invalid> wrote:

> Jeg fatter ikke en dyt af Birger og Runes udvekslinger. Teknikken ser
> da fascinerende ud, omend det ikke er gået op for mig, hvad JEG kan
> bruge det til.

F.eks. når du nævner en kunstner på din side, så finder den selv
infoormationerne, laver et link og viser informationer om den person,
på samme måde, som hvis man havde brugt title-attributten.

Det var en mulighed.

Og nej, som bl.a. jeg har srevet før, så kan man ikke nøjes med CSS og
HTML til det, netop fordi det skal være dynamisk. Det er slet ikke
meningen med CSS, at man skal kunne indsætte dynamisk indhold, derfor
kan man heller ikke uden meget meget stort besvær.

Meningen er at gøre den samlede kode så nem at implementere som
muligt. At den skal være tilgængelig for så mange brugere som muligt,
og at den validerer.

> Reload af en hel side på 200 kb bør vel ikke være et
> problem nu om dage?

Nu ikke for at lyde sur, men du bør i det mindste spørge ind til
problemet, før du kkritiserer. Birger vil under alle omstændigheder
kunne give svar, men jeg kan måske også, hvis det handler om specielt
det med skærmlæserne og navigeringen.

Reload er meget brugeruvenligt fordi det ødelægger brugerens flow og i
helt særlig grad for blinde, hvilket mange ikke er klar over. Og 200kb
for måske 3 linjers brugbar tekst er meget meget langsmmeligt for
brugeren. Udover, det også vil belaste serveren unødigt.

Det handler om at giive brugeren den bedste brugeroplevelse. Hvis
siden er for langsom eller virker "træg", så flygter de. Det samme er
tilfældet, hvis siden ikke kan bruges i deres browser eller bruges af
en skærmlæser osv.

Har du set Brigers side i en browser?

Har du afprøvet den, så du kan se, hvad probemet er? Både Birger og
jeg beskriver det faktisk i flere indlæg. Men bl.a. tastenavigering i
Opera er lidt buggy, og det samme er placeringerne i Chrome
ved :hover.

At der er AJAX indblandet, betyder ikke, det er dér løsningen til
problemerne er. Jeg skitserer mine egne mulige løsninger på Opera-
problemet med både en CSS og en JS-løsning.

Prøv at spørge i stedet for at kritisere.


MVH
Rune Jensen

---

On 21 Maj, 11:59, Rune Jensen <runeofdenm...@gmail.com> wrote:

> F.eks. når du nævner en kunstner på din side, så finder den selv
> infoormationerne, laver et link og viser informationer om den person,
> på samme måde, som hvis man havde brugt title-attributten.

....og der er ikke noget i vejen for at smide det ind i en title-
attribut. Så kan man bare ikke selv style sin popup, og man kan ikke
bruge tags i popuppen heller.

En ren serverside-løsning er mulig, for man kan lave en slags
serverside AJAX også, men meningen er, det skal kunne implementeres
forholdsvist nemt, som en slags one-size-fit-all.

Som det er nu, så er alt på front enden for så vidt godt nok. Det vi
diskuterer er mulige løsninger på bl.a. placeringerne af popuppen ved
navigering i Chrome og Opera.

Hertil ville jeg forsøge med ::not(:focus) og en ::not(:hover), begge
på #forklaring. Det er CSS3 og validerer nok ikke, men både Opera og
Chrome forstår det.

Det eneste man egentlig skal for at bruge Birgers kode, der er, man
skal kode det serverside script, som skal slå op i databasen og finde
forklaringen på ordet. Selve ordet, som skal slås op ligger i en
querystring variabel. Så det er en alm. standard request, man skal
lave på den variabel i scriptet, og et almindelig DB-opslag. Det er
ikke svært, eftersom selv jeg kan det.

Men netop det er udenfor grupen, da det er serverside.


MVH
Rune Jensen