ugrás a tartalomhoz

Böngésző azonosítás

Gixx · 2015. Jan. 19. (H), 05.43
We want to serve you and not track you.

Akár ez is lehetne a mottója a gondolatmenetemnek, ami már hosszú ideje érlelődik bennem. Mivel az évek során egyáltalán nem láttam, hogy bárki is, akárcsak javaslat szinten érdemben foglalkozott volna a témával (ennek ellenére simán elkerülhette a figyelmemet), gondoltam, én most itt szűk körben kifejtem, mi a problémám a jelenlegi helyzettel, és hogy kiindulásképp miben látnám a megoldást. Aztán ebből hátha kikerekedik egy olyan konstruktív vita, amit majd akár nemzetközi szinten is érdemes lesz folytatni. Vagy nem.

Nem kizárt, hogy az írásom hagy majd kívánnivalókat maga után szakmailag (is). Ezért kérem, hogy ha az inger-mérőtök eléri az „irritáló” jelzést, akkor úgy olvassátok, mint egy hirtelen felindulásból elkövetett értetlenkedést, és legyintsetek reá. Köszi.

Az alapprobléma

Szerintem itt mindenki tisztában van vele, hogy mi is az a User-Agent sztring, mire hivatott, és hogy mire nem alkalmas. De azért röviden felvázolom az én meglátásaimat.

Íme egy példa a valós életből:

Mozilla/5.0 (iPhone; U; CPU iPhone OS 5_1_1 like Mac OS X; en) AppleWebKit/534.46.0 (KHTML, like Gecko) CriOS/19.0.1084.60 Mobile/9B206 Safari/7534.48.3

Mit is látunk itt? Egy iPhone-on futó, Webkit alapú böngészőt. Tapasztaltabbak azt is tudják, hogy Google Chrome az illetékes. Plusz látunk egy tonna felesleges adatot:

  1. Mozilla/5.0 – ezt komolyan használja még bármi is bármire? Mire jó? Ezt annó a Netscape vezette be, és az IE lemásolta, mert azt látta, hogy sokkal több oldal működik, ha ez ott van, mert már akkor is divat volt a szelektálás. A 90-es évekről beszélek…
  2. Jön egy katyvaszos, zárójeles rész, ami az eszközt és az operációs rendszert hivatott azonosítani, több-kevesebb sikerrel. Androidoknál vannak aztán az igazán cifra dolgok.
  3. Ezt követi a megjelenítő motor név és verzió,
  4. és a miheztartás végett zárójelben megmagyarázza a dolgot, hogy legyen mihez viszonyítani. Elvégre „a Trabant is olyan, mint a Porsche”… Csudijó. Ez se jó semmire.
  5. Jön a böngésző verziója, de bárcsak szabványos lenne mindenhol… Persze nem az. És nem is egyértelmű. A példánál maradva a CriOS-ről talán a legutolsó utáni helyen gondolnám azt, hogy a Google Chrome-ról van szó.
  6. Végül megint egy csomó adat, ami leginkább csak arra jó, hogy a böngésző detektáló reguláris kifejezésünkbe egy újabb kitételt tegyünk, mert ez nem Safari.

Mi ezzel a probléma?

Az, hogy csak arra nem jó, amire kellene, hogy legyen: eszköz–rendszer–böngésző egyértelmű megállapítására, nyomonkövetésre és felhasználó azonosítására alkalmatlan módon. Bár ez utóbbi többnyire most is teljesül, előbbire sokszor csak komoly megalkuvás árán alkalmas.

Kliens oldalon ugyanúgy lehet csak detektálni a böngészőt, mint a szerver oldalon: a User-Agent sztring reguláris kifejezéssel történő mintaillesztésével. Persze kliens oldalon jobb esetben oda van rakva a navigator tulajdonság, ami azonban annyit ér, mint puskagolyónak az integetés.

Miért van szükség a változtatásra?

Manapság nem hagyhatjuk figyelmen kívül az újnak éppenséggel nem mondható alternatív böngészési megoldásokat, melyeket az egyre-másra felvonultatott készülékek hoztak be a mindennapokba.

Saját tapasztalatból tudom, hogy a reszponzív megközelítés nem minden esetben követhető, és egy-egy megjelenítési forma bizony megköveteli, hogy külön sablonokat, sőt, egyes esetekben külön alkalmazást is kapjon.

Nekem (és akkori kollégáimnak) az alkalmazást többek közt az eszköz, annak felbontása és a futtatott böngésző figyelembevételére is fel kellett készítenünk.

Nem volt mindegy, hogy mobil, tablet vagy tévés eszközről van-e szó. Sőt, még a játékkonzolokra is figyeltünk egy időben. Ezt a mai napig sem lehet egyértelműen meghatározni. A felbontást és a képpontsűrűségi szorzót pedig még ha sikerül is pontosan visszakapni, akkor sem biztos, hogy mit kell megjeleníteni, ha az eszközt nem sikerült beazonosítani. Hány esetben fordul elő még a mai napig is, hogy a telefonnak sokkal nagyobb a felbontása, mint mondjuk egy tévére köthető médiabox böngészőjének? Nem beszélve az okostévék elég gyenge processzorral megtámogatott beépített csodáiról.

Az sem volt mindegy, hogy milyen böngésző. Mert bár túlnyomó többségben Webkit-alapú böngészők uralkodnak, de ezen belül lehet Safarival, Chrome-mal, Dolphinnal vagy egyéb szakadár böngészővel vagy csak simán az Android alapértelmezett böngészőjével is dolgunk. A CSS és JS támogatottsági problémák csak a kezdetet jelentették. De amikor a websocketnek a Safari és a Chrome különböző verzióját támogatta, és emiatt kétféle módon is kellett szerver oldalon (bitenként) feldolgozni a csomag-fejléceket, na az fincsi volt.

A sort még lehetne folytatni, a lényeg, hogy számos olyan szolgáltatás van, ami napi szinten szenved egy apróság miatt, amit még csak igazából különösebb erőfeszítésbe sem kerülne mindenki által elfogatott formára hozni és szabványosítani.

Mire lenne szükség?

Szerintem égető szükség van a User-Agent sztring teljes megreformálására a JavaScript navigator interfészével egyetemben. Az elképzelésem szerint az új azonosító minden egyes blokkja egyértelműen megfeleltethető lenne a navigator interfész új tulajdonságainak. Ezt követően pedig nem lenne semmi akadálya, hogy a szerver oldali nyelvekben is megjelenjen egy erre épülő modul. Én mindezt a következők szerint képzelem el:

navigator.device.type
A készülék típusa (például: desktop, mobile, tablet, TV, game console)
navigator.device.manufacturer
A készülék gyártója (Dell, Lenovo, Apple, Samsung)
navigator.device.model
A modell (populáris) elnevezése (ThinkPad, iPhone, Galaxy S3)
navigator.device.number
A modell száma, ha van (I8190, iPhone 6, XS15)
navigator.os.name
Az operációs rendszer (Apple iOS, Google Android, Microsoft Windows)
navigator.os.version
A verzió (6.0, 4.4.2, NT 6.0)
navigator.os.language
A nyelv (en)
navigator.browser.name
A böngésző neve (Safari, Chromium, Opera, Internet Explorer, Dolphin)
navigator.browser.version
A böngésző verziója
navigator.browser.language
A böngésző nyelve (mert eltérhet az operációs rendszerétől)
navigator.browser.engine
A megjelenítő motor (Trident 6, Webkit 534.46.0)

A lista persze nem feltétlenül teljes, szinte a végtelenségig lehetne finomítani avagy bonyolítani, én csak azt az érzésem szerint szükséges minimumot vázoltam fel, amivel egyértelműen meg lehet mondani egy a webszerverre beérkező kérésről, hogy kiféle-miféle forrásból származik.

Ezek alapján a fenti példa a következőképpen nézne ki (akár):

Mobile, Apple iPhone 5, Apple iOS 5.1.1 en, Chromium 19.0.1084.60 en, WebKit 534.46.0

Így szerintem a teljes formájában is sokkal informatívabb. És ha így lenne, akkor nem kellene brutális méretű adatbázisokat fenntartani, és nem kellene erőforrászabáló reguláris kifejezés osztályt írni sem. Nem kéne saját magunk útjába akadályokat görgetni.

Nektek mi a véleményetek?

 
1

+1

szabo.b.gabor · 2015. Jan. 19. (H), 09.09
+1
2

ha jól értem: eszköztulajdonság dekl. vs megjelenítés

EL Tebe · 2015. Jan. 19. (H), 09.15
készülék típusa (például: desktop, mobile, tablet, TV, game console)

Ezt ennyire speckó módon sztem nem lehet belőni, mert ezek közt sok átfedés is lesz. Gondolj csak azokra az eszközökre, amik egyik kategóriába sem sorolhatóak egyértelműen. Pl olyan mobil eszköz, ami dokkolva van és a megjelenítés monitoron/TV-n történik.
Itt máris nem tudod a megjelenítést helyesen a megjelenítő eszközhöz igazítani, mert "Sammtung Sun 4"-ről megy a http kérés, azt mégis egy 30"-os UHDTV-n nézik :)

De szinte lehetetlen - és a tulajdonosnak üzletileg sem érné meg - ha ezekre az (egyébként folyamatosan frissítendő és bővítendő eszközinformációkra), kellene felkészíteni egy-egy felületet (pláne visszamenőlegesen is).

--

Azt most hirtelen nem tudom, hogy pl a http fejlécekben van-e / lehet-e / tud-e / érdemes-e olyan információ, ami csak a mobil és asztali böngészést különböztet meg hálózat használat szempontból: ebben a kontextusban a mobil/desktop közt például csak annyi különbség, hogy az első az oldalletöltés költséggel/sávszélproblémával jár (mobilnet), a másik pl kábelen külön költség nélkül.

--

User-Agent:
In HTTP, the User-Agent string is often used for content negotiation, where the origin server selects suitable content or operating parameters for the response. For example, the User-Agent string might be used by a web server to choose variants based on the known capabilities of a particular version of client software.


content negotiation:
Content negotiation is a mechanism defined in the HTTP specification that makes it possible to serve different versions of a document (or more generally, a resource representation) at the same URI,


Ez alapján a cél alapján valóban lehetne szépen csiszolni a fenti sztringen.

--

Azt tudnám még elképzelni, hogy a megjelenítési arányokat, felbontásra vonatkozó információkat lehetne pontosítani, a böngésző csapná hozzá a kéréshez az OS megjelenítési (és a böngésző ablakméretei) beállításai alapján és másik oldalon - amennyiben erre szükség van - pedig párosítani css/html oldalon (de akár más tartalmat kiszolgálni ugyanazon az url-en).
Ez mondjuk most is részben elérhető, de külön hekmány kell pl a képek kiszolgálásánál (lásd img##kukac##2x.png és hasonlók).
De lehet hogy ez is annyival megbonyolítaná/megdrágítaná a megjelenítések kialakítását, hogy csak kevesek használnák ki.
6

De ha már változna...

Gixx · 2015. Jan. 19. (H), 12.05
..., akkor miért nem változhatna úgy a dolog, hogy a böngésző egy fél-statikus user agentet használjon? Tipikusan az eszközt és az operációs rendszert elég lenne telepítéskor, esetleg minden induláskor egyszer megállapítani. Magára a böngészőre vonatkozó adatok, app és "engine" lehetne "hard-coded".
3

A példánál maradva a

Poetro · 2015. Jan. 19. (H), 09.41
A példánál maradva a CriOS-ről talán a legutolsó utáni helyen gondolnám azt, hogy a Google Chrome-ról van szó.

Chrome on iOS. Egyébként nem lenne ildomos odaírni, hogy Chrome, mert nem az, ugyanis a böngésző motorja teljesen más, mint más platforomokon, elvégre ez csak egy Chrome bőrbe bújtatott Safari.
7

Az én hibám...

Gixx · 2015. Jan. 19. (H), 12.08
..., de a CriOS-ról mindig a Briós jutott eszembe :)
8

Nekem meg a CryoPrison a

kuka · 2015. Jan. 19. (H), 12.16
Nekem meg a CryoPrison a Demolition Manből… :(
10

Puszty búgyet

Hidvégi Gábor · 2015. Jan. 19. (H), 14.27
Egyetértek, nekem is volt korábban hasonló felvetésem. Ezek mellett kéne küldeni még a képernyő (felbontás, átmérő) és a hálózat adatait, meg esetleg hogy mekkora képeket kér az illető, valamint hogy PC vagy mobileszköz.
4

Sok éve olvastam egy cikket,

kuka · 2015. Jan. 19. (H), 11.51
Sok éve olvastam egy cikket, melyben egy User-Agent2 HTTP fejléc bevezetését javasolta a szerző, melynek gépi feldolgozásra optimizált értéke lenne. Az a cikk már rég eltűnt.

Pedig az a javaslat nekem logikusabbnak tűnt. Csupán úgy kellene az érték kinézzen mint más összetett adatot tartalmazó fejlécek esetében, például Content-Type: text/html; charset=utf-8. Ez alapján a te példád így nézne ki:
User-Agent2: Mozilla/5.0; device-type=Mobile; device-manufacturer=Apple; device-model=iPhone; device-number=5; os-name="Apple iOS"; os-version=5.1.1; os-language=en; browser-name=Chromium; browser-version=19.0.1084.60; browser-language=en; browser-engine="WebKit 534.46.0"
Vagy lévén a HTTP lehetővé teszi a fejlécek tördelését:
User-Agent2: Mozilla/5.0;
    device-type=Mobile;
    device-manufacturer=Apple;
    device-model=iPhone;
    device-number=5;
    os-name="Apple iOS";
    os-version=5.1.1;
    os-language=en;
    browser-name=Chromium;
    browser-version=19.0.1084.60;
    browser-language=en;
    browser-engine="WebKit 534.46.0"
Szerintem ez sokkal olvashatóbb embernek és gépnek egyaránt, emellett egyszerűen bővíthető, például a Hidvégi Gábor által javasoltakkal. (Bár szerintem a kép méretnek határozottan semmi keresnivalója User-Agent* fejlécben. Inkább valami Accept-* fejlécben mutatna jól.)
5

Tetszik

Gixx · 2015. Jan. 19. (H), 11.58
Ez is egy nagyszerű megoldás lenne! Tetszik.
9

Köszönet a moderátornak

Gixx · 2015. Jan. 19. (H), 12.22
Köszönet a moderátornak, hogy kijavította a helyesírási és főleg a tartalmi szarvas hibákat :) Néha sikerült pont fordítva leírnom azt, amit akartam (Mozilla) :D
11

Ezért van a szerkesztő :)

Joó Ádám · 2015. Jan. 19. (H), 17.53
Ezért van a szerkesztő :)
12

Amellett, hogy a kuka által

Joó Ádám · 2015. Jan. 19. (H), 18.19
Amellett, hogy a kuka által már írt név–érték forma szerencsésebb volna, illetve vannak a fent javasolt értékekben logikátlanságok (a renderer név és verzió miért nincs szétválasztva? A gyártó, a név és a szám érdekel bárkit is külön?), az eszközök kapcsán érdemes megfontolni, hogy már a media query-k esetén is kivezetésre vannak jelölve az eszköztípusok, és helyettük a képességek szerint lesznek alkalmazandók a stílusok.

Itt azonban felmerül a kérdés, hogy ildomos-e ilyen mennyiségű adatot minden kéréssel utaztatni. Esetleg érdemesebb a szervernek kezdeményeznie egy feltételes átirányítást a számára releváns képességek alapján:
If-Resolution-At-Least: 2dppx
Location: ?resolution=high
13

Ha kívánságműsor...

vbence · 2015. Jan. 19. (H), 23.00
Akkor én is leírom két szívem csücskét:

1) Az Android isActiveNetworkMetered mintájára egy boolean ami megmondja, hogy a user forgalmi díjas kapcsolaton netezik-e (olyankor nincs gyomrom retinára optimalizált bitmepeket küldeni).

2) Kijelző való élet beli átmérője (inch/cm) - egyértelmű okokból.
14

Teljesen egyetértek.

inf3rno · 2015. Jan. 23. (P), 00.53
Teljesen egyetértek. Írhatnánk valami petíciót a megfelelő helyre, amiről fogalmam sincs, hogy micsoda. Tippre a W3C lesz az, mert ez egy HTTP header, és ha jól tudom ők tartják karban a HTTP-t, legalábbis náluk van a standard leírása.

Továbbgondolva a témát szerintem nincs értelme azzal foglalkozni, hogy mi a gyártó, vagy hogy milyen verziójú a motor, ami a böngésző alatt van. Ehelyett capability-re kellene koncentrálni inkább. Erre js-ben már vannak összetákolt kódok, amik lekérdezik, de mennyivel jobb lenne ezt az információt már a header-ben megkapni,

pl:
- html-version: 5.0;
- css-version: 2.0; additional-selectors=checked,disabled; etc...
- js-version: 1.8.5; ajax=1; ajax-impl=active-x-6; websockets=1; webworkers=1; push-state=1; etc...
- display: touch; 1920x1080; 10"; 3d; etc...
- network: 3g; limited-speed-preferred; etc...

Mert igazából erre vagyunk kíváncsiak.

Ezt akár accept típusú header-ben is lehetne küldeni, vagy prefer header-ben. Nyilván ennél az 5 perc alatt összedobott változatnál jóval kidolgozottabb szabvány kell, pl nem csak whitelist, hanem blacklist is. Kapásból a szabványra lehetne írni js és szerver oldali feldolgozókat, amik kinyerik ezekből az adatokból, hogy mire képes a böngésző, és mire kell optimalizálni a kimenetet. A legtöbb dolgot, amit most js-ben csinálunk ezek miatt, ugyanúgy meg lehetne oldani szerver oldalon is, ha lennének ilyen header-ek.
15

Tippre a W3C lesz az, mert ez

Joó Ádám · 2015. Jan. 23. (P), 05.33
Tippre a W3C lesz az, mert ez egy HTTP header, és ha jól tudom ők tartják karban a HTTP-t, legalábbis náluk van a standard leírása.


IETF.
16

Ja nekem is úgy rémlett, hogy

inf3rno · 2015. Jan. 23. (P), 07.40
Ja nekem is úgy rémlett, hogy van még valami csavar a történetben.
17

Míg válaszolnak...

Pepita · 2015. Jan. 23. (P), 17.01
Míg válaszolnak a petícióra, egyrészt megöregszünk (ok, tudom: pesszimista vagyok :)), másrészt addig is kell kezdjünk valamit a problémával.

Jelenleg én úgy gondolom, hogy nem feltétlenül kell a kliens oldalt kisebb-nagyobb bonyolultságú js-el terhelni. A useragent stringet megkapod szerveroldalon, ezzel mindenki annyit kezd, amennyit éppen tud. Ha "mobil" megjelenést preferál az eszköz, akkor 99%-ban benne van a "mobile / Mobile" szó. Ez persze még édeskevés önmagában.
Viszont meg kell adni (jól látható linkkel, menüvel) a lehetőséget a látogatónak, hogy változtasson a nézeten. (Ez a véleményem valószínűleg akkor is fennáll, ha történik szabványfejlesztés az ügyben.)
És el kell menteni min. egy sütibe, hogy ha már egyszer beállította, mindig azt kapja, míg nem vált újból.

Érdemes lehet még tárolni a stringet a kért beállítással, ezek statisztikája alapján akár automatizáltan is lehet fejleszteni az eszközfelismerést, ill. a hozzá tartozó megjelenés kiválasztását.
Nyilván ennél az 5 perc alatt összedobott változatnál jóval kidolgozottabb szabvány kell
Nekem ez az 5 perces is már sokkal jobban tetszik, mint a useragent... :)
18

A süti jó ötlet akkor is, ha

inf3rno · 2015. Jan. 23. (P), 21.37
A süti jó ötlet akkor is, ha js-el deríti ki az ember a dolgokat első körben. Ilyenkor bele lehet menteni sütibe, hogy miket támogat a böngésző (már ha támogatja a sütit), és nem kell az összes tesztet újra lefuttatni rá, plusz a szerver is egyből tudni fogja, hogy mire számítson. Elvétve van csak ebből probléma, mondjuk ha be és kikapcsolt js-el is teszteljük az oldalt.
19

elvétve...

Pepita · 2015. Jan. 23. (P), 23.41
Meg ha:
Pl opera mini proxyn,
Gyenge proci / ram,
Más (sok) JS is fut,
Lehetne sorolni sokat.

Ez - szerintem - tipikusan szerver feladat. De épp most indul egy nagyobb projekt, amiben meg kell oldanom, remélem lesz időm beszámolni róla.
20

Hajrá! :-) Hát a

inf3rno · 2015. Jan. 24. (Szo), 17.16
Hajrá! :-)

Hát a legegyszerűbb szerintem a felhasználóra bízni egy külön fülön, hogy melyik változatot preferálja:
- js vagy csak html (kevesebb funkcióval)
- mobilra, tabletre vagy pc-re optimalizált

Lehetne betenni egy olyat a kezdőoldalra, hogy válasszon a lehetőségek közül, aztán utána cookie-ban elmenteni. Nyilván az sem 100%-os, de jobb, mint a semmi.
21

kezdő oldal

Pepita · 2015. Jan. 26. (H), 09.03
Elég ritka ma már, hogy kezdő oldalra érkezzen. Amit talált a keresőkben...
22

A kezdő oldalt úgy értettem,

inf3rno · 2015. Jan. 26. (H), 15.40
A kezdő oldalt úgy értettem, hogy amikor cookie nélkül beérkezik, de tényleg félreérthető volt. Mondjuk a google botok átirányítása a megfelelő helyre így gondolom nem egyszerű.
23

Nem kell Redirect

Pepita · 2015. Jan. 26. (H), 20.32
Az alkalmazás elején detect, végén session alapján view. A detect része a cookie és session beállítása.
24

és mi van akkor...

Gixx · 2015. Jan. 28. (Sze), 15.15
És mi van akkor, amikor a `detect` még a PHP futása előtt végbemegy? Teszem az nginx által? Mert ilyenre is van példa.
25

link?

Pepita · 2015. Feb. 2. (H), 19.47
Kíváncsi vagyok minden példára a témában.
Akkor add át az alkalmazásodnak a szükséges adatokat. Nem feltétlenül PHP az sem.
26

Nem tudok linket adni

Gixx · 2015. Feb. 3. (K), 12.17
...hisz a céges webshop kódját nem fogom kiadni, de tény, hogy vannak benne ilyen jellegű kitételek :)

Valami ilyet kell elképzelni.
27

külön domain

Pepita · 2015. Feb. 3. (K), 19.59
Ja, ha eleve másik domain a mobil, akkor egyszerűbb így, igen.
Én viszont csak view réteget cserélek és ehhez nem kell al domain, jobb a session és / vagy süti.
Jó doctype és Google is szereti.
28

Egy ideje egy csomó oldal

MadBence · 2015. Feb. 3. (K), 20.05
Egy ideje egy csomó oldal mobil böngészőként azonosít, és átdob az m.akarmi oldalra. Rendkívül idegesítő. Legyenek inkább reszponzívak az oldalak.

(User-Agent: Mozilla/5.0 (X11; Linux x86_64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/42.0.2288.8 Safari/537.36)
29

Vicces ez a user agent, a

inf3rno · 2015. Feb. 3. (K), 20.49
Vicces ez a user agent, a fentiek alapján lehetne firefox, opera, chrome és safari is így első ránézésre :D
30

Az csak egy gügye Chrome. A

kuka · 2015. Feb. 3. (K), 21.00
Az csak egy gügye Chrome. A Chromium egy pici fokkal annál is rosszabb:
Mozilla/5.0 (X11; Linux x86_64) AppleWebKit/537.36 (KHTML, like Gecko) Ubuntu Chromium/39.0.2171.65 Chrome/39.0.2171.65 Safari/537.36
31

csúnya...

Pepita · 2015. Feb. 4. (Sze), 07.22
Én ezért mondom, hogy még mindig ki kell tenni jól látható linket a váltáshoz, és sütiben tartani, hogy mit preferált utoljára.
Nem lehet elég jó felismerést csinálni, mert szinte naponta jön ki újabb agent string.
Ezen kívül hagyni kell dönteni is a látogatót.
32

Featúra kérelem

Hidvégi Gábor · 2015. Már. 10. (K), 15.28
Beküldtem a Bugzillába, meglátjuk, mit szólnak hozzá a srácok.
33

Hát remélem lesz belőle

inf3rno · 2015. Már. 10. (K), 20.41
Hát remélem lesz belőle valami. Igazából ez is olyan dolog, hogy már 10 éve meg lehetett volna csinálni, csak mindenki baromira lusta volt hozzá.

Ami még érdekes, hogy mindenki fully supported-et ír ES5-re, aztán pár napja találtam olyan bug-ot - Object.defineProperty-vel kapcsolatban - ami egyedül firefox-ot nem érinti. Egyébként maga a szabvány is gányolt ezzel kapcsolatban, 10x jobbra meg lehetett volna csinálni az egészet. Szerintem alapvetően ott van a gond webfejlesztésben, hogy nincs beleszólásunk a szabvány kidolgozásába. Összeül max egy tucat ember, összetákolják, aztán letolják mindenkinek a torkán. Baromi ritka az olyan szabvány, ami nyílt, és bárki ötletelhet (személy szerint csak egyet ismerek).
36

es-discuss, bárki szabadon

MadBence · 2015. Már. 10. (K), 22.04
es-discuss, bárki szabadon felvethet ötleteket, amiket aztán a közösség véleménye/visszajelzése alapján a TC beveszi, vagy nem veszi bele a nyelvbe. Milyen bugot találtál amúgy? Ha a firefoxban működik, akkor az implementációs probléma, nem a szabványé.
37

Object.create-el létrehozott

inf3rno · 2015. Már. 10. (K), 23.10
Object.create-el létrehozott objektumban nem működik az Object.defineProperty-nél, az enumerable: false. Ez konkrétan implementációs hiba, de pl az, hogy minden egyes értékadásnál újra be kell állítani, hogy enumerable: false maradjon, már nem az. Logikusan átgondolva ez valami olyasmi kellene, hogy legyen, ami független az értéktől, és a property-re jellemző dolog az adott objektumon, tehát valamilyen metaadattal kellene leírni, és egy szimpla értékadás nem szabadna, hogy megváltoztassa. Ami szintén zavaró, hogy a setter-nél és getter-nél nem találtak ki olyan tárolóhelyet, amibe menteni tudnánk az adatokat, mindig closure-t kell használni, és onnan előkaparni mindent. De ugyanígy ezeréves dolgokkal is vannak problémák, pl hibakezelésnél nincs Composite Error, nekünk kell összeszórni saját implementációt. Nincs rá lehetőség a környezetek többségében, hogy tömbként lekérjük a stacktrace-t, stb... Olyan dolgokról meg akkor nem is beszéltem, hogy a window.onerror hibaüzenetet ad vissza ahelyett, hogy error objektumot adna, stb... A nodejs szerintem baromi hasznos a javascript szempontjából. Bár ezek a tervezési hibák sajnos többnyire a core-ban fordulnak elő, azért a nodejs egy stabil platform szemben a böngészőkkel, ahol állandóan tákolni kell, hogy egyről a kettőre jusson az ember, már ha alacsony szinten próbál fejleszteni. Nyilván magasabb szinten a zűrök egy jelentős részét elfedik a keretrendszerek, mert ők megszenvedtek velük helyettünk.

Köszi a linket, valószínűleg küldeni fogok bele pár dolgot.
34

Egyébként szerintem nyugodtan

inf3rno · 2015. Már. 10. (K), 20.43
Egyébként szerintem nyugodtan írhattad volna, hogy a mostani user-agent header helyére szeretnéd, bár majd úgyis átnevezik a saját szájízük szerint, ha hajlandóak implementálni.
35

Kíváncsi voltam, mit

Hidvégi Gábor · 2015. Már. 10. (K), 21.13
Kíváncsi voltam, mit reagálnak rá. Persze mindjárt előszedték a követhetőséget, csak nem hiszem, hogy ez oszt vagy szoroz, múltkor olvastam, hogy még privacy módban is elég információt küld az azonosításhoz az összes böngésző.

Ajánlják, hogy legyen szabványos, aminek van alapja, csak akkor meg sosem lesz belőle semmi.
38

Természetesen összerakhatnak

inf3rno · 2015. Már. 10. (K), 23.12
Természetesen összerakhatnak ők egy szabványt, mivel ők az első implementálói a dolognak, ez előny, nem hátrány. :D Egyébként akkor meg érdemes a szükséges minimumra szorítkozni, böngésző engine verziószámmal, felbontás, kijelző átmérője, css,js,cookiek bekapcsoltsága ennyi.
39

Leírtam én is a véleményemet.

inf3rno · 2015. Már. 10. (K), 23.30
Leírtam én is a véleményemet. Nyilván nem lesz semmi a dologból, mert ahhoz hátszél is kellene. Egy hozzáértőnek szerintem körülbelül 1 napjába telne megírni amúgy a szabványt, csak hát látványosan nem akarnak semmi ilyesmit csinálni.
40

Kb én is ugyanoda jutottam, a

inf3rno · 2015. Már. 11. (Sze), 03.40
Kb én is ugyanoda jutottam, a whatwg mailing list-en kellene próbálkozni tovább, azt javasolják. Illetve, hogy érdemes lenne kivenni az olyan részeket, amiknek nem feltétlen van haszna fejlesztői szempontból, viszont felhasználhatóak a felhasználók nyomonkövetésére. Gondolom a szabványnak tételesen fel kellene sorolni, a lehetséges tulajdonságokat és azok biztonsági kockázatát, illetve javaslatot tenni, hogy melyeket implementálják és melyeket nem.

(Hát ez gondolom egy jó hosszú beszélgetés lenne a mailing list-en, ha nem próbálnak meg azonnal lekoptatni. Nekem a személyes tapasztalatom, hogy még ha meg is győzöd őket, hogy ez meg ez tök jó lenne, ha benne lenne a szabványban, akkor is általában az van, hogy de mégsem tesszük bele, mert csak. Nekem személy szerint erre most nincs időm, de ha gondolod vedd fel velük a kapcsolatot, hátha sikerül elintézni.)
41

"Üljünk össze"

Gixx · 2015. Már. 12. (Cs), 11.36
Nincs tapasztalatom a szabványok írásában, de ha lenne egy open doksi (google docs), amibe mindenki beleírná a javaslatait, amiből egy másik kevésbé nyílt doksiban a hozzáértőbbek összerakhatnának egy javaslatot, amivel talán érdemben is foglalkoznának odafent.

Már csak azért is, mert a reakciók sokkal kevésbé voltak elutasítóak annál, mint amit vártam.
42

Szerintem két részre kéne

Hidvégi Gábor · 2015. Már. 12. (Cs), 16.01
Szerintem két részre kéne szedni a "szabvány" tervet is, a User Agent String-ben lévő változók minimális kiegészítésével elég hamar lehetne végezni.
43

Én azt javaslom, hogy először

inf3rno · 2015. Már. 12. (Cs), 16.07
Én azt javaslom, hogy először mindenképp keressük meg az illetékest ezzel kapcsolatban, mert a végső döntést mindenről ő(k) fogja hozni, és nem mi.
44

A pozitív döntés érdekében

Hidvégi Gábor · 2015. Már. 12. (Cs), 16.20
A pozitív döntés érdekében lehet kész anyaggal kéne megkeresni.
45

Végülis úgy tiszta legalább,

inf3rno · 2015. Már. 12. (Cs), 16.22
Végülis úgy tiszta legalább, hogy mire gondoltok, és megelőzhetőek az ilyen fingerprintes viták is, mint ami firefox-nál kialakult.

Én javaslum a user-agent2 helyett a capabilities-t vagy hasonlót elnevezésnek.

A másik, ami benne szokott lenni ezekben:

The key words MUST, MUST NOT, REQUIRED, SHALL, SHALL NOT, SHOULD,
SHOULD NOT, RECOMMENDED, NOT RECOMMENDED, MAY, and OPTIONAL in this
specification have the meaning defined in [[!RFC2119]].
46

Félig off

Hidvégi Gábor · 2015. Ápr. 22. (Sze), 15.25
Csak részben kapcsolódik a témához: ha a böngésző tudná, hogy korlátos (fizetős) netet használ, akkor be lehetne építeni, amit ma mindenki JS-sel old meg, hogy a képeket csak akkor töltse le, ha bekerül a viewportba.

Ha elküldenénk a net típusát, akkor mobilra olyan kódot küldhetnénk ki, ami a fentebb leírt módon működik, korlátlan netnél meg kiküldhetnlnk minden képet.

Engem legalábbis nagyon irritál az a trend, hogy görgetés közben töltődnek be a képek, akkor is, ha desktop PC-n nézem, korlátlan nettel. Igénytelennek tartom, amit tovább ronthat, ha a képek méretét nem küldik ki, azaz miután a böngésző letöltötte, megjelenik, de a mellette lévő szöveg átformázódik, a tartalom lefele csúszik.

Már azzal is sokat lehetne segíteni a dolgon, ha nem akkor kezdenénk el letölteni a képet, amikor bekerül a képernyőre, hanem mondjuk egy képernyővel korábban, így mire odaérek, már ott lenne, és sokkal jobb lenne a felhasználói élmény.

Ad extremum a böngészők mobilinternet esetén JS nélkül is automatikusan végezhetnék a képek betöltését (azaz addig nem töltik le, amíg nem látszik, mondjuk az előző bekezdésben leírt algoritmus alapján).
47

13

vbence · 2015. Ápr. 22. (Sze), 17.45
13/1 ;)
50

Kicsit továbbvittem

Hidvégi Gábor · 2015. Ápr. 22. (Sze), 21.13
Egyre jár az agyunk, ezt már megfigyeltem.
48

korlátlan?

Poetro · 2015. Ápr. 22. (Sze), 19.30
A böngésződ honnan tudja, hogy korlátlan neten vagy? Ha WiFit használsz, az nem jelenti, hogy korlátlan. Lehet, hogy a netet a telefonodról kapod, vagy a gépedben levő SIM kártyáról. Még akkor is ha asztali gépen vagy.

És ugyan lehet, hogy korlátlan a net, de rossz a jelerősség telefonon vagy WiFin. Ekkor is inkább töltsön le több Mb adatot, amikor ISDN-nél vagy EDGE-nél nem gyorsabb a letöltés? Hogy változna mindez, ha változnak a körülmények letöltés közben?

Ezt nagyon nehéz általánosítani, ezért senki sem teszi.
49

Pl. be lehetne állítani az

Hidvégi Gábor · 2015. Ápr. 22. (Sze), 21.12
Pl. be lehetne állítani az operációs rendszer lenyíló menüjében, csak akarni kell.
51

beállítani

Poetro · 2015. Ápr. 23. (Cs), 08.25
Amit be lehet állítani, azt a felhasználók 99% nem teszi meg, ha nincs rákényszerítve. Ha pedig egyszer beállította, utána elfelejti hol.
52

Akkor úgy kell neki

Arnold Layne · 2015. Ápr. 23. (Cs), 15.52
Szerény véleményem szerint azért már fájjon a té elhasználó feje. Így is elég sok eszköze gondolkodik már helyette, szerintem nem kéne még egy.
53

Beállítani

Poetro · 2015. Ápr. 23. (Cs), 17.18
Szóval, amikor nekem naponta kb 10-szer valtozik, hogy milyen technológiát használok netezésre (true story), mindannyiszor át kellene állítanom a beállításokat. Igen csábító ajánlat.
54

Elképzelhető, hogy van ennél

inf3rno · 2015. Ápr. 23. (Cs), 20.14
Elképzelhető, hogy van ennél jobb megoldás a problémára, csak utána kellene gondolni.
55

Ha nem tetszik, ne használd.

Hidvégi Gábor · 2015. Ápr. 23. (Cs), 20.21
Ha nem tetszik, ne használd. De ha nincs is ilyen lehetőséged, akkor biztosan nem tudsz vele élni.