Horizontale sub-menu's verschijnen achter adobe

[pbd4499]

Als we een adobe documentje in internet explorer hebben en we klikken dan op een menu knop waar vervolgens weer een/meerdere submenu's uit voortvloeien dan verschijnen deze submenu's achter een PDF document.

Als er een gewoon image of tekst of anders staat dan ligt het submenu wel bovenop.

Heeft iemand een oplossing voor dit probleem?

 

[defietser]

Misschien maar daarvoor hebben we wel wat info nodig zoals een online vb of de html, css en eventueel javascript codes.
Mvg
Defietser

 

[That Guy]

Dat zou inderdaad wel handig zijn.

Even redenerend, ik neem aan dat je de pfdjes in een iframe oid. openen. In dat geval zou je even met de css-property z-index kunnen kijken.

 

[pbd4499]

Ik weet het maar helaas kan ik het niet online zetten want het gaat hier om een interne site (intranet)

In ieder geval dank voor de tip en ik ga de z-index testen

 

[pbd4499]

Ik heb de z-index in zowel het css voor de knop als voor die van het iframe aangepast maar de subknoppen blijven achter het iframe steken.

Als ik achter src="" heb staan werkt het menu goed maar weldra daar de pdf-bestandsnaam wordt ingevuld verschijnen de subknoppen weer achter het pdf.

 

[defietser]

Post de code dan hier.
Want zo maar iets uit het duimpje zuigen gaat voor mij niet op. Ik heb liever de code zodat ik kan uitzoeken wat er mis gaat of niet.
Mvg
defietser

 

[csshunter]

Nou, ik heb 's efkens wat zitten experimenteren met een uitklapmenu dat over een pdf in een iframe moet kunnen klappen, maar het lukt me aan geen kanten.
Zo ongeveer alle varianten van { position: absolute; } en { position: relative; } in combinatie met z-indexen gebruikt, flow-volgorde van iframe en #menu omgewisseld, proberen te floaten, enz.: niets hielp.

• Maar bij een gewone html-pagina in een iframe kan er wel prachtig een menu overheen uitklappen!

Het lijkt er zwaar op, dat de werkbalken met knoppen die rond het pdf'je zitten (waarmee je de pdf kunt vergroten, opslaan, printen, enz.) gewoon niet toestaan dat er iets overheen geplakt wordt. Op zich eigenlijk ook niet zó onlogisch, want het zijn natuurlijk bedieningselementen waarvan men kennelijk vindt dat die altijd bereikbaar moeten zijn.

• Alleen de uitrolvakjes van de browser zelf zijn de baas over de pdf-knoppen en -inhoud: die komen er wel overheen, zie screenshot.

Wat dan wel?

• Menu als verticaal harmonica-menu aan de linkerkant?
• Pdf's laten open in nieuw venster?
• Idem, met op de pagina van het menu telkens een preview / thumbnail van een screenshot-img van de pdf, op het moment dat je over een menu-item hovert?
• Voor alle werkplekken van het intranet een kantelscherm laten aanrukken, dat rechtop kan staan en meer ruimte biedt voor een uitrolmenu aan de bovenkant?

Met vriendelijke groet,
CSShunter

 

[pbd4499]

Ja, die bevindingen heb ik ook opgedaan tijdens een paar testen en heb eveneens geexperimenteerd met absolute, relative etc.

Als ik src="" laat staan (zonder geopend pdf erin dus) dan valt het menu wel netjes over de oppervlakte als de z-index hoger staat ingesteld dan de plek waarin we het pdfje willen openen.

Wordt nu src="naampdf.pdf" dan krijgt het pdf op de een of andere manier de overhand en trekt zich niets meer van de z-index aan. Wellicht een bug in Adobe dan.

 

[pbd4499]

Ik heb het gevonden: er zit ergens een bug in een javascript van Dreamweaver. Met het plaatsen van een ouder java script werkt het.

 

[csshunter]

Hè? :shocked:
Hoe kan dat nou? Is het dan geen gewoon iframe met een pdf erachter geopend, maar iets met een speciaal javascript?
Wel nieuwsgierig!
Kan je dat javascript ergens uploaden, zodat we kunnen zien wat dat is? Want zou wellicht voor meer mensen bruikbaar kunnen zijn, die een "inwendig pdf-je" op hun site willen zetten.
Graag!

Met vriendelijke groet,
CSShunter

 

[pbd4499]

Het pdfje is in een iframe opgenomen.

Ik heb het java-script nog niet kunnen vergelijken met de nieuwste versie. Het zal wel de een of de andere functie zijn waar een programmeer-foutje dienaangaande het PDF gebeuren zit.

- Pak het zip bestand uit op je bureaublad;
- zet er een ander pdfbestand in dat je hebt (linken);
- start de html file en test de knoppen over het pdf

Uiteraard moet hier snel een oplossing voor komen want ik ben tijdens m'n zoektocht heel wat klachten hierover tegengekomen.

het gaat hem dus om het/de verschil(len) van de javascirpts:
- SpryMenuBar.js (oudere versie 1.4);
- SpryMenuBarV1.6.js (recentste versie 1.6 met de pdf bug).

Helaas kon ik de niet gezipte bijlage(n) niet meer verwijderen.

Svp gelijk berichten als iemand het eerst de bug heeft gevonden opdat de rest niet onnodig blijft doorzoeken.

 

[csshunter]

Hoi,
is dit wel het goede testbestandje "ttttt.html"?
In deze versie zitten het SpryMenu en het pdf-iframe elk gevangen in een table-cel, en kunnen ze elkaar niet overlappen. Zie ook geen verschil bij aanhaken van de twee js-bestanden - maar dat is dan ook logisch.

CSShunter

 

[pbd4499]

jep, je moet zelf met je editor de link aanpassen en daarin linken naar een pdfje dat je thuis hebt.

zie screenshot dat de knoppen over de pdf in het iframe zitten.

De oudere javascripts moeten dit klaarblijkelijk toch in goede banen kunnen leiden en ze bovenop de pdf zetten.

 

[csshunter]

Nou, ik vind dat heel knap!

Ik krijg bij jouw pagina met een ingemonteerde pdf nooit een menu dat verder komt dan de grens van het pdf-iframe:

• zie deze met gebruik van SpryMenuBar.js, en
• zie deze met gebruik van SpryMenuBarV1.6.js.

Overigens heeft FF bij mij een refresh nodig om de pdf-viewer aan de praat te krijgen: het bleef erg stil in dat grote witte vlak.
Dusdoende:
heb ik iets fout gedaan, was het toch een ander ttttt.html bestand, of heb je je screenshot gephotoshopt?

HO! STOP de persen!
Ik had buiten de waard gerekend. Schoot me te binnen dat Dreamweaver zonder het te melden af en toe wat IE-voorkeur heeft. Dus de testpagina's geopend in Internet Explorer, die ik nog altijd voor de vergelijking geïnstalleerd heb staan (anders was ie er al lang af).
- En inderdaad, in IE doen de pagina's het precies zo als je omschreef. Dreamweaver heeft, gebruik makend van de niet standards compatible uitbreidingslust van IE, een IE-only oplossing verzonnen!

Gaan we even verder kijken:

• Bij Opera (9.64) komt het menu ook niet verder dan zijn eigen cel.
• Chrome blijft eveneens binnen de perken.
• Bij Safari (4.0.2) komt het menu weer wel over het iframe heen, maar daar wordt bij mij de broncode van het pdf-je vertoond i.p.v. de pdf zelf. - O, daar moet ik eerst via "Wijzig > Voorkeuren > Beveiliging" de plug-in's activeren (die standaard uit staan).

Het is maar een weet!

Met vriendelijke groet,
CSShunter

 

[pbd4499]

Hehe, was ik al bang voor dat men ging denken dat ik het screenshot gephotoshopt had.

Is het echt wel een IE-only oplossing? Ik heb de scripts nog niet vergeleken. Volgens mij moet het met een aanpassing ook voor overige browsers werken. Zelf controleren we alle versies van IE en slechts Mozilla FF op correcte verschijning.

Helaas kan ik de java-scripts in deze situatie niet gebruiken aangezien wij met Joomla werken kan ik deze niet 1,2,3 zomaar in Joomla implemneteren.

 

[csshunter]

In SpryMenu css en javascript staat de truc uitgelegd: om van de controls in de pdf af te komen, wordt er via javascript een extra iframe ingevoegd, precies onder de menu box. Vervolgens krijgt die via css voor IE een alpha-filter opacity van .1 mee (= bijna transparant).
Er staat uitdrukkelijk bij: "HACK FOR IE".

Ik heb nog even geprobeerd om met toevoegen van de css3 { opacity: 0.1;} Firefox over de streep te halen, maar dat is me niet gelukt. FF wil niet echt jofel een iframe over een iframe heen zetten en dat dan vervolgens weer transparant maken, wat ik me wel een beetje kan voorstellen.

Ik vrees dat het dus toch een IE-only truc is, maar misschien weet iemand anders nog een oplossing.

Met vr. groet,
CSShunter

 

[pbd4499]

Ik heb net effe geprobeerd maar het wil niet lukken met mijn css. Ík begrijp bij css niet goed waarom er wel eens herhalingen achter bijv:

ul.MenuBarVertical a.MenuBarItemSubmenuHover

komt te staan. Wat doet a.MenuBarltemSubmenuHover dan? Een instructie binnen het CSS die volgt op ul.MenuBarVertical of moet die instructie appart worden opgeroepen vanuit het HTML/PHP bestand?

Bijgaand ons css.

 

[pbd4499]

CssHunter, ben jij er al uit?

 

[csshunter]

Voorrangsregels bij CSS

Hoi pbd4499,
Ik loop achter!

Eerst je vraag over wat a.MenuBarltemSubmenuHover doet.
Eigenlijk staat dat al in de commentaren in het Sprymenu-stylesheet:

[font=courier]/* Menu items are a light gray block with padding and no text decoration */

ul.MenuBarVertical a {
	background-color: #EEE;
	color: #333;
}

/* Menu items that are open with submenus: are set to MenuBarItemHover 
with a blue background and white text */

ul.MenuBarVertical a.MenuBarItemHover {
	background-color: #33C;
	color: #FFF;
}[/font]

Oftewel:

1. De gewone links <a>...</a> in de items die in de <ul class="MenuBarVertical">...</ul> zitten, krijgen een grijze achtergrond (#EEE; en een donkerblauwe text-kleur #333).
2. Maar: links met de class .MenuBarItemHover die in diezelfde <ul class="MenuBarVertical">...</ul> zitten, krijgen een blauwe achtergrond met witte text.

De volorde van de css-bestanddelen is dus bepalend voor wat er gebeurt.
Het gaat steeds van algemeen (de <ul> met een bepaalde class) naar specifiek (de <a> die binnen zich binnen die <ul> bevindt).
Zo kun je eindeloos trappetjes bouwen: allemaal cascades!

Bijvoorbeeld: de gewone tekstkleur van een list-item van een <ul> met een bepaalde achtergrondkleur is zwart, de links zijn blauw, en binnen de link zit een woord dat je graag een extra kleur-accent wilt geven. Maar een submenu heeft een andere achtergrond, enz.
NB: wat in een specifieker trappetje zit en niet genoemd wordt, wordt in het algemeen geërfd van zijn voorganger.

• Een illustratie-pagina met bovenstaand voorbeeld.
• De officiele w3.org voorrangsregels voor css: best ingewikkeld!

Dit was een mini-mini-notendop: hier valt nog véél en véél en véél meer over te zeggen!

CSShunter

PS: in het SpryMenu hebben ze zowat alle elementen een speciale class toebedeeld. Normaal gesproken hoeft dat niet persé als je de goede volgorde aanhoudt. Maar het SpryMenu zal die "extra" class-namen nodig hebben om er via het javascript dingen mee uit te kunnen halen.

 

[pbd4499]

Dank je voor je uitleg CssHunter, ik ga het bestuderen. Het is dus toch een cascade binnen het css. Het was me niet duidelijk hoe dat precies werd aangeroepen behalve als het dan slechts om een enkele aanroep vanuit html gebeurde.

Nu moet ik er toch wel uitkomen naar ik mag hopen......