CSS Naked Day
Idén is lesz CSS Naked Day? El ne felejtsük! :)
■ A pucér weblapok apropóján érdekes vitafonal bontakozott ki szemantikáról, keresőoptimalizálásról, leírónyelvekről, webalkalmazások és weblapok ütköztetéséről – a szerk.
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:
Perl alapjai VII.- Fájlműveletek
presidento:
Web Worker – Számolni? Böngészőben?!
Bártházi András:
Google alapjai I.
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 |
|---|---|---|---|---|---|---|
| 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 | 2 | 3 | 4 | 5 |
Időszerű
Elemezzük a helyzetet
A törekvés támogatandó, de éppen ellentétes azzal, amilyen irányba halad a WEB az alap technológiát tekintve. Ennek hangot adtam már többször és itt van egy élő példa, hogy miért nem jó az irány.
A webalkalmazások HTML alapon való megvalósítása ellentétes a szemantikus dokumentumleírással, de legalábbis minél komplexebb egy oldal, webalkalmazás, annál valószínűbb, hogy nem tartható szép formában a HTML kód (és itt érdemes számításba venni a dinamikusan létrehozott HTML-t is). Ennek köszönhetően az ember kénytelen feláldozni a szép HTML-t azért, hogy kényelmesen tudjon dinamikus honlapokat (?) készíteni. Ez pedig éppen a keresők munkáját nehezíti meg, ergó van egy újabb gyakorlati indok, hogy miért nem jó irány a HTML és CSS a fejlődő WEB-nek.
Mi a véleményetek?
SEO
SEO
Meglátásom szerint jelenleg a szorcs.hu az a kereső, ami jó irányba tart. A kereső próbál meg felnőni a feladathoz, nem pedig a kereső (kb. a Google) diktálja a szabályokat, hogy most éppen miképpen eszi meg a tartalmat.
És itt van a kutya elásva, mert ezért (is) nem értek egyet a HTML és CSS based irányú WEB fejlődésével. Egyrészt akarunk jól kereshető tartalmat, amit könnyen fel tud dolgozni a kereső, de akarunk egy ultrabrutál dinamikus, alkalmazásszerű működést (a JS már ezt szolgálja, még ha asszinkron kérés nincsen is jelen), ami meg éppen ellentétes megoldásokat követel az előző ponthoz képest. Azaz honlap (hypertext dokumentum) vs. webalkalmazás.
A SEO egy olyan valami, amit én száműznék a WEB-ről. Ha ez megvan, akkor kell újragondolni a WEB-et, mert jelenleg félúton vagyunk. Kell a szöveges tartalom, de egyre inkább az látszik, hogy a tartalom formája mindegy, mert már nem csak szöveges keresők vannak. Ennek okán át kell szervezni a WEB technológiai alapjait és el kell érni, hogy a tényleges tartalom legyen az alapja a keresési listák rangsorának, ne pedig a sallang (a.k.a. SEO). A SEO-val vissza lehet élni (meg is teszik sokan), konkratan sz@r content mellett, jó helyezést lehet elérni. A felhasználó szív a legjobban, mert közel sem releváns találatot kap a keresés során. A szorcs.hu interjúban nekem a "zöld"-re való keresési példa tetszett, hogy majd erre a zöldségről (környezetvédelem) is ad találatot a jövőben.
Az inteligens, többféle tartalomformára alapzott keresés jegyében kellene elindítani a WEB újraszervezését/újratervezését, szerintem.
Arról egyébként már nem is beszélve, hogy a Google kereső a SEO-t leszámítva sok esetben nevetségesen pocsék találatokat ad. Egy blog esetében összeollóz különböző URL-en elérhető bejegyzésekből egy szöveget és így ad találatot. A találat pedig ezen oknál fogva egyáltalán nem releváns a megadott keresőkifejezésre. Ezért is utálom a Google based honlapon belüli keresőmegoldásokat.
remélem halott
Ráadásul amit mostanában SEO álnéven árulnak (tisztelet a kivételnek, mert van!) az egy google-hack-implementáció, de mondjuk egy modern(ebb) kereső [szorcs], vagy másabb elven működő keresőben, már egyáltalán nem biztos, hogy hasznos lesz.
Persze amíg mindenki a google-t használja és amíg a megrendelők ennyire sötétek (miért ne lennének azok?) addig teljesen mindegy.
A seo is egy szakma, abban az univerzumban, ahol kommunikációból lehet főiskolai oklevélhez jutni!
Nem
Mondani szokás, hogy a Google a világ legbefolyásosabb vak internetezője, és mint ilyen, a SEO igen sokat lökött a szemantikus web szekerén. Sajnos koránt sem ideális a helyzet (és ahogy azt az előző hozzászólásban írod, még inkább rossz felé haladunk), de a SEO alapja még mindig a szemantikus forráskód, tehát jó.
Rossz SEO
Szóval az olyan SEO nem tetszik nekem, mint a marketing esetében az a hozzáállás, hogy majd jól megmarketingeljük -- ez egyébként egy olyan idegesítő szó -- aztán király lesz. Ez a hozzáállás nem jó. Elsődleges kellene, hogy legyen a minőségi tartalom, csak utána a SEO.
Igen
Te hogyan oldanád meg a problémát?
A szemantikus web tartalom még szemantikusabb jelölésére bővítik és kezdik implementálni a WhatWG által anno megálmodott HTML5-öt, ami szerintem egy jó irány.
A megjelenítés az egy újabb réteg, aminek leírására véleményem szerint a CSS teljesen jól funkcionál, csak ugyanúgy bővítésre szorul, amit a CSS3 jól példáloz.
Ezekkel a szabvényokkal csak egyetlen egy a baj, hogy nagyon lassan halad nemcsak a kidolgozásuk, de utána az implementálásuk is a böngészőkbe. Ha ezeket a folyamatokat fel lehetne gyorsítani és akár kisebb iterációkra bontva akár hónapok alatt kidolgozni, majd a (vezető) böngészőkben implementálni, akkor sokkal jobban haladna a webes világ, illetve lehetőség lenne arra, hogy az újabb igényeket ne 5-10 évenként kapjuk a kezünk alá.
Ami a webalkalmazásokat illeti, ott egy olyat tudnék elképzelni, hogy minden ilyen kötelezően egy
<application/>elemen belül kellene írni, amin belül használható lenne már jópár olyan funkció, ami jelenleg "biztonsági okokból" nem elérhető, például lokális file betöltése az alkalmazásba, stb.Ezen az elemen belül pedig lehetnének olyan elemek, amik jelenleg hiányoznak és kínkeservesen lehet implementálni hatalmas HTML markuppal és JS kódolással.
És akkor kereső szempontból ha egy application-nel van dolga, akkor egyszerűen a benne levő tartalommal nem foglalkozna, csak és kizárólag az application leírását venné figyelembe, amit — ami most hiányzik szerintem a webes keresőknél — ember beavatkozással revizálnának.
Maga a markup amúgy hasonlatos lehetne a XULhoz, cserébe annak egy egyszerűsített — megvizsgálva a jelenlegi webalkalmazások támasztotta igényeket — és könnyebben érthető változata.
XUL
Re
Harmadik bekezdés: nem csak az implementálás sebessége, hanem az implementációk ajánlások ellenére való különbözősége is probléma. De még ha lenne is kb. egyforma sebességű implementálás, és valóban egyformán működnének a render engine-ek, akkor sem változtatna semmit sem azon a képen, hogy a HTML a szöveg leírására, míg a CSS a szöveg formázására való és nem dinamikus UI leírására.
A többihez: nem ismerem a XUL-t, de kiindulva abból, amit látok a Firefox extension-ökből, egész jó irány lehet.
Én egyébként valami olyan megoldást képzelnék el talán ideális megközelítésnek, amikor egy API-n keresztül lehet a plain tartalmat kinyerni, ezt használnák a keresők és egyéb harmadik szereplők (szöveget, videót, hangot, képet, stb.). A többire (UI, stb.) konkrét ötletem nincsen, nem voltam sose otthon az ilyen alacsony szintű tervezésben, de az biztos, hogy a HTML és CSS nem jó irány a UI tervezésre.
Megítélésem szerint egyébként egy üzenetküldő FORM is már alkalmazás, tehát a HTML-ben (mint dokumentumleíró nyelv) semmi helye nincsen a FORM tag-nek és a hozzá kapcsolódó dolgoknak. A HTML és CSS kombó a szó szerint vett honlapok esetén jó, amikor nincsen interakció, csak láncolt dokumentumok vannak. Itt már látom értelmét a HTML5-ben bevezetésre kerülő (img tag mintájára) video és audio tag-nek, mert csak beágyazzuk a tartalmat ami a szöveg kiegészítése.
tehát a HTML-ben (mint
Ha pedig nem űrlapot használunk, akkor marad a kézi pöttyögés, akárcsak a parancssoros programok esetében. Viszont web oldalt nem annyit használunk mint parancssoros programot, tehát a paraméterezés szintaxisát nehezebb lenne megjegyezni. Én pedig nem is akarom. Jól megvagyok a HTML dokumentumokba ágyazott űrlapokkal.
Ezért mondtam ...
Lehet ezen hosszasan vitázni, lehet görcsösen ragaszkodni ahhoz az állapothoz, ami most van, mert sokan ebből élnek. De legyünk már annyira objektívek, hogy belássuk: a mai WEB már közel sem a hypertext-ről szól.
A félreértések elkerülése végett: hypertext alatt olyan dokumentumot értek, melyben az egyes oldalak egymásra hivatkoznak. Ez jó volt régen, ma már nem erről szól a WEB.
Vegyünk egy gyakorlati példát: YouTube. A YouTube egy videóraktár, egy olyan felület, mely alapvetően a videók megjelenítésére van kihegyezve. Valójában egy online alkalmazás, honlapnak csak jóindulattal, a felhasznált technológia miatt lehet nevezni. A hangsúly a videó megjelenítésen és nem a szöveges tartalmon van.
Tehát a YouTube valójában megfeleltethető egy asztali alkalmazásnak, mely a YouTube szerverfarmjáról olvassa be a tartalmat (online, realtime). És mivel a YouTube egy jelentős szereplője a ma WEB-jének, ezért elég rendesen megkérdőjelezhető a jelenlegi technológiai háttér létjogosultsága.
A YouTube igenis egy weboldal
A YouTube nem más, mint tartalmi oldalakra (videó lejátszó oldalak) mutató listák.
Maga a feltöltő alkalmazása igen, egy alkalmazás. Van desktop, mobil és online verziója. Az online verziónak a sajátossága, hogy online elérhető, a weben. Igazából ez nem is tekinthető teljes értékű alkalmazásnak, mint inkább egy widget-nek, ahogy az embed formája is a videó lejátszójának.
A GMail már alkalmazásnak nevezhető, de ha belegondolunk, végülis ott is csak listák és tartalmak megjelenítéséről van szó, amik egymásra linkelnek (folder / tag listák, levél listák, levelek tartalma, csatolmányokra való hivatkozások).
Az új email írása szintén egy widget-nek tekinthető, viszont szervesen beépül a GMail tartalmaiba, hiszen ezen a widget-en keresztül generálod te magad a saját tartalmadat.
Másképpen látjuk ...
A YouTube-ot ketté lehet szedni ilyen értelemben, de ha desktop alkalmazás lenne, nem létezne online változata, akkor lenne egy upload része és lenne a katalógus. Mindkét funkció ugyanúgy az alkalmazás része lenne, viszont a felhasználók nagyobb része csak fogyasztana az online raktárból, egy kisebb hányad viszont fel is töltene.
Az online RSS olvasó is tartalmat szolgál ki, mégsem tekinteném honlapnak, habár a jelenlegi technológia miatt rá lehet húzni. Ha emlékeim nem csalnak, akkor először offline RSS olvasók voltak, mint desktop alkalmazások, majd ezeket kezdték online implementálni (az e-mail szoftverek mintájára).
De ha már a Google-t említetted, akkor a Google termékei pontosan jól demózzák azt amiről beszélek, hogy szerintem a WEB a láncolt dokumentumokból átlépett egy következő fázisba, az online alkalmazások fázisába. Innentől pedig a szöveges tartalomszolgáltatás is egy alkalmazásnak tekinthető. Mert mint kuka írta, egy keresési megoldás szerves része a tartalomszolgáltatásnak. De a keresés az már nem a tartalom (a.k.a. dokumentum), hanem az azt megjelenítő alkalmazás része. Nevezhetjük ezt widget-nek, de csak azért próbálod így megközelíteni, mert ragaszkodsz a HTML + CSS féle dokumentumodellhez.
Persze furcsán hathat, hogy van a browser, mint alkalmazás és azon belül még egy alkalmazás. Igen, ez furcsa, csak annó nem ez volt a WEB, ami ma. Régen a browser alkalmazás (a nevéből következően) böngészésre adott lehetőséget (dokumentumokban!), nem pedig alkalmazások futtatására, mely kétirányú, interkatív kommunikácót feltételez (a HTTP meg ugye nem erre termett).
Az, hogy valami online alkalmazásként van megalkotva, nem jelenti azt, hogy nem szolgáltat tartalmat. Ezért mondom, hogy nincsen bajom a WEB fejlődési irányával, jó dolog a bárki általi tartalomszolgáltatás lehetősége, a hardcore multimédiás megoldások, de ehhez már kellene egy újabb technológiai háttér. De mint proclub írta, ezen technológiai váltás esélye egyenlő a nullával.
Update: De menjük tovább. Ahol a megjelenítés mögött adatbázisháttér van, különböző paraméterek szerint történik a tartalom megjelenítése (blogtól kezdve a portálokig minden), az már kő keményen alkalmazásnak tekinthető. Innentől pedig a statikus honlapokat kivéve (.html + .css fájlok) minden online tartalom már online alkalmazásnak tekinthető. Ezen alkalmazások frontend-jének technológiai háttere egy dokumentumleíró nyelv. Így már világosabb, hogy mi a furcsa számomra az egészben?
Ahol a megjelenítés mögött
Akkor egy picit keverjük meg a dolgokat: mi van akkor, ha minden oldala egy blognak statikus HTMLként van cache-elve, a
<html>-től a</html>-ig (oké,DOCTYPEaz elején ott van :)), akkor már statikus tartalmak láncolatáról van szó, amit dinamikusan állítottunk elő.Az, hogy ezt a tartalmat egy alkalmazás állítja elő, ugyanaz, mintha Amanda a Word segítségével WYSIWYG állítaná elő, vagy John egy textedit-ben írná meg plain text-ként a szöveget.
Tehát szöveges / vizuális / audióvizuális tartalom kiszolgálására, ami felfogható egyirányú kommunikációnak, arra "tökéletesen" (tökéletlenül) alkalmas a HTML.
A folyamat igazából ugyanaz, a statikus tartalmat az ember írja, egy alkalmazás segítségével, ami a böngészők számára érthető kommunikációs formátummá alakítja azt. Végső soron egy papírlapra kinyomtatott tartalom is alkalmazások használatával jön létre, pedig ha más nem is, de az igazán nevezhető statikusnak.
A hozzászólások egy blog esetében pedig, ha kivetítjük a "való világra", felfogható úgy, hogy egy hatalmas papírra folyamatosan rányomtatják a postán beérkező leveleket. Tudom, hogy sarkított a példa, de itt is a végeredmény egy statikus tartalom lesz.
Mivel ezen alkalmazások a web-en az esetek 99%-ában statikus tartalmat generálnak, így a fentiek alapján, a HTML-t használjuk, mert az való erre.
Re
A blog statikus oldalakként való leképezése még akár bele is férhet az én "valódi honlap" értelmezésembe. De csak abban az esetben, ha semmi más navigációs lehetőség nincsen, mint egy tartalomjegyzék az összes bejegyzésről, valamint az egyes bejegyzések egy-egy .html-t jelentenek, melyek végén (a lap alján) van egy következő és egy előző bejegyzésre mutató link.
Amikor megjelennek olyan funkciók, hogy natív keresés, havi listázás, kommentelhetőség, utolsú 10 komment listázása sidebar-on, stb, amitől egy blog életre kel, akkor már nem honlapról, hanem online alkalmazásról beszélünk. Ez már nem dokumentum, hanem interaktív alkalmazás. Az alkalmazás biztosítja a felületet a tartalom megjelenítésére és adott esetben annak részleges előállítására (kommentelés).
Tehát az alapvetőn koncepcionális probléma az, hogy a .html-ben megjelennek UI elemek és nem válik el egymástól a tartalom és az alkalmazás user interface-e. A content szerves része lesz az alkalmazás frontend-je. Ez pedig minden, csak nem ideális megközelítés, főleg úgy, hogy a dokumentumok leírására kitalált technológiákkal próbálják utánozni a desktop alkalmazások működését.
WEB 2.0
A következő generáció, a valódi WEB 2.0 az lehetne, amikor elfelejtjük a jelenlegi öszvér modellt. A WEB nagyon átalakult (és az iPad-hez hasonló újabb eszközök révén még jobban át fog), most már nagyon nagy szerepet kap az interaktivitás. Ahol pedig interaktivitás van ott konkrétan alkalmazásokról beszélünk.
Ebből kiindulva a jelenlegi modellt el kell dobni és az alapoktól kezdve kell felépíteni az új WEB-et, mely alapvetően az alkalmazásokról szól. Minden WEB-es sziget (jelenlegi nevén honlap), mely egy domain név alatt elérhető, az egy alkalmazás lenne.
Ennek megfelelően lenne kidolgozva a technológiai alap, ami értelmében akár az egész HTTP menne a kukába, mert látszik, hogy nem igazán jó megoldás amikor valóban online alkalmazásokat akarunk építeni (mert ugye alapvetően nem a kétirányú kommunikációra tervezték, ami viszont egy alkalmazás alapja).
Ez a meg közelítés persze elég nagy irányváltás lenne a jelenlegi helyzethez képest. De ahogyan egyre jobban integrálódnak a különböző készülékek és újfajta ötletek a mindennapi életben, úgy válik egyre elavultabbá a jelenlegi modell. A végtelenségig nem lehet húzni a váltást. Nemrég volt szó éppen itt a Weblaboron az érintőképernyőből fakadó problémákról.
Szerintem új alapokra kell helyezni a WEB-et, és lehetőleg minél előbb ...
Not going to happen
Sőt, ennél messzebb megyek. A fejlesztők nem lennének hajlandóak átállni. Mert ugye egy részről visszafele kompatibilisnek kell maradni, másrészt a nagy szoftverek gyártói (Google) sem fognak úgy hirtelen beleölni pár milliárdot az átállásba, harmadrészt meg a webfejlesztők megdöbbentően nagy része nem látott még Wiresharkot közelről, nem hogy a TCP kapcsolatokról tudjon valamit.
Összegezve: a jelenlegi dokumentum-szerű technológiával készült oldalakat könnyű feldolgozni, parzolni, könnyű indexelni és elég felhasználói bázisa van ahhoz, hogy ne tűnjön el csak úgy. Minden olyan technológia, amiről ez nem mondható el, valószínűleg halálra van ítélve.
Full CSS Naked Day