ugrás a tartalomhoz

When web standards fail us

Joó Ádám · 2011. Okt. 4. (K), 19.47
Amikor a szabványok cserben hagynak minket
 ■
1

Ezen nagyon nem kell

Hidvégi Gábor · 2011. Okt. 4. (K), 21.10
Ezen nagyon nem kell csodálkozni. A W3C-ben a szabványokat a nagy cégek írják, mert megvan hozzá a hatalmuk, és úgy alakítják azokat, ahogy az aktuális érdekeiknek megfelel (lásd Canvas és az Apple), vagy hogy kiszolgálják az éppen dúló divathullámot. Sajnos az ő és az internetezők igénye halmazainak sokszor kicsi a metszete.

Álljon itt az én listám, amit hiányolok a jelen és jövő szabványaiból:
- a http (valamint az ftp/sftp/ssh) szabvány kiegészítése, hogy egy kérésre több fájlt is lehessen kérni vagy küldeni, jelentősen csökkentve ezáltal az overhead-et
- CSS-ben egy előre nem ismert dimenziójú html elem szülő eleméhez képest való vízszintes/függőleges középre igazítása egyszerűen (például így: vertical-align: center; horizontal-align: center)
- CSS-ben változók és kifejezések használata (á la CSS expressions)
- látva, hogy mennyire sikertelen a jelenlegi, szöveg alapú keresés (google, bing, yahoo), be kell vezetni a szemantikus webet, ahol a megosztott adatokat többletjelentéssel lehet ellátni, valamint meg lehet adni az összefüggéseket
- kombóbox a HTML-ben
- alkalmazásfejlesztés támogatása (ExtJS, XForms)
2

-

Tyrael · 2011. Okt. 5. (Sze), 12.52
- http://en.wikipedia.org/wiki/HTTP_pipelining
- hogy a vertical-align nem azt csinálja amit az ember elsőre várna tőle, az epic fail, kb. a legtovább létező valid kifogás volt a table-less design ellenzői között.
- css expressionstől én berzenkedem, új biztonsági attack vektor.
- szemantikus web: xml jó lehetett volna, de inkább arra megy a világ, hogy bármilyen szar/hibás kontentet tudjon kezelni a böngésző (már az opera is feladni látszik a harcot...).
- kombóbox nekem nem fontos, de okosabb selectek, optgroup-okban lehessen már minden browserben háttérképeket használni, etc.
- alkalmazásfejlesztés támogatás alatt mit értesz, valami egységes frameworkot? hogy ne kelljen userlandból implementálni az alapokat?

Tyrael
4

- a http pipelining-ot a

Hidvégi Gábor · 2011. Okt. 5. (Sze), 13.45
- a http pipelining-ot a wikipédia szerint nem használja egy böngésző sem (mondjuk szerintem ez elavult információ lehet), továbbá érzésem szerint a párhuzamos letöltések jobban terhelik a szervert, én inkább azt az ötletet támogatnám, amikor csomagban jönnének le a fájlok, mint pl. a .gz vagy egy .zip

- css kifejezésekre már vannak újabb kezdeményezések; a jelenlegi túl statikus, múlt századi őskövület, ami visszafogja a fejlesztéseket, továbbá a különböző mobil- és táblaeszközök elterjedésével (a legújabb mobiloknak öt hüvelyken van HD felbontása!) szükségszerű lesz átgondolni ezt az egész témakört, mert az eddigi megoldások (CSS media query) segítségével nem tudjuk megmondani a képernyő fizikai méretét

- erről jut eszembe, hogy be kéne vezetni a kliens internetsebességének lekérdezhetőségét, és lehetőséget a tartalom ehhez való szabására, gondolva itt a mobilnetesekre, akiknek jóval lassabb és drágább a hozzáférése, mint egy adsl vagy kábelnet

- szemantikus web: az egész kezdeményezést a 2000-es évek elején a WhatWG csoport torpedózta meg, akik így definiálják magukat: "An unofficial collaboration of Web browser manufacturers and interested parties", ezért ugrott az XHTML és az XML, ez pedig szerintem a minőség rovására fog menni

- a kombóbox a webes alkalmazások fejlesztésénél nagyon hasznos

- egységes, natív keretrendszert értek az alkalmazásfejlesztés támogatása alatt, mint például az ExtJS, csak böngészőbe beépítve
10

eddigi megoldások (CSS media

H.Z. v2 · 2011. Okt. 5. (Sze), 16.29
eddigi megoldások (CSS media query) segítségével nem tudjuk megmondani a képernyő fizikai méretét


Mi a helyzet a mm-ben, cm-ben stb. megadott méretekkel? Vagy mi egyéb okod lenne lekérni a fizikai méretét CSS-ből?
11

mm, cm?

Poetro · 2011. Okt. 5. (Sze), 16.32
Mi az mm illetve cm? Ezek valami keretrendszerek? A képernyőm fizikai méretét még én sem tudom, csak az látható képátlót. Nem hiszem, hogy ez szoftveresen lekérdezhető lenne :)
12

Hát nem tudom... Ugye a dpi

H.Z. v2 · 2011. Okt. 5. (Sze), 16.58
Hát nem tudom... Ugye a dpi adott (elvileg, hogy a gyakorlatban ez mennyire pontos... :D) és többé-kevésbé jól eltalálja a böngésző a méreteket, ha milliméterben adom meg őket pixel helyett. (a laptopomon, Vista alatt - máshol nem néztem, mert valahol olvastam, hogy az ilyen méretezés kerülendő, így sürgősen leszoktam róla)
22

Az Ivy Bridge megújítja az

Hidvégi Gábor · 2011. Okt. 6. (Cs), 11.37
Az Ivy Bridge megújítja az ultrabookokat
megtartják a régóta optimálisnak tartott 13 colos paramétert, de a natív felbontás 2560x1440 képpont is lehet, vagy akár több

Egy időben a World of Warcraft nevű játékhoz fejlesztettem egy kiegészítőt, és nagyon megtetszett az ott alkalmazott szemlélet. Eleve úgy készítették el a rendszert, hogy gond nélkül támogassa és jelenítse meg az egyes UI elemek relatív hosszát, így számomra úgy tűnt, hogy rugalmasabban kezeli az oldalon belüli nagyítást és kicsinyítést (itt jellemzően olyan dialógusablakra kell gondolni, ahol különböző beállításokat lehet elvégezni).

Többek között megadható, hogy egy elem melyik sarkával melyik másik elemhez, és annak melyik sarkához kapcsolódjon.

Példa: van egy beviteli meződ, a bal felső sarka kapcsolódik a szülőelem bal felső sarkához, attól X1, Y1 távolságra van. Ez után van egy listbox, aminek a bal felső sarka a beviteli mező jobb felső sarkához kapcsolódik, attól X2 távolságra van (Y2 = 0).

Így belegondolva ennek igazából akkor van előnye a CSS-hez képest, ha mondjuk több elemet szeretnél áthelyezni az oldalon belül más kiinduló helyre, úgy, hogy az egymástól való távolságuk az megmaradjon. Továbbá az is megadható, hogy például bizonyos elemek magassága akkora legyen, mint az ő kapcsolódó elemük magassága, így elég az elsőt átméretezni, a második pedig követi.

Annyit nem használtam azt a rendszert, hogy egyértelműen kijelenthessem, jobban működik, mint a CSS, de szerintem érdemes rajta elgondolkozni.
3

Kérdéses, hogy a szemantikus

prom3theus · 2011. Okt. 5. (Sze), 13.04
Kérdéses, hogy a szemantikus web mennyire lenne sikeres (vagyis: alkalmazott). Az egyik gond itt, hogy még a jelenlegi szemantikai támogatást se használja a többség, a másik gond pedig a WYSWYG szerkesztés: elvárható-e egy irodai asszisztenstől, hogy szemantikai összefüggéseket határozzon meg a szövegben? (nem)

A kombóboxot nem tartom égetően fontosnak - vagy ha az (mert egyébként vitán felül nagyon hasznos kontrol), akkor az ExtJS kontroljainak 90%-át kívánnám HTML támogatottan megvalósítva látni, mert úgy kerek, egyébként mindig lenne valaki, aki szerint a kombóboxon felül még kéne egy ilyen majd egy olyan is...

A CSS kifejezések támogatása szerintem nem biztos, hogy szerencsés volna. Leíró nyelvet bajos elmozdítani programnyelv irányba, a CSS néha így is okoz fejtörést a feldolgozáskori sebesség-optimalizálás terén, hát még ha kifejezések kiértékelésével társulna... másrészt ezekre a problémákra a JS megoldást tud nyújtani: miben lenne hatékonyabb a kifejezések értelmezése a CSS-ben, mint ugyanaz a JS segítségével (a JS motorok egyre csak gyorsulnak és egyre fejlettebbek, a CSS motorok kifejezés futtató/kiértékelő mechanizmusaival szemben valószínűleg sokéves előnyben lennének, ha utóbbiak megjelennének - ha pedig a CSS kifejezéseket is a böngésző JS motorja értelmezné, újra adódik a kérdés: minek is?).

Az utolsó pontot pedig nem tudom értelmezni: milyen módon és miért van szükség a HTML-ben ExtJS-t és/vagy XForms-t támogatni? (kérdezem ezt annak dacára, hogy az ExtJS közel van a szívemhez)
5

Tyraelnek adott válaszaim jók

Hidvégi Gábor · 2011. Okt. 5. (Sze), 13.57
Tyraelnek adott válaszaim jók ide is, az utolsó ponthoz: szerintem azért van szükség az alkalmazásfejlesztés támogatására, mert boldog-boldogtalan webes alkalmazást fejleszt, azaz a web eddig inkább statikus volt (a weboldalak 99%-a ebből a szempontból csak adatmegjelenítésre alkalmas), de egyre inkább szükség van az interneten keresztül történő adatmenedzsmentre, információtárolásra. Ez a jelenlegi eszközökkel nehézkes és lassú.

A szemantikus web azért lesz sikeres, mert az információk és az összefüggéseik részletesebb megadása nagyságrendekkel pontosabb találatokat fog eredményezni, mint manapság. Természetesen az egy megoldandó probléma, hogy miként könnyítsük meg a plusz adatok megadását, pár hete többek között ezzel kapcsolatban keresek kutatás-fejlesztésre társakat nyílt projekt keretében.
6

Elolvastam amit Tyrael-nek

prom3theus · 2011. Okt. 5. (Sze), 14.36
Elolvastam amit Tyrael-nek írtál. A CSS mobilos lehetőségeinek korlátait sajnos nem túlságosan ismerem valóban, holott ez egy egyre növekvő piac (lassan el fogom hinni azt is, hogy ez egy létező piac és nem csak egy bazi nagy lufi néhány buzzword köré gyógyulva). Tehát mobilokra vonatkoztatva egy határozott "talán"-nal toldanám ki a kétségeimet a szükségességet illetően :)

Nem hiszek a teljesen eldesktoposodó internetben, ahogyan szintén sosem fogom azt gondolni, hogy valaha az életben szükséges lesz olyan Word dokumentumot írni, ami pont úgy viselkedik, mint egy asztali alkalmazás.
Szerintem: ha asztali alkalmazás kell, használjunk asztali fejlesztésre szánt környezetet; ha webes, használjunk rá webest (rnd(szerveroldali nyelv)+HTML+CSS+mondjukExtJS === RIA); ha pedig főképp csak információt akarunk megjelentetni akkor HTML-t CSS kíséretében, esetleg némi JS-sel megtámogatva. Ha a víziódat magam elé képzelem, az az érzésem támad, hogy olyan asztalos vagyok aki minden eszközt kalapácsnak- és minden problémát szögnek nézhet. Valójában pedig kevés olyan embert láttam ebben a szakmában akinek kellő önfegyelme volt ahhoz, hogy ne nézzen mindent kalapácsnak vagy szögnek.

A szemantikussággal is ugyanez - vagy legalábbis hasonló a problémám: user error, de nem képezhetünk mindenkiből szemantikusan gondolkodni tudó félandroid programozó-wannabe-t. Ahhoz pedig, hogy a szemantikusan tuningolt szövegek létrejöjjenek, vagy ennek nagyon széleskörű oktatására (és így sok-sok évre), vagy MI alkalmazására lenne szükség: szerintem egyik sem várható, hogy a következő 20 évben realizálódni fog a dolgunkat nagyban megkönnyítő megoldás. A web nagy része szöveg: hírek, cikkek, ezek tucatnyi recitálásai. A webalkalmazások a webnek csak egy nagyon kis szegmensét teszik ki és nem hiszem, hogy ez drasztikusan változni fog a közeli jövőben. Ha pedig így van, annak se látom értelmét, hogy az újságírók, cikkíró asszisztensek szemantikát tanuljanak.
Nem azt mondom, hogy a szemantikus webnek nincs értelme, csak csupán azt, hogy az általad vizionált mértéket tartom túlzónak.
7

A szög-kalapács dilemma

Hidvégi Gábor · 2011. Okt. 5. (Sze), 14.56
A szög-kalapács dilemma bennem is felmerül sokszor, és emiatt igyekszem felülvizsgálni a gondolataimat, ellenőrző kérdéseket feltenni, hogy jól látom-e. Majd a jövő eldönti, egyelőre hiszek abban, hogy ezek a problémák megoldhatóak, és a nagy többséget szolgálják.
8

De hogy érdemben is

Hidvégi Gábor · 2011. Okt. 5. (Sze), 16.23
De hogy érdemben is válaszoljak: ha figyeled a híreket, látható, hogy egyre inkább terjednek az okostelefonok, valamint kisebb mértékben a táblapc-k is. Ezek jellemzően nem Windows operációs rendszerre épülnek, hanem Androidra, iOS-re és így tovább, azaz a hagyományos alkalmazások nem működnek rajtuk. Ezt tovább bonyolítja, hogy a Windows 8 ARM architektúrán is futni fog, amin ugyancsak nem fut az x86-os kód.

Persze mindegyikre van most ilyen-olyan applikáció piactér, de szerintem ezek hosszú távon nem lesznek népszerűek, mert kétlem, hogy a fejlesztőknek megéri n darab platformra megírni ugyanazt a szoftvert. Szóval ketten maradnak a porondon, de személyes ellenérzések miatt a Javát rögtön kiejteném, így marad a web, tehát itt van szükség egy szabványos alkalmazásfejlesztő és -futtató rendszerre.
9

Android

Poetro · 2011. Okt. 5. (Sze), 16.25
Nem tudom, neked miért esett ki a Java, mivel Android alá Java-ban kell fejleszteni az alkalmazásodat. Ezen kívül több keretrendszer létezik, amihez HTML/CSS/JS-ben fejleszted az alkalmazásodat, és azt lefordítja több platformra (Apple iOS, Google Android, HP webOS, Microsoft Windows Mobile, Nokia Symbian OS és RIM BlackBerry).

Ha szerinted nem lesznek népszerűek, akkor miért tolja minden OS gyártó a saját alkalmazás piacterét, valamint más szereplők, mint az Amazon is belépett már erre a területre, valószínűleg nem kis sikerrel.

kétlem, hogy a fejlesztőknek megéri n darab platformra megírni ugyanazt a szoftvert

A fejlesztők nagyon ritkán írják meg a szoftverüket több platformra, de a népszerűekre általában igen. Lásd Adobe CS, Microsoft Office, Libre Office, OOo, Mozilla Firefox. Vannak olyanok amik csak egy platformon működnek, de ez nem jelenti azt, hogy attól még nem lehet lenne nyereséges valamit csak arra a platformra fejleszteni. Gondolom hallottál iOS alkalmazás sikertörténetekről. És ha elegendő nyereséget látnak más platformra való protoláson is, akkor meg fogják tenni, hidd el.
13

Nem szeretem a Javát, mert

Hidvégi Gábor · 2011. Okt. 5. (Sze), 17.22
Nem szeretem a Javát, mert eredetileg az én ötletem volt, de lenyúlták ('93-'94 körül kezdtem el írni egy nagyon hasonló rendszert).

Minden OS gyártó azért tolja a saját piacterét, mert pénzt szeretnének keresni belőle. Blogmarkban is volt kinn, és én örömmel üdvözöltem, hogy a Mozilla olyan web alapú op.rendszert fejleszt, amivel minden mobilos funkció elérhető és használható. Ha ez megvalósul, ezek az alkalmazáspiacok bajba kerülhetnek.

Továbbá ne felejtkezzünk el a felhasználókról, akik két különböző OS-t birtokolva kénytelenek lehetnek ugyanazt az alkalmazást kétszer megvenni. Erre megoldás lehet egy közös webes platform.
14

Opera

Poetro · 2011. Okt. 5. (Sze), 17.56
Az Operának is van egy widget rendszere, amiben lehet alkalmazásokat készíteni HTML / CSS / JS alapokon. Jelenleg minden platformon van megfelelő böngésző, amivel lehetne ezeket futtatni, csak az API-t kellene beépíteni ezekbe.
17

csak az API-t kellene

Hidvégi Gábor · 2011. Okt. 6. (Cs), 06.53
csak az API-t kellene beépíteni ezekbe
Erről beszélek. Csak előbb szabványosítani kéne, hogy a többiek elfogadják.
15

Java

Poetro · 2011. Okt. 5. (Sze), 17.58
Nem szeretem a Javát, mert eredetileg az én ötletem volt, de lenyúlták ('93-'94 körül kezdtem el írni egy nagyon hasonló rendszert)

James Gosling, Mike Sheridan, and Patrick Naughton initiated the Java language project in June 1991.

Java (programming language)
18

Tegnap sietnem kellett, így

Hidvégi Gábor · 2011. Okt. 6. (Cs), 06.54
Tegnap sietnem kellett, így nem tudtam mindent leírni, és a smiley is lemaradt. Természetesen nem én találtam fel a javát, de teljesen függetlenül én is egy hasonló fejlesztésbe kezdtem, a babok megjelenéséről 1995 végefelé olvastam a PC World hasábjain.
16

Alkalmazásbolt

Poetro · 2011. Okt. 5. (Sze), 18.01
Továbbá ne felejtkezzünk el a felhasználókról, akik két különböző OS-t birtokolva kénytelenek lehetnek ugyanazt az alkalmazást kétszer megvenni. Erre megoldás lehet egy közös webes platform.

Ez eddig is így volt, ebben nincs semmi újdonság. Ha megvetted az MS Office-t, vagy Adobe CS-t Windows alá, akkor külön meg kell venned MacOS X alá is.
19

Így van, de most képzeld el,

Hidvégi Gábor · 2011. Okt. 6. (Cs), 07.03
Így van, de most képzeld el, hogy van egy közös webes platform, és nem kell ugyanazt a szoftvert megvenned n-szer. Valamint, ha pénzt kérnek egy appért, valószínűleg nem fognak 30%-ot lenyúlni, mint ahogy a Google vagy a Microsoft stb. teszi, mert bárki indíthat egy piacteret, azaz lesz verseny.
20

Szerintem (ha csak logikusan

prom3theus · 2011. Okt. 6. (Cs), 10.35
Szerintem (ha csak logikusan próbálom követni a folyamatokat az iparban): a tegnap webalkalmazásaiból már tisztán látszik, hogy sokkal több is kihozható lenne, ha a lehetőségek fejlettebbek lennének (lehetőség = böngészők API-ja). Ahhoz viszont, hogy web alapra lefejlesszen az MS egy Office termékcsaládot a desktop-os változattal _teljesen_ megegyező képességekkel, idő kell, tapasztalat kell, erőforrás kell és mindeközben elő kell készíteni rá a felvevő piacot (fogjuk rá: megtörtént/történés alatt van), el kell jönnie annak az időnek, amíg minden embert rávesznek arra, hogy többedrészt legyen online, mint offline. Stb. Ez nagyon összetett folyamat, túlmutat az ismereteimen a vázolása, de csak ezekbe a lépésekbe belegondolva is látni lehet, hogy a nyilvánvaló piaci (pénzbevételi) érdek mellett társadalmi tényezők is gátat szabnak a webalkalmazások fejlődésében. Időnek kell eltelnie (nem is kevésnek), amíg az emberek felfedezik maguknak a "desktop-on túlt", az újdonságokat pedig ezért is célszerűbb talán valóban lassabban adagolni. Amellett a piacnak egy jogos félelme is van: ha berobbanna a nagy webapp őrület, minden cég és startup ontaná magából a desktop alkalmazásokkal konkurálni képes webes alkalmazásokat, szinte boritékolható lenne egy .com lufi v2, de még ha ezt el is kerülné a piac, az biztos, hogy a feje tetejére állna teljesen - márpedig a piac sokkoló hirtelenséggel történő felborulása egyetlen szereplőnek sem tenne jót, de talán az ügyfeleknek/vásárlóknak sem.

Amire rá szeretnék mutatni: többféle, egymástól többé vagy kevésbé függő vagy független folyamatnak kell összeérnie ahhoz, hogy a web, mint alkalmazás-platform valóban sikeres legyen és valóban elérje (később meghaladja) a desktop platformok alkalmazásainak használhatóságát, hasznosságát.
21

Így van, viszont amire

Hidvégi Gábor · 2011. Okt. 6. (Cs), 10.46
Így van, viszont amire beérnek a folyamatok, a szabványoknak készen kell állniuk, és a böngészőknek teljes támogatással kell rendelkezniük, ezért kell idejében elkezdeni a munkát. Én erre buzdítok mindenkit.
23

- CSS-ben egy előre nem

Hidvégi Gábor · 2011. Okt. 6. (Cs), 12.26
- CSS-ben egy előre nem ismert dimenziójú html elem szülő eleméhez képest való vízszintes/függőleges középre
Erre megoldás lesz a box-align: CSS3 Flexible Box Layout Explained, ezen belül a "box-pack and box-align" bekezdés érdekes.
But we can also set box-align to center and, depending on the box-orient value, the element will be centered either vertically or horizontally.
24

Kérdés az, hogy van-e jövője

Hidvégi Gábor · 2011. Okt. 11. (K), 09.15
Kérdés az, hogy van-e jövője a központosított (W3C) szabványoknak egy ilyen gyorsan fejlődő és változó területen, mint a web?

Az első a sorban, aki a saját elképzelései szerint kezdte a saját elképzelései szerint formálni az internetet, a Microsoft volt, az Internet Explorerben bevezetett különböző újításaival. Ezekért kapott hideget-meleget, némelyik feledésbe merült, más megoldásokat pedig átvett a konkurencia, és most már szabványtervezet része (pl. XMLHTTPRequest). Sokak szerint (többek között emiatt) az önállósága miatt a Microsoft az ördögtől való, azt viszont nem tudják - vagy nem akarják - észrevenni, hogy a többiek is pont ezt csinálják.

2004-ben, megelégelve a W3C lassúságát, valamint a tervezett X(HT)ML alapú (szemantikus) web koncepcióját nem elfogadva, megalakult a WhatWG (Apple, Mozilla, Opera), amely elkezdte a HTML(5) szabvány kidolgozását. Ezzel annyira sikeresek lettek, hogy a W3C engedett a nyomásnak, és elfogadta ezt az irányt.

Az egyik legújabb szakadár kezdeményezés a Google-Microsoft-Yahoo által grundolt schema.org, vagy a Google-féle Dart, de a sor hosszan folytatható.

Hamar feltűnhet a témában kicsit is jártasoknak, hogy ezek a cégek mind a W3C tagjai, és ténykedésük ezer kérdést vet fel:
  • Jót tesznek-e ezzel a világnak, hogy a saját kezükbe veszik a gyeplőt?
  • Az internetező többség vagy az adott cégek fognak ebből jól járni?
  • Van-e értelme a W3C-nek?
  • Ha nincs, mit szerencsétlenkednek még ott?
  • Ha van, miért engedjük (az internetezők és webfejlesztők közössége), hogy a tőkeerős cégek diktáljanak?
  • Hogyan lehetne a szabványosítás folyamatát a fejlődés sebességéhez felzárkóztatni?
  • Segítene-e, ha a szabványokat "felrobbantanánk", és azokat kis, hatékonyan működő csoportoknak adnánk ki fejlesztésre?
  • Ha átengedjük a cégeknek a szabványok fejlesztését, mi a garancia arra, hogy az internet nyílt marad, nem pedig az ő érdekeiket szolgáló platform?
  • Ha nem engedjük át, fogunk-e úgy valaha is egyről a kettőre jutni, hogy a W3C tagjai folyamatosan torzsalkodnak egymással?