Project

General

Profile

Bug #4195

Menu dækker over indhold med lille søgefelt og to linjers menu

Added by Stefan Søndervang 3 months ago. Updated 15 days ago.

Status:
Open (waiting)
Priority:
Normal
Target version:
Estimated time:
URL med eksempel:
Kategorier:
Administration - Menuer og taksonomier

Description

Ifm https://platform.dandigbib.org/issues/4132 har jeg testet søgefeltet med en og to linjer samt med lille og langt søgefelt. Eneste problem var når man havde to linjers menu med det lille søgefelt, så dækkede menuen over indhold.


Related issues

Related to DDB CMS - Bug #4132: Søgeboksen kan lægge sig oven på indholdResolved (tag version)
Related to DDB CMS - Enhancement #3667: Hovedmenu flyttes over søgefeltetResolved (tag version)

History

#1 Updated by Stefan Søndervang 3 months ago

  • Related to Bug #4132: Søgeboksen kan lægge sig oven på indhold added

#2 Updated by Stefan Søndervang 3 months ago

#3 Updated by Christel Krabbenhøft 3 months ago

  • Assignee changed from Christel Krabbenhøft to Thomas Hansen

Hej Thomas. Jeg tillader mig at assigne sagen til dig med håb om du kan kigge på den inden for de næste par uger. //Christel

#4 Updated by Thomas Hansen 22 days ago

Nej, nu må i sgu stoppe, den header kommer bare ikke til at fungere med alle de forventninger i har.

Den store udfordring er at fordi headeren er "position: fixed" (for at den klistrer sig til toppen af vinduet), så bliver det hele taget ud af layout flowet og de efterfølgende elementer opfører sig somom den ikke var der (med overlapning til følge). Det fikser man så ved at tilføje noget padding til toppen af body'en der flytter de efterfølgende elementer ned.

Problemet er at det er temmelig en udfordring at finde ud af hvor meget padding det så skal være, for headeren har ikke en fixed højde (hvilket somregel er tilfældet når man bruger "position: fixed")...

Ud over at den skal tage hensyn til at både main-menu og secondary-menu hver kan have så mange menu punkter at de deler sig over flere rækker, eller at de tilsammen bare ikke kan være der, så er der det extended søgefelt som enten bare er der eller kan toggles dynamisk. Selv om vi ved hvor stort søgfeltet og en enrækkes menu er, så kan vi ikke vide hvornår browseren beslutter sig for at dele menuerne op over 2 rækker, så det er forsøgt reddet ved hjælp af JavaScript der sætter ekstra klasser for at fortælle CSSen hvad situationen er. Så vi har .search-form-extended, .extended-search-is-not-open, .has-second-level-menu., secondary-menu-below-main og .has-multiline-main-menu..

Benjamin har gjort en heroisk indsats for at forsøge at få det hele til at spille, men der er så mange faktorer i spil at det ikke er til at overskue.

Så for at bringe det tilbage til et punkt hvor det er til at have med at gøre, så er der nogen løsninger:

A) Sætte nogen hårde begrænsninger på hvad redaktørerne kan, f.eks. sige at der kun kan være en række i hver menu og så hårdt cutte når de ikke holder sig til det (evt. med nogen explicitte switches til om den sekundære menu skal flyttes under main menu), så vi fra serversiden kan være sikre på hvor meget plads der skal bruges.

B) Droppe sticky delen så det kan layoutes uden at man skal indsætte paddings for at ungå overlap.

C) Droppe sticky support for IE, og forsøge med den nye "position: sticky" som skulle udmærke sig ved at opføre som et almindelig element så længe det er på skærmen (så man ikke behøver paddings), men transmogriffe sig om til noget der opfører sig som "position: fixed" når den rammer kanten. På papiret lyder den som helt det rigtige, men det kan kun bevises i praksis ved at prøve.

 

#5 Updated by Stefan Søndervang 22 days ago

  • Status changed from Ready for development to Closed

Vi gør i stedet D og lukker sagen.

Sagen påvirker kun biblioteker, som ikke gør det som er anbefalet i designguiden: https://www.danskernesdigitalebibliotek.dk/fileadmin/user_upload/DDB/dokumenter/DDB_Designguide_v2.pdf. Derfor skal der ikke bruges mere tid eller krafter med dette.

#6 Updated by Christel Krabbenhøft 22 days ago

  • Assignee deleted (Thomas Hansen)

#7 Updated by Thomas Hansen 22 days ago

Nåmen, fedt, så var det godt jeg brugte 2.5 på at analysere problemet og komme med et løsningsforslag. Option C ville stadig eliminere en masse potentielle problemer.

Forresten så ved jeg ikke om det bare var i mit udviklingsmiljø, Firefox eller noget tredje, men det er vel heller ikke meningen at søgefeltet skal skjule den sekundære menu når den er lille?

#8 Updated by Christel Krabbenhøft 15 days ago

  • Status changed from Closed to Open (waiting)
  • Assignee set to Christel Krabbenhøft
  • Target version changed from Release 31 - bugfixes to Release 33 - Bugfixes

Vi drøfter internt, om vi ikke bør gå med løsning C til en senere release (fx rel. 33).

Also available in: Atom PDF