Çështja e Hapësirës së Bardhë

Hyrje:

Si zhvillues të uebit, ne nuk jemi të panjohur për veçoritë e shfletuesit dhe çështjet e pajtueshmërisë. Për shumë prej nesh, ditët e frikshme të mundjes me mungesën e mbështetjes së Internet Explorer për standardet e uebit janë ende të gdhendura në kujtimet tona. Megjithatë, ndërsa teknologjia evoluon, lindin sfida të reja dhe për disa zhvillues, Safari në pajisjet iOS po bëhet ekuivalenti modern i Internet Explorer.

Çështja:

Kohët e fundit, kam hasur në një problem hutues gjatë punës në një aplikacion ueb — hapësira e bardhë shfaqet në Mobile Safari kur u hap tastiera.
Fillimisht, kur u nisa të zgjidhja problemin e hapësirës së bardhë në Mobile Safari, u emocionova dhe i sigurt se do të gjeja një zgjidhje të shpejtë dhe elegante. Si një zhvillues me përvojë në internet, nuk e imagjinoja kurrë që ky problem në dukje i thjeshtë do të shndërrohej në një udhëtim irritues, duke më shtyrë të shkruaj atë që kisha frikë se do të bëhej një blog dështimi.

Misteri i Hapësirës së Bardhë:

Gjithçka filloi në mënyrë të pafajshme - një hapësirë ​​e bardhë u shfaq në Mobile Safari kur u hap tastiera. Fillimisht, unë e hodha atë si një problem të vogël me një zgjidhje të drejtpërdrejtë. Nuk e dija që kjo çështje e thjeshtë do të më përndjekte për ditët dhe netët në vijim.

Safari — I dyshuari i zakonshëm:

Pa u menduar dy herë, drejtova gishtin nga Safari. Takimet e kaluara me këtë shfletues shpesh më kishin lënë të shqetësuar, edhe kur nuk isha i fokusuar në përputhshmërinë e ndër-shfletuesve. Dyshimet e mia u duk se u konfirmuan kur çështja u shfaq si inekzistente në Mobile Chrome.

Të provosh qasje të ndryshme:

Për të zgjidhur problemin, kam provuar strategji të ndryshme. Unë u përpoqa të parandaloja Safari nga përmirësimi i përvojës së përdoruesit duke shtuar user-scalable=no, por kjo nuk e zgjidhi problemin. Shtimi i overflow: hidden për çdo element dukej si një zgjidhje e shpejtë, por rezultoi joefektive.

Korrigjimi i makthit:

Kur bashkova telefonin tim me mjetet e zhvilluesve të Safari-t, vura re diçka të çuditshme – hapësira e bardhë nuk ishte një diferencë ose mbushje, por ishte jashtë HTML-së. Edhe me overflow: hidden të aplikuar në çdo element të mundshëm (html, trup dhe më shumë), kishte ende një rrotull të padëshiruar.

Gjuetia për të dhëna:

Në dëshpërimin tim, e diskutova këtë çështje me zhvilluesit e tjerë. Një teori ishte se Safari mund të përpiqet të shtyjë fushën e hyrjes kur ajo shfaqet në fund të faqes. Megjithatë, ndryshimi i pozicionit të hyrjes nuk e zgjidhi problemin.

Pozicionimi i përkulur dhe ngjitës:

Kam konsideruar ndikimin e përdorimit të pozicionimit fleksibël dhe ngjitës në paraqitje. Për habinë time, heqja e të gjitha pozicioneve ngjitëse dhe fikse nuk ndihmoi. Si mjet i fundit, ndryshova paraqitjen për të përdorur div me lëvizje lëvizëse në vend që të mbështetesha në lëvizjen e dritares, por problemi vazhdoi.

Tmerri i dritares.innerHeight:

Në dëshpërimin tim, u përqëndrova në çështjet e lidhura me pamjen, duke shpresuar se llogaritjet dinamike të lartësisë duke përdorur variablin --vh do të shpëtonin ditën. Por për tmerrin tim, zbulova se window.innerHeight nuk ishte i besueshëm. Vlera ndryshoi me çdo ndryshim të madhësisë së dritares që aktivizon lëvizjen, duke e bërë atë plotësisht të paparashikueshme - një tipar i papranueshëm për një API kaq themelor.

Unë madje u përpoqa të përdor scrollIntoView si një zgjidhje të mundshme. Mendova se lëvizja manuale në fund të HTML sa herë që përdoruesi haste hapësirë ​​të bardhë në portin e shikimit mund të ndihmonte. Megjithatë, për keqardhjen time, scrollIntoView nuk funksionoi në këtë gjendje dhe nuk kishte asnjë mjet për të llogaritur saktë koordinatat y për të lëvizur manualisht, duke pasur parasysh sjelljen jo të besueshme të window.innerHeight. Kjo përpjekje më la të ndihem më i pafuqishëm pasi kuptova se edhe disa zgjidhje jokonvencionale nuk mund të më shpëtonin nga moçali.

Frika nga e panjohura:

Si zhvillues, unë mbështetem shumë në API-të si window.innerHeight për dizajn të përgjegjshëm, efekte paralele dhe përvoja të tjera ndërvepruese. Mendimi që një mjet kaq kritik të bëhej i paparashikueshëm nuk ishte aspak i frikshëm. Si mund të ndërtojmë aplikacione të sofistikuara në internet nëse nuk mund t'u besojmë blloqeve themelore të ndërtimit?

Nuk ka ndihmë nga ekipi i Safari:

I dëshpëruar për përgjigje, kontrollova forumet dhe komunitetet e zhvilluesve, vetëm për të gjetur zhvillues të tjerë që luten me ekipet e Apple dhe Safari për të adresuar këtë dhe çështje të tjera të lidhura. Mungesa e një zgjidhjeje të qartë ishte dëshpëruese.

twitter.com/jensimmons/status/1491064075987873792
Edhe pse në një përpjekje për të gjetur ndihmë në komente, në një moment sapo fillova ta shijoja atë (njerëzit kanë mënyra shumë kreative për të shprehur zhgënjimin)

Disa temë që qarkullon rreth të njëjtit problem:

https://stackoverflow.com/questions/52857694/safari-on-ios-scrolls-beyond-html-element-when-virtual-keyboard-is-opened?noredirect=1&lq=1
https: //stackoverflow.com/questions/70572209/white-space-outside-html-on-mobile-safari-when-keyboard-is-open

Një defekt që nuk mund ta zgjidhja:

Pasi shterova të gjitha përpjekjet e mia, me ngurrim më duhej të pranoja humbjen. Tani do të përpiqem ta trajtoj këtë çështje në një nivel dizajni, duke e pranuar atë si një dështim të gabimeve për mua - një zhvillues që krenohet me zgjidhjen e problemeve.

Të jetosh me zgjidhje të përkohshme:

Tani për tani, kam përdorur për të çaktivizuar disa ngjarje touchmove për të shtypur rrotullat e paqëllimshme. Është larg nga një zgjidhje ideale, por është më e mira që mund të bëj derisa të gjendet një zgjidhje e duhur.

// To wrappers where user would attempt drag/touchmove/scroll
addEventListener('touchmove', (e: any) => {
    e.preventDefault();
});

// To element where I would like to avoid this behaviour
addEventListener('touchmove', (e: any) => {
    e.stopPropogation();
});

Përfundim:

Si një zhvillues, frika se Safari do të bëhet Internet Explorer i ri është shumë reale. Çështja e hapësirës së bardhë në Mobile Safari shërben si një kujtesë e qartë se si edhe problemet në dukje të vogla mund të kalojnë në sfida monumentale. Derisa të sigurohet një rregullim konkret, ne duhet të mbështetemi në përshtatshmërinë dhe zgjuarsinë tonë për të punuar kundër këtyre pengesave dhe për të ofruar përvojën më të mirë të mundshme të përdoruesit. Le të shpresojmë që në të ardhmen e afërt, ekipi Safari i Apple t'i pranojë dhe t'i trajtojë këto çështje, duke i kursyer zhvilluesit nga zhgënjimi dhe pafuqia e mëtejshme.

Gjetjet e lidhura me shikimin:
Vetëm për ta përmendur, kam provuar tashmë -webkit-fill-available; lvh, dvh, svh Por këto nuk reflektohen me tastierë të hapur dhe të mbyllur. Gjithashtu, të gjitha pazaret që lidhen me portin e shikimit nuk janë të lidhura me çështjen e hapësirës së bardhë në përgjithësi sipas gjetjes sime.
Diskutime më të gjata dhe përditësime teknike në lidhje me problemin e portit të shikimit:
https://stackoverflow.com/questions/37112218/css3-100vh-not-constant-in-mobile-browser
Nicolas Hoizey e ka hulumtuar pak këtë: https://nicolas-hoizey.com/articles/2015/02/18/viewport-height-is-taller-than-the-visible-pjes-of-the-document-in -disa-shfletues-mobilë/