HTML5 hurdles: what is missing and web browser update rate problems
A valódi probléma a HTML5 mögött
■ 
Friss blogmarkok
- Web Akadálymentesítési Útmutató (WCAG) 2.1 – nyilvános munkaterv – Megjelent a WCAG (Web Akadálymentesítési Útmutató) 2.1 nyilvános munkaterv (0)
- MongoDB Apocalypse Is Here as Ransom Attacks Hit 10,000 Servers – Több tízezer védtelen MongoDB szerverre csaptak le hackerek (2)
- 12 Signs You’re Working in a Feature Factory – A cél nélküli funkciógyártás néhány tünete (0)
- Translatable, custom dates in Twig templates of Drupal 8 – Saját dátumok megjelenítése, fordíthatóan a Drupal 8 smink rétegével dolgozva (0)
- NativeScript – Cross-Platform Native Development with Javascript – Fejlesszünk natív mobilalkalmazást JavaScripttel (0)
- GitHub Security Update: Reused password attack – Érdemes bekapcsolni a kétfaktoros azonosítást, ha a GitHub jelszavunkat más oldalakon is újra felhasználtuk (17)
- UX Design könyv – Hogyan tervezz felhasználóbarát és szerethető alkalmazásokat? (0)
- Introducing unlimited private repositories – Megváltozik a GitHub díjszabása: minden előfizetéshez korlátlan számú privát repository jár (0)
- Drupal 8 Twig: add custom CSS classes to menus (based on menu name) – Saját elképzeléseink szerinti CSS osztályok (automatizált) hozzáadása a Drupal 8 menüihez (0)
Cikkajánló
Bártházi András:
CSS alapjai VII.
Bártházi András:
Perl alapjai II. - Fejlesztői környezet, alapok
sunz:
PHP, valamennyire biztonságosabban
Friss csiripek
Csiripek betöltése…
Aktív fórum témák
Új fórum témák
Archívum
| H | K | Sze | Cs | P | Szo | V |
|---|---|---|---|---|---|---|
| 28 | 29 | 30 | 31 | 1 | 2 | 3 |
| 4 | 5 | 6 | 7 | 8 | 9 | 10 |
| 11 | 12 | 13 | 14 | 15 | 16 | 17 |
| 18 | 19 | 20 | 21 | 22 | 23 | 24 |
| 25 | 26 | 27 | 28 | 29 | 30 | 1 |
A lényeg:A common consensus
Továbbá:
Nemrég olvastam, hogy a Firefox is hasonlóan gyorsan fog verziót váltani ezentúl, nem értem, miért kellett a Mozillának belemennie egy ilyen értelmetlen versenybe, pont amiatt, mert a nem szakembereknek fogalma sincs a verziókról meg a különbségekről.
A héten volt egy blogmark, Designing for the future web, amiben a szerző azt indítványozza, hogy mindenki használja a HTML5-öt, legyen az a közös platform mindenhol. Alátámasztásul azt hozza fel, hogy a mobiltelefonokon és tableteken a kezdetektől a két legelterjedtebb böngésző az Opera és a Chrome.
Ezzel csak az a gond, hogy igazából csak az Opera támogatta eddig a HTML5-öt a leginkább, a Chrome 10 biztosan nem ismer legalább egy lehetőséget (az <input> elem list attribútumát). Erre véletlenül találtam, és ki tudja, hány téren van még elmaradása a szabványtervezettől.
A PC-k terén még nagyobb a szórás a verziók között, és sok esetben nem is lehet a felhasználót hibáztatni, hogy nem frissít, lehet, hogy minden ilyen lehetőség le van tiltva vállalati érdekek miatt.
Tehát manapság senkinek sem tanácsolnám a HTML 5-re való áttérést, de azt különösen nem, hogy olyan új elemekre építsék az oldalukat vagy alkalmazásukat, ami HTML 5 specifikus. A HTML 4.01 tökéletesen megfelel a legtöbb mai feladatra, és teljesen mindegy, hogy egy elemet <header>-nek, vagy <div id="header">-nek hívunk.
Még egy fontos dolog: kettővel ez alatt van egy blogmark, amiben leírják, hogy változik a Chrome User Agent stringje. Egyre inkább terjed a divat, aminek legalább van alapja, hogy ne böngészőspecifikus kódot írjunk, hanem nézzük meg, hogy mit tud a szoftver (feature detection). Emiatt ezt a blogmarkot senkinek sem ajánlom elolvasásra, mert teljesen fölösleges.
Ja, és senki se használjon Chrome-ot, mert már az első verziónál kiderült, hogy a felhasználó beleegyezése nélkül küldi az információkat a különböző szokásainkról a Google-nak. Szerencsére voltak annyira hülyék, hogy nyílt forrásúvá tették, ezért egy német cég, az SRWare fogta, és kigyomlálta belőle ezeket a dolgokat (minden mást érintetlenül hagynak), és teszi mindezt a mai napig; pár nap késéssel lehet tőlük letölteni a legújabb, Chrome-ra alapuló böngészőt.
SRWare Iron
Off
Mégoffabb
(A "teljesen mindegy, hogy egy elemet <header>-nek, vagy <div id="header">-nek hívunk" felfogással végképp nincs mit kezdeni.)
class
article-nek is lehetheaderésfootereleme, valamint létezhet egy globálisheaderérdemes lehet a továbbiheaderésfooterelemeket<div class="header">illetve<div class="footer">-rel megkülönböztetni. Ezen kívül dívik most az a nézet is hogy:A "teljesen mindegy, hogy egy
Mivel nem különösebben fejted ki ezt, ezért nem igazán értem, mi is a bajod vele.
A HTML 5-ben bevezettek egy csomó új elemet, én kiemeltem egyet a sok - általam teljességgel feleslegesnek ítélt - közül, íme, az érveim:
A világon hárman találkoznak az általad készített kóddal: te, a kereső, valamint az oldalad látogatójának böngészője. Ki mit nyer az új elemekkel?
Te: nevezheted <article>-nek vagy <div>-nek, ez utóbbi esetben adsz neki egy id-t vagy classt, lényegtelen. A kódod struktúrálására eddig is volt lehetőség, ez csak és kizárólag rajtad múlt.
A kereső: a keresőket jelen pillanatban a HTML elemeken belüli szövegek érdeklik, részükről teljesen mindegy, hogy <div>-nek vagy <article>-nek hívod a kódban. Mivel az új elemeket (és a régieknek sem) nem lehet metaadatokkal ellátni, ezért semmilyen plusz információt nem hordoznak a keresők számára.
A böngésző: jelenleg - tudomásom szerint - semmilyen módon nem használják ki a böngészők az új elemek túlnyomó többségét, csak két dolog érdekli őket: blokk elem vagy sem az illető. Nekik egy dolguk van csak, kirajzolni, semmi más. A látogató számára továbbra is marad a CTRL+F, annak meg mindegy, miben van a szöveg.
Egy speciális csoport van még, a fogyatékkal élők különleges böngészői, de azok számára már eddig is volt ajánlás (ARIA), a HTML 5 új elemei nem segítenek.
Tehát - meglátásom szerint - senki nem nyer vele. Akkor mi az értelme?
Egy fő kérdés van, amit fel kell tennünk: alapvetően mire használjuk az internetet? A válasz: információátádásra.
Következő kérdések: segítik-e a HTML 5 új elemei az információ átadását? Ha bármit keresek ezentúl, könnyebben fogom-e megtalálni? A keresők pontosabb találatot fognak-e adni, ha oldalaimban <article>, <header> és társait használok <div>-ek helyett?
Hívhatom a Trabantot ezután Mercédesznek, ugyanolyan lassan fog menni, és ugyanazok lesznek a problémái, mint eddig. A HTML 5 új elemeinek nagy többségével az a gond, hogy pont az információátadás hatékonyságát nem növeli, hanem ugyanolyan szinten marad, mint korábban. Akkor minek használjuk, ha nem nyerünk vele semmit?
Egyre komolyabb igény van az internet alapú applikációk futtatására, egy-két új scriptobjektumon kívül nem kapunk semmit. Ott van példának az ExtJS/Sencha, egy tipikus applikáció olyan elemekből épül fel, ami ebben megtalálható, erre semmilyen támogatás nincs a HTML-ben.
A HTML 5 egy rossz kérdésre adott rossz válasz. De a kérdés megértéséhez előbb egy lépéssel hátrébb kell menni, és nagyobb távlatból rátekinteni a problémára. Csak az időnket vesztegetjük, az meg, ugye, korlátos.
Jövő
inputelemek), ami egyébként csak nagyon összetett eszközökkel lenne lehetséges. Valamint ezek az elemek könnyebbé teszik a HTML tartalom átkonvertálását más formátumra, mint például könyvek, magazinok, tartalomjegyzékek stb.Az, hogy egyes szoftverek még nem használják, vagy nem használják ki a HTML5 nyújtotta előnyöket teljesen mellékes, majd amikor felkészítik rá őket, valamint a tartalom is ebben a formátumban lesz, akkor majd élvezhetjük ennek a gyümölcsét. Ennek legjobb mozgatórugói a keresőmotorok lesznek, akik majd tudnak kivonatot készíteni a tartalomból, és ennek megfelelően indexelnek, az szabványt nem követők pedig hátrább kerülnek majd a találatok között.
Persze más eszközök is lehetnek, amit például a böngészőgyártók tudnak majd szorgalmazni, például automatikus tartalomjegyzéket, illetve navigáció segítő elemeket nyújtanak például context menüben, illetve a tartalom fülé lebegtetett widgetek révén. Ezeket már most meg lehet írni böngésző kiegészítő formájában, és szerintem nem tévedek nagyot, ha azt mondom, hogy már folyamatban vannak ilyen fejlesztések.
Természetesen vannak hasznos
Ezek az elemek (section, nav, article, aside, hgroup, header, footer) csak és kizárólag a HTML dokumentum struktúráját írják le, semmilyen információval nem rendelkeznek azzal kapcsolatban, hogy miként kapcsolódnak egymáshoz vagy más elemekhez. Kapcsolatok hiányában nem lehet egyértelmű következtetéseket levonni a dokumentum felépítéséről, valamint nem lehet egy több állományba szabdalt dokumentumról egyszerűen gépileg megállapítani, hogy az egybe tartozik.
Igen, a fenti elemekkel legfeljebb ennyit lehet kezdeni, de ezt a már meglévő elemekkel is gond nélkül meg lehetett oldani eddig is egy jól struktúrált HTML-ben, szóval nem léptünk előrébb.
A legfontosabb, hogy ettől nem fogsz pontosabb találatokat kapni a keresőkben, mert az oldalon lévő szöveget nem fogják jobban megérteni. Bevezethetsz ezer új, hasonló elemet, de a lényegen nem fog változtatni: az alapokkal van gond.
Én értem amit írsz arról,
Íme, két példa arra, hogy
HTML 5
<html>
<head>
<meta name="keywords" value="könyv, Alexander Dumas, Monte Cristo grófja, zene">
</head>
<body>
<section>
<article>
<header>
<h1>Ez izgalmas olvasmány</h1>
<p>Nagyon fontos, hogy olvassunk, így tágul a világképünk</p>
</header>
<p>Tegnap kiolvastam egy jó kalandkönyvet, <a href="http://www.wikipedia.org/en/Alexander_Dumas">Alexander Dumas</a>-tól a <a href="http://www.wikipedia.org/hu/Monte_Cristo_grofja">Monte Cristo grófját</a>. Közben végig Ákos egyik albumát hallgattam, így, ha beteszem ezt a zenét, mindjárt a könyvből ismerős tájak jutnak eszembe.</p>
</article>
<article>
<header>
<h1>A kedvenc zeném</h1>
<p>Ajánlom mindenki figyelmébe</p>
</header>
<p><a href="..." tag="zene">Hallgassátok meg a youtube-on</a></p>
</article>
</section>
</body>
</html>
Saját elképzelés:
<?xml-stylesheet type="text/xsl" href="weblap.xsl" ?>
<struktura xmlns:blog xmlns:könyv xmlns:zene xmlns:video>
<blog>
<bejegyzes kulcsszavak="könyv, Alexander Dumas, Monte Cristo grófja">
<cim>Ez izgalmas olvasmány</cim>
<bevezeto>Nagyon fontos, hogy olvassunk, így tágul a világképünk.</bevezeto>
<szoveg>Tegnap olvastam egy jó kalandkönyvet <könyv:író="Alexander Dumas" konyv_azonosito="konyv">Alexander Dumas</könyv:író>-tól, a <könyv:cím="Monte Cristo grófja" konyv_azonosito="konyv">Monte Cristo grófját</könyv:cím>. Közben végig <eloado:nev>Ákos</eloado:nev> <lemez cim="...">egyik albumát hallgattam</lemez>, így, ha beteszem ezt a zenét, mindjárt a könyvből ismerős tájak jutnak eszembe.</szoveg>
</bejegyzes>
<bejegyzes kulcsszavak="videó, vicces">
<cim>A kedvenc zeném</cim>
<bevezeto>Ajánlom mindenki figyelmébe</bevezeto>
<szoveg><video cim="Santana: Guajira" kulcsszavak="Santana, Guajira" href="...">Hallgassátok meg a youtube-on</video></szoveg>
</bejegyzes>
</blog>
</struktura>
[Ehhez természetesen le kell gyártani egy XSL stíluslapot, hogy a böngészőben megjelenjen. A kimenet lehet akár az első példában lévő 5-ös HTML, de akár egy 4.01-es is, mert lényegtelen, hogy a böngészők melyiket kapják.]
Nézzük, mit nyerünk az utóbbi megközelítéssel:
- sokkal több információt lehet kinyerni belőle
- akár minden elemnek külön definiálhatjuk a jelentését kulcsszavakkal
- jelezhetjük az adatok közti összefüggést (a konyv_azonosito egyezéséből ki lehet találni, hogy ugyanarról van szó)
- minőségibb tartalom jön létre
- az elején az xmlns-ekben megadjuk, milyen elemkészletet használunk fel, az elemkészletek egy központi helyen vannak tárolva
- ha magukat a címkéket is központi adatbázisból választjuk, akkor jóval könnyebben találhatjuk meg azokat az idegennyelvű oldalakat, amelyek ugyanarról szólnak, mint a mienk
- az adatok megjelenése elkülönül a struktúrájuktól
- a kliens dönti el, miként jeleníti meg az adatokat (persze mi adunk egy lehetőséget az XSL segítségével)
- lehetőség nyílik az adatok szűrésére a jelentésük alapján
- visszafele kompatibilis (tehát lehet belőle HTML-t generálni)
Természetesen ennek a módszernek vannak hátrányai is:
- meg kell érte dolgozni
- szemléletváltásra van szükség
- jóval szigorúbb, mint a HTML, ezáltal sokaknak elsőre beletörhet a bicskája
Na, akkor most vessük össze ezt a HTML article, header, footer elemeivel.
<article>, <header> és társai + egyéb gondolatok
Az input elemeknél például a dátum megvalósítását nagyon jónak tartom.
Ha megkéred a felhasználót, hogy írjon be egy dátumot, akkor különböző formátumban adhatja meg. Pl.: 2011. ápr. 1., 2011.04.01., 2011-04-01, 11.04.01. stb. Nyilván azonos formátumban szeretnéd tárolni a dátumokat, hogy könnyen összehasonlítható legyen. Szerveroldalon mindenféleképpen ellenőrizned kell. Ma már a felhasználok elvárják/elvárhatják az azonnali reakciót. Ez így jobban közelít a megszokott asztali alkalmazásokhoz. Tehát el kell készíteni valamilyen javascript kódot, hogy a felhasználó kapjon jobb felületet. Emellett ez neked is egyszerűbb, mert azonos formátumot kapsz.
Jelenleg egy nagyobb karakter halmazt tartalmaz az oldal, hogy megvalósítsa ezt a funkciót javascript segítségével, aminek nincsen "hasznos" információ tartalma. (Tehát ezt a látogatók és keresők nem fogják figyelembe venni.)
A html5-el ezt a "fölösleges" karakter halmazt le tudod cserélni <input type="date">-ra, ami ugyanannyi karakter, mint a <input type="text"> változat. Így kevesebb lesz a tartalom leírásra nem használt karakterek mennyisége. (Emellett gyorsabban töltődik be az oldal...)
A legjobb az egészben, hogy mindenhol ugyanaz a dátum kiválasztó ablak jelenik meg. Ugyanott vannak a navigációs gombok minden honlapon. Ez nekem mint felhasználónak nagy könnyebbséget okoz. Nem kell felmérnem a terepet, hogy hogyan tudok hónapot váltani stb. Webfejlesztőként is jó, előírhatóm, hogy kötelező kitölteni és azonos dátum formátumot kapok. Megúszom a javascriptes ellenőrzést. (A szerveroldalit nem.) Nem kell több lehetőséget lekezelni, hogy ha felhasználó más formátumban adja meg a dátumot, akkor átkonvertáljam az én kedvenc formátumomra (Egy jól megadott, más formátumú dátumnál egy hibaüzenet csak felhúzza a felhasználót.) Tehát a felhasználó kiválasztja a dátumot én meg megkapom azt egy standard formában.
Talán múltkor épp te írtad, hogy számítástechnikában kitaláltak rengeteg programozási nyelvet, ahelyett hogy egy jól használhatót használnának. Ezen már én is gondolkoztam többször.
A weben szerencsére egész jó helyzet. A html-t használják struktúra leírására és az információ átadására. A css-t a design-re és a javascriptet az interakcióra.
Szerintem a html5 épp hogy egyszerűsíti a helyzetet. A videókat egyszerűen beágyazhatjuk az oldalba, mint egy képet és nem kell flash (vagy más) technikával bajlódni. Remélem, hogy a közeljövőben kiváltódik a feed is és tovább csökken a szükséges nyelvek és formátumok száma.
Már egy html, css, javascript párosítással írhatunk asztali alkalmazásokat operációs rendszer függetlenül (pl.: opera widget)! Amivel nagyon sok dolgot meg tudunk tenni. Például készíthetők egyszerűbb játékok, naptár programok, e-book olvasók stb.
Az rss speciális elemeinek
Az <input type="date"> viszont rossz példa, mivel használata pont a régi böngészők miatt korlátozott lehet. Azok ugyanis, mivel nem ismerik fel a típusát, <input type="text">-ként fogják értelmezni, amibe a felhasználó azt ír, amit akar.
Mint írod, a szerveroldalon mindenképp ellenőrizni kell, ez igaz, viszont még az <input type="date">-ből érkező adatokat is, mert a böngészők (vagy robotok) bármit küldhetnek.
Értem én, hogy hasznos, de amíg sokan használnak olyan böngészőt, amelyik nem jól értelmezi a HTML 5 új elemeit, addig szerintem fel sem merülhet, hogy áttérjünk rá mindenfajta meggondolás nélkül.
Az ilyen, nem támogatott elemek használata összezavarhatja a felhasználót. Ő csak azt látja, hogy máshol meg tudták oldani a dátum megadását három select segítségével, itt meg egy beviteli mezőbe kell begépelni egy speciális formátumban. Rosszabb esetben fogja magát, és keres egy másik, hasonló oldalt, te meg magyarázkodhatsz a megrendelőd felé, hogy miért olyan kevés a vásárlás.
Próbáld ki
Próbáld ki Operában vagy nézd meg a képeket a következő oldalon: http://marxsoftware.blogspot.com/2011/01/html5-date-picker.html .
Én is távlatokról írtam, mint a többiek. Az átváltásnál természetesen kell lennie átmenetnek, amikor a két megoldás egymás mellett működik. De ez nem tart a végtelenségig. Átmenet nélkül nem lehet bevezetni új technikát.
Gondolj bele, hogy a súlyos műtéteknél a biztonságos gépeken lévő beteget is átmenetileg másképp (kisebb tudású gépeken és bizonyos funkciók monitorozása nélkül) kell átvinni az intenzív osztályra, ahol újra minden monitorozható. Nagyon szélsőséges példa, csak arra szerettem volna utalni, hogy minden átállásnál van átmenet és szükségeseket a váltások, mert nem maradhat a beteg a műtőben (így akadályozza a többi műtétet és az intenzív is jobban megfelel a számára).
Valamelyik szerkesztő írta, hogy a webfejlesztőknek a szabványok terén a böngésző előtt kell járnunk, különben hátrányba kerülnek másokkal szemben. Tegyük fel van egy régi vágású honlapod és egy új. Az új több munka és nem is látszik. Ha kijönnek az új böngészők, akkor a felhasználók számára hirtelen láthatóvá vállnak az addig rejtett dolgok. Ekkor azok a honlapok, amelyek fel vannak erre készítve jobb benyomást keltenek és könnyen hozzászoknak a felhasználók. Ha te ekkor kapkodva hozod össze az újításokat, akkor lekéstél már a többiekhez képest, átpártolnak a látogatók.
Jelenleg is vannak olyan látogatók akik látják ezeket az újdonságokat. Az új böngésző kiadásnál viszonylag hirtelen jut el a nagyon sok emberhez az automatikus frissítésen keresztül (ami a legtöbb böngészőnél működik). Ma már otthon nagyon sok embernek van számítógépe és látni fogja a különbséget, még akkor is ha munkahelyén még ősrégi böngészőt kell használnia.
<form method="post"
Dátum: <input type="datetime" name="datum">
<input type="submit">
</form>
datum.php
<?php
print_r($_POST);
?>
</pre>
Böngészők, amelyek nem ismerik:
IE7, IE8, IE9, Firefox 4 (Ezzel a használt böngészők hány százalékát fedtük le? Több, mint nyolcvan?)
Böngészők, amelyek ismerik:
Opera 11, Chrome 10
Az <input type="date"> által küldött dátumformátum:
éééé-hh-nn
Ezt mondjuk még oda lehet írni a felhasználóknak, ha régi a böngészője, hogy ilyen formában adja meg a dátumot.
Az <input type="datetime"> által küldött formátum:
éééé-hh-nnTóó:ppZ
Na, ezt már nem várhatod el senkitől, hogy így adja meg, ha régi a böngészője. Vagy új, mint a Firefox 4.
Amikor Chrome alatt rákattintok a datetime elem valamelyik nyilacskájára, automatikusan kitölti egy ilyen kinézetű adattal:
2011-04-02T10:36:48.024Z
Amikor rákattintok a submit gombra, a böngésző a következő hibaüzenetet jeleníti meg: Érvénytelen érték.
<input type="time"> A Chrome ebbe is elsőre helytelen értéket ír be.
A legfontosabb, hogy egy látogató se szenvedjen hátrányt amiatt, hogy régi böngészőt használ. Az <input type="date"> helyett sokkal biztonságosabb és kényelmesebb három <select> elemet használni még egy jódarabig.
Úgy gondolom, hogy egy téma
Ennek semmi köze a
csak az anti chrome
roviden: tenyleg hazatelefonal(t) a chrome, de ez benne van (volt?) az EULA-ban, ezen kivul majdnem az osszes ilyen feature kikapcsolhatova valt, valamint megnyitotta a google mind a browsernek a forraskodjat, mind pl. az RLZ algoritmust/forrast.
sot, levalasztottak a browserrol a teljes google brandinget, a chromium-hoz ok is csak utolag kulon csomagoljak hozza a google sallangot.
az SRWare iron az elso idokben valoban nem csinalt mast, mint kicsapta a chrome-bol a hazatelfonalos dolgokat, de azota ezek nagy resze mar a chromium-ban sincs benne, illetve kikapcsolhato.
nem igaz viszont, hogy "minden mást érintetlenül hagynak" hiszen pl. szallitanak beepitett adblockert, meg meg par aprosagot.
osszessegeben az en velemenyem szerint anno is tul volt lihegve ez a tema, jelenleg meg mar tenyleg csak a megrogzott osszeeskuveshivok gondoljak azt, hogy (a chrome-on keresztul) kemkedik utanuk a google.
forras:
http://www.srware.net/en/software_srware_iron_chrome_vs_iron.php
http://en.wikipedia.org/wiki/Google_Chrome#Usage_tracking
http://en.wikipedia.org/wiki/Chromium_(web_browser)
http://en.wikipedia.org/wiki/SRWare_Iron
http://www.google.com/chrome/intl/en/eula_text.html
http://www.google.com/chrome/intl/en/privacy.html
Tyrael
A "lényeg", hogy az író is téved
Ha ezt betartja továbbra is mindenki, akkor fejlődjön minden összetevő a maga tempójában és nincsen szükség verziókra.
Másrészről régen hallottam ekkora butaságot, minthogy "és teljesen mindegy, hogy egy elemet <header>-nek, vagy <div id="header">-nek hívunk".
Ha te egy id-val nevezed el a fejlécedet, akkor arról csak te tudsz. Ha egy szabványban leírt taget használsz, arról mindenki tudja, hogy az a fejléc.