ugrás a tartalomhoz

Link mérete szétesik

domel · 2015. Ápr. 28. (K), 12.12
Üdv!
Van egy olyan gondom amit témakörben nem is tudom hova tegyek, mert szétesik a link betümérete, de mégsem a html kód a hibás. Szóval van egy képfeltöltős oldal ami kiszedi a képből a koordinátákat, és egy google maps linkben a kép alá helyezi:


Eddig jó, aztán a harmadik képtől valami megváltoztatja a betüméretet, és ilyen lesz:


Szétesik tőle az oldal, pedig a képek szélessége mindig 500 pixel, a link szélessége is ugyanannyi mert a koordinátákban csak hat szám változik, karakterre ugyanannyi marad. A fenti képek telefonról készültek, asztali gépen a probléma nem jelentkezik. Van egy másik telefonom is, az is egy katasztrófa. Csak annyit látok, hogy a telefon böngészője kénye-kedve szerint változtatja a betüméretet, és nem tudom miért. Meg lehet ezt valahogyan tiltani a telefonnak (böngészőnek)?
 
1

Firebug

Hidvégi Gábor · 2015. Ápr. 28. (K), 12.31
Azt nézted valamilyen debuggerben, hogy a "széteső" linkre milyen stílusok vonatkoznak? Nem lehet, hogy valamelyik beágyazott tartalom okozza a galibát?
2

néztem

domel · 2015. Ápr. 28. (K), 19.19
Néztem, de nincs különbség a jó és a szétesett oldal között. A telefon hülyesége lesz, csak azért egy kicsit idegesítő, hogy miért csak a saját oldalam esik szét, és miért nem az index.hu vagy akármilyen oldalak. Ha minden egyes link betüméretét beállítom, akkor nem a harmadik képtől, hanem kb a hatodiktól fog szétesni. Szóval sájsze az egész..
4

Hol lehet az oldalt megnézni?

Hidvégi Gábor · 2015. Ápr. 29. (Sze), 09.14
Hol lehet az oldalt megnézni?
3

van egy rossz hírem

szabo.b.gabor · 2015. Ápr. 29. (Sze), 08.34
a rossz hír az, hogy ezt te rontod el :)
5

HTML

Poetro · 2015. Ápr. 29. (Sze), 10.11
Valószínűleg valami nem stimmel a HTML-ben. Például nem zártál le egy elemet. Meg kellene nézni, hogy valid-e a HTML.
6

akkor itt az oldal

domel · 2015. Ápr. 30. (Cs), 21.38
Helló! Akkor itt lenne az oldal: képfeltöltős oldal szétesik
Esetleg írjátok meg, hogy milyen telefonról néztétek, és hogy a hiba fenn áll-e vagy sem, illetve hogy milyen programot használtok hibakeresésre (én Opera dragonfly-t, de nemigazán értek hozzá)
(asztali böngészőben nem fog szétesni)

BlackBerry telefon, azért a kocka képernyő mentés
7

Firefox androidra, illetve az

inf · 2015. Május. 3. (V), 05.53
Firefox androidra, illetve az alap androidos böngésző is jól vitte nekem. Ez a kattogós hang, amit ad az oldal viszont rohadt idegesítő.

Lezáratlan tagről nincs szó. Egyébként ajax-os, úgyhogy valószínűleg nem játszana be a dologba. Nem túl jó a HTML, http://app.validator.pro/#/http://www.spessart.hu/zz/index4.htm a doctype elavult, a form tag-nél nem jó a syntax. Ezen kívül pl ilyen tag-ek vannak, hogy center, ami talán már akkor is deprecated volt, amikor még a chrome meg az opera nem is létezett. Nem utf-8-at használ, ami hosszú távon jó nagy káoszhoz fog vezetni, valszeg már most is ahhoz vezet, mert az ajaxos válasz utf-8ban jön vissza az oldal meg windows 1250-es kódolású. Az is fura, hogy az accept-ben xml-t kér, viszont a válasz nem valid xml, hanem csv header-el jön, miközben egy html fragment van benne, amit szövegként használ. A post teljesen felesleges, amikor egy sima get-et csinál, a nyet helyett meg az üres body teljesen megfelelő lenne. A másodpercenkénti frissítés is teljesen felesleges, kinyírná a szervert, ha lenne forgalma, jobb lenne valami reálisabb időköz, mondjuk 5-10 másodperc. Én személy szerint egyáltalán nem csodálom, hogy belezavarodnak a böngészők a fentiek tükrében. A hibát nem sikerült megtalálnom, hogy hol van a rendszerben, lehet, hogyha mindent kijavítasz, akkor magától megjavul.
8

Akkor átrágom magam a fenti

domel · 2015. Május. 3. (V), 10.11
Akkor átrágom magam a fenti észrevételeken, bár a headerek és karakterkódolások sosem mentek :( ...max. megnézem mások hogy csinálják
9

Nem bonyolultak nézd meg a

inf · 2015. Május. 3. (V), 15.35
Nem bonyolultak nézd meg a content-type és accept header-eket, biztos, hogy sok helyen le van írva hogyan kell használni őket, az accept a te esetedben nem is fontos.

Szerintem jobban tennéd, ha HTML helyett inkább JSON-t küldenél, és a scripted alakítaná át HTML-re az adatot. Kisebb úgy a forgalom, és egy helyen van a HTML. Ha PHP-t használsz, akkor json_encode, amivel json-t tudsz csinálni, a javascript-nél meg JSON.parse.
Utána meg érdemes DOM tree-t építeni, nem innerHTML-t használni, mert kevésbé injektálható, ha createTextNode-al helyezed bele a szöveget. Ha beküldésnél ellenőrzöd a tartalmat, hogy nincs e benne javascript, akkor mondjuk nem számít annyira.

A fájl feltöltésnél is oda kell figyelni néhány dologra: itt összeszedtem, hogy mire, már ha tudsz angolul. Érdemes rászánni az időt, mert biztonságosabb lesz így.
10

Meg van a hiba!

domel · 2015. Május. 4. (H), 00.54
Meg van a hiba (hogy rohadjon ki a bele) :)))))
Igaz hogy a kód egy tákolmány, mégsem ez volt a hiba, hanem maga a fájl szerkezete amit feltöltöttem. A Notepad++ -ban a "Kódolás" menüben az "UTF-8 kódolás" -t átállítottam "UTF-8 kódolás BOM nélkül" -re, és láss csodát, minden úgy jelenik meg ahogy azt szeretném. Szerintem önmagában ez sem lehetett volna baj, csak korábbról bent maradhatott valami szemét a file szerkezetében.
És persze idegesítő az is, hogy az egyik browser hibának veszi, a másik meg nem.

Köszönöm mindenkinek a segítséget!