Ophæv float hvis div bliver længere end skærmbillede

<ole>

I 9 ud af 10 tilfælde bruges float på en misforstået, uhensigtsmæssig og unødvendig måde.

Float er fint, når man f.eks. ønsker at lave tekstomløb ved et billede -  display:inline-block er den CSS-kommando, som er beregnet til at placere to block elementer (f.eks. DIV) ved siden af hinanden. Bruger du float skal du 'hacke' dig ud af bl.a. det problem, du sidder med nu.

Det er ikke uden grund, float ofte kaldes WWW's mest abused feature - og at den på mange måder har overtaget TABLE's plads på dén trone  =)

/mvh
</bole>

Jeg kiggede på inline-block, men efter overvejelse har jeg valgt at bruge float til at placere min indkøbskurv, idet problemerne med at bruge inline-block og den ændrede formatering af elementer pga. white-space i html-koden ville gøre min kode sværere at vedligeholde.

Når min indkøbskurv følger brugerens scroll, får DIV'en denne klasse i stedet for dens oprindelige med float:


Principielt ville jeg vel have samme problem uanset hvordan jeg positionerer min DIV (så længe den følger brugerens scroll), idet problemet som sådan ikke er positioneringen, men størrelsen af DIV'en der giver problemet (at DIV'en bliver så lang, at den ikke kan være i skærmbilledet)?

Min første tanke var at "måle" brugerens browservindue, og så lade mit script fjerne fixed-klassen når længden på DIV'en var større end længden på browservinduet.

Ja, problemet er et designproblem. Det er ofte uhensigtsmæssigt at lade elementer følge scroll - og det er altid uhensigtsmæssigt, hvis elementerne kan udvide sig uden styring.

Man kan altid hacke sig ud af designproblemer, og du kan i pricippet godt bruge JavaScript som et hack - men det løser ikke det grundlæggende designproblem.

Med hensyn til white space opfører elementer med inline-block sig fuldstændig som alle inline elementer har opført sig siden WWW's og HTML's Dag Ét. Det burde ikke kunne gøre vedligeholdelse vanskeligere ... tværtimod.

Til gengæld ændrer float fundamentalt på dokumentets flow og mefører bunker af vedligeholdelses problemer. Tusinder af tråde i alverdens udviklerfora vidner taler sit tydelige sprog  *o)

Det der kan gøre det vanskeligere at overskue er at følgende ikke renderes på samme måde ved brug af inline-block:


Når der træffes valg, er der også altid fravalg, lige så vel som ikke at vælge også er et valg.

Jeg har valgt at det er hensigtsmæssigt at min indkøbskurv følger brugerens scroll, idet brugeren derved hele tiden kan have et overblik over hvad der er i kurven, også selvom han/hun er scrollet 3 skærmsider ned for at tilføje noget i kurven.

Det giver nogle komplikationer, f.eks. at indkøbskurven kan blive så lang at det pludselig ikke er hensigtsmæssig at den følger brugeren, idet en del af den dermed ikke er synlig.

Design er på mange måder en afvejning af flere elementer, i denne situation især en afvejning af fordele/ulemper vejet op imod brugeroplevelsen.

I forhold til mit designproblem og at du bragte inline-block på banen, kan jeg stadig ikke se at min problemstilling ville være anderledes ved brug af inline-block frem for float.

Jeg er enig i at float påvirker dokumentets flow, men i mit tilfælde er det ikke float jeg har problemer med.

Nej, float er ikke dit øjeblikkelige problem, men ligesom jeg ofte pointerer det uhensigtsmæssige i brugen af tabeller til layoutformål, gør jeg det samme ved float. Derudover udsprang kommentarerne om float oprindelig af ordlyden i dit spørgsmål  =)

Naturligvis renderes disse to kode ikke ens:


På fuldstændig samme måde som disse to ikke gør det:


Det er jo 'stenalder HTML', og derfor ville det være overraskende, hvis det forholdt sig anderledes.

Sæt en rimelig max højde på kurven og vertikal scroll på overflow

eller lav et script der holder øje med højden af din kurv og hvis den bliver => end browser højden slår du scroll fra

mener slå fixed pos fra

#6+7: Det er altid en mulighed at scripte sig ud af problemet, men det ville være en kedelig nødløsning. Det er bedre at løse det egentlige problem  =)

mikkelnh...> Det skrev jeg også selv som den løsning jeg forventede var en mulighed.

olebole...> Jeg må i tænkeboks omkring hvordan jeg vil løse problemet, hælder nok mest til at scripte mig ud af mit problem, idet en scrollbar vil give andre udfordringer i forhold til mit design.

Det vigtigste for mig var at få andre på banen omkring fordele/ulemper og en belysning af muligheder, og det har jeg fået.

Du samler stadig ikke på point?

En indkøbskurv med begrænset højde, der ligger fast, vil helt klart være mest brugervenligt. Så kan brugeren stå, hvor somhelst i et vareskærmbillede og tjekke/overskue sin kurv - uden at skulle scrolle væk fra det, som er det væsentlige. 'Det væsentlige' i denne forbindelse er den vare, hun er inde at kikke på, og som fik hende til at tænke på noget, hun lige skulle tjekke i sin kurv.

Det er slet ikke usandsynligt, at en brugervenlig løsning med en scrollbar i varekurven ikke svinger med dit design. Det er derfor, skriver jeg, at dit problem er et designproblem.

Du har ikke gennemtænkt brugervenligheden i designfasen, hvilket er, hvad du nu tager høvlene for  =)

PS: og nej tak, jeg samler stadig ikke point  =)

Sæt en minimumshøjde i pixels - en maksimumshøjde i procent - samt overflow:auto. Så laver du en rigtig brugervenlig kurv. Resten af din opgave er så bare at tilpasse designet til den gode løsning.

Det er nu engang mest hensigtsmæssigt at tilpasse sko, så de passer til et par gennemsnitsfødder - i stedet for at skulle høvle fødderne til, så de passer til skoene  *o)

Jeg har jo netop tænkt brugervenligheden ind, idet kurven har en fast placering (øverste højre hjørne i browseren), uanset hvor brugeren er i vareoversigten.

Andre hjemmesider vælger at kurven er fastlåst i f.eks. toppen af sidens design, hvilket i mine øjne ikke er særlig brugervenlig. En typisk vareoversigt på min side fylder måske 3 skærmbilleder, og hvis brugeren er scrollet ned i bunden af siden vil kurven med en sådan løsning ikke være synlig.

På en hjemmeside med f.eks. elektronik betyder det måske ikke så meget om brugeren kan se hvad der er i kurven hele tiden, men uden at ville røbe mit projekt, mener jeg at det er vigtigt for mine brugere at kunne se nøjagtigt hvad de har stoppet i kurven.

Reelt formoder jeg ikke at længden af min kurv er et stort problem, idet mine kunder oftes vil bestille et få antal varer af gangen og dermed vil holde sig indenfor sidens længde.

Tilføjes en vare i min kurv fylder denne 2-3 linjer, hvilket jeg også overvejer at ændre på, men som skrevet tidligere vil alle beslutninger betyder kompromier i den ene eller anden retning.

Som jeg skrev er jeg nu gået i tænkeboks omkring hvordan jeg vil løse min uhensigtsmæssighed, enten via tilpasning af design, eller via en kodeløsning.

Ja, du har tænkt over brugervenlighed, men det har ikke medført en brugervenlig løsning. Det er ikke nok at beslutte sig for at gøre det bedre end de andre, hvis man bare ender med at gøre det anderledes - men lige skidt  =)

Jeg forstår ikke "Reelt formoder jeg ikke at længden af min kurv er et stort problem", når spørgsmålet udtrykker det stik modsatte. Højden af din kurv er da helt uomtvisteligt et problem, hvis kurven kan blive for høj til skærmbilledet - eller tvinger brugeren til at bruge en browserhøjde, hun ikke ønsker.

"Tilføjes en vare i min kurv fylder denne 2-3 linjer, hvilket jeg også overvejer at ændre på"

Ja, det er langt udenfor debat, at du har designproblemer. Den slags skulle du have opdaget i Photoshop ... længe inden du begyndte at kode. Du har lavet en klar 'ommer'.

Jeg ved ikke, hvad du kalder det, men på et webbureau havde designeren fået det tilbage i hovedet, sammen med en røffel om at udføre sit arbejde ordentligt.

Det ved du jo inderst inde godt selv, for var det ikke tilfældet, ville der jo ikke være brug for at gå i tænkeboks på dette tidspunkt. Så ville du jo bare kunne kode løs  *o)

Jeg har vurderet flere af mine potentielle konkurrenters hjemmeside, hvoraf en enkelt er positioneret world wide med en 3-cifret million-omsætning.

Ud fra det jeg har set, og min egen viden selvfølgelig, har jeg besluttet hvordan jeg gerne vil have mit design til at se ud og hvordan jeg gerne vil have det til at fungere.

Jeg er ikke designer og har heller ikke selv designet mit layout 100%, men uanset hvem jeg tidligere har lavet hjemmeside for, og hvor mange penge der har været betalt for designet, så har jeg aldrig været ude for at der ikke var designmæssige ændringer med baggrund i programmeringsmæssige udfordringer.

Jeg har truffet nogle valg, og deraf også nogle fravalg. Uanset hvilken løsning jeg vælger at anvende, gør jeg det ud fra nogle designmæssige og funktionalitetsmæssige ønsker. Der vil altid være nogen der ikke er enige i de valg.

I forhold til at min world wide konkurrent har et budget, og dermed en ressource-ramme, der ligger milevidt over det jeg arbejder med, så mener jeg at min hjemmeside (når jeg engang bliver færdig), fungerer væsentlig bedre end både den og mine øvrige konkurrenters hjemmeside.

Jeg takker for dine input, men jeg tror lige så godt vi kan stoppe debatten her, idet jeg ikke formoder vi bliver enige.

Det har ikke været min mening at forsøge at overbevise dig om at mine valg er rigtige, men jeg har forsøgt at vise at mine valg er truffet efter grundige overvejelser, og dermed også afvejelse af fordele og ulemper ved mine valg.

Hvis man gør som konkurrenterne, sikrer man i hvertfald, man ikke skiller sig ud. Anyway, så har du ret i, at dine argumenter ikke overbeviser mig - og at vi nok ikke bliver enige  =)