|
| Menu-div skaber scrollbar i IE7 Fra : Ukendt |
Dato : 14-09-07 14:07 |
|
Hej,
Denne side har en menu:
http://www.time4art.dk/
Som tager udgangspkt i denne:
http://www.dynamicdrive.com/dynamicindex1/chrome/index.htm
Det virker fint i IE6, men i IE7 kommer der horiontal scrollbar når siden
indlæses. Denne scrollbar forsvinder når man "aktiverer" objentet, dvs.
kører musen henover et menu-punkt, som har et undermenu-pkt. DIV'en bliver
synlig.
Jeg har dog ændret det, så det min menu ligger i en TABLE og ikke i en UL
som det originalt gøres i. Submenuer bliver fortsat renderet ud i DIV'er som
i originalen.
Er der nogle som har et bud på hvorfor dette sker? (originalen virker jo
fint i IE70 som ses på Dynamics side, højrestillet.)
Venligst
Arne Johansen
| |
Ukendt (14-09-2007)
| Kommentar Fra : Ukendt |
Dato : 14-09-07 14:28 |
|
> Det virker fint i IE6, men i IE7 kommer der horiontal scrollbar når siden
> indlæses. Denne scrollbar forsvinder når man "aktiverer" objentet, dvs.
> kører musen henover et menu-punkt, som har et undermenu-pkt. DIV'en bliver
> synlig.
Det skal lige nævnesat det også sker i IE 6, når man kører siden sammen,
dvs. gør browser-venidue smallere.
Det forsvinder når man fjerner undermenu-punkter. Det er KUN når DIV'erne
til submenuer er renderet med ud i html. (som usynlig ved side indlæsning)
Venligst
| |
Allan Vebel (14-09-2007)
| Kommentar Fra : Allan Vebel |
Dato : 14-09-07 16:16 |
|
Arne Johansen skrev:
> Jeg har dog ændret det, så det min menu
> ligger i en TABLE og ikke i en UL som det
> originalt gøres i.
Hvorfor? Har du samme fejl med den originale?
--
Allan Vebel
http://html-faq.dk
| |
Ukendt (14-09-2007)
| Kommentar Fra : Ukendt |
Dato : 14-09-07 16:58 |
|
"Allan Vebel" <spam@do.not> skrev i en meddelelse
news:46eaa5b8$0$90265$14726298@news.sunsite.dk...
> Arne Johansen skrev:
>
>> Jeg har dog ændret det, så det min menu
>> ligger i en TABLE og ikke i en UL som det
>> originalt gøres i.
>
> Hvorfor? Har du samme fejl med den originale?
>
> --
> Allan Vebel
> http://html-faq.dk
>
Jeg genbruge en menucontrol som renderer det ud som table.
Spørgsmålet er om renderingen reagerer forskelligt, om en DIV ligger i samme
(parent) celle med en TABLE eller en UL?
Venligst
| |
Ukendt (14-09-2007)
| Kommentar Fra : Ukendt |
Dato : 14-09-07 20:04 |
|
>> Jeg har dog ændret det, så det min menu
>> ligger i en TABLE og ikke i en UL som det
>> originalt gøres i.
>
> Hvorfor? Har du samme fejl med den originale?
>
> --
> Allan Vebel
> http://html-faq.dk
>
Så er der spolet tilbage så det hele ligger i UL, som i originalen. (dog kun
i udviklingsmiljø)
Det virker som om at de 200px som DIV'en er, lægges på sidens definerede
bredde, dvs. ialt 1100px;
Indenfor de 1100 px er der så scrollbar horisontalt, som forsvinder når
DIV'en bliver sat til visibel ved hover.
Hmmm....giver det mening? :)
Venligst
| |
Ukendt (14-09-2007)
| Kommentar Fra : Ukendt |
Dato : 14-09-07 20:10 |
|
> Så er der spolet tilbage så det hele ligger i UL, som i originalen. (dog
> kun
> i udviklingsmiljø)
>
> Det virker som om at de 200px som DIV'en er, lægges på sidens definerede
> bredde, dvs. ialt 1100px;
> Indenfor de 1100 px er der så scrollbar horisontalt, som forsvinder når
> DIV'en bliver sat til visibel ved hover.
>
> Hmmm....giver det mening? :)
>
> Venligst
Jow - sørme så.
Primitiv test af postulat:
Når man kører browser vindue sammen så den flugter kanter på siden, så har
scrollbar en px bredde på 200px.
Denne class er DIV'ens, og når width ændres til 100px så halveres
scrollbaren til 100px ved tryk på F5. Primitiv måde at forklare det på, men
HVORFOR pokker gør den det?
..dropmenudiv
{
position: absolute;
top: 0px;
border: 1px solid #BBB; /*THEME CHANGE HERE*/
border-bottom-width: 0;
font: normal 12px Verdana;
line-height: 18px;
z-index: 100;
background-color: white;
width: 100px;
visibility: hidden;
filter:
progid:DXImageTransform.Microsoft.Shadow(color=#CACACA,direction=135,strength=4);
/*Add Shadow in IE. Remove if desired*/
text-align: left;
}
| |
Jørgen Farum Jensen (14-09-2007)
| Kommentar Fra : Jørgen Farum Jensen |
Dato : 14-09-07 17:09 |
|
Arne Johansen skrev:
> Jeg har dog ændret det, så det min menu ligger i en TABLE og ikke i en UL
> som det originalt gøres i. Submenuer bliver fortsat renderet ud i DIV'er som
> i originalen.
Som Allan skriver, hvorfor det?
>
> Er der nogle som har et bud på hvorfor dette sker? (originalen virker jo
> fint i IE70 som ses på Dynamics side, højrestillet.)
Jeg synes du har større problemer end det -
menuen er venstrejusteret i Firefox. Din
side rammer klokken ved 217 fejl!!!
Et bud på det konkrete spørgsmål er at du
har en ul og/eller nogle li'er som ikke
har en eksplicit bredde/padding når siden
indlæses, først får det ved mouseover.
Det sker muligvis i et af de JavaScripts, du
bruger, jeg har ikke kigget så nøje efter.
Du bruger 18 kilobyte JavaScript for at fremkalde
en time-delay effekt på undermenuerne, som virker
irriterende langsomt og absolut ikke tilføjer
siden noget. I det hele taget bruger siden for
meget båndbredde for at præsentere nogle meget
enkle budskaber.
--
Med venlig hilsen
Jørgen Farum Jensen
Håndbog i webdesign: http://webdesign101.dk/wwwbog/udgave2/
Webdesign med stylesheets: http://webdesign101.dk/cssbog/
..
| |
Ukendt (14-09-2007)
| Kommentar Fra : Ukendt |
Dato : 14-09-07 17:29 |
|
"Jørgen Farum Jensen" <jfjenzen@yahoo.dk> skrev i en meddelelse
news:46eab211$0$47434$edfadb0f@dread11.news.tele.dk...
> Arne Johansen skrev:
>
>> Jeg har dog ændret det, så det min menu ligger i en TABLE og ikke i en UL
>> som det originalt gøres i. Submenuer bliver fortsat renderet ud i DIV'er
>> som i originalen.
>
> Som Allan skriver, hvorfor det?
>>
>> Er der nogle som har et bud på hvorfor dette sker? (originalen virker jo
>> fint i IE70 som ses på Dynamics side, højrestillet.)
>
> Jeg synes du har større problemer end det -
> menuen er venstrejusteret i Firefox. Din
> side rammer klokken ved 217 fejl!!!
Jøsses - hvis alt var 100% iorden, så var der vel ingen grund til at søge
info. Og ja, jeg var helt klar over det med firefox.
Tak for dit svar. Ikke en dyt bevendt. Men så fik vi sat tal på fejlene.
Venligst
| |
Jørgen Farum Jensen (14-09-2007)
| Kommentar Fra : Jørgen Farum Jensen |
Dato : 14-09-07 21:21 |
| | |
Philip Nunnegaard (14-09-2007)
| Kommentar Fra : Philip Nunnegaard |
Dato : 14-09-07 23:57 |
|
> http://diveintomark.org/archives/2003/05/05/why_we_wont_help_you
Det link minder mig om, når jeg spurgte her inde for 5 år siden.
Ingen kvalificerede svar, fordi min kode ikke var bare i nærheden af at
validere.
Validatoren var dog heller ikke til megen hjælp, når man ikke vidste, hvad
man skulle gå efter.
Forleden oplevede jeg f.eks., at den viste 6 fejl på en side.
Sandheden var, at der kun var én fejl! De resterende 5 fejl var afledt af
denne ene fejl;
Fejlen kom af en ikke afsluttet <b> (sorry! ved godt at hardcore-folket
disser <b> og mener, at man skal bruge <strong>). Dette fik den til at gå
kold over en for tidlig </p>, en for tidlig </div> og endnu en for tidlig
</div> (fordi det lå i en div inde i en anden div) - og så selvfølgelig
dermed også </body> og </html>.
Er man uerfaren, virker det for uoverskueligt. De 7 fejl kunne jeg leve med,
fordi det var tilstrækkeligt overskueligt til, at jeg kunne tage dem fra en
ende af, men som uerfaren har man jo gerne 100-200 fejl - hvoraf de 100 er
ens fejl, der passende kunne vises på en anden- og mere overskuelig måde: I
stedet for at vise det som 100 enkeltstående fejl, burde den vise det som 1
fejl, der forekommer 100 gange. Det gør det mere overskueligt!
Jeg behøver kun at få at vide én gang, at <b> skal afsluttes med </b>, og at
dette sjusk i øvrigt forekommer 100 gange!
Endnu værre: Som uerfaren kunne jeg ikke en gang få validatoren til at vise
fejlene, fordi jeg ikke anede en skid om doctype-erklæringen.
Ingen til at forklare mig, at jeg skulle indsætte dette:
<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Strict//EN"
" http://www.w3.org/TR/xhtml1/DTD/xhtml1-strict.dtd"> (husker ikke, hvad man
skulle indsætte for html4).
Jeg forstod ikke engang, hvorfor jeg skulle indsætte dette i min kode, for
det gav jo ingen synlig forskel i mine browsere.
Kort sagt: Jeg anså det bare for noget pseudointellektuelt pladder for
førsteårsstuderende nørd-wannabes.
Jeg håber, at teknikken en dag gør det muligt for w3c at lave en validator,
der for det første er på dansk (jeg er elendig til at forstå engelsk og
andet kavdervældsk) og for det andet opfylde ovenstående ønsker om
forenkling af fejlmeldingerne. - herunder skelne mellem regulære fejl og så
fejl, der bare er afledt af denne ene fejl, samt ovenstående ønske om
gruppering af fejltyper.
Resultatet blev, at jeg valgte at opgive ævred og helt skide standarderne et
langt stykke i mange år efter (indtil for et års tid siden) efter devicen:
"Hvorfor stræbe efter det, når jeg ikke engang kan få fejlmeldinger, jeg kan
forstå?".
Yderligere problemer får man, når man bruger asp eller php i sin kode med
bruger-interaktivitet. Så kan man ikke gardere sig imod, at brugerne sjusker
med afslutningen af fed og kursiv. (Jeg er dog begyndt at bruge en
WYSIWYG-teksteditor, der dæmmer op for en del af den slags).
| |
Jørn Andersen (15-09-2007)
| Kommentar Fra : Jørn Andersen |
Dato : 15-09-07 01:59 |
|
On Sat, 15 Sep 2007 00:56:46 +0200, "Philip Nunnegaard"
<philip@fjerndettehitsurf.dk> wrote:
>> http://diveintomark.org/archives/2003/05/05/why_we_wont_help_you
>
>Det link minder mig om, når jeg spurgte her inde for 5 år siden.
>Ingen kvalificerede svar, fordi min kode ikke var bare i nærheden af at
>validere.
>
>Validatoren var dog heller ikke til megen hjælp, når man ikke vidste, hvad
>man skulle gå efter.
>Forleden oplevede jeg f.eks., at den viste 6 fejl på en side.
>Sandheden var, at der kun var én fejl! De resterende 5 fejl var afledt af
>denne ene fejl;
Ud over din glimrende udredning, kan man tilføje et råd: Ret fejlene
enkeltvis fra oven og så revalidér, så forsvinder fejlene "i klumper".
Når man har prøvet det nogle få gange, så finder man hurtigt de fejl,
som gentager sig - eller forårsager afledte fejl.
Mvh. Jørn
--
Jørn Andersen,
Brønshøj
| |
Philip Nunnegaard (15-09-2007)
| Kommentar Fra : Philip Nunnegaard |
Dato : 15-09-07 02:14 |
|
> Ud over din glimrende udredning, kan man tilføje et råd: Ret fejlene
> enkeltvis fra oven og så revalidér, så forsvinder fejlene "i klumper".
> Når man har prøvet det nogle få gange, så finder man hurtigt de fejl,
> som gentager sig - eller forårsager afledte fejl.
En rigtig god teknik, som jeg burde bruge mere systematisk.
Jeg opdagede selv muligheden ved at trykke på "Revalidate" efter et par
rettelser - og pludselig var der forsvundet mere end de par fejl, jeg havde
rettet.
| |
Allan Vebel (16-09-2007)
| Kommentar Fra : Allan Vebel |
Dato : 16-09-07 00:13 |
|
Philip Nunnegaard skrev:
> Det link minder mig om, når jeg spurgte her
> inde for 5 år siden.
Jeg kan ikke lige huske dig fra den tid, kaldte du
dig noget andet dengang?
> Ingen kvalificerede svar, fordi min kode ikke var
> bare i nærheden af at validere.
Ja, vi er hårde
> som uerfaren har man jo gerne 100-200 fejl - hvoraf
> de 100 er ens fejl, der passende kunne vises på en
> anden- og mere overskuelig måde
Det er jo bare en maskine, men den er dog blevet
meget bedre med årene. I sluthalfemserne skulle man
godt nok tænke dybt over fejlmeddelelserne.
> Resultatet blev, at jeg valgte at opgive ævred og helt
> skide standarderne et langt stykke i mange år efter
Det er netop det man ikke skal gøre, tag bolden op og
spil den videre. Internettet er kommet for at blive, og det
udvikler sig hurtigere end biler og anden teknologi.
Da jeg lavede min første hjemmeside i 1998, var der
ikke noget der hed validering.
> Yderligere problemer får man, når man bruger asp
> eller php i sin kode
Det er jeg ikke enig i - det er blot at tænke den slags
ind i designet.
--
Allan Vebel
http://html-faq.dk
| |
Philip Nunnegaard (16-09-2007)
| Kommentar Fra : Philip Nunnegaard |
Dato : 16-09-07 01:31 |
|
> Jeg kan ikke lige huske dig fra den tid, kaldte du
> dig noget andet dengang?
Nej. Jeg hed det samme, men jeg var ikke nær så aktiv dengang, som jeg er i
dag.
> Det er jo bare en maskine, men den er dog blevet
> meget bedre med årene. I sluthalfemserne skulle man
> godt nok tænke dybt over fejlmeddelelserne.
Det skulle man så også i 2002. Eller også er jeg bare blevet bedre til at
forstå dem.
>> Resultatet blev, at jeg valgte at opgive ævred og helt
>> skide standarderne et langt stykke i mange år efter
>
> Det er netop det man ikke skal gøre, tag bolden op og
> spil den videre. Internettet er kommet for at blive, og det
> udvikler sig hurtigere end biler og anden teknologi.
Jeps. Jeg savnede bare en mur at spille bolden op ad.
>> Yderligere problemer får man, når man bruger asp
>> eller php i sin kode
>
> Det er jeg ikke enig i - det er blot at tænke den slags
> ind i designet.
Problemet er, når man ikke tænker det ind fra version 1.
Hvad pokker skal jeg gøre ved det, hvis en bruger poster en besked, hvor han
kursiverer sin tekst, men ikke lige får den afsluttet?
Det kan jeg jo ikke gardere mig imod, at han/hun gør, med mindre jeg skal
køre en megatung funktion ved hver post, der gennesøger indlægget ord for
ord for alle tænkelige html-tags for at få dem afsluttet. Men hvad der
ligger i databasen fra 2002, kan jeg jo ikke rigtigt ændre på nu 5 år efter.
| |
Allan Vebel (16-09-2007)
| Kommentar Fra : Allan Vebel |
Dato : 16-09-07 21:33 |
|
Philip Nunnegaard skrev:
> Hvad pokker skal jeg gøre ved det, hvis en
> bruger poster en besked, hvor han kursiverer
> sin tekst, men ikke lige får den afsluttet?
Det er mange forskellige cms-systemer, og
derfor lige så mange måder at gøre det på.
Jeg har set systemer hvor man blot skulle
markere et ord, og derefter klikke på kursiv-
knappen, så sætter systemet selv de rigtige
koder ind - på samme måde som et hvilket
som helst tekstbehandlingssystem.
> der gennesøger indlægget ord for ord for alle
> tænkelige html-tags for at få dem afsluttet.
Det kommer jo an på hvordan dit system er
opbygget. Der findes også systemer hvor html-
kode bare bliver ignoreret.
> Men hvad der ligger i databasen fra 2002, kan
> jeg jo ikke rigtigt ændre på nu 5 år efter.
Det kan man faktisk godt - det er mere om det
har noget formål.
--
Allan Vebel
http://html-faq.dk
| |
Philip Nunnegaard (17-09-2007)
| Kommentar Fra : Philip Nunnegaard |
Dato : 17-09-07 06:20 |
|
> Det er mange forskellige cms-systemer, og
> derfor lige så mange måder at gøre det på.
Jeg bruger generelt ikke færdige CMS-systemer, da jeg ikke kan gennemskue
andres kode så godt, at jeg ville være i stand til at implementere det i- og
skræddersy det til mine hjemmesider.
> Jeg har set systemer hvor man blot skulle
> markere et ord, og derefter klikke på kursiv-
> knappen, så sætter systemet selv de rigtige
> koder ind - på samme måde som et hvilket
> som helst tekstbehandlingssystem.
Hvad der er postet indenfor det seneste år er sådan set ikke noget problem,
netop fordi jeg bruger en WYSIWYG-teksteditor (TinyMCE) i alle formularer,
der gør alt benarbejdet for mig.
Men det gjorde jeg ikke før. I det hele taget holdt jeg mig i en periode
langt væk fra alt, hvad der bare lugtede af JavaScript, fordi mange af de
scripts, man kunne hente forskellige steder, var IE-only.
> Det kommer jo an på hvordan dit system er
> opbygget. Der findes også systemer hvor html-
> kode bare bliver ignoreret.
I php er der selvfølgelig strip_tags. Den findes ikke mig bekendt i asp, som
jeg brugte dengang.
Før i tiden var det bare et simpelt textarea i formularen, hvor der var frit
slaw mht. anvendelse af almindeligt brugte html-koder.
Derfor er de ting, brugerne (mig selv inklusive) postede, noget forfærdeligt
rod.
I en enkelt af sektionerne er alt tilgængeligt tilbage til foråret 2002,
hvor jeg var totalt newbie på serverside-området.
| |
Allan Vebel (17-09-2007)
| Kommentar Fra : Allan Vebel |
Dato : 17-09-07 12:27 |
| | |
Ukendt (14-09-2007)
| Kommentar Fra : Ukendt |
Dato : 14-09-07 20:39 |
|
"Arne Johansen" <ras[at]vip.cybercity.dk> skrev i en meddelelse
news:46ea876e$0$90264$14726298@news.sunsite.dk...
> Hej,
>
> Denne side har en menu:
> http://www.time4art.dk/
>
> Som tager udgangspkt i denne:
> http://www.dynamicdrive.com/dynamicindex1/chrome/index.htm
>
>
> Det virker fint i IE6, men i IE7 kommer der horiontal scrollbar når siden
> indlæses. Denne scrollbar forsvinder når man "aktiverer" objentet, dvs.
> kører musen henover et menu-punkt, som har et undermenu-pkt. DIV'en bliver
> synlig.
>
> Jeg har dog ændret det, så det min menu ligger i en TABLE og ikke i en UL
> som det originalt gøres i. Submenuer bliver fortsat renderet ud i DIV'er
> som i originalen.
>
> Er der nogle som har et bud på hvorfor dette sker? (originalen virker jo
> fint i IE70 som ses på Dynamics side, højrestillet.)
>
Ok - årsagen er fundet. Det er den DIV som udgør dropdownmenuen. Og som er
hidden ved sidens indlæsning. Det duer vist ikke at have den liggende inde i
cellen, da det virker hvis jeg flytter den ud af tabel-struktur. Det er en
løsning, men det ødelægger lidt min .net-menucontrol, hvis jeg skal smide
½-delen af menuen (dynamisk opbygget) ud i en "ekstern plads-holder. ØV,
hvis det er tilfældet"
Hvad kan man gøre rent html/css-mæssigt?
TD/TD'en hvori det hele ligger:
<tr>
<td style="width: 100%; background-image: url(Images/1w_red.gif);
background-repeat: repeat-x;
text-align: right; padding-right: 20px;">
<div class="chromestyle" id="chromemenu">
<ul>
<li><a href=" http://www.dynamicdrive.com">Home
<li><a href="#" rel="dropmenu1">Resources</a></li>
<li><a href="#">News</a></li>
<li><a href="#">Search</a></li>
</ul>
</div>
<div id="dropmenu1" class="dropmenudiv">
<a href="/Default.aspx?id=d1dd813b-3a76-420b-8499-6135a54fe269">Viden om
perler</a>
<a href="/Default.aspx?id=38e47a3d-1026-4558-b1d8-74eda1e11510">Viden om
BLIB</a>
<a href="/Default.aspx?id=4a1255e3-f9be-4d31-b610-5d00c0e7328d">Viden om
opaler</a>
<a
href="/Default.aspx?id=9556aa64-a790-43ea-a95c-795fb9947ee5">HomeParty</a>
<a
href="/Default.aspx?id=80fe9284-2845-42ce-9023-b103e6af23fe">Viden om
ædelsten</a>
</div>
<script type="text/javascript">
cssdropdown.startchrome("chromemenu")
</script>
</td>
</tr>
| |
|
|