/ Forside / Teknologi / Udvikling / HTML / Nyhedsindlæg
Login
Glemt dit kodeord?
Brugernavn

Kodeord


Reklame
Top 10 brugere
HTML
#NavnPoint
molokyle 11184
Klaudi 5506
bentjuul 3377
severino 2040
smorch 1950
strarup 1525
natmaden 1396
scootergr.. 1320
e.c 1150
10  miritdk 1110
Ordbog - opfølgning.
Fra : Birger Sørensen


Dato : 28-05-11 20:45

Dette blot for dem der har interesse.

Ordbogen er nu lagt i database - og det er stadig ordbogen fra
vinsiderne.dk, der leverer test-data, hvorfor http:// er udeladt fra
link.
Der er oprettet to tabeller: en der kobler ord sammen med anchors, og
en der kobler anchors sammen med forklaringen.
Det muliggør flere begreber til samme forklaring, ligesom der er ændret
en smule i js og rutiner til markering, så det faktisk er muligt
manuelt at koble ord, der ikke findes i ordbogen sammen med en
eksisterende forklaring. Der er desuden sat plads til en sprogkode, så
det skulle være muligt at få skærmlæsere til at oplæse disse ord, på
deres oprindelige sprog. Og der er sat plads af til en overskrift til
forklaringerne (ingen af disse to ekstra felter er dog taget i brug
endnu, ligesom der ikke findes flere forklaringer til samme ord endnu.
Det er stadig Prebens oprindelige data der anvendes).

En husker:
Det der var nok det alvorligste problem, var forkert placering af
popup-forklaringen i visse browsere, og at Opera ikke reagerede på den
første mouseover.
I IE blev forklaringerne anbragt forkert ved mouseover, men rigtigt ved
tabbing gennem anchors. For simpelhedens skyld, gjorde Chrome så
omvendt: anbragte forklaringerne rigtigt ved mouseover, men forkert ved
focus.
Det er ikke lykkedes mig at finde ud af hvad det er der gør denne
forskel - det er fysisk de samme beregning der udføres, den samme
funktion der kaldes.
(Har haft lidt eksperimentering inde over: forklaringsfeltet ligge i IE
og Chrome i øverste højre hjørne (0,0) har højde 0px og bredde 0px
(offsetTop, offsetLeft, offsetHeight og offsetWidth er alle 0) - så
hvordan de faktisk blev vist, er lidt af en gåde...)

Nu vil jeg så referere til
bbsorensen.com/ordbog/?men=Test - virker ikke i IE7 eller
kompatibilitet.
Et klik på knappen "Test tekst" vil automatisk indsætte en tekst, der
kan anvendes til Test - pudsigt nok...
(Der optræder 9 valideringsfejl, som skyldes HTML tags i teksten i
textarea, der viser test-teksten, der er kompileret fra vinsiderne.dk,
og krydret med 3 manuelt indsatte link, for begreber der p.t. ikke
findes i ordbogen, men alligevel har en forklaring der - det er en del
af testen :') )

Jeg har foretaget nogle ændringer.
Først er mouseover på link der skal vise en forklaring, ændret til blot
at fokusere linket. Men fokusering af linket bevirkede i forvejen at
forklaringen vises.
Når linket er fokuseret, vises forklaringen. Derfor er der på linkene
og på forklaringen, tilført en mouseout, der fjerner fokus fra linket -
ellers ville forklaringen blive stående, til et nyt link fokuseres,
hvilket er meget lidt praktisk. Nu skal man altså føre musen ud af link
eller forklaring, for at den fjernes. Hvilket svarer til den måde det
virkede på før ændringerne.
Der er tilføjet beregning, så forklaringen ikke overskridder det felt
teksten vises i. For at dette kan have effekt, skal det/de elementer
der viser teksten med link, have position:relative. (Det er den gamle
"hasLayout" - elementet skal have dimensioner).
Når det så er gjort, virker tingene faktisk efter hensigten!

Nåh, ja. Næsten.
FF og IE8 gør rigtigt.
Opera gør rigtigt - også ved første mouseover!
Chrome har et problem med noget matematik. Link i ventre side vises
forkert - lidt for langt til højre, så der kommer scrollbar og teksten
rykker. Tager man musen ned i forklaringen, og tilbage til linket,
flyttes forklaringen til der hvor den burde være - scrollbaren fjernes,
men teksten rykker ikke tilbage, før et andet link vælges (og gentager
man musens bevægelse, flytter forklaringen igen).
Kan ikke påstå jeg forstår det. I beregningen af forklarings position,
indgår linkets position og forklaringens bredde. Og det er de samme tal
hver gang. Men 2+2 er åbenbart ikke nødvendigvis 4 i Chromes udgave af
javascript...
En pudsighed er, at selvom det virker i IE8, kan man se at den har
besvær med at regne - når linkene fokuseres ved mouseover, tegnes en
stiplede box, der indikerer, at linket har fokus. Det er bare ikke på
alle link, denne boks rammer rigtigt - specielt i højre sider, markes
boksen forkert, og i øverste linie, med forkert størrelse.

Prisen er, at det ikke længere er så enkelt at tabbe sig gennem
forklaringerne.
I chrome vises forklaringerne stadig helt galt, når der tabbes.
I Opera går det vist som det plejer - bortset fra at der ikke er system
i rækkefølgen - eller måske er det bare mig der ikke er vant til
Opera...
I IE8 og FF, skal der tabbes 2 gange. Den første vælger det næste link,
som står i forklaringen (hvis der er nogen - ellers virker det som det
skal), men med mindre man har musen over forklaringen, vil den blive
skjult af denne operation, så det link der fokuseres, bliver faktisk
usynligt, efter det er fokuseret. Det er dog til at leve med.

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



 
 
runeofdenmark@hotmai~ (28-05-2011)
Kommentar
Fra : runeofdenmark@hotmai~


Dato : 28-05-11 16:30

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

> Prisen er, at det ikke l ngere er s enkelt at tabbe sig gennem

Brug en tabindex på -1 på popuppen. Så kan man ikke tabbe sig igennem
popuppen, men man kan taste retur og få de informationer. En tabindex
på -1 er ikke W3C standard, men for usability, så vidt jeg kan læse
mig frem til, en af løsningerne.

Muligvis kan man i stedet lave en generel tabindex på de anchors der
er i koden med spring på f.eks. 10, og så inkrementere disse inde i
popuppen. Jeg er ikke fortaler for tabindex, jeg mener, det skal
bruges i nødsituationer. Og denne fremgangsmåde vil også gøre koden
mere kompleks.


PS. Det hele besværliggøres af, at der er links i den popup. Det gør
det sværere at tabbe og det gør det i den grad svært for skærmlæsere.

Det sidste kan man muligvis komme udenom ved at lave en default
content i CSS, som hedder noget i retning af "Beskrivelse fra ordbog
indlæst" med en visible:hidden. Det er fordi, at den, som bruger
skærmlæseren ikke kan se, at indholdet (og kontekst) har ændret sig
under oplæsning, så det skal man informere om på en eller anden måde.

PPS. Du har ikke afprøvet det jeg skrev omkring brugen af ::not() ?


MVH
Rune Jensen

runeofdenmark@hotmai~ (28-05-2011)
Kommentar
Fra : runeofdenmark@hotmai~


Dato : 28-05-11 16:59

On 29 Maj, 00:29, runeofdenm...@hotmail.com wrote:

> Det sidste kan man muligvis komme udenom ved at lave en default
> content i CSS, som hedder noget i retning af "Beskrivelse fra ordbog
> indlæst" med en visible:hidden. Det er fordi, at den, som bruger
> skærmlæseren ikke kan se, at indholdet (og kontekst) har ændret sig
> under oplæsning, så det skal man informere om på en eller anden måde.

Problemet er for så vidt kun at give brugeren besked om, der er en
slags aside fra det egentlige indhold. Du bruger en <span> så vidt jeg
kan se - man kunne måske med fordel ændre dette til netop <aside>. Jeg
er ikke helt klar over, om det er den korrekte måde at bruge tagget
på, men det lyder logisk for mig.

Og <aside> er faktisk også (en slags) block-element.

Her:
http://dev.w3.org/html5/spec/Overview.html#the-aside-element


MVH
Rune Jensen

Chano Andersen (29-05-2011)
Kommentar
Fra : Chano Andersen


Dato : 29-05-11 02:12

Den 29-05-2011 00:58, runeofdenmark@hotmail.com skrev:
> Og<aside> er faktisk også (en slags) block-element.
>
> Her:
> http://dev.w3.org/html5/spec/Overview.html#the-aside-element

Det er et HTML5 tag, og derfor er det måske ikke lige det man på
nuværende tidspunkt skal benytte til generalt tilgængelige sites...
Desuden kræver brugen jo et eller andet sted også, at man 100% holder
sig til HTML5, og det er måske lige en lidt for stor omgang bare for at
løse dette?

- Chano Andersen

Birger Sørensen (29-05-2011)
Kommentar
Fra : Birger Sørensen


Dato : 29-05-11 09:51

runeofdenmark@hotmail.com kom med denne ide:
> On 29 Maj, 00:29, runeofdenm...@hotmail.com wrote:
>
>> Det sidste kan man muligvis komme udenom ved at lave en default
>> content i CSS, som hedder noget i retning af "Beskrivelse fra ordbog
>> indlæst" med en visible:hidden. Det er fordi, at den, som bruger
>> skærmlæseren ikke kan se, at indholdet (og kontekst) har ændret sig
>> under oplæsning, så det skal man informere om på en eller anden måde.
>
> Problemet er for så vidt kun at give brugeren besked om, der er en
> slags aside fra det egentlige indhold. Du bruger en <span> så vidt jeg
> kan se - man kunne måske med fordel ændre dette til netop <aside>. Jeg
> er ikke helt klar over, om det er den korrekte måde at bruge tagget
> på, men det lyder logisk for mig.
>
> Og <aside> er faktisk også (en slags) block-element.
>
> Her:
> http://dev.w3.org/html5/spec/Overview.html#the-aside-element
>
>
> MVH
> Rune Jensen

Foreløbig holder jeg mig til HTML4.01 strict. Så <aside> kommer ikke på
tale endnu.
Men løsningen med en eller anden info, der kun præsenteres til brugere
af skærmlæsere, er måske ikke så tosset. Læser skærmlæsere hidden
fields?
tab-index holder jeg mig helst fra. For det første komplicerer det
koden, og for det andet bliver det kompliceret, at holde styr på. Det
er ikke givet, at ordbogen kun skal bruges på en enkelt tekst på en
given side. Som det er, kan man bruge det så mange gange man lyster på
samme side. Hvis jeg begynder at rode tab-index ind i det, skal der
holdes styr på hvor mange der indsat i forrige tekster. Ikke en
umulighed - skal tage den med i overvejelserne.
Følger Opera tabindex? Hvis, hvordan er tastningen?
Jeg har det lidt med tab-index, som jeg har det med z-index. Lad være
med at pille, hvis det ikke er absolut nødvendigt. Og når det er
nødvendigt, er det som regel fordi en eller flere af browserne ikke gør
som de skal/forventet, og man er nødt til manuelt at korrigere for
forskelle i browserne.

Nuværende CSS, der styrer visningen ser sådan ud:
..ref_ord:focus + #forklaring, #forklaring:hover {
   display : block;
   }
ref:ord er klasse for links, og #forklaring er forklaringen. Og så
altså i kombination med mouseover på #forklaring der fokuserer linket,
og mouseout på dem begge, der fjerne focus fra ref_ord.
Det skulle nedgradere fint (ikke testet), derved at mouseover ikke vil
focusere linket uden js - der kan heller ikke hentes forklaring, så
uden js, skal man bruge linket, for at komme til ordbogen og se
forklaringen.
Jeg kan ikke lige se hvordan :not kan bruges, så du kommer nok til at
uddybe.
(:not er ikke implementeret før IE9 - ved ikke hvordan de andre
browsere har det med den. Har heller ikke indtryk af at den er
gennemarbejdet i doc endnu.)

Birger

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



Rune Jensen (28-05-2011)
Kommentar
Fra : Rune Jensen


Dato : 28-05-11 19:40

On May 29, 3:11 am, Chano Andersen <sunsite012...@chanoandersen.dk>
wrote:
> Den 29-05-2011 00:58, runeofdenm...@hotmail.com skrev:
>
> > Og<aside>  er faktisk også (en slags) block-element.
>
> > Her:
> >http://dev.w3.org/html5/spec/Overview.html#the-aside-element
>
> Det er et HTML5 tag, og derfor er det måske ikke lige det man på
> nuværende tidspunkt skal benytte til generalt tilgængelige sites...
> Desuden kræver brugen jo et eller andet sted også, at man 100% holder
> sig til HTML5, og det er måske lige en lidt for stor omgang bare for at
> løse dette?

Klart nok. Men jeg ved ikke rigtigt, hvordan man ellers skal gøre
det...

Som sagt er det kun at man får gjort opmærksom på den ændring i
teksten, at her kommer en sidenote. Det kan sikkert gøres på anden
måde. Måske med <small>?


MVH
Rune Jensen

Rune Jensen (29-05-2011)
Kommentar
Fra : Rune Jensen


Dato : 29-05-11 05:01

On 29 Maj, 10:50, Birger Sørensen <s...@bbsorensen.com> wrote:

> Foreløbig holder jeg mig til HTML4.01 strict. Så <aside> kommer ikke på
> tale endnu.

OK, men det kan nok løses på anden måde - som sagt.

> Men løsningen med en eller anden info, der kun præsenteres til brugere
> af skærmlæsere, er måske ikke så tosset. Læser skærmlæsere hidden
> fields?

Jeg kan lave en lokal test her i aften.

Der er visse andre muligheder, nogle mere drastiske end andre. F.eks.
kan man hard-code via CSS en stemme-ændring.

> tab-index holder jeg mig helst fra. For det første komplicerer det

Og jeg er enig - også udfra du har velbegrundede argumenter.

> Følger Opera tabindex? Hvis, hvordan er tastningen?

Ja, jeg mener, at Opera er ret fleksibel hvad det angår. Men som du
selv påpeger, er tabindex en last-solution (og i virkeligheden noget
hver enkelt webdesigner på gøre op med sig selv, hvor vigtigt det er).

Opera kan faktisk TABbbe igennem popuppen. Men kun på de links, som er
henvisninger til ordbogen. Det kan vel muligvis klares med en global
class.


> Nuværende CSS, der styrer visningen ser sådan ud:
> .ref_ord:focus + #forklaring, #forklaring:hover {
>         display : block;
>         }
<SNIP>
> Jeg kan ikke lige se hvordan :not kan bruges, så du kommer nok til at
> uddybe.

::not var ment som en metode til at holde Opera fra at lave problemer
med TABbing, SVJH. Måske er den ikke nødvendig. Jeg kigger, når
projektet er lidt længere fremme.

> (:not er ikke implementeret før IE9 - ved ikke hvordan de andre
> browsere har det med den. Har heller ikke indtryk af at den er
> gennemarbejdet i doc endnu.)

Jo - alle de større browsere forstår ::not(). Så hvis man vil, kan man
nok bruge det til at lave et hack, så man kun rammer IE9+ (men det er
en sidenote).

::not() er en negering af udtrykket, og der er ikke så mange
ændringer, der kan foretages der i standarden. Den er pretty straight-
forward. F.eks.:

a:hover::not(:focus) {
color: green;
}

vil ændre tekstfarven ved hover, men kun hvis den ikke samtidig har
focus fra en TAB.


MVH
Rune Jensen

Søg
Reklame
Statistik
Spørgsmål : 177419
Tips : 31962
Nyheder : 719565
Indlæg : 6407871
Brugere : 218876

Månedens bedste
Årets bedste
Sidste års bedste