A HTML alapú web problémái és megoldási javaslatok
Többek között egy nemrég indított fórumtéma kapcsán nyilvánvalóvá vált, hogy egyre többen ütköznek a HTML alapú web korlátaiba, a nem jól átgondolt technológiák, a lassan reagáló W3C szabványügyi szervezet egyre több fejfájást okoz a fejlesztőknek nap mint nap.
Javaslom, hogy gyűjtsük össze ezeket a problémákat, és konstruktívan mindenki írja le a megoldási javaslatait.
■ Javaslom, hogy gyűjtsük össze ezeket a problémákat, és konstruktívan mindenki írja le a megoldási javaslatait.
CSS
1, lehetőség legyen egyszerűen egy tetszőleges, előre meg nem mondható méretű doboz középre való igazítására a szülőjéhez viszonyítva, függőlegesen és vízszintesen, mondjuk így:
vertical-align: center;
horizontal-align: center;
}
2, CSS változók (ezek megvalósítására már vannak törekvések, de tudtommal nem a CSS3 részeként), példa:
.beviteli_mezo {
border-color: $keretszin;
}
3, aritmetikai műveletek:
width: 100%;
}
.beviteli_mezo {
width: #szulo.width - 20px;
}
re css
Szerintem te a flexible boxokra gondoltál ezzel, ha jól tévedek azokkal lehet ilyet csinálni, régebbi geckok a
-mozelőtaggal működnek, a webkitre is van előtag, operával és az explorerrel viszont nem tudom mi a helyzet ezügyben :/Nem; sok ügyfél kérése, hogy
Aritmetikai műveletekre már
sass
Ant
style.cssbuild.xmlHTTP protokoll
Egy HTML dokumentum tipikusan több részből áll: menü, fejléc, tartalom, hirdetések, és mindegyik különböző időben frissül, a hirdetési blokk minden letöltéskor, a tartalmi rész és a menü jóval ritkábban. Ezek együtt azt eredményezik, hogy az interneten található tartalmak (szövegek, képek, gyakorlatilag bármilyen fájl) jórészét annyiszor kell letölteni, ahányszor megnyitjuk az adott oldalt a böngészőben, ezzel felesleges forgalmat produkálva.
Komolyabb tartalomkezelő rendszerek persze már képesek valamennyire szofisztikált gyorstárazásra, de legtöbbször itt is minden fájl esetében küld a böngésző egy kérést, hogy változott-e a tartalma. Bár ilyenkor nem szokott nagyobb adatátvitel történni, a fejléckérések is többtized másodperces lassulást okozhatnak - fölöslegesen.
Ezt megérteni a legkönnyebben úgy lehet, ha mondjuk Total Commanderrel egy szerverre FTP-n keresztül másolunk fel fájlokat. Itt lehet látni, hogy minden egyes kérés előtt hány fejléc kiküldése szükséges, és egy példa: 21 fájl feltöltése összesen 46k méretben kb. 13k/sec sebességgel történik, míg egy fájl 180k méretben 62k/sec-cel megy fel (512 kilobites feltöltési sebességű ADSL vonalon).
Javaslataim:
1, A Server Side Include (SSI)-okhoz hasonlóan lehessen egy HTML oldalt több részre bontani, és ezeknek a részeknek a frissítését szerveroldalon lehessen menedzselni, válasz küldésekor pedig csak azokat a részeket kiküldeni, amelyek megváltoztak.
2, az oldalhoz tartozó fájlokat (amelyek ritkán változnak) lehessen egy fájlba csomagolni, így egyszerre kiküldeni őket, ezzel jelentősen csökkentve a letöltési időt. Az oldal következő lekérésekor egy összesített listát kérhetne a kliens a szervertől, hogy mi változott, és csak a módosított fájlokat kapná vissza, azokat is egy fájlba csomagolva.
re
Ez afelől is probléma szerintem, hogy a keresők szeretik a legfrissebb/legújabb/véletlenszerű tartalmak blokkokat is beindexelni, ilyenkor vannak a nagy anyázások, amikor az az oldal mégse tartalmazza azt, amit mi keresünk. Erre elsőre azt mertem kitalálni, hogy akkor legyen minden egyes ilyen blokk egy külön elérhető tartalom, de azzal meg az adatforgalmat hizlaljuk meg csúnyán :(
Nem tudom erre fog-e megoldást jelenteni az aside tag, az lenne igazából a logikus szerintem.
Ha jól rémlik mozilláéknak van erre valami megoldásuk, de már nem emlékszem pontosan mi is volt ez :/ Talán a sprite-okat akarták helyettesíteni azzal, hogy a szerveroldalon becsomagolják egy fájlba őket. Estére megpróbálom előtúrni.
Ha jól rémlik mozilláéknak
Komolyabb tartalomkezelő
Az ETag és az Expires header tudtommal megoldja ezt a kérdést. Megfelelő expires beállítás esetén a böngésző még a headereket sem küldi föl a szervernek, hanem local cache-ből húzza elő a file-t. Ha viszont az oldalon frissítést nyomunk, akkor másképp történik, akkor a böngésző azért megérdeklődi a szervertől, hogy változott-e valami, és akkor töltődik le újra, ha változott (ETag alapján). Szóval egy full-cache oldalon nem történik fölösleges http request, csak ha frissítést nyomunk, és még akkor sem biztos, hogy le is töltődik újra a file.
Az ETag és az Expires header
Az ETag az inkább csak egy hash, amivel meg tudod mondani, hogy az adott dokumentum megváltozott-e.
Szóval lehet ezekkel a fejlécekkel játszani, de továbbra is a gondot az okozza, hogy a dokumentum különböző részei más-más időközönként frissülnek, mégis mi egy egységként kezeljük őket.
Random filenév
A css-t úgy szoktam
mod_expires-t használsz?
igen
Ez a hozzászólás válasz egy
Pontosan. A Google is leírja, hogy a PageRank alapján az az oldal kerül előre egy találati listában, amelyikre a legmagasabb PageRank-ű oldalak mutatnak. Persze, a címek és feliratok is benne vannak valahol az algoritmusban, de elhanyagolható szorzóval.
Nem jelent mást. Mivel amikor keresel, szövegre, karakterláncra keresel, ezért lényegtelen, hogy mi a csomagolása, <h1> vagy <div>.
Jól látod, viszont a fejlesztőket túlértékeled. Egy darab fejlesztőről van szó, méghozzá arról, aki a HTML kódot írja, a világon rajta kívül kb. hétmilliárd embert nem érdekel, mi van odaírva. Bár igazából az oldal fejlesztője sem számít abból a szempontból, hogy a keresők hogyan dolgozzák fel a tartalmat.
Tehát csak a keresők számítanak, akik jelenleg - minimális kivétellel, lásd azt a pár mikroformátumot - csak a szöveget tudják feldolgozni, pontosabban a szavakat. Egyáltalán nem érdekli őket, hogy <nav>-ban van, vagy pedig <div>-ben vagy <article>-ben.
Bár gúnynak szántad, de ebben is tökéletesen igazad van. Az egész HTML kérdéskört máshonnan kéne szemlélni, mert a HTML 5 fejlesztése rossz irányba viszi a dolgokat.
A HTML az egy felületleíró nyelv, dokumentumleírónyelv. Arra nagyjából megfelel, hogy struktúrálja a dokumentumainkat, de ennél semmi többre. Amikor keresel valamit a weben - ami bizonyára elég gyakran előfordul -, akkor nem fejlécekre meg menükre keresel, hanem adatokra. Téged az érdekel, hogy ez az egyhatos motor hány lóerős, vagy mivel olcsóbb elmenni Rómába, repülővel vagy vonattal.
Tehát amikor a végtelen primitívnél egy fokkal komolyabb dologra keresel, a keresők megbuknak a teszten. Azért, mert nem adat alapúak, hanem szavakra épülnek.
Úgy gondolom, hogy a HTML témakörben ugyanazt a forradalmi változást kéne elérni, mint kb. tíz éve, amikor a backenden (pl. PHP-ben) áttértünk a sablonrendszerekre (template-ek, pl. Smarty), ugyanezt kéne meglépni most a HTML-nél, azaz szétválasztani a megjelenítést az adatoktól. Ez hasonló ahhoz, ahogy a stílusok is CSS fájlban vannak, nem a HTML-ben magában.
Milyen előnyökkel jár ez:
- nincs beleégetve a dokumentumba, hogy miként jeleníted meg a benne levő adatokat
- kisebb dokumentumok
- adat vagy objektum alapon közelítjük meg a kérdést, az oldalon lévő objektumok megjelölése könnyebb
- könnyebb egy dokumentumból az adatokat kinyerni
- emiatt könnyebb a gépi feldolgozás
Persze vannak hátrányai:
- egy kicsit tanulni kell, időt és energiát kell belefektetni
Véleményem szerint erre a jelenlegi XML+XSLT technológiapáros tökéletes megoldást nyújtana, mert széleskörűen támogatott (kivéve persze a keresők, akik fényévekkel le vannak maradva a témában).
Hogy miért viszi a HTML 5 fejlesztése rossz irányba a dolgokat? Mert nem a lényeggel foglalkoznak a fejlesztők, hanem a <div id="nav">-ot átnevezik <nav>-ra. Ettől nem kapunk pontosabb találatokat a keresőkben sehol.
SEO
Ez így nem igaz. Tapasztalat. Van SEO-s emberünk, profi, direkt grafikonokat készít a munkáiról, hogy honnan indult egy oldal, és hova jutott, miután kezelésbe vette. Az ő véleménye, hogy a Google össze-vissza nyilatkozik és beszél arról, hogyan rendezi a találatokat. Elemzi a domaint, a linket, hogy abban milyen szövegek vannak, az oldalra mutató linkeket, hogy azoknak a linkeknek milyen szövegei vannak, igenis kiemelten kezeli a h1 taget és annak tartalmát, nézi, hogy az oldal mikor indult, hány éve van változatlan tartalommal a weben, mennyire gyorsan válaszol a szerver, mennyire követi a kód a szabványokat, az adott szó mennyire elől helyezkedik el, és a kulcsszó milyen gyakorisággal fordul elő az oldalon belül. Biztos vagyok benne, hogy a Google, egészen más értéket fog adni, annak az oldalra mutató linknek, ami egy <aside> mezőben van, és megint egészen mást, ami egy <article>-ben. És fordítva. Ha a lóerő az egyik helyen egy <aside>-ban szerepel, valószínűleg hátrébb lesz, mint ahol ugyanez az <article>-n belül. Ha a <footer>-ben, akkor pedig még lejebb, ha pedig <h1>-ben, vagy a domainben is, akkor pedig elől. És ha ugyanaz a tartalom, akkor az fog előrébb kerülni, akinél előbb jelent meg (IDŐ tényező, ami miatt fontosabb, hogy gyorsan legyen vmi, mint hogy tökéletes eredménnyel lépj csak piacra)
Re
Persze, így van, a kérdés az
De ami a legfontosabb, hogy addig, amíg szavakkal egzakt módon nem lehet leírni valamit (és bizony, ilyen sosem lesz az emberek között, mert a szavak valódi jelentését annyi minden befolyásolja [kultúra, hely, életkor stb.]), addig a szóalapú keresés csak nagyon szűk korlátok között fog működni.
"Mennyiből lehet elutazni Rómába autóval, vonattal, busszal, repülőgéppel?"
Minden információ fenn van a neten, mégsem tudnak a keresők egy ilyen egyszerű kérdésre válaszolni, méghozzá azért, mert szavakra keresnek, nem jelentésre.
?
Most vitathatjuk a keresők működésének mechanizmusát, azok tökéletlenségét, de amíg nem írsz jobbat és gyorsabbat, ez van. És ahogy Churchill mondta a demokráciáról: "Nem jó, de nincs jobb."
Az emberek nem értenek az internethez. Csak használják. Sokan a google-be írják be, hogy freemail.hu , majd kattintanak az első találatra. Mint ahogy volt is ebből egy vicces probléma a facebook-kal: Facebook Login Ranking Problems Return In Google Search
És lehet, hogy hülyék a nethez, de vásárolnak és tájékozódnak rajta, sikerrel. Lehet vitatni a kereső algoritmusok működését is, a találatok pontosságát valószínűleg javítani fogja, ha a kereső tudja a 2010-ről, hogy az most dátum, vagy szélesség. Mint ahogy javította a keresések pontosságát, hogy szinonimákat, többesszámokat és elgépeléseket is figyelembe vesz.
Ha neked van jobb elképzelésed, hogyan lehetne a netet jobban használni, vagy egy szeletében javulást elérni, dolgozd ki, keress üzleti befektetőket, valósítsd meg és tarold le a piacot. Ezt csinálták anno a Flash-sel is. Kellett az animáció, kiszolgálták ezt a piaci rést. Ha te tudsz olyan platformot teremteni, ami böngészőkbe beépülve, lehetővé tenné, hogy relevánsabb eredményeket adjon találatra az új technológia, akkor hajrá.
Már megcsináltam, és el is
Érdekes ötlet