---

Jeg er stadigvæk glad for tipset om UDM4,som jeg har stor
fornøjelse af. Mit manglende kendskab til html og css forhindrer
mig i at se dropdown menuen ved første besøg på hjemmesiden
http://qusqo.homepage.dk
Hvad går galt?

--
Vil du lære at kode HTML, XHTML, CSS, SSI, ASP eller ASP.NET?
- Pædagogiske tutorials på dansk
- Kom godt i gang med koderne
KLIK HER! => http://www.html.dk/tutorials

---

Den 22-02-2010 12:24, Dan Olsen skrev:
> Jeg er stadigvæk glad for tipset om UDM4,som jeg har stor
> fornøjelse af. Mit manglende kendskab til html og css forhindrer
> mig i at se dropdown menuen ved første besøg på hjemmesiden
> http://qusqo.homepage.dk
> Hvad går galt?

Du har ingen CSS?


MVH
Rune Jensen

---

Dan Olsen skrev:
> Jeg er stadigvæk glad for tipset om UDM4,som jeg har stor
> fornøjelse af. Mit manglende kendskab til html og css forhindrer
> mig i at se dropdown menuen ved første besøg på hjemmesiden
> http://qusqo.homepage.dk
> Hvad går galt?
>
Det er ikke dit muligvis manglende kendskab
til CSS, men dine øjne der ikke kan se en
hvid tekst på en hvid bagground.

Det er sandsynligvis i filen
/udm4/udm-resources/udm-style-qusqo.dk.js
det går galt, mere specifikt i

//styles which apply to each navbar item
....
um.items = [
....
]

Gennemgå nøje dette array for at sikre dig
at også topmenuens punkter får det rette farver
og borders - brug evt. nogle alternative værdier

Menuen virker som sikker tilsigtet, det er
kun topmenuen der ikke vises i normaltilstanden.
En genvej kan være
a.navButton {color:white;background:grey;}

Der er desuden en del syntaksfejl. De har
muligvis også indflydelse.

Jeg synes heller ikke h3-formateringen af
a-markørene, hvis det kun er for bogstavstørrelse
er det smartere at formetere a-markøren.
--
Med venlig hilsen
Jørgen Farum Jensen
http://webdesign101.dk
..

---

Den 22-02-2010 12:58, Jørgen Farum Jensen skrev:

> //styles which apply to each navbar item
> ...
> um.items = [
> ...
> ]
>
> Gennemgå nøje dette array for at sikre dig
> at også topmenuens punkter får det rette farver
> og borders - brug evt. nogle alternative værdier

Æhm... styler den menu i JS?
Javascript er til funktioner ikke til styling.


MVH
Rune Jensen

---

Rune Jensen skrev:
> Den 22-02-2010 12:58, Jørgen Farum Jensen skrev:
>
>> //styles which apply to each navbar item
>> ...
>> um.items = [
>> ...
>> ]
>>
>> Gennemgå nøje dette array for at sikre dig
>> at også topmenuens punkter får det rette farver
>> og borders - brug evt. nogle alternative værdier
>
> Æhm... styler den menu i JS?
> Javascript er til funktioner ikke til styling.

Det kommer vel an på indholdet af de JavaScript
filer?

Det omfangsrige array jeg refererer til er i virkeligheden
input til en menugenerator, der genererer en obfuskeret
js-fil - i mit tilfælde en php-fil - der i sin tur generer
menuelementernes styling.

Det er altsammen en smule tricky, men veldokumenteret og
faktisk meget nemt at have med at gøre - hvis man vel at
mærke læser manualen, hvori der blandt andet står at
arrayet ikke skal medtages på siden, når først det
er brugt til generatoren.

Jeg anbefaler UDM4 fordi den er langt mere flesibel end
noget jeg selv kunne lave, og tillige har et helt
fremragende tastaturnavigations-modul.

Ulempen er selvfølgelig at det er pløkumuligt at
gennemskue hvor en eventuel fejl måtte være. Derfor
mine råd i foregående posting. Menuen fungerer, det
er kun topmenu punkterne, der har forkerte farver.

Se for eksempel
http://webdesign101.dk/showcase/
--

Med venlig hilsen
Jørgen Farum Jensen
Håndbog i webdesign: http://webdesign101.dk/wwwbog/udgave2/
Webdesign med stylesheets: http://webdesign101.dk/cssbog/
..

---

Den 22-02-2010 15:40, Jørgen Farum Jensen skrev:
> Rune Jensen skrev:

>> Æhm... styler den menu i JS?
>> Javascript er til funktioner ikke til styling.
>
> Det kommer vel an på indholdet af de JavaScript
> filer?

Jeg er ikke helt sikker på, hvad du mener, men med funktioner, der mener
jeg, at man grundstyler med CSS, så at så meget som muligt virker der -
og derefter plugger man JS på.

Funktioner kan være f.eks. forbefring af tilgængeligheden,
tidsforsinkelse, dynamisk bredde af menuer måske også, eller at rykke en
submenu til den modsatte side, hvis der ikke er plads (kan vidst ikke
laves med CSS?) eller simpel tastaturkontrol - se sidste svar.

> Det omfangsrige array jeg refererer til er i virkeligheden
> input til en menugenerator, der genererer en obfuskeret
> js-fil - i mit tilfælde en php-fil - der i sin tur generer
> menuelementernes styling.

Obsfuskerede scripts tager tid at pakke ud. At sende CSS igennem
JS-enginen virker på mig lidt dobbelt. Hver gang der skal laves en
DOM-handling, koster det tid, så vidt jeg har forstået en meget krævende
handling, så koster det endnu mere, at det skal behandles af først JS,
dernæst CSS, vel?

> Det er altsammen en smule tricky, men veldokumenteret og
> faktisk meget nemt at have med at gøre - hvis man vel at mærke læser
> manualen, hvori der blandt andet står at
> arrayet ikke skal medtages på siden, når først det
> er brugt til generatoren.

Det virker lidt i overkanten, at man skal have en manual for at lave en
menu, synes jeg ;)

> Jeg anbefaler UDM4 fordi den er langt mere flesibel end
> noget jeg selv kunne lave, og tillige har et helt
> fremragende tastaturnavigations-modul.

Jeg kan faktisk godt se, hvad du mener, men den virker ikke uden JS. Når
jeg ankommer til en side for første gang, slår NoScript extension alt JS
fra, og hvis jeg ikke tillader siden, kommer det ikke igennem. Derfor
kan jeg så risikere at komme ind på en side, som jeg ikke kan navigere.

Jeg ved godt, .dk-domæner er ikke det store problem med injection osv.
men alligevel, det bør virke uden JS.

> Ulempen er selvfølgelig at det er pløkumuligt at
> gennemskue hvor en eventuel fejl måtte være. Derfor
> mine råd i foregående posting. Menuen fungerer, det
> er kun topmenu punkterne, der har forkerte farver.

Det er hele fordelen ved unobtrusive design i en nøddeskal, jo.. ;)

Hver del fuldstændigt separeret fra de andre, og kan derfor tjekkes og
rettes for sig, fuld overskuelighed, og siden kan bruges med hver del,
CSS og JS slået fra, meget tilgængeligt, fordi hvert led har en fallback.

> Se for eksempel
> http://webdesign101.dk/showcase/

ja, den virker netop ikke uden JS? For jeg ser ingen drop down ;)

Fordelen ved menuen er tastaturkontrol, som du skriver. Men som vi
tidligere har diskuteret (i denne gruppe var det vidst?), så har
cursor-tasterne nogle helt grundlæggende funktioner for brugeren, at
scrolle siden.

Derfor foretrækker jeg, at man holder sig til de indbyggede (TAB,
SHIFT+TAB), som også er dem, man normalt ville bruge. At indlægge fuld
tastaturkontrol via cursor er en krævende opgave at lave kodemæssigt så
vidt jeg har læst (fylder meget), og ikke mange har åbenbart haft succes.

Jeg synes det kunne være sjovt, hvis vi kunne sammensætte en sådan kodet
menu i gruppen, men udfra en unobtrusive synsvinkel. Jeg har leget lidt
med Kenneths menu her, foreløbig uden JS:

http://webdesigngruppen.dk/test/CSS_drop_down_poc.asp

Først og fremmest, så har jeg indlagt et område udenom menuerne (gult),
som "holder menuen" af hensyn til, hvis man hover over meget små menuer,
så risikerer man, den "hugger i" på sidste niveu f.eks. hvilket er meget
irriterende. Derfor lidt ekstra whitespace til de fummelfingrede. Det er
sikkert skodkode, men det virker foreløbig.

IE kan TABbe den første menu, men ikke andre, heller ikke SUBmenuer. Det
er jo ikke overvældende.

Nogle idéer?


MVH
Rune Jensen

---

Rune Jensen skrev:
> Den 22-02-2010 15:40, Jørgen Farum Jensen skrev:
>> Rune Jensen skrev:
>
>>> Æhm... styler den menu i JS?
>>> Javascript er til funktioner ikke til styling.
>>
>> Det kommer vel an på indholdet af de JavaScript
>> filer?
>
> Jeg er ikke helt sikker på, hvad du mener, men med funktioner, der mener
> jeg, at man grundstyler med CSS, så at så meget som muligt virker der -
> og derefter plugger man JS på.
>
> Funktioner kan være f.eks. forbefring af tilgængeligheden,
> tidsforsinkelse, dynamisk bredde af menuer måske også, eller at rykke en
> submenu til den modsatte side, hvis der ikke er plads (kan vidst ikke
> laves med CSS?) eller simpel tastaturkontrol - se sidste svar.

Det er jo alle de egenskaber man for forærende med dette
menusystem. Jeg kan tilføje, at James Edwards, som står bag,
har beskrevet Scriptet indgående i The JavaScript Anthology,
og muligvis også på Sitepoint (jeg har ikke set efter...).

Så hvis man er sådan sindet kan man ved bogens hjælp
konstruere det selv samme på egen hånd.

>> Det omfangsrige array jeg refererer til er i virkeligheden
>> input til en menugenerator, der genererer en obfuskeret
>> js-fil - i mit tilfælde en php-fil - der i sin tur generer
>> menuelementernes styling.
>
> Obsfuskerede scripts tager tid at pakke ud. At sende CSS igennem
> JS-enginen virker på mig lidt dobbelt. Hver gang der skal laves en
> DOM-handling, koster det tid, så vidt jeg har forstået en meget krævende
> handling, så koster det endnu mere, at det skal behandles af først JS,
> dernæst CSS, vel?

Det kan godt være jeg tager fejl, men obfuskering er vist
det der sker ved fuldstændig sammentrækning og forkortelse
af et script.
>> Det er altsammen en smule tricky, men veldokumenteret og
>> faktisk meget nemt at have med at gøre - hvis man vel at mærke læser
>> manualen, hvori der blandt andet står at
>> arrayet ikke skal medtages på siden, når først det
>> er brugt til generatoren.
>
> Det virker lidt i overkanten, at man skal have en manual for at lave en
> menu, synes jeg ;)

Systemet bygger ikke på et færdigt script og et
færdigt stylesheet, men på at du fodrer et script med
et array, der indeholder alle de værdier, du ellers ville
sætte i et stylesheet og på det grundlag genererer et
script, enten js eller php.

Manualen indeholder en beskrivelse af fremgangsmåden samt
en del nyttige tips. Quickguide på et par sider er dog nok.

>> Jeg anbefaler UDM4 fordi den er langt mere flesibel end
>> noget jeg selv kunne lave, og tillige har et helt
>> fremragende tastaturnavigations-modul.
>
> Jeg kan faktisk godt se, hvad du mener, men den virker ikke uden JS. Når
> jeg ankommer til en side for første gang, slår NoScript extension alt JS
> fra, og hvis jeg ikke tillader siden, kommer det ikke igennem. Derfor
> kan jeg så risikere at komme ind på en side, som jeg ikke kan navigere.

Der er jo vildt meget der ikke virker uden JavaScript,
heller ikke unobtrusive scripting. Det der faktisk virker
er topmenuen, og rådet i manualen er at man sørger
for at alle topmemnuens punkter fører til sektionsforsider,
hvor undermenuernes punkter er beskrevet i klar tekst og
almindelige HTML links. (Det har jeg ikke selv været for
godt til, men jeg prøver da).
> Jeg ved godt, .dk-domæner er ikke det store problem med injection osv.
> men alligevel, det bør virke uden JS.

???

>> Ulempen er selvfølgelig at det er pløkumuligt at
>> gennemskue hvor en eventuel fejl måtte være. Derfor
>> mine råd i foregående posting. Menuen fungerer, det
>> er kun topmenu punkterne, der har forkerte farver.
>
> Det er hele fordelen ved unobtrusive design i en nøddeskal, jo.. ;)


> Hver del fuldstændigt separeret fra de andre, og kan derfor tjekkes og
> rettes for sig, fuld overskuelighed, og siden kan bruges med hver del,
> CSS og JS slået fra, meget tilgængeligt, fordi hvert led har en fallback.
>
>> Se for eksempel
>> http://webdesign101.dk/showcase/
>
> ja, den virker netop ikke uden JS? For jeg ser ingen drop down ;)

Nej, jf. dit eget foregående.
> Fordelen ved menuen er tastaturkontrol, som du skriver. Men som vi
> tidligere har diskuteret (i denne gruppe var det vidst?), så har
> cursor-tasterne nogle helt grundlæggende funktioner for brugeren, at
> scrolle siden.
>
> Derfor foretrækker jeg, at man holder sig til de indbyggede (TAB,
> SHIFT+TAB), som også er dem, man normalt ville bruge. At indlægge fuld
> tastaturkontrol via cursor er en krævende opgave at lave kodemæssigt så
> vidt jeg har læst (fylder meget), og ikke mange har åbenbart haft succes.

Tastaturmodulet er valgfrit, det fylder 6 kb.
> Jeg synes det kunne være sjovt, hvis vi kunne sammensætte en sådan kodet
> menu i gruppen, men udfra en unobtrusive synsvinkel. Jeg har leget lidt
> med Kenneths menu her, foreløbig uden JS:
>
> http://webdesigngruppen.dk/test/CSS_drop_down_poc.asp
>
> Først og fremmest, så har jeg indlagt et område udenom menuerne (gult),
> som "holder menuen" af hensyn til, hvis man hover over meget små menuer,
> så risikerer man, den "hugger i" på sidste niveu f.eks. hvilket er meget
> irriterende. Derfor lidt ekstra whitespace til de fummelfingrede. Det er
> sikkert skodkode, men det virker foreløbig.

Jeg har fuld forståelse for de synspunkter, du gør gældende.
Hvad man råder folk til at gøre afhænger dog meget af hvor
de folk, man rådgiver (eller underviser, eller skriver
artikler og bøger for) befinder sig, både i henseende til
faglig kunnen men også deres aktuelle job. UDM4 har den
fordel, at udfyldningen af det føromtalte array faktisk
får det til at stå meget tydeligt for brugeren hvilke
egenskaber der skal værdisættes hvordan for at opnå
det resultat man ønsker.

Jeg er bekendt med den teknik du beskriver for at
undgå at en menu folder sammen i samme øjeblik
musen ryger uden for det aktive punkt. Jeg foretrækker
helt klart en time delay løsning.

Jeg synes at det er et interessant projekt du har startet,
men kan ikke love at jeg vil deltage. Og jeg ved faktisk
ikke hvor meget mere "unobtrusiveness" du kan forlange
end den UDM4 tilbyder. Funktionaliteten i UDM4 bevares
så meget som det er muligt uden JS.

Unobtrusiveness har intet at gøre med hvor læsbar noget
kode er, men udelukkende om en nødvendig funktionalitet
bevares i indholdet når *hverken* CSS eller JS kan tolkes.

Til den ende er jeg godt tilfreds med mit "eksempel"
http://webdesign101.dk/showcase/
--

Med venlig hilsen
Jørgen Farum Jensen
Håndbog i webdesign: http://webdesign101.dk/wwwbog/udgave2/
Webdesign med stylesheets: http://webdesign101.dk/cssbog/
..

---

Den 23-02-2010 15:01, Jørgen Farum Jensen skrev:
> Rune Jensen skrev:

>> Jeg ved godt, .dk-domæner er ikke det store problem med injection osv.
>> men alligevel, det bør virke uden JS.
>
> ???

Javascript bruges bl.a. til XSS, injection af malware hos brugeren via
sårbarheder i f.eks. IE eller Adobes plugins, direkte nedhenting af
malware via f.eks. fake "Antivirus XXXX" phishing-sider mm. Som regel
med obsfuscated JS for at "snyde" AVer eller nysgerrige brugere.

Det er hovedårsagen til, jeg har den extension. Jeg kerer mig en hel del
om sikkerhed, og jeg ved, at ikke alt som er automatisk og usynligt for
brugeren er godt, derfor vil jeg gerne kunne kontrollere det.

Danske domæner er ikke lige så inficerede med disse scripts som
udenlandske, faktisk ligger vi helt i bund sammen med bl.a. Irland og
Japan hvad angår disse inficeringer (2009-tal). Men det betyder ikke, at
man ikke riskerer det på danske sites, jvfr. hackingen af UnoEuros
servere sidste år.

Læs mere om denne extension til FF her:

http://noscript.net/

Hvor der også er links til oficielle eksperters udtalelser.


MVH
Rune Jensen

---

Rune Jensen skrev:
> Den 23-02-2010 15:01, Jørgen Farum Jensen skrev:
>> Rune Jensen skrev:
>
>>> Jeg ved godt, .dk-domæner er ikke det store problem med injection osv.
>>> men alligevel, det bør virke uden JS.
>>
>> ???
>
> Javascript bruges bl.a. til XSS, injection af malware hos brugeren via
> sårbarheder i f.eks. IE eller Adobes plugins, direkte nedhenting af
> malware via f.eks. fake "Antivirus XXXX" phishing-sider mm. Som regel
> med obsfuscated JS for at "snyde" AVer eller nysgerrige brugere.
>
> Det er hovedårsagen til, jeg har den extension. Jeg kerer mig en hel del
> om sikkerhed, og jeg ved, at ikke alt som er automatisk og usynligt for
> brugeren er godt, derfor vil jeg gerne kunne kontrollere det.
>
> Danske domæner er ikke lige så inficerede med disse scripts som
> udenlandske, faktisk ligger vi helt i bund sammen med bl.a. Irland og
> Japan hvad angår disse inficeringer (2009-tal). Men det betyder ikke, at
> man ikke riskerer det på danske sites, jvfr. hackingen af UnoEuros
> servere sidste år.
>
> Læs mere om denne extension til FF her:
>
> http://noscript.net/
>
> Hvor der også er links til oficielle eksperters udtalelser.

Tak for den forklaring. Endnu et strå til kamelens ryg.
Jeg skal såmænd nok klare mig både med og måske uden, men
jeg tænker på de stakkels seniorer, som jeg prøver at
overbevise om PC'ens og internettets velsignelser. De er
nok bedre tjent med at jeg ikke oplyser dem om at de
de risikerer malware ved at bruge DR's hjemmeside m.fl.

Det er virkelig en seriøs afvejning jeg må gøre mig
hver sæson, oplysning om sikkerhed, antivirusprogrammer,
firewalls og kryptering af trådløse net mv. vs. den nytte
de kan have at bruge en browser og et e-mail program.

--

Med venlig hilsen
Jørgen Farum Jensen
Håndbog i webdesign: http://webdesign101.dk/wwwbog/udgave2/
Webdesign med stylesheets: http://webdesign101.dk/cssbog/
..

---

Den 23-02-2010 18:16, Jørgen Farum Jensen skrev:

> Tak for den forklaring. Endnu et strå til kamelens ryg.
> Jeg skal såmænd nok klare mig både med og måske uden, men
> jeg tænker på de stakkels seniorer, som jeg prøver at
> overbevise om PC'ens og internettets velsignelser. De er
> nok bedre tjent med at jeg ikke oplyser dem om at de
> de risikerer malware ved at bruge DR's hjemmeside m.fl.

Det tror jeg du har ret i. Ikke fordi det ikke kan ske, men fordi det i
så fald ikke er en "hverdagsbegivenhed", og chancen er lille på danske
sites. Så kan man være forskrækket over alting, og så kommer man ingen
vegne.

Derimod, så kan man jo sagtens give nogle generelle råd ved surfing.
F.eks. at man ikke skal klikke videre, hvis AVet giver en advarsel (man
har det af en årsag). Eller om det siden vil sælge er for godt til at
være sandt. Sammenlign denne sikkerhed med, at man låser døren, når man
går, og at man ikke køber guld af en tilfældig person på gaden med stor
frakke ("special price - only for you!").

Jeg anbefaler heller ikke, at man "forskrækkes", men jeg er dybt
overrasket over, at der stadig er nogle (specielt yngre mennesker?), som
synes uvidende om helt grundlæggende IT-sikkerhed sådan som den er i
dag. F.eks. at man holder alle sine programmer opdaterede - også
browseren. Hvor mange IE-brugere har _ikke_ opgraderet endnu, selv om de
kan...

Det gælder også med folks hjemmesider, hvor mange ikke har
inputvalidering, ikke har "database sanitation" vha. parameterized
queries, stadig beholder den gamle Wordpress/Joomla eller -plug in uden
at opdatere[1] osv. Det er klart for mig, at hvis man vil benytte meget
avancerede teknikker og selv rode med koden, bør man også kende disse
teknikkers mulige sårbarheder (her tænker jeg serverside og database).

> Det er virkelig en seriøs afvejning jeg må gøre mig
> hver sæson, oplysning om sikkerhed, antivirusprogrammer,
> firewalls og kryptering af trådløse net mv. vs. den nytte
> de kan have at bruge en browser og et e-mail program.

Ja, men bare det at følge ganske alm. best practice, f.eks. holde alt
opdateret, kan højne den generelle sikkerhed. Jeg mener ikke at man skal
tage netstikket helt fra - det håber jeg ikke, du tror, jeg mener ;)

Mht. seniorer: Et medlem af min famile, som er oppe i årene og ikke
videre ekspertbruger, kan godt finde ud af at holde maskinen, antivirus
og browser samt Readeren opdateret, og er én af de mest mistænksomme jeg
kender overhovedet hvad angår "tvivlsomme links" eller meddelelser i det
hele taget fra maskinen.. Jeg har da også for nyligt fået slået
Javascript fra i dennes Adobe Reader "af sikkerhedsgrunde"[2}. Sumatra
PDF-reader, som jeg selv bruger, ville jeg ikke kunne få installeret
uden spørgsmål, som kræver alt for lange forklaringer, for det er et
helt andet UI..


MVH
Rune Jensen

[1] Min hjemmeside er ASP - alligevel får jeg rigtigt mange forsøg på
bl.a. cross site-scripting til anerkendte CMSer med sikkerhedshuller,
som f.eks. Joomla (MosConfig_absolutepath). Disse er rettet imod
ikke-opdaterede CMSer og plugins, dvs. folk, som ikke gider opdatere
eller ikke interesserer sig for sidens sikkerhed.

[1]
http://www.channelinsider.com/c/a/Tech-Analysis/Simple-Fix-for-Adobe-Readers-Latest-JavaScript-Vulnerability-248857/

---

Den 23-02-2010 15:01, Jørgen Farum Jensen skrev:

> Det kan godt være jeg tager fejl, men obfuskering er vist
> det der sker ved fuldstændig sammentrækning og forkortelse
> af et script.

Ja, men ikke nødvendigvis kun det. Man kan også lave en slags ZIPping
via JS, så ligner JSen ren gibberish, men den fylder mindre (der skal så
lige tages højde for overhead på "udpakkeren").

Man sammentrækker og ZIPper af to grunde SVJV: For hastighed ved
download eller for at skjule koden. Det ene behøver ikke udelukke det
andet, og det behøver ikke være mistænkeligt, bare er det svært at rette
i. Derfor har forfatteren også (bør have) en "master", som ikke er
obsfuscated.

Både MS og Google gør det, SVJV.

> Der er jo vildt meget der ikke virker uden JavaScript, heller ikke
> unobtrusive scripting. Det der faktisk virker
> er topmenuen, og rådet i manualen er at man sørger
> for at alle topmemnuens punkter fører til sektionsforsider, hvor
> undermenuernes punkter er beskrevet i klar tekst og almindelige HTML
> links. (Det har jeg ikke selv været for godt til, men jeg prøver da).

Min anke imod scriptet er, at de har indsat JSen alt for tidligt. Dermed
kan man ikke bruge hovedfunktionen uden JS. Sikkert ikke godt forklaret,
så her er et eksempel:

http://blakehaswell.com/lab/dropdown/deux/

Her er der brugt lidt JS til bl.a. tidsforsinkelse samt til
tastaturkontrol. Det er helt OK udfra, at dette ikke kan laves med ren
CSS, og hovedfunktionen med submenuer virker også uden JS. Altså tag ét
lag væk, og hovedfunktionen er der stadig.

Jeg synes så de skulle have gjort det på samme måde med dit eksempel og
indsat den avancerede keyboardkontrol efter CSSen.

Dit menuscript er ikke dårligt, men ovenstående trækker ned IMØ.
Specielt fordi det må have været nogle virkelig begavede kræfter bag at
kunne lave den tastenavigering i det hele taget.


MVH
Rune Jensen

--
WinAMP:
Soon - Waiting For the Summer

---

Rune Jensen wrote:

>> Det kan godt være jeg tager fejl, men obfuskering er vist
>> det der sker ved fuldstændig sammentrækning og forkortelse
>> af et script.
>
> Ja, men ikke nødvendigvis kun det. Man kan også lave en slags ZIPping
> via JS, så ligner JSen ren gibberish, men den fylder mindre (der skal så
> lige tages højde for overhead på "udpakkeren").

Tænker du på gzip? Det virker lidt som om, nogle begreber bliver blandet
sammen her. Gzip har ikke noget specifikt med Javascript at gøre, men
virker med alle typer (statiske) dokumenter.

> Man sammentrækker og ZIPper af to grunde SVJV: For hastighed ved
> download eller for at skjule koden. Det ene behøver ikke udelukke det
> andet, og det behøver ikke være mistænkeligt, bare er det svært at rette
> i. Derfor har forfatteren også (bør have) en "master", som ikke er
> obsfuscated.

Formålet med at komprimere kode er ikke at obfuskere den, men alene at
gøre filstørrelsen mindre. Det er ikke umuligt at læse komprimeret kode
- bare meget svært. Man kan selfølgelig argumentere for at man
komprimerer den for at få obfuskeret kode - fair nok, så får man et
ordentligt performance boost med oven i hatten.

> Både MS og Google gør det, SVJV.

Alle burde gøre det. Google gør det med Closure Compiler
(http://code.google.com/closure/compiler/) som også bruges af jQuery.

--
Peter Farsinsen
peter@farsinsen.dk

---

Den 23-02-2010 22:12, Peter Farsinsen skrev:
> Rune Jensen wrote:

>> Ja, men ikke nødvendigvis kun det. Man kan også lave en slags ZIPping
>> via JS, så ligner JSen ren gibberish, men den fylder mindre (der skal så
>> lige tages højde for overhead på "udpakkeren").
>
> Tænker du på gzip? Det virker lidt som om, nogle begreber bliver blandet
> sammen her. Gzip har ikke noget specifikt med Javascript at gøre, men
> virker med alle typer (statiske) dokumenter.

Nej, jeg tænker på JS-komprimering via JS. Jeg kan ikke huske hvad det
hedder, men det er forholdsvist brugt, og det minder om ZIPping. Det
kræver så en udpakker, som følger med siden ved nedhentning, også
skrevet i JS.


MVH
Rune Jensen

---

Rune Jensen wrote:

>> Tænker du på gzip? Det virker lidt som om, nogle begreber bliver blandet
>> sammen her. Gzip har ikke noget specifikt med Javascript at gøre, men
>> virker med alle typer (statiske) dokumenter.
>
> Nej, jeg tænker på JS-komprimering via JS. Jeg kan ikke huske hvad det
> hedder, men det er forholdsvist brugt, og det minder om ZIPping. Det
> kræver så en udpakker, som følger med siden ved nedhentning, også
> skrevet i JS.

Fair nok. Jeg har aldrig hørt om det, så er også blank på det.

Lyder dog både dumt og kostbart ;)

--
Peter Farsinsen
peter@farsinsen.dk

---

Den 23-02-2010 23:36, Peter Farsinsen skrev:
> Rune Jensen wrote:
>
>>> Tænker du på gzip? Det virker lidt som om, nogle begreber bliver blandet
>>> sammen her. Gzip har ikke noget specifikt med Javascript at gøre, men
>>> virker med alle typer (statiske) dokumenter.
>>
>> Nej, jeg tænker på JS-komprimering via JS. Jeg kan ikke huske hvad det
>> hedder, men det er forholdsvist brugt, og det minder om ZIPping. Det
>> kræver så en udpakker, som følger med siden ved nedhentning, også
>> skrevet i JS.
>
> Fair nok. Jeg har aldrig hørt om det, så er også blank på det.
>
> Lyder dog både dumt og kostbart ;)

Jomen det er jeg enig i.

Men hvis man ikke har mulighed for det, eller ikke kender til GZIP... så
er der nogle, som gør det.

Jeg er ikke selv inde i teknikken, eftersom jeg kun har haft interesse i
det i forbindelse med botbehavior (og jeg bruger ikke selv frameworks),
men her har jeg fundet noget:

http://www.secureworks.com/research/threats/thepacker/

Det er desværre ret teknisk. Måske andre kan uddybe?


MVH
Rune Jensen

---

Rune Jensen wrote:

> http://www.secureworks.com/research/threats/thepacker/
>
> Det er desværre ret teknisk. Måske andre kan uddybe?

Hvad vil du have uddybet?

Jeg synes artiklen 'pretty much says all', herunder den uforholdsmæssige
(mis)brug af javascript, samt problematikken med, at malicious scripts
indlejres i eks. 'packer'.

--
Med venlig hilsen
Stig Johansen

---

Rune Jensen wrote:

> Den 22-02-2010 15:40, Jørgen Farum Jensen skrev:
>
>> Se for eksempel
>> http://webdesign101.dk/showcase/
>
> ja, den virker netop ikke uden JS? For jeg ser ingen drop down ;)
>

Glemmer i ikke at tænke SEO?

Søgemaskiner har jo ingen mulighed for at trawle siden hvis links kun
angives vha JS.

--
Med venlig hilsen
Stig Johansen

---

Stig Johansen skrev:
> Rune Jensen wrote:
>
>> Den 22-02-2010 15:40, Jørgen Farum Jensen skrev:
>>
>>> Se for eksempel
>>> http://webdesign101.dk/showcase/
>> ja, den virker netop ikke uden JS? For jeg ser ingen drop down ;)
>>
>
> Glemmer i ikke at tænke SEO?
>
> Søgemaskiner har jo ingen mulighed for at trawle siden hvis links kun
> angives vha JS.
>
Kun hvis linksene er gemt i et JS array. Den slags menuer
vi her taler om er synlige i udfoldet stand hvis du slår
CSS fra. Slår du JS fra er topmenuen fortsat tilgængelig.
Og det er vist det man mener med unobtrusive,
det vil sige at funktionaliteten skal være bevaret uden
præsentationslag og funktionslag.

--

Med venlig hilsen
Jørgen Farum Jensen
Håndbog i webdesign: http://webdesign101.dk/wwwbog/udgave2/
Webdesign med stylesheets: http://webdesign101.dk/cssbog/
..

---

Den 23-02-2010 23:41, Jørgen Farum Jensen skrev:
> Stig Johansen skrev:

>> Glemmer i ikke at tænke SEO?
>>
>> Søgemaskiner har jo ingen mulighed for at trawle siden hvis links kun
>> angives vha JS.
>>
> Kun hvis linksene er gemt i et JS array. Den slags menuer
> vi her taler om er synlige i udfoldet stand hvis du slår
> CSS fra. Slår du JS fra er topmenuen fortsat tilgængelig.
> Og det er vist det man mener med unobtrusive,

Ikke helt. Man adskiller CSS og JS helt, sådan at CSS er design og JS er
funktion (behaviour). Optimalt er HTMLkoden helt fri for inline CSS og
inline JS, JSen er helt fri for "designkode", som kan laves med CSS.

Dette bevirker, at man ændre CSS og JS uafhængigt, hvilket vil sige, man
vil f.eks. kunne lave en anden styling, lad os sige fra en vertikal menu
til en horisontal ved udelukkende at ændre i CSSen, fordi det er
designdelen man så vil ændre. Man vil også kunne tilføje ny <li>
(menuitem) ved alene at røre HTMLen, her er det indholdet, man ændrer.

Dette gør det nemmere at fejlfinde også.

Idéen er gammel, se f.eks.:
http://www.alistapart.com/articles/behavioralseparation

> det vil sige at funktionaliteten skal være bevaret uden
> præsentationslag og funktionslag.

Ja. Og med præsentationslaget, om muligt, sålænge dette gælder designet.


MVH
Rune Jensen

---

Den 24-02-2010 00:54, Rune Jensen skrev:

> Idéen er gammel, se f.eks.:
> http://www.alistapart.com/articles/behavioralseparation

Optimalt sådan her:

Man starter med noget indhold, ren tekst.

Dette giver man betydning med mark up, hvorefter man validerer

Derefter laves så meget som muligt af designet udfra markuppen, og man
validerer, CSSen lægges i selvstændig fil.

Til sidst lægges funktionerne på, der tjekkes for fejl, og man lægger
JSen i selvstændig fil.

Hvis der opstår fejl i forbindelse med kodningen og test, så ved man,
det må være i det yderste lag, det lag, man er i gang med.

Forvirring kan opstå i og med, der er behavior-elementer i CSS, f.eks.
:hover*). Men eftersom CSS er det andet lag, det næst-vigtigste lag, så
foretrækker jeg man bruger CSS om muligt i stedet for f.eks. onblur.


MVH
Rune Jensen

*) Det har været diskuteret i de forskellige standardiseringsorganer i
forbindelse med bl.a. HTML5 og CSS3, hvor meget man bør "blande"
indhold, design og funktion. Nogle ville f.eks. gerne have
valideringsmuligheder i text-felter i selve HTMLen, f.eks. om en
mailadresse er valid. Jeg ved ikke rigtigt om jeg kan lide den idé.
Se f.eks.:
http://www.w3.org/TR/html5/forms.html#attr-input-pattern

---

Jørgen Farum Jensen:
8X
> Og det er vist det man mener med unobtrusive,
> det vil sige at funktionaliteten skal være bevaret uden
> præsentationslag og funktionslag.

Måske er det bare mig...
Hvordan kan man bevare funktionaliteten, hvis funktionslaget slås fra?
Hvordan åbner man døren, uden håndtaget?

Birger

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

---

Den 24-02-2010 00:58, Birger Sørensen skrev:
> Jørgen Farum Jensen:
> 8X
>> Og det er vist det man mener med unobtrusive,
>> det vil sige at funktionaliteten skal være bevaret uden
>> præsentationslag og funktionslag.
>
> Måske er det bare mig...
> Hvordan kan man bevare funktionaliteten, hvis funktionslaget slås fra?
> Hvordan åbner man døren, uden håndtaget?

Det er også normalt problemet ved 100% JS eller Flash-løsninger, som dog
delvist er løst med Jørgens script, men ideelt set:

Selve det at gå til en anden side kan laves i JS-funktionslaget, men det
ligger allerede som mulighed i mark up (a-tag), som er vigtigere end
funktionslaget.

Markuppen præsenterer, at her er et dørhåndtag, som fører et bestemt
sted hen, hvis det åbnes.

CSSen giver dørhåndtaget et pænt og indbydende udseende, og placerer
det, så det er nemt at nå.

JSen sørger for, at liflig musik strømmer ud når man trykkker...

Eller hvordan man nu formulerer det.

Uden funktionslaget, vil man stadig kunne finde vej, man man vil da
hellere følges på vej af stemningsfuld musik... Uden designlaget, vil
man stadig kunne finde dørhåndtaget, man skal bare lede lidt mere ;)


MVH
Rune Jensen

---

Birger Sørensen skrev:
> Jørgen Farum Jensen:
> 8X
>> Og det er vist det man mener med unobtrusive,
>> det vil sige at funktionaliteten skal være bevaret uden
>> præsentationslag og funktionslag.
>
> Måske er det bare mig...
> Hvordan kan man bevare funktionaliteten, hvis funktionslaget slås fra?
> Hvordan åbner man døren, uden håndtaget?

<a href="...">

Men jeg har udtrykt mig utydeligt - jeg er helt bekendt
med lagdelingen i struktur, præsentation og "behaviour"
og har valgt ordet funktionslag i stedet for adfærdslag.

Kritikken mod UDM4 kan rettes mod at styling af menuen sker
via JS-genereret CSS. Og min pointe er at basal
funktionalitet grundlæggende til stede uanset om JS eller
CSS eller begge dele er "slået" fra - blot man iagttager
at undermenuer ikke kan vises når JS er slået fra. En
pointe programmøren understreger, og som mister sin
betydning hvis topmenuens punkter, som god designskik også
foreskriver, linker til sider der resumerer
sektionsindholdet og i brødteksten har links til de
individuelle sider i sektionen.

--

Med venlig hilsen
Jørgen Farum Jensen
Håndbog i webdesign: http://webdesign101.dk/wwwbog/udgave2/
Webdesign med stylesheets: http://webdesign101.dk/cssbog/
..

---

Jørgen Farum Jensen wrote:

> Kun hvis linksene er gemt i et JS array.

Så vidt jeg kan se, er links netop gemt i JS ( i dit eksempel).

Det er jo ikke kun CSS, der bliver genereret vha JS, men også selve HTML'et.

--
Med venlig hilsen
Stig Johansen

---

Stig Johansen skrev:
> Jørgen Farum Jensen wrote:
>
>> Kun hvis linksene er gemt i et JS array.
>
> Så vidt jeg kan se, er links netop gemt i JS ( i dit eksempel).
>
> Det er jo ikke kun CSS, der bliver genereret vha JS, men også selve HTML'et.
>

Så har du set forkert. Grundlaget for menuen
er en ganske almindelig ul med indlejrede ul'er,
som du kan se i bunden af kildekoden. Og som selvfølgelig
vises hvis slår både JS og CSS fra.

Men det er jo sådan set ikke min opgave at forsvare
et produkt, men kun at pege på at det er en mulig løsning
hvis man gerne vil have en dropdown navbar, der kan
de ting som Rune så omhyggeligt har specificeret.
Den har tjent mig godt i de sidste 6-7 år, men nu
skal der sker noget nyt, så derfor er jeg begyndt
at (gen)bruge "mit eget" menupanel, se
http://webdesign101.dk/

Jeg kan iøvrigt nævne at en af grundene til at jeg
anlagde UDM4 var, at jeg netop var utilfreds med
at forgængeren - Ger Versluis HV-menu (se eksempel
her http://www.webdesign101.dk/xhtml/navigation/hvmenu/)
- forudsatte et eksternt JS array til links og linkstekster.

--

Med venlig hilsen
Jørgen Farum Jensen
Håndbog i webdesign: http://webdesign101.dk/wwwbog/udgave2/
Webdesign med stylesheets: http://webdesign101.dk/cssbog/
..

---

Jørgen Farum Jensen skrev:

> Ulempen er selvfølgelig at det er pløkumuligt at
> gennemskue hvor en eventuel fejl måtte være. Derfor
> mine råd i foregående posting. Menuen fungerer, det
> er kun topmenu punkterne, der har forkerte farver.

Jeg synes også at det er underligt at man ikke kan se
en css-fil i http://qusqo.homepage.dk/

Det er rigtigt - det er pløkumiligt at fejlsøge i sådan
noget. Vis kilde vister bare en masse javascript, som
man så skal forholde sig til.

http://www.dr.dk/drnetradio/index.dr?evt=k&name=p4_fyn
har samme problem - de skjuler også deres fejl på en fej
måde, så det ikke er nemt at vejlede dem.

Det gør det umuligt at høre netradio i IE8.

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

---

Den 22-02-2010 23:18, Allan Vebel skrev:

> http://www.dr.dk/drnetradio/index.dr?evt=k&name=p4_fyn
> har samme problem - de skjuler også deres fejl på en fej
> måde, så det ikke er nemt at vejlede dem.
>
> Det gør det umuligt at høre netradio i IE8.

Jeg tror også, det er betinget af kravet om cross-browser, for hverken
lyd eller billede er integreret dele af HTML4. Der er mig bekendt ingen
universel løsning på at indlægge streaming/video/lyd på en hjemmeside
uden proprietær plugin/ActiveX (det sidste er et gennemhullet som en si
for sikkerhedshuller, det samme er Flash), men hvis HTML-guderne og
Google vil, kan det være det kommer før end ventet, måske... i HTML5.

http://www.version2.dk/artikel/13964-google-opkoeb-kan-give-html5-knivskarp-video

At det så er obsfuskatet kode på DRs side, er sikkert for at holde hele
kodeblokken på et minimum i kb (en form for ZIPping), men ja, det gør
det skidesvært at fejlsøge, og det kan koste i den anden ende...


MVH
Rune Jensen