ugrás a tartalomhoz

Mire jó a HTML5 main jelölőeleme?

Szántai Károly · 2013. Júl. 7. (V), 16.41
Például segíthet a weboldalunk akadálymentességében
 ■
1

Szerepek

Hidvégi Gábor · 2013. Júl. 8. (H), 08.40
Mint ahogy a szerző is leírja, a role attribútum révén már lassan tíz éve lehetőségünk van az oldalon a felolvasóprogramok számára megmondani, hogy melyik elem milyen funkcióval bír. Azt is megjegyzi, hogy a böngészők számára nem hordoznak jelentést, továbbá némi keresés után kiderül, hogy a Google sem jutalmazza, se nem bünteti az új tag-ek használatát.

Innentől kezdve a bevezetésük redundáns, mert kétféleképp is meg lehet adni egy elem szerepét. Humán olvasó számára elsőre nem derülhet ki egyértelműen, hogy egy adott tag mi is tulajdonképpen (a gmail-ben például <div>-eket használnak gombként), ha hosszú és nem jól tagolt a kód, továbbá a role attribútum felüldefiniálja a típust (a <header role="footer">).

Mindemellett az akadálymentesítésért felelős ARIA jóval több funkciót határoz meg, mint amit a HTML 5-ben (vagy 5.1-ben) megkapunk, azaz, ha teljeskörűen szeretnénk támogatni a fogyatékkal élőket, mindenképp rákényszerülünk a role attribútum használatára.

Összefoglalva

Mivel
  • csak a felolvasóprogramok értelmezik csak az elemek szerepeit (role, új tag-ek), a role attribútumot mindenképp, de az épp szabványosodó elemeket valószínűleg nem,
  • kétféleképp is megadhatunk egy szerepet
  • jóval több ARIA szerep létezik, mint ami a HTML-ben bennevan, és a W3C nagyon lassan emeli csak be ezeket,
ezért javaslom, hogy az egyértelműség kedvéért tartsuk meg és használjuk a role attribútumot, és a következő elemeket vegyük ki az ajánlásból:
article, aside, command, details, dialog, summary, figure, figcaption, footer, header, main, mark, meter, nav, progress, section, time. Ez egy, a mai divatnak megfelelő, egyszerűbb, letisztultabb HTML-t eredményez, és mindenki azonnal tudná az időközben megjelenő új ARIA szerepeket használni, nem kéne várni a jóval lassabb HTML szabványosításra. Emellett nem kéne az olyan böngészők miatt extra kódot betenni, amelyek még nem ismerik az új szerepet.

CSS-ben a szereppel rendelkező elemeket a következőképp lehet stílusozni:

*[role="navigation"] {
  (...)
}
2

Teljesítmény

Poetro · 2013. Júl. 8. (H), 10.31
CSS-ben a szereppel rendelkező elemeket a következőképp lehet stílusozni:

*[role="navigation"] {
  (...)
}

Egz ilyennek tudod, milyen teljesítménybeli következményei vannak? Tegyük fel, hogy egy hosszabb táblázat van az oldalon, mondjuk pár száz soros. Ekkor kb. 20-100ms-os késleltetést is okozhat egy-egy komolyabb DOM manipuláció, mivel újra fel kell dolgozni a CSS-t.

(a gmail-ben például <div>-eket használnak gombként)

Én ahol megtaláltam, mindenhol <button> minden gombot. Kényelmesebb mint egy <a href="#">felirat</a> után mindig megakadályozni a böngésző alapértelmezett működését, és CSS-sel ugyanúgy formázható, és szemantikusabb is.
3

Egz ilyennek tudod, milyen

Hidvégi Gábor · 2013. Júl. 8. (H), 11.44
Egz ilyennek tudod, milyen teljesítménybeli következményei vannak?
Ezerféleképp lehet jobb css-t írni, ez egy példa volt. Egyébként, ha már itt tartunk, a népszerű CSS reset és html shim technológiák is hasonló módon befolyásolhatják a teljesítményt, ahogy írod.

Én ahol megtaláltam, mindenhol <button> minden gombot.
Ha egyvalaki elköveti, elköveti más is, főleg a Google-nak kéne ilyenekre vigyáznia, mert sokan azt hihetik, hogy úgy a jó, ahogy ők csinálják. Ennek a lehetőségét kéne megszűntetni.
10

Ennek a lehetőségét kéne

Thor · 2013. Júl. 9. (K), 08.57

Ennek a lehetőségét kéne megszűntetni.


Utána meg már csak az kellene, hogy csak szőke hajú és kék szemű web programozók csinálhassanak weboldalt..

Remélem csak viccnek szántad amit írtál.
A web egyik "jósága", hogy kevés kőbevésett szabály van, miért baj az, ha valaki nem botton-al old meg egy adott feladatot? Rosszul alszol esténként, vagy mi?
Egyébként, ha megnézed a gmail nyitó oldalán a Sign in "gombot", ~30 sor css vonatkozik rá, szóval teljesen mindegy milyen elemmel oldod meg, mindenképp kell CSS.
A másik, hogy sok esetben egy <a> <li> optimálisabb tud lenni.
13

Én csak azt mondom, hogy ha

Hidvégi Gábor · 2013. Júl. 9. (K), 09.33
Én csak azt mondom, hogy ha egy elem megjelenítését meg lehet oldani gombbal is, akkor nem kéne divet vagy spant használni.
4

Vitatkoznék

Szántai Károly · 2013. Júl. 8. (H), 19.02
@Gábor: Az akadálymentességgel foglalkozó szakemberek (beleértve engem is) nem hiszem, hogy támogatják az ötletedet. A "divitis" betegség, azaz mindenre csak a div-et használjuk, komoly gond. Szerintem pont az lenne a lényeg, hogy inkább a szemantikailag korrekt, natív HTML elemek helyes használata legyen előtérben.

Az ARIA eredetileg arra szolgált, hogy a fejlesztők által kitalált, a HTML-ben nem létező widget-ek helyes szemantikája valahogyan leírható legyen. Ha valaki például div-ekből és span-ekből gyárt egy csúszkát, akkor azt a képernyőolvasó program is csúszkának érzékelje.

Ha követném a gondolatmenetedet, akkor a <h1> helyett is ezt használhatnánk:
<div role="heading" aria-level="1">

Ezt a képernyőolvasó ugyanúgy "első szintű címsor"-ként olvassa fel, mint a <h1>-et. Szerintem Te is megerősítenél, hogy inkább maradjunk a <h1>-nél...

Azt se felejtsd el, hogy a képernyőolvasó programok mindig a böngészőprogramok által átadott információkra hagyatkoznak. Vagyis olyan szituáció nincs, hogy a képernyőolvasó program támogatja (érti) az adott elemet, de az alatta dolgozó böngészőprogram nem. Ugyanis a böngészőprogram felelőssége, hogy az accessibility API-n keresztül például a <main> elemről átadja az infókat a képernyőolvasónak. Ezen infók között kell szerepelnie az adott elem szerepének is. Magától a képernyőolvasó nem fogja az elem szerepét megérteni. Vagyis mindenképpen fontos, hogy a böngésző is értse az elemet. Persze ha mégsem értené, akkor jól jön az ARIA role, amivel az általunk átadott szerep megy át a böngészőtől a képernyőolvasóhoz.
5

A "divitis" betegség, azaz

Hidvégi Gábor · 2013. Júl. 8. (H), 19.44
A "divitis" betegség, azaz mindenre csak a div-et használjuk, komoly gond.
Miért? Kérlek, indokold az állításaidat.

Szerintem Te is megerősítenél, hogy inkább maradjunk a <h1>-nél...
Szerintem teljesen lényegtelen, milyen tag-be tesszük a tartalmat, a kódkiegészítős szövegszerkesztők korában pedig az nem érv, hogy többet kell gépelni. Az egy megszokás, hogy a <h1>-ben van a főcím, jópár helyen nem is használják, az alacsonyabb szintű címeket pedig legtöbb esetben tényleg csak hasraütésszerűen osztogatják a sitebuilderek. A legfontosabb, hogy jelöljük meg a szerepet, hogy milyen módon, az már nem számít.

Vagyis olyan szituáció nincs, hogy a képernyőolvasó program támogatja (érti) az adott elemet, de az alatta dolgozó böngészőprogram nem.
A böngészők nem foglalkoznak a tag-ekkel, hisz az ő feladatuk annyi, hogy megjelenítsék a tartalmat. Őket az érdekli, hogy mekkora, milyen színű az elem, semmi más. Ugyanígy vannak ezzel a keresők is, s bár az egyes elemtípusoknak van egy bizonyos minimális szorzója, a legkevésbé dönt ez arról, milyen helyen végez az oldalunk a sorban.

A role attribútumos megoldás jóval rugalmasabb, mint az új tag-ek létrehozása. Ráadásul ez az egész szabványosdi leragadt a múltban, hisz a web nem csak statikus dokumentumokból áll, nem csak <article>-k és képaláírások gyűjteménye, hanem dinamikus tartalom, tulajdonságokkal rendelkező objektumok hada (ha például veszel egy jegyet, az X együttes Y dátumkor lévő koncertjéről szól), összefüggésekkel, amik leírására új ARIA szerepek lennének szükségesek. Ha megvárjuk, míg mindegyik ilyen új dolgot beemeljenek az ajánlásba, megőszülünk.
6

Ne értsd félre, az eredeti

Szántai Károly · 2013. Júl. 8. (H), 22.32
Ne értsd félre, az eredeti felvetésed nem ördögtől való, és jól kivitelezve szerintem is sok logika lehet benne. Már mástól is hallottam, olvastam hasonló (értsd: mindent egy jelölőelemmel jelöljünk) felvetést. Még az is lehet, hogy a jövő ebbe az irányba halad majd, bár én jelenleg nem látok ilyen irányú masszív elmozdulást.

Én csak attól félek, hogy a Te korrekt hozzáállásoddal ellentétben, sokan ugyanúgy hanyagolnák a role dolgot, mint mondjuk most a képek alt attribútumát. Kollégáim, és én is nagyon sokat küzdünk, hogy a fejlesztők megértsék, hogy miért lényeges ennek az icipici attribútumnak az értelmes(!) kitöltöttsége. A role ennél sokkal szofisztikáltabb. A "divitis" (egészen pontosan a role nélküli divitis) ezért veszélyes. Most még mindig úgy érzem, hogy jobban járunk, ha a fejlesztő a natív szemantikájú elemet használja, mert abból legalább nem hagy le semmit.

...új ARIA szerepek lennének szükségesek. Ha megvárjuk, míg mindegyik ilyen új dolgot beemeljenek az ajánlásba, megőszülünk.

Nem igazán látom, hogy egy új ARIA szerep bevezetése, azaz támogatásának implementálása mennyivel lenne egyszerűbb, gyorsabb, gördülékenyebb mondjuk egy képernyőolvasó szoftver esetén, mint most a HTML elemeknél. Az ARIA ugyanolyan ajánlás (pontosabban hivatalosan még nem is az), mint a HTML.

Egyébként létezik egy Using WAI-ARIA in HTML című W3C dokumentáció, amit érdemes átolvasni, hiszen sok itt felmerült kérdésre iránymutatást kínál.
8

sokan ugyanúgy hanyagolnák a

Hidvégi Gábor · 2013. Júl. 9. (K), 06.42
sokan ugyanúgy hanyagolnák a role dolgot, mint mondjuk most a képek alt attribútumát
Igen, bennem is ez fogalmazódott meg ellenérvként.

Nem igazán látom, hogy egy új ARIA szerep bevezetése, azaz támogatásának implementálása mennyivel lenne egyszerűbb
Először van az ARIA, utána a HTML, két (lassú) lépcső, ha a másodikat megspórolhatnánk, már mindenki nyerne.
14

Az "alt" nagyon rossz példa

Thor · 2013. Júl. 9. (K), 09.35
Az "alt" nagyon rossz példa már ne haragudj..

.. nagyon amatőr oldal ami "alt"al operál, mert ha a képhez extra info tartozik, a képtől függetlenül illik megjeleníteni, hogy mindig látszódjon, ne csak akkor ha a felhasználó fölé viszi a cursor-t.
.. a másik, hogy nagyon sok helyen <div> -ben jelenítik meg a képeket, ahol nincs <alt> lehetőség..

Az "alt" 10 éve jó volt.. a mai világban egy szinte felesleges fi csőr.
Lehet kicsit tovább kellene képeznetek Magatokat mielőtt más fejlesztőknek ilyen nagyon kétséges dolgokat agitáltok.

A másik sületlenség a divitis, egyszerűen azért, mert nincs alternatívája, sokszor akkor is használni kell a megjelenítés miatt, amikor az ember nem szeretné, mert hála a w3c-nek a CCS egy kalap szar sokszor, mert 2-3 elemnél túl sok együttállást kell(ene) figyelembe venni (inline, display, float, stb).
16

Az a helyzet, hogy a HTML

Hidvégi Gábor · 2013. Júl. 9. (K), 09.40
Az a helyzet, hogy a HTML primitívsége miatt csak az alt segítségével lehet a képekről bővebb információt adni. És hiába telik el tizenöt év a 4.01 és az 5.0 között, ennyi idő alatt nem jutott el a készítői agyáig, hogy teljesen felesleges dolgokat fejlesztenek.
18

Semmi sem gátolja, hogy az

Thor · 2013. Júl. 9. (K), 10.04
Semmi sem gátolja, hogy az extra infót a kép mellett jelenítsd meg nagy képek esetén.
Kis képek esetén meg többnyire lényegen minden extra infó, mivel "kicsik" és alig láthatók, nem is beszélve az alt késleltetéséről/láthatóságáról. Szóval minden csak nem felhasználóbarát, csak arra jó, hogy egy modern web felület mellett salak anyagozzák az oldalt.

15 év?:)
Nem is számoltam még soha sem utána, kösz..:)
19

A gond, hogy nincs eszköz

Hidvégi Gábor · 2013. Júl. 9. (K), 10.25
A gond, hogy nincs eszköz összekötni a képet a hozzátartozó információval. Az alt attribútumot pedig a keresők és a felolvasóprogramok értelmezik.

A 15 év úgy jött ki, hogy 1999-ben véglegesítették a 4.01-et, az 5.0-t pedig jövőre.
21

Értem, ott a pont.. .. max

Thor · 2013. Júl. 9. (K), 10.40
Értem, ott a pont..

.. max annyi a kérdésem, hogy ha van egy nemzetközi weboldalam
ami x > 10 nyelven "tud", akkor mit érek a keresőkkel és az alt-ban lévő információval.:)
25

Fejlesztettem

Poetro · 2013. Júl. 9. (K), 10.57
Én fejlesztettem ilyen oldalt, és igencsak hasznos, amikor például ki kell kapcsolnod a képeket, mert olyan interneted van csak (például mobilon, vagy a világ egy nem túl jól elláttott pontján). Ekkor látod az alt attribútumot, még ha a képet nem is vagy képes megtekinteni. Ráadásul ha te egy bizonyos nyelven jelenítesz meg, akkor annak megfelelő alt attribútumot raksz ki, így a tartalom kereshető lesz, és a felolvasó, valamint szöveges böngészők is megbírkóznak vele.
27

Ott a pont. Más kérdés, hogy

Thor · 2013. Júl. 9. (K), 11.03
Ott a pont.

Más kérdés, hogy "belőlük" nem fogsz megélni, de aláírom, karitatív célokra tényleg van értelme.:)
22

<figcaption>

complex857 · 2013. Júl. 9. (K), 10.44
Nem erre van a <figure> és <figcaption> páros? Az előbbibe bele lehet tenni az <img> -t majd az utóbbival a megmagyarázni, mi van a képen. Valahogy így képzelem el:

<figure>
<img ... > (vagy video, stb...)
<figcaption>Szivárványok és egyszarvú pónik.</figcaption>
</figure>
Tény hogy ez is egy újdonsága a html5nek, így az özönvíz előtti oldalakon nem lehet számon kérni, de nekem úgy tűnik az alt attribútumokhoz képest ez mégiscsak előrelépés, tekintve, hogy mindkét elembe lehet további blokk szintű elemeket pakolni így a magyarázott dolog és a magyarázat is lehet rendesen jelölt.
24

Igazad van.

Hidvégi Gábor · 2013. Júl. 9. (K), 10.53
Igazad van.
32

Részben igazad van..

Thor · 2013. Júl. 9. (K), 11.12
Részben igazad van..
http://html5doctor.com/the-figure-figcaption-elements/

Ezek alapján ez azt csinálja, mintha egy div-et raknál szöveggel a kép alá.
Szerintem nem megoldás egy nemzetközi oldalon.. vagy legalábbis én nem látom hol
segítene.
Ez inkább megint a szemantikus oldalt erősíti.. nem ad semmire megoldást, csak a keresőknek.
33

Szerintem nem megoldás egy

Poetro · 2013. Júl. 9. (K), 11.14
Szerintem nem megoldás egy nemzetközi oldalon

Miért nem megoldás nemzetközi oldalon?
40

Mert neki van egy sikeres

bamegakapa · 2013. Júl. 9. (K), 11.39
Mert neki van egy sikeres nemzetközi oldala, tehát ő jobban tudja és pont :). Bírom az ilyen arcokat egyébként. Úgyse fogja megérteni, hogy az oldala nem azért sikeres, mert ő faszagyerek és tesz a szabványokra meg a "best practice"-okra, hanem annak ellenére.
43

Olvasd el még egyszer, amit

Thor · 2013. Júl. 9. (K), 12.01
Olvasd el még egyszer, amit írtam, mert ott volt benne a "szerintem".

Egyébként több van, de nem tudom jobban.. de Te nyilván meg tudod mondani, hogy egy képhez miként tudok X nyelven "alt" szerű infót fűzni.

Nyilván Te is faszagyerek vagy és tudsz érvelni is, és válaszolni a kérdésre.

A figcaption mindig megjelenik, X nyelv > X megjelenés, vagy tudsz módot arra, hogy a felhasználó nyelvének megfelelően "eltűnjön" a többi (Javascript nélkül)? Vagy el tudod magyarázni, hogy a keresőkön kívül mennyiben más mint ha Te raksz egy elemet infóval a kép/képek alá?

Az a baj zsenikém, hogy a magyar web programozók zöme, elég alacsony szinten űzi az ipart és bocs, ha ezért nem veszek be mindent, csak amit érvekkel alá is támasztasz.
45

A személyeskedésen nem

bamegakapa · 2013. Júl. 9. (K), 12.11
A személyeskedésen nem sértődök meg, mivel bevallom, ugyanazt feltételeztem rólad, amit te rólam :).

A problémádat illetően (bár a pontos feladat ismeretében csak sötétben tapogatózok), vagy nem raknám ki az összes nyelven a feliratot, csak az oldal aktuális nyelvén, vagy használnám a lang attribútumot és a megfelelő CSS szelektorokat. Az, hogy az adatot divbe vagy figcaptionbe rakod, ilyen szempontból lényegtelen, gondolom azért döntesz a div mellett mégis, mert rühelled a HTML5-öt és nem értesz egyet vele, ami önmagában is remek szakmai érv. Mit nyersz a divvel azon kívül, hogy hős ellenálló leszel?
48

:) Nos, én valószínű <p>-be

Thor · 2013. Júl. 9. (K), 12.47
:)
Nos, én valószínű <p>-be tenném mert az csak 1 karakter (és nem kell a keresőknek megfelelnem).:)

Érdekes, hogy rögtön nem érted a problémát: adott egy kép amihez több nyelven kellene hozzárendelned infót ("alt"), úgy hogy a keresők is megegyék, és ne kelljen trükköznöd.

A lang a kereső felé megoldás, de megjelenítéskor nem megoldás, mert nem tudsz a felhasználó által beállított nyelvének megfelelő CSS alkalmazni, szerintem csak dinamikusan tudnád elrejteni ami nem kell (figcaption). Szerintem.

Nem mondtam, hogy jobb, csak azt mondtam az "alt" attribútum hülyeség és korlátos, én sehol nem használom.. és a figcaption alapján ezek szerint más is megértette, csak kicsit korlátosan.
60

Előrevetítettem, hogy lehet,

bamegakapa · 2013. Júl. 9. (K), 14.16
Előrevetítettem, hogy lehet, hogy nem fogom pontosan átlátni a problémádat, mivel nem magyaráztad el. Miért akarod egy dokumentumon belül hozzárendelni az összes nyelven? Én ennek így hirtelen nem látom semmi értelmét. Hogy jeleníted meg jelenleg a megfelelőt? :)

Az alt attribútummal egyébként szerintem semmi baj nincs, ha tudja az ember, hogy mire való. De nem akarlak meggyőzni, csináld csak, ahogy jól esik.
42

Miért megoldás?

Thor · 2013. Júl. 9. (K), 11.48
Miért megoldás?
46

alt

Poetro · 2013. Júl. 9. (K), 12.12

<figure>  
<img alt="${image.title}" src="${image.src}">
<figcaption>${image.title}</figcaption>  
</figure>
És aki feltölti az oldalt tartalommal, az megadja a megfelelő nyelven az alt-ot is, ami akár lehet a termék neve is, vagy akármi alapján kerül oda a kép. Pont olyan bonyolult megoldani, mint bármilyen többnyelvű tartalmat.
49

Neked is.. a kérdés úgy

Thor · 2013. Júl. 9. (K), 12.49
Neked is.. a kérdés úgy hangzott: egy kép -> több "alt" különböző nyelveken, dinamikus kód nélkül.
54

A HTML-ben semmilyen szinten

Joó Ádám · 2013. Júl. 9. (K), 13.37
A HTML-ben semmilyen szinten nincs erre támogatás, miért az alt-ból hiányolod?
62

Nem hiányolom, csak rögtön

Thor · 2013. Júl. 9. (K), 19.51
Nem hiányolom, csak rögtön kérdésessé teszi a "alt" fontosságát, mert a keresők csak egy nyelven tudják "értelmezni" a fájlt. Viszont fentebb volt, hogy agitálják a fejlesztőket, hogy használják, mert ha nem az ciki.:)
64

Nem teszi kérdésessé, mert

Joó Ádám · 2013. Júl. 9. (K), 20.05
Nem teszi kérdésessé, mert rajtad kívül senki sem akarja ugyanazt a tartalmat minden nyelven egyszerre kiszolgálni. Mert semmi értelme.
69

:D

szabo.b.gabor · 2013. Júl. 10. (Sze), 08.28
:D
70

Látatlanban nem lehet

Hidvégi Gábor · 2013. Júl. 10. (Sze), 09.44
Látatlanban nem lehet megítélni, hogy minek van értelme és minek nincs.
72

De abban megegyezhetünk, hogy

bamegakapa · 2013. Júl. 10. (Sze), 10.16
De abban megegyezhetünk, hogy nem a csavarhúzó hibája, ha valaki nem tudja beverni vele a szöget?
73

Meg : )

Hidvégi Gábor · 2013. Júl. 10. (Sze), 10.29
Meg : )
39

Nem szép dolog, hogy

bamegakapa · 2013. Júl. 9. (K), 11.34
Nem szép dolog, hogy megzavartad az önfeledt fikázást :P.
61

Nem teljesen erre való

Szántai Károly · 2013. Júl. 9. (K), 14.25
Az alt és a <figcaption> más dologra szolgál. Utóbbi az ábra címe, ami nem feltétlenül az, ami az ábrán (képen, videón, stb.) látszik. Ha előveszek egy nyomtatott újságot, akkor ott is számtalanszor más a kép alatt megjelenő, szerkesztőségi képaláírás, mint amit maga a kép ábrázol. Az alt-nak az a feladata, hogy ha nem látszik a kép (mert nem jelenik meg, vagy mert a felhasználó eleve nem lát), akkor felhasználó hozzájusson a képen látható információhoz is. Ez sokszor leíróbb, mint a képaláírás.

Persze számtalan olyan szituáció lehet (százalékos arányt nem igazán mernék becsülni), amikor az alt és a figcaption szövege betűről betűre egyforma. Azon valóban van némi vita az akadálymentességgel foglalkozó guruk között, hogy ilyen esetben pótolhatja-e a figcaption az alt-ot.

És akkor még ott van a longdesc attribútum, amit éppen most akarnak visszatenni a HTML5-be. Illetve az aria-describedby attribútum, ami lehetővé teszi, hogy az oldalon lévő bármely szöveg összeköthető legyen a képpel.
63

Utána meg jönnek a google

Thor · 2013. Júl. 9. (K), 19.56
Utána meg jönnek a google robotok és azok fogják írni a kódot,
mert nem lesz ember aki meg tudná jegyezni az összes elemet és azok mindegyik attribútumát.:))
Szerintem mondjon le az internet.:)
53

ne csak akkor ha a

Joó Ádám · 2013. Júl. 9. (K), 13.32
ne csak akkor ha a felhasználó fölé viszi a cursor-t


Az alt akkor jelenik meg, ha a kép nem jeleníthető meg. Összekevered a title-lel.

Lehet kicsit tovább kellene képeznetek Magatokat mielőtt más fejlesztőknek ilyen nagyon kétséges dolgokat agitáltok.


Szerintem neked kellene az alapokkal tisztában lenned, mielőtt ekkora arccal előadod magad.
65

Igazad van..de, egyiknek

Thor · 2013. Júl. 9. (K), 20.09
Igazad van.. meleg van..
.. de, akkor sincs értelme az alt tagnak..:))
De szíve joga mindenkinek, mit használ..

Kösz, képzem is magam rendesen.. Kozel mesterrel.:)
66

Kis keveredés

Pepita · 2013. Júl. 10. (Sze), 03.38
Itt szerintem kicsit összekeverted az alt-ot a title-el. Az alt helyettesítő információra való, abban az esetben, ha a kép valamilyen oknál fogva nem jelenik meg. "Extrázni" a title jó, mint a neve is mutatja.
Szerk.: most látom, hogy kb. ugyanezt már Poetro is írta...
7

a kódkiegészítős

Joó Ádám · 2013. Júl. 8. (H), 23.15
a kódkiegészítős szövegszerkesztők korában pedig az nem érv, hogy többet kell gépelni


Én nem használok kódkiegészítést, mert eddig még minden megvalósítás, amivel találkoztam, elvérzett valahol.

Szerintem teljesen lényegtelen, milyen tag-be tesszük a tartalmat … A legfontosabb, hogy jelöljük meg a szerepet, hogy milyen módon, az már nem számít.


Ennek a hozzáállásnak az eredménye, hogy annyi felhasználói felület használhatatlan a weben. Mert ha úgy néz ki, mint egy link, gomb, legördülő lista, akkor mindegy, hogy mi van a forrásban, ugye? Az meg, hogy nem fog úgy viselkedni, ahogy elvárom, mert a kedves fejlesztő a felét elfelejtette implementálni, már más kérdés.

A böngészők nem foglalkoznak a tag-ekkel, hisz az ő feladatuk annyi, hogy megjelenítsék a tartalmat. Őket az érdekli, hogy mekkora, milyen színű az elem, semmi más.


Ez nem igaz, nagyon sok elemnhez viselkedés is tartozik, a címekből pedig van, amelyik tartalomjegyzéket készít, míg egy parancssori böngésző nem is látja például a CSS-t.

Ugyanígy vannak ezzel a keresők is, s bár az egyes elemtípusoknak van egy bizonyos minimális szorzója, a legkevésbé dönt ez arról, milyen helyen végez az oldalunk a sorban.


Gondolom ezért költ a Google ennyi emberórát arra, hogy a szemantikus jelölésről prédikáljon – mert lényegtelen.

A role attribútumos megoldás jóval rugalmasabb, mint az új tag-ek létrehozása.


Nagyon kíváncsi lennék rá, mitől.

Ráadásul ez az egész szabványosdi leragadt a múltban, hisz a web nem csak statikus dokumentumokból áll, nem csak <article>-k és képaláírások gyűjteménye, hanem dinamikus tartalom, tulajdonságokkal rendelkező objektumok hada (ha például veszel egy jegyet, az X együttes Y dátumkor lévő koncertjéről szól), összefüggésekkel, amik leírására új ARIA szerepek lennének szükségesek.


Két különböző dologról beszélsz. A HTML felhasználói felületeket ír le szemantikusan, és nem is akar mást leírni. Te a tartalom leírásáról beszélsz, amivel lehet foglalkozni, de számonkérni a HTML-en semmi értelme.
9

Én nem használok

Hidvégi Gábor · 2013. Júl. 9. (K), 06.55
Én nem használok kódkiegészítést, mert eddig még minden megvalósítás, amivel találkoztam, elvérzett valahol.
Az én szövegszerkesztőmben egy egész primitív megoldás van, de nagyon jól működik: rövidítéseket definiálok, például beírom, hogy "fori", nyomok egy szóközt, és beteszi, hogy for (var i = 0, l = .length; i < l; i++) { }, és a kurzor a .length elé ugrik.

Mert ha úgy néz ki, mint egy link, gomb, legördülő lista, akkor mindegy, hogy mi van a forrásban, ugye?
Itt arra gondoltam, hogy a <header> vagy a <div role="header"> megegyezik, az ilyen típusú elemeknek nincs viselkedése, mint egy linknek.

Ez nem igaz, nagyon sok elemnhez viselkedés is tartozik, a címekből pedig van, amelyik tartalomjegyzéket készít
Nem véletlenül nem soroltam fel viselkedéssel kapcsolatos elemeket, másrészt a <div role="heading" aria-level="1">-ekből is lehet tartalomjegyzéket készíteni.

Gondolom ezért költ a Google ennyi emberórát arra, hogy a szemantikus jelölésről prédikáljon – mert lényegtelen.
A Google másba is rengeteg pénzt és emberórát ölt, ha rákeresel arra, hogy az utóbbi évben hány nem működő projektet szűntettek meg, akkor láthatod, hogy nekik is vannak melléfogásaik.

»A role attribútumos megoldás jóval rugalmasabb, mint az új tag-ek létrehozása.«

Nagyon kíváncsi lennék rá, mitől.
Leírtam, azért rugalmasabb, mert ha kitalálnak egy új szerepet, akkor nem kell hozzá HTML tag, hanem role attribútumként adod meg.

Két különböző dologról beszélsz.
Ez igaz.
12

szerintem

szabo.b.gabor · 2013. Júl. 9. (K), 09.33
szerintem ebben a formában a div és a role felesleges, nem hordoz információt
<div role="header"></div>
<div role="main"></div>
<div role="aside"></div>
mindenképp előrelépés, ha helyette ezt használjuk
<header></header>
<main></main>
<aside></aside>
az hogy jelenlegi (vagy inkább régebbi) eszközökkel mindez hogyan viselkedik performancia terén, teljesen mindegy, ha megoldható, hogy menjen valamilyen szinten.

lehet, hogy zsákutca amerre ez az irány visz, de inkább lépjen rossz irányba a dolog, minthogy egy helyben topogva megerőszakolja önmagát.

igazából az élet úgyis eldönti, hogy melyik verzió életképes, de messzebbről nézve..

-végy egy darabot abból az alapanyagból, melynek típusa tojás.
avagy
-végy egy tojást..

ezen gondolom nincs vita.
15

(az elejére) Mi az indok? de

Hidvégi Gábor · 2013. Júl. 9. (K), 09.36
(az elejére)
Mi az indok?

de messzebbről nézve..

-végy egy darabot abból az alapanyagból, melynek típusa tojás.
avagy
-végy egy tojást..

ezen gondolom nincs vita
Tökéletesen mindegy, melyik formát használjuk.
28

nem :P

szabo.b.gabor · 2013. Júl. 9. (K), 11.03
Tökéletesen mindegy


egy gépnek igen, de amíg humanoidok is szerepelnek a történetben, addig nem
34

A sitebuilderekre gondolsz? A

Hidvégi Gábor · 2013. Júl. 9. (K), 11.14
A sitebuilderekre gondolsz? A kódot még nagy weboldalak esetében is egy-két ember tartja karban, a mai fejlett, Firebug-szintű eszközökkel egy elem megtalálása, és módosítása két pillanat.
44

Tapasztalataim szerint ezek

bamegakapa · 2013. Júl. 9. (K), 12.03
Tapasztalataim szerint ezek az új tagek lényegesen olvashatóbbá, áttekinthetőbbé teszik a kódot. A sokmillió div között könnyű elveszni, még a megfelelő behúzás és eszközök használatával is. Részemről nagy örömmel használom őket.
11

Kellene egy cikk, arról mire

Thor · 2013. Júl. 9. (K), 09.17
Kellene egy cikk, arról mire jó egyáltalán a HTML5.

Eltekintve pár valóban hasznos újítástól, semmi olyan nincs benne ami átütő
lenne, parasztvakítás szinte az egész, vagy 10 évet késett.

A cikk érdekes, elolvastam.. de szerintem a többség továbbra sem fog foglalkozni ezekkel a fícsörökkel, mert szimplán idiótaság, ugyanúgy mint a szemantikus web.

Egyébként a cikkben ott a lényeg is, nevezetesen hogy egy komoly, valós érvet/előnyt sem tudott igazán csatasorba állítani, miért is jók ezek a elemek, amiért érdemes egy már létező weboldalt sok-sok pénzért átalakítani.
17

Off

Hidvégi Gábor · 2013. Júl. 9. (K), 10.03
A modern böngészők miatt nem fejlődik a web.
ha a ballasztot kivesszük a HTML5-ből, kiderül, hogy az újítások nem nagyon elegek még egy HTML 4.02-s verziószámhoz sem
Egyetértek az általad leírtakkal, két dolog kivételével. Mi a bajod a szemantikus webbel? Másrészt lehet, hogy számodra idiótaság, de nem kerül semmibe megjelölni az elemek funkcióit (oldalanként pár darabról van szó), és máris pár százalék látogató könnyebben tud tájékozódni. Nem kerül semmibe.
20

Jó cikk, meg amire hivatkozik

Thor · 2013. Júl. 9. (K), 10.34
Jó cikk, meg amire hivatkozik is..:)
Szinte teljesen egyetértek a benne foglaltakkal.

Egyrészt mert idő és pénz, minél nagyobb egy oldal annál több, és gyakorlatilag nem kapnak érte semmit. Bocsánat a bukósságért, de kit érdekel, hogy akadálymentes legyen egy oldal a kormányzati és UE-s oldalakon kívül? Minden a százalékokon és a pénzen múlik.. ezeknek a "sikere" is (de 96 százalék, hogy halva születettek).

Másrészt szerintem egyre inkább dinamikus lesz a web, afelé megyünk el és nem a szemantikus web felé.
Maga a koncepció is nevetséges szerintem.. emlékszem ~10 éve a "meta" volt a varázsszó mindenre ráhúzták, most egyesek nagyon erőltetik a "szemantikus" szót, mivel jó üzlet.. valakinek.. mondjuk a legnagyobb, legsunyibb kémszervezetnek, a google-nak.

A látogatód soha nem fogja nézegetni az oldal forrását, max. ha fejlesztő, a browser-ek meg nem igazán támogatják.. majd esetleg egyszer. A sokadik probléma, hogy a felhasználók többsége egyszerű mint a faék, azt használja amit "kap", nem fog ezekkel szórakozni.
29

Rokkantnyugdíjas

Poetro · 2013. Júl. 9. (K), 11.05
Például Magyarországon a nyugdíjasok a népesség kb 30%-át teszik ki. Ennek 25%-a rokkantnyugdíjas (KSH - 2011). Namármost ezek egy része igenis igényli az akadálymentességet, még ha te nem is gondolsz rájuk. Jobb gazdasági helyzetben levő országokban is hasonló lehet a helyzet, és ott több a fizetőképes kereslet is. Ráadásul ezek az emberek méginkább rá vannak utalva az internet adta lehetőségekre, mivel rokkantak, ezáltal kevésbé mobilisak. Nem véletlen, hogy az USA-ban és az UK-ban annyi megnyert per van a különböző e-kereskedelmi oldalak ellen, amik nem támogatták az akadálymentességet.
36

Azt is tedd hozzá, hogy a

Thor · 2013. Júl. 9. (K), 11.20
Azt is tedd hozzá, hogy a magyar nyugdíjasok 80 százaléka, de lehet több nem is használ internetet.

Egyébként értelek.. de a magam részéről nem ölnék milliókat abba, hogy akadálymentesek legyenek az oldalaim.

Az USA meg külön állatfaj mindenki tudja.
38

lelked rajta

Poetro · 2013. Júl. 9. (K), 11.31
Ha te úgy gondolod, hogy rokonod, ismerősöd, potencionális partered, aki fogyatékkal él nem érdemli meg, hogy használhassa a weboldalad, hát lelked rajta. Én szeretném nekik is megadni a lehetőséget egy teljesebb élethez.
55

a magam részéről nem ölnék

Joó Ádám · 2013. Júl. 9. (K), 13.45
a magam részéről nem ölnék milliókat abba, hogy akadálymentesek legyenek az oldalaim


Mi kerül milliókba azon, hogy div helyett a megfelelő elemet használod, áruld már el.
79

Bocs, nem tudtam, hogy

Thor · 2013. Júl. 10. (Sze), 16.34
Bocs, nem tudtam, hogy éhbérért dolgoznak itt emberek.:)
81

?

Joó Ádám · 2013. Júl. 10. (Sze), 16.45
?
67

Kis statisztika...

Szántai Károly · 2013. Júl. 10. (Sze), 07.25
Az USA meg külön állatfaj mindenki tudja.

Ha esetleg nemzetközi honlapokon dolgozol, akkor csak úgy szólok, hogy pl. az USA-ban 6,6 millió(!) látássérült él. Ha nem használsz alt attribútumot, illetve az oldalad nem akadálymentes, akkor nagyságrendileg ekkora piaci szegmenst dobsz.
Statisztikai forrás

Az Egyesült Királyságban ugyanez az érték közel 2 millió. Előrejelzések szerint ez az érték folyamatosan emelkedik a népesség öregedése miatt.
Statisztikai forrás

a magyar nyugdíjasok 80 százaléka, de lehet több nem is használ internetet.

Az előrejelzések szerint 2050-re az EU lakosságának 70%-a (!) 65 évesnél idősebb lesz, az idős kor minden nyűgjével együtt. Ez az érték már most is nagyon magas, és folyamatosan növekszik. Te is, én is, és az összes itteni fórumozó, azaz a klasszikus internet generáció is eljut majd ebbe a korosztályba. Lehet, hogy Te nyugdíjasként nem fogsz majd internetezni, én azért szeretnék.
80

Megadom magam.. Csak annyit

Thor · 2013. Júl. 10. (Sze), 16.42
Megadom magam..

Csak annyit fűznék hozzá, hogy azt elfelejtetted leírni, hogy a teljes lakossághoz viszonyítva hány százalék a 6,6 millió.:)
Remélem sejted miért firtatom.
83

Számok

Hidvégi Gábor · 2013. Júl. 10. (Sze), 17.00
Thor: hidd el, tényleg nem sok meló annyi pluszt beletenni a kódba, hogy a felolvasóprogramok is értelmezzék. A 2%-ot értelmezd úgy, hogy egy kereskedelmi oldal esetében 2% plusz vásárló, azaz 2% plusz bevétel. Ez a mostani válságban nem elhanyagolható!

Károly: az általad idézett statisztikai adatok sajnos nem sokat mondanak, mert nem tudjuk, hogy ebből hányan használják az internetet (az össz számuk egyébként az USA lakosságának körülbelül 2%-a). Továbbá a nyugdíjasok magas számából sem következik semmi, nem biztos, hogy szükségük lesz felolvasóprogramot használni.

Ami viszont érdekelne, hogy mennyi a felolvasóprogramok valós használati aránya, mert bár próbáltam rákeresni, de valamit elrontottam, mert nem találtam semmi érdemlegeset.
85

nem biztos, hogy szükségük

Joó Ádám · 2013. Júl. 10. (Sze), 17.11
nem biztos, hogy szükségük lesz felolvasóprogramot használni


Nekem sincs rá szükségem, mégis jó lenne néha csak hátradőlni és hallgatni egy cikket, de ez úgy tűnik sci-fi marad.
92

Hát passz.. .. kíváncsi

Thor · 2013. Júl. 10. (Sze), 19.07
Hát passz..
.. kíváncsi lennék én is statisztikákra, hogy hány oldal is van megcsinálva úgy, hogy felolvasó program is megegye (és nem csak kereskedelmi), mert szép hogy arról vitatkozunk, hogy kell-e, nem kell-e, de alapvetően még az sem egyértelmű, hogy a weboldalak hány százaléka támogatja jelenleg a felolvasó programokat, meg egyáltalán a szemantikus html5-ös elemeket.

Csodálkoznék, ha 1 százalék felett volna ez a szám, mivel nyilván az adott területtől függ, hogy mennyire releváns az, hogy felolvasó programmal használják.
23

Eltekintve pár valóban

Poetro · 2013. Júl. 9. (K), 10.52
Eltekintve pár valóban hasznos újítástól, semmi olyan nincs benne ami átütő
lenne, parasztvakítás szinte az egész

Melyekre gondolsz, ami parasztvakítás? Nem lehet, hogy csak neked nem kellett még olyan weboldalt vagy alkalmazást építeni, amikben ezek a szinte egyedülálló módok a feladat megoldására?
  • Web Storage
  • WebSQL
  • Drag-and-drop
  • History API
  • Offline applications
  • Document editing
  • Web Messaging
  • Web Sockets
  • Web Workers
  • Canvas
  • Audio
  • Video

HTML5-höz kapcsolódó technológiák:
  • Geolocation
  • Indexed DB
  • Selectors API
  • File API
  • MathML
  • SVG
  • Web Open Fonts
  • Touch events
26

Ezek többségét már pár éve

Hidvégi Gábor · 2013. Júl. 9. (K), 10.59
Ezek többségét már pár éve tudta a(z akkor) 98% elterjedtségű Flash (azaz bő kétmilliárd embert nem érdekelt, hogy plugint kell letölteni), most meg törheted a fejed, ha a kedves felhasználónál nincs támogatva az adott featúra. Tehát ismét csak ott vagyunk, hogy évek mennek el valódi fejlesztés nélkül, hisz nagyjából mindegy, hogy egy flash vagy egy html api függvényeit használod.
30

azért..

szabo.b.gabor · 2013. Júl. 9. (K), 11.10
annyiban nem mindegy, hogy a flash egy zárt dolog és egy cég kezében van, ha az adott cég azt mondja, hogy egy bizonyos platformra nem fejlesztem le ezt a dolgot, akkor onnantól kezdve arra a platformra nem lesz, ha az a cég azt mondja, hogy mostantól 5 ft-ért használhatod ezeket a lehetőségeket, akkor ha nincs pénzed ki vagy zárva, stb..

ehhez képest, hogy vannak nyílt szabványok és lehet őket implementálni, azért elég nagy előrelépés.
31

Flash

Poetro · 2013. Júl. 9. (K), 11.11
Ne akarjunk már visszamenni olyan technológiákhoz, amik egyetlen cég kezében vannak, és senki nem tudott használható futtatókörnyezetet írni hozzá az Adobe-on (Macromedia-n) kívül. Ezeknek nyílt szabványoknak kell lennie legalább 2-3 konkurens motorral, amik lefedik a követelmények 90+%-át. Enélkül azóta is mindenhol csak Flash oldalakat látnánk, amik teljesen használhatatlanok, kereső motorok által nehezen feldolgozhatók, nem hordoznak semmilyen szemantikát, és akadálymentességben is csapnivalók.
35

Az Opera kiesésével van három

Hidvégi Gábor · 2013. Júl. 9. (K), 11.19
Az Opera kiesésével van három motor, a webkit, a firefoxé meg az internet exploreré, a flash-hez képest ez legalább háromszoros hibázási lehetőség. A zártsággal kapcsolatban igazatok van Szabó B. Gáborral.

Enélkül azóta is mindenhol csak Flash oldalakat látnánk, amik teljesen használhatatlanok, kereső motorok által nehezen feldolgozhatók
Ne keverjük a teljesen flash-es oldalakat a flash api hívásokkal, ha szeretnél socketen keresztül kommunikálni vagy egy fájlt feltölteni, elég egy apró objektumot betenni.
37

Nem így működik

Poetro · 2013. Júl. 9. (K), 11.28
Ne keverjük a teljesen flash-es oldalakat a flash api hívásokkal, ha szeretnél socketen keresztül kommunikálni vagy egy fájlt feltölteni, elég egy apró objektumot betenni.

Azt te is tudod, hogy nem így működik. Ha fel kell venni egy Flash fejlesztőt valaminek a lefejlesztésére, abból az szokott lenni, hogy egyből sokkal több mindent Flash-en keresztül akarnak majd megvalósítani. Én is fejlesztettem Flash alkalmazásokat 6-8 évig úgyhogy tudom. Ha a megrendelő meglát valami csillivillit, akkor neki az fog kelleni. Legyenek azok fontok, Flash Shared Objects, audió, videó, canvas, fájl feltöltés, dinamikus képek, adatok stb. Ezek után nehéz kiszállni, mert túl sok a lefejlesztett technológia, amit nem szeretnének újra lefejleszteni más nyelven, környezetben.
58

Meg a blink.

hunkris · 2013. Júl. 9. (K), 14.01
Meg a blink.
41

Ez sok így egyszerre..:)Az

Thor · 2013. Júl. 9. (K), 11.44
Ez sok így egyszerre..:)

Az első kupacból a Canvas, Audio, Video a valóban tisztán WEB-es új tartalom, a többi szinte mind csak "szabványosítás" a W3C égisze alatt, több már előtte is létezett (nem flash!), és bár lehet keverni a HTML-t a Javascript-el, szerintem nem szerencsés, mint ahogy Te is írod ezek inkább a "HTML5-höz kapcsolódó technológiák" (az SVG Fonts, Touch kivételével persze).

Ja, hogy tedd hozzá: ez 10 év gyümölcse.. szerinted nem nevetséges?

Ugyanaz a helyzet a webkamerával és a mikrofonnal.

Egyébként
.. a File api-t sajnos nagyon is kellett használnom.. egy kalap sz*r, ha nem teszel hozzá X javascript függvényt ami a hiányosságait kompenzálja (fájlok száma, mérete pl.),
.. de a többi közül is kellett párral már foglalkoznom.. és szintén kicsit "hiányosak", de nyilván XX év és kész lesz.
47

szabványosítás

Poetro · 2013. Júl. 9. (K), 12.23
szinte mind csak "szabványosítás" a W3C égisze alatt

De pont ennek kellene örülni, hogy végre szabványosítva van, és tudod, hogy mit várj egy böngészőtől, ami támogatja a szabványokat.
Ja, hogy tedd hozzá: ez 10 év gyümölcse.. szerinted nem nevetséges?

Nevetségesnek nem nevezném, inkább annak örülök, hogy végre van változás, és elkezdték a különböző böngésző és más tartalomfejlesztők szabványosítani a megoldásaikat, hogy ezáltal szélesebb körben elterjedhessenek, ne csak egy bizonyos szűkebb körben lehessen őket használni (például csak Safari-ban, Gecko-ban vagy Trident alatt). A korábbi eltávolodása a böngészőknek végre közeledéssé vált, és a legújabb implementációk már igen közel állnak egymáshoz, már csak a sebesség, használhatóság, kényelmesség és a támogatott platformok a különbségek.

Gondolj csak vissza A Netscape 4 / Internet Explorer 4 vagy az IE5-6-os időkre. Ahhoz képes egy igencsak nagy előrelépés történt abban az utóbbi 10 évben.
50

Örülök én is. Ennek ellenére

Thor · 2013. Júl. 9. (K), 12.57
Örülök én is.
Ennek ellenére még mindig az a véleményem, hogy vakítás.:)
Tény persze.. elnézést, hogy nekem a HTML5 csak html "leíróra" korlátozódik
és szerintem nem keverendő.. de ha keverjük, akkor nem vakítás, főleg CSS3-al.
52

A felsorolt API-k nem részei

Hidvégi Gábor · 2013. Júl. 9. (K), 13.00
A felsorolt API-k nem részei a HTML 5 leírónyelv definíciójának.
56

Melyek?

Poetro · 2013. Júl. 9. (K), 13.53
A History, Offline applications, Drag-and-drop, Document editing, valamint Web Storage, Web Sockets, Web Workers, Web Messaging, Web SQL részei a HTML5 specifikációnak, utóbbi 5 külön modulba lett kiszervezve.
57

Akkor valamit félreértettem.

Hidvégi Gábor · 2013. Júl. 9. (K), 13.58
Akkor valamit félreértettem.
51

Szabványosítás

Hidvégi Gábor · 2013. Júl. 9. (K), 12.58
Ne feledd el megemlíteni, hogy mind az <audio>, mind pedig a <video> elemek által lejátszott tartalmak formátumában még nincs megegyezés a böngészőgyártók közt, így szolgáltatóként kénytelen vagy legalább három formátumban legyártani ugyanazt a folyamot, ha a lehető legtöbb klienst támogatni szeretnéd. Ugyanez igaz a különböző API-kra, tehát pontosan ugyanott vagyunk, mint tíz éve, csak a szereplők köre bővült, és a munkánk mennyisége nőtt.
59

Addig is

Poetro · 2013. Júl. 9. (K), 14.02
Addig is több formátumban le kellett a videókat generálni, elvégre a Flash 6 nem tudta lejátszani a Flash 8-as videókat, ami pedig nem tudta lejátszani a Flash 9-est, ami pedig a Flash 11-est. Szóval, ha neked régebbi Flash plugined volt, akkor nem jutottál hozzá a tartalomhoz.

Az, hogy bővült a szereplők köre igencsak üdvözítő, mert a hatalom nem egy kézben van, ezért nagyobbak a lehetőségek, és a változatosság. A munkánk eddig is sok volt, teljesen mindegy milyen platformot nézel. A platformok között mindig is voltak különbségek, ha támogatni akartad őket, akkor többet kellett dolgozni. 10 éve is voltak mobiltelefonok és más kézi számítógépek, amiken lehetett böngészni, csak kevesebben voltak, ezért kisebb támogatást kaptak a webfejlesztő társadalomtól.
68

Ária

Hidvégi Gábor · 2013. Júl. 10. (Sze), 07.34
A részemről lezárom a témát, továbbra is egyetértek az első hozzászólásomban leírtakkal, nem sikerült meggyőznötök. Most pedig a célközönséghez szólok.

Tisztelt sitebuilder kollegák és fogyatékkal élők!

Szeretném összefoglalni az internet fejlődését az utóbbi tizenöt évben, ami mindannyiótokat érint.

Sikeresen abszolváltuk a HTML-be az ARIA szerepek töredékét! Igaz, hogy már korábban megvolt a role attribútumunk, amivel pontosan ugyanezt lehetett megcsinálni, és ha rendes munkát szeretnénk kiadni a kezünkből, továbbra is a segítségére vagyunk szorulva, de ilyen kicsinységekkel nem foglalkozunk. De legalább most már két eszközünk is van ugyanannak a feladatnak az elvégzéséhez.

Az új, szemantikusnak nevezett tag-ekkel olvashatóbbá vált a kód, a HTML munkások fellélegezhetnek! Igaz, hogy olyan lényegtelen dolgokkal nem foglalkoztunk, mint például a sablonozás, azaz dokumentumaink továbbra is ugyanolyan statikusak, mint egy kőszobor, ezzel plusz munkát róva a fejlesztőkre, a webszerverekre, a hálózatra és a böngészőkre, mert hát adataink folyamatosan változnak, bővülnek. Ez semmiség! A lényeg, hogy az a pármillió sitebuilder tudjon a kódban kézzel görgetve, ránézésre is megtalálni dolgokat, ne kényszerüljenek a szerkesztőjük beépített keresőjének használatára vagy egy jó nevezéktanra.

Szerencsére nem jutott idő az elmúlt tizenöt évben olyan bagatell dolgokra, mint a dokumentumainkban lévő adatok jelentéssel való felruházása, így keresőink, mint a google meg a bing és társaik, nem kényszerülnek fölösleges fejlesztésre. Mit érdekelnek minket az összefüggések, elég nekünk, ha karakterláncokra tudunk keresni!

Sikeresen szabványosítottunk! Igaz, hogy a szabványokat most minden böngésző máshogy értelmezi, és ugyanannyi munkánk van a különböző platformok támogatásával, mint azelőtt, de ilyen kicsinységekkel továbbra sem foglalkozunk. A szabványok mindenek felett! Igaz, hogy felnőtt közben egy új generáció, de legalább elmondhatjuk, hogy anno mi is meg tudtunk csinálni mindent, csak akkor még Trabantnak hívták, ma pedig Mercédesznek!

Tisztelt sitebuilder kollegák és fogyatékkal élők!

Érezzétek megtisztelve magatokat, hogy ebben a csodálatos tizenöt évben mindenki ennyire a ti kényelmetekkel foglalkozott, a maradék csekély két és fél milliárd internetezővel nem kell törődni. Komolyan, kit érdekel, hogy nekik mi az érdekük?
71

Gondolkodtál már politikusi

bamegakapa · 2013. Júl. 10. (Sze), 10.04
Gondolkodtál már politikusi pályán? :P
74

Csatlakozom.. .. nem

Thor · 2013. Júl. 10. (Sze), 11.29
Csatlakozom..
.. nem sörözéseket kellene szervezned, hanem inkább pártot alakítani.:)
75

Az minimum elgondolkodtató,

Max Logan · 2013. Júl. 10. (Sze), 13.18
Az minimum elgondolkodtató, hogy aki tovább lát az orránál, érvel, nem tőmondatokban fejti ki gondolatait, milyen szinten kilóg és kvázi kivülállóként kezelt tagja modern társadalmunknak...

Értem, hogy itt poénra vettétek az egy-egy hozzászólásotokat, de sajnos ez a jelenség társadalmi szinten jelen van.

(Egyik legjobb példa, hogy rendszeresen boncsánattot kérnek emberek, ha 10 többszörösen összetett mondatot írnak le egy kommentben, fórum hozzásólásban. A hétköznapokban számtalanszor megkapom pl. én is, hogy fárasztó vagyok, túlgondolkodom a dolgok, ne legyek már olyan okoska, stb. Pedig dehogy, ez lenne a normális, nem az a felszínesség, ami jelen van mindenhol...)
76

A felszínesség és az okoska a

bamegakapa · 2013. Júl. 10. (Sze), 14.07
A felszínesség és az okoska a skála két széle. Az arany középút valahol a kettő között lenne. Különben meg ki lehet fejteni tőmondatokban úgy a gondolataidat, hogy abban minden benne legyen, de ez csak a legnagyobbaknak megy, és akkor se biztos, hogy mindenki megérti :).

Az említett beszéd lánglelkű kollégánktól egyébként megindító volt, nem is lehetett rá nagyon érdemben reagálni :).
77

Erre kövessetek

Hidvégi Gábor · 2013. Júl. 10. (Sze), 14.58
78

Ez egy fórum vala (topic)

Thor · 2013. Júl. 10. (Sze), 16.29
Ez egy fórum vala (topic) tudtommal és Gábor hozzászólására nem lehet másképp reagálni, mert önmagában megérne egy misét vagy többet (topic-ot) a hozzászólása (nem nekem, mert én egyetértek vele).
Azonkívül túlmutat a eredeti nyitó témán, mert ha jól értettem, szimplán atomot dobna a w3c nevű szervezetre (én is), de sajnos vannak a földön védett állati fajok, így ez nem lehetséges.

A cikk szerintem eléggé ki lett vesézve, és számomra csak az jött le, hogy nagyon nagy a szórás fejlesztő és fejlesztő között (pl: ki mit tart fontosnak) és hogy nincs abszolút igazság.. főleg ilyen kánikulában.:)
84

Valóban, a mondanivalóm az,

Hidvégi Gábor · 2013. Júl. 10. (Sze), 17.06
Valóban, a mondanivalóm az, hogy nem értek egyet a fő csapásiránnyal. A w3c meg szerintem előbb-utóbb lehúzhatja a rolót, erőtlen társaság. A WHATWG szépen átvette a kezdeményezést, aztán kicsit késve jöttek rá, hogy nagy baj lesz ebből, ha bármely jöttment helyettük alakítja a szabványokat. Leveleztem egy belsőssel, elmondta, hogy a w3c szabványügyesei rég eladták a testüket, és mindenképp amellett fognak érvelni, ami a megbízó/fizető cégük érdeke.
86

Leveleztem egy belsőssel,

Joó Ádám · 2013. Júl. 10. (Sze), 17.20
Leveleztem egy belsőssel, elmondta, hogy a w3c szabványügyesei rég eladták a testüket, és mindenképp amellett fognak érvelni, ami a megbízó/fizető cégük érdeke.


És mi ebben a meglepő? Egy konzorcium az érdekelt felek egyeztető testülete, nem szeretetszolgálat.

Mint aki idestova öt éve aktívan részt vesz az ISO és a Magyar Szabványügyi Testület munkájában, bátran mondhatom, hogy ez mindenhol így működik. Politikai és üzleti érdekek mentén történő kompromisszumkeresésről szól minden szabványosítási folyamat.
87

Nincs ebben meglepő, csak itt

Hidvégi Gábor · 2013. Júl. 10. (Sze), 17.45
Nincs ebben meglepő, csak itt pár cég diktál az egész világnak, mert az érdekelt felekbe ez utóbbi csoport is beletartozik. A politikusokat pedig helyből rühellem, mert szinte kivétel nélkül csak a saját rövidtávú igényeik alapján döntenek, hisz csak a következő megválasztásukig látnak előre. Ráadásul elég hamar bebizonyítják, hogy nem értenek semmihez, mert életükben egy percet sem dolgoztak.

Naívan úgy gondolom, hogy ha hosszútávon lennének képesek dolgozni a közösség érdekében, sokkal jobban járna mindenki, hisz ők is többet kapnának vissza.

Az pedig az én egyéni meglátásom, hogy a HTML 5-öt meg ezt az egész szabványosítási folymatot jórészt a Microsoft lejáratására hozták létre.
88

Nincs ebben meglepő, csak itt

Joó Ádám · 2013. Júl. 10. (Sze), 17.53
Nincs ebben meglepő, csak itt pár cég diktál az egész világnak, mert az érdekelt felekbe ez utóbbi csoport is beletartozik.


Miért nem lép akkor be a világ a W3C-be?

A politikusokat pedig helyből rühellem, mert szinte kivétel nélkül csak a saját rövidtávú igényeik alapján döntenek, hisz csak a következő megválasztásukig látnak előre.


Erre kényszeríti őket a képviseleti demokráciának nevezett politikai rendszer.

Naívan úgy gondolom, hogy ha hosszútávon lennének képesek dolgozni a közösség érdekében, sokkal jobban járna mindenki, hisz ők is többet kapnának vissza.


Ameddig egy szakmai fórumon egy-egy technológiai megoldás mellett az az érv, hogy ezért fizet a megrendelő, azért pedig nem, miért várjuk, hogy a politikus a közösség hosszútávú érdekeit vegye figyelembe a saját rövidtávú érdeke helyett? Ő is csak ember.

Az pedig az én egyéni meglátásom, hogy a HTML 5-öt meg ezt az egész szabványosítási folymatot jórészt a Microsoft lejáratására hozták létre.


Bővebben?
94

Szabványok

Hidvégi Gábor · 2013. Júl. 10. (Sze), 19.17
Egy olyan szervezetbe lépjek be, amiről úgy gondolom, hogy záros határidőn belül meg fog szűnni, vagy legalábbis elveszti a hatalmát? Oda, ahol az igazgató Tim Berners-Lee sem tud elérni semmit (pedig ő a szemantikus web híve)? Oda, ahol a bennlévő nagy cégek képviselői politikusi rutinjukkal lemosnak két pillanat alatt? Nem lenne sok értelme, más terveim vannak.

A HTML 5-ben és társaiban egy csomó mindent úgy "szabványosítottak", hogy a Microsoftnak már volt rá kész, működő megoldása, amit sok helyen használtak. Az egyik példa erre az addEventListener - attachEvent függvénypáros, vagy az általam kritizált új tag-ek bevezetése, amelyek pont az IE-kben okoztak problémát, de gyakorlati hasznuk nincs (a kicsit jobban olvasható, "szemantikus" kód nem hozott minőségi változást a weben, cserében pár éve, amikor még többen használtak régebbi explorereket, script nélkül nem jól jelentek meg az ilyen oldalak).
95

Egy olyan szervezetbe lépjek

Joó Ádám · 2013. Júl. 10. (Sze), 19.26
Egy olyan szervezetbe lépjek be, amiről úgy gondolom, hogy záros határidőn belül meg fog szűnni, vagy legalábbis elveszti a hatalmát? Oda, ahol az igazgató Tim Berners-Lee sem tud elérni semmit (pedig ő a szemantikus web híve)? Oda, ahol a bennlévő nagy cégek képviselői politikusi rutinjukkal lemosnak két pillanat alatt? Nem lenne sok értelme, más terveim vannak.


Ne te, a világ! (Arra akartalak rávezetni, hogy nincs olyan, hogy „az egész világ”. Aki valóban részt vesz a folyamatban, annak konkrét érdekei fogalmazódnak meg a döntései nyomán, amik óhatatlanul szemben fognak állni mások érdekeivel. Ez van most is, és sosem fog másképp működni.)

az általam kritizált új tag-ek bevezetése, amelyek pont az IE-kben okoztak problémát, de gyakorlati hasznuk nincs (a kicsit jobban olvasható, "szemantikus" kód nem hozott minőségi változást a weben, cserében pár éve, amikor még többen használtak régebbi explorereket, script nélkül nem jól jelentek meg az ilyen oldalak)


Most ne menjünk bele abba, hogy a Microsoftnak miért kell mindig külön utakon járnia, aminek eredményeképp csak az ő böngészőjében nem jelentek meg jól az ismeretlen elemek szkriptelés nélkül.

De te most tulajdonképpen azt mondod, hogy csak azért, mert van egy cég, amelyik egy évtizedig nem nyúl hozzá a böngészőjéhez, ezért ne adjunk hozzá olyan új elemeket a szabványhoz, amelyeknek egy szabványos böngészőben akkor is gond nélkül meg kell jelennie, ha nem ismeri azokat?

A verseny már csak ilyen, aki nem lép, az lemarad. Én nem sajnálom ezért a Microsoftot.
96

ezért ne adjunk hozzá olyan

Hidvégi Gábor · 2013. Júl. 10. (Sze), 21.19
ezért ne adjunk hozzá olyan új elemeket a szabványhoz

Dehogy ezt mondom, hanem azt, hogy ne találjuk már fel újra és újra a kereket, mert csak az időt vesztegetjük, hanem koncentráljunk a lényegre. Ha van egy működő attachEvent függvényünk, akkor nincs szükség az addEventListener bevezetésére. És ne érts félre! Nem a Microsoftot védem, hanem magunkat, a felhasználókat!
97

Nem tudom, hogy miért

Joó Ádám · 2013. Júl. 10. (Sze), 22.29
Nem tudom, hogy miért döntöttek egy más név mellett, valószínűleg valamiféle konzisztenciára való törekvés állhat a háttérben (amellett, hogy az addEventListener() egy elég sztenderd név sok nyelv sok könyvtárában, az attachEvent() egyszerűen rossz: nem eseményt adsz vele ugyanis hozzá, hanem eseménykezelőt). Ezek egyébként tipikusan olyan dolgok, amik szerintem – legyen szó a Microsoftról vagy bármelyik másik szereplőről – védhetetlenek. Mégis milyen akadálya van egy alias létrehozásának a motorban?
98

Szükség van rá, mert ..

Thor · 2013. Júl. 10. (Sze), 23.10
Szükség van rá, mert
.. sokkal dallamosabb ha kimondod.:-)
.. az illető verhető a mellét, hogy na ezt én csináltam..
.. miből élnének meg a keretrendszerek fejlesztői, ha végre csinálnának egy normális
új HTML/CSS/Javascript rendszert.:)

Egyébként amit írsz, az manapság tendencia más nyelveken is.

A múlt héten k anyáztam például, mert egy idióta kitalálta, hogy java-ban a Properties.save függvény milyen ódivatú.. legyen deprecated.. legyen helyette store.. nyilván ő is a lovaggá ütésre pályázik, remélem éles lesz a penge.:)

De ott van, hogy a webnél maradjunk, a híg trágya fos jquery, aminek sok függvényét életveszély közvetlenül használni, mert az egész egy ámokfutás, időnként valamelyik fejlesztőnek elgurul a gyógyszere és "újít".. ilyen a koncepció nélküli "új" ajax "modul", ami kész agyrém.
99

Most már viszont az

bamegakapa · 2013. Júl. 11. (Cs), 00.28
Most már viszont az addEventListener működik az IE-ben is, ha ők túlléptek rajta, talán nekünk is sikerülni fog.
101

Szalmabáb

Hidvégi Gábor · 2013. Júl. 12. (P), 10.08
https://yourlogicalfallacyis.com/pdf/LogicalFallaciesInfographic_A3.pdf
82

A hétköznapokban

Joó Ádám · 2013. Júl. 10. (Sze), 16.55
A hétköznapokban számtalanszor megkapom pl. én is, hogy fárasztó vagyok, túlgondolkodom a dolgok, ne legyek már olyan okoska


Ne hidd azt, hogy csak te élted ezt meg. De az életképes ember egy idő után tanul a tapasztalataiból, és rájön, hogy teljesen felesleges beszélni, mert semmit sem szabad várni az emberektől. Ha akarsz valamit, csináld meg, te, egymagad.

Listen, smile, agree, and then do whatever the fuck you were gonna do anyway.

– Robert Downey, Jr.
89

Pesszimista

Pepita · 2013. Júl. 10. (Sze), 18.33
Ádám, te tényleg ilyen pesszimista vagy, vagy csak ma van rossz napod? Nem mondom, hogy nincs igazad, de a "semmit se" azért erős túlzás - szerintem.
90

Egy idő után ez a vége, ha az

Joó Ádám · 2013. Júl. 10. (Sze), 18.43
Egy idő után ez a vége, ha az idealizmus objektivitással párosul :) Végső soron én realizmusnak nevezném. Ha tartod magad hozzá, amit írtam, akkor nem érnek csalódások.
91

De igazi örömök sem :(

Pepita · 2013. Júl. 10. (Sze), 18.55
Ha tartod magad hozzá, amit írtam, akkor nem érnek csalódások.

Na mentem, nehogy most ezt kezdjem vitatni... (Tőlem törölheted is.)
93

De igazi örömök sem :( Fair

Joó Ádám · 2013. Júl. 10. (Sze), 19.16
De igazi örömök sem :(


Fair trade :)
100

100! jee!

szabo.b.gabor · 2013. Júl. 11. (Cs), 15.44
nem faktoriális, csak felkiáltójel..

én úgy gondolom, hogy ez nem pesszimizmus, csak egy követendő viselkedésmód, olyan szempontból, hogy sokan tervezgetnek meg beszélnek róla, de soha nem lesz belőle semmi, ha valamit csinálni akarsz, akkor kezdd el és úgyis megtalálnak azok az emberek akik szintén csinálni akarnak valamit (vagy ha nagy baromságot csinálsz, akkor nem :D)