URLs are already dead
Mit jelent a fejlesztőkön kívüli ~1,2 milliárd netező számára az URL?
■ 
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 I.
kgyt:
Akadálymentes weboldalak II.
bbalint:
PHP obfuszkátor
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 |
Semmilyen kutatással
Üzlet
Szerintem ez nem más, mint üzlet, méghozzá ebben az esetben a SEO-sok részéről. A google algoritmusa optimista esetben egy kétszáz változóból álló egyenlet alapján adja a találatokat, ezekből egy lehet az url. Nem biztos, hogy az, de valószínű. Az url szorzóját nem ismeri senki, csak a legbelső és legmegbízhatóbb munkatársak, pár ember. Mindenki más csak találgatni tud, és nem tudjuk, hogy van-e különbség az
article?id=26vagy a/szep_cimközött, és hogy az utóbbi tényleg többet ér-e.A másik ilyen a gyorsaság – amíg a válaszidő nem másodperceket tesz ki, az átlagfelhasználó nem fog alternatívákat keresni, hisz a sebesség csak egy faktor, de a másik oldalon a termék lehet, hogy drágább, lassaban szállítják ki, újra be kell regisztrálni, új felhasználói felületet kell megtanulni stb.
A nagy kedvencem a sorban az AJAX, a fejlesztőkön kívül nincs a világon egy ember sem, akit érdekel, hogy újratöltéssel vagy anélkül jön le az oldal egy szelete. Teljesen mindegy nekik, hogy kattintgatás közben el van-e mentve minden, vagy pedig alul egy Mentés gombra kell kattintani, sőt, sokakat megzavar az előbbi viselkedés, mert nem ehhez szoktak hozzá. Az AJAX szerintem a fejlesztők hülyítésének tipikus esete.
Szóval ezek és hasonszőrű társaik szerintem inkább csak arra jók, hogy mi, fejlesztők vegyük meg valakinek a szolgáltatását (keresőoptimalizálás, ilyen-olyan tanácsadás), és jóval kisebb a jelentőségük, mint ahogy azt sokan beállítani szeretnék. És ezzel természetesen nem azt mondom, hogy nem fontosak.
Az URL egy név, a jelentősége
99,99%-ban zérus
Te sorszámozod a fájlokat a
Egy modernnek nevezett
Nem tudom, hogy honnan
Arra próbáltam utalni, hogy a
Mert hogy ha valaki nem
a létrehozott fájlok száma
Na erre kíváncsi vagyok!
System | C: | minden
274.874 fájl
Data | D: | minden adatfájl
367.394 fájl
Átlagfelhasználó vagy?
A mobileszköz a limitált
Egy átlagfelhasználó is rengeteg dokumentumot, könyvet, fényképet, filmet tárol.
A programozós projektjeim
Így van. És mi a képek neve?
A kép készítésének pontos
Ez a fényképezőgépből "jön
Azt kell, hogy mondjam, egyet
Ez nagyon érdekes ötlet. Az
Vista óta igen
Maga az ötlet persze nem újdonság, anno a BeOS fájlrendszere támogatott úgynevezett "attributes" nevű dolgot minden fájlon ami key-value store-ra emlékeztetett amiben utána lehetett keresni, indexelve volt és volt hozzá query api ami támogatott mindenféle szokásos dolgot mint kissebb/nagyobb és hasonlók. Részletek itt, 5. fejezet környékén..
Köszönöm
Én egy darabig hardlinkeket
Kutatás
A cikk nem a szép URL-ekről
Igaz
Nekem elég csak megnéznem,
És kinek a felelőssége ez?
Passz. :-)
Nem lett bevezetve
Irreleváns
Az URL nem a fejlesztőknek
Az emberek azért nem
Hogyan kellene kinézzen? Strukturált felületnek, egyenként – kiegészítéssel! – hozzáadható és szerkeszthető, törölhető szegmensekkel, lehetőséggel a fában történő navigációra, információval az egyes szintekről, a query string módosításához külön, táblázatos komponenssel.
Nem rossz ötlet, bár ezek a
És úgy gondolod, hogy egy
Nem azt mondom, hogy rossz
Nem kell hozzá API, a
Nem intuitív
http://thepiratebay.se/search/alien%201979/0/99/200
Itt az utolsó előtti szám vezérli a rendezést, azaz, ha a következőképp néz ki:
http://thepiratebay.se/search/alien%201979/0/5/200
akkor méret szerint sorrendez.
Vagy például az edigitalnál:
http://www.edigital.hu/Szamitastechnika/Monitor-c1067.html
ár szerint rendezve
Túl hosszú lenne, húzd ide az egeret
Valami alapján ki kell találni, hogy melyik paraméter mit jelent, tehát API nélkül nem sokat ér az egész, valamint egységes paraméterkezelés is szükséges.
A Pirate Bay egyértelműen
Szabvány
orderby=price&order=0paraméterekkel oldotta meg, míg választhatták volna a következőt is:orderby=price_asc. Így igazából csak az url előzmények állnak a rendelkezésünkre, amivel kezdeni lehet bármit is, ezt meg már kezelik a böngészők, mert bal oldalon kiírják az url-t, jobb oldalt meg az oldal címét.Nem tudom, hogy ennél hatékonyabb lenne-e az általad vázolt ötlet (anélkül, hogy bárkinek is túl sok energiát kellene belefektetnie jobban olvasható url-ekbe). Szabványosítás nélkül nem tudom, mit lehet a jelenlegi helyzetből kihozni. Ha meg nem értjük sem a paramétert, sem pedig az értékét, akkor nem mindegy, hogy néz ki? De, jelenleg szerintem igen.
Az más kérdés, hogy mindenképp célszerű lenne szabványosítani az url-ekben lévő paramétereket, mert ekkor könnyebben lehetne keresni.
Az tény, hogy rossz választás
A Pirate Bay egyértelműen
nem szemantikus:
http://example.com/products?category=2&pid=25"szemantikus":
http://example.com/products/2/25Ez mitől jelent többet (mitől szemantikusabb), mint a fentebbi? Ha érthetővé szeretnénk tenni egy címet, akkor
kulcs=értékformában kéne szerepelnie a paramétereknek, különben nem érnek semmit. Ez viszont csak azt bizonyítja, amit az 5-ös hozzászólásban leírtam.A szegmens és query string
A saját ökölszabályom szerint paraméterbe az való, amit elhagyva ugyanazt az oldalt kapom, valamilyen más beállítással. Rendezés, szűrés, választott formátum, egyes szekciók megjelenítése/elrejtése stb.
A saját szabályok helyett
form, that, along with data in the non-hierarchical query component
(Section 3.4), serves to identify a resource within the scope of the
URI's scheme and naming authority (if any). The path is terminated
by the first question mark ("?") or number sign ("#") character, or
by the end of the URI.
Hol látod, hogy ellentmondok
A szegmens és query string
Nem látom a szabályt az
Az a szabály, hogy nincs
A meaningful IRInek csak routing vagy link építés szempontjából van jelentősége, illetve weboldalaknál SEO szempontjából ki tudja mekkora. Szóval az esetek döntő többségében csak a fejlesztők dolgoznak vele. A felhasználónak édesmindegy, hogy mi van az IRI-ben, megosztáskor copy-paste-eli, egyébként meg csak a domain érdekli. A böngészők sem jelenítik meg, linkeknél külön címet kell adni neki, az ablakoknál, lapoknál meg title-t jelenítik meg helyette, szóval egyedül a címsorban kap helyet. Nekem legalábbis ez a tapasztalatom. Nem véletlen, hogy a legtöbb felhasználó azt sem tudja, hogy micsoda. Mindenki kattintgatással, és űrlap küldéssel navigál, és ez így jó, mert ez volt a hypermedia eredeti célja, hogy linkeket kövessünk, ne pedig kézzel gépeljük be az IRIket. Bevált.
Akkor nem értem, mi bajod
1) Továbbra is várom az ezt az állítást alátámasztó kutatást.
2) Kezd kibaszottul felháborítani, hogy engem senki nem vesz felhasználószámba. Én olvasom és átírom az URL, s amikor a te alkalmazásodat használom, akkor annak a felhasználója vagyok.
A böngészők megjelenítik, a linkeknek az átlagfelhasználó nem ad címet, a title médiafüggő és nem mond róla semmit, hogy hol tartózkodom.
Nem tudom, hogy ez volt-e a hypertext eredeti célja, még mielőtt Fielding utólag aláépítette a doktori disszertációját, de az biztos, hogy a web célja és sikerének egyedüli oka a címezhetőség, szemben a kattintgatással, ami minden grafikus platform sajátja.
Déjà vu
Azt kockáztatva, hogy magamat ismétlem (mert meg mernék rá esküdni, hogy ezt a kört már egyszer lefutottuk valahol a weblaboron és a böngészőm visitednek jelöli a lenti linket), de az egyetlen kutatás amiről tudok és kapcsolódik ide az pont azt mondja ki, hogy URL-ek elég fontos szerepet döntenek el a kereső találatok közötti választásban: An eye-tracking study of information usage in Web search (2007, Microsoft).
A kutatás mérései alapján kvázi az idő 24%-ban az URL-t nézik a látogatók az egyes bejegyzésekben (cím és snippet teszi ki az idő többi részét), de a konklúzió elég összetett (ami hasznosnak tűnik bizonyos fajta sitehoz az káros lehet más fajtánál egy találati oldalon), érdemes elolvasni.
Ez persze nem alátámasztja az "felhasználót nem érdekli az URL" hipotézist, hanem inkább cáfolja, legalábbis kereső találat oldalakon, de annál rosszabb a tényeknek.
Nem értem, te akkor most
Punks not dead
Ez egy speciális eset,
Lehet, hogy az vizsgált eset
- Van valami elképzelésük arról, mi is lehet az URL
- Tudják, hogy alapvetően navigáció támogatására használható
Ezeket akkor se felejtik el ha épp nem egy kereső oldalt néznek, így az eredeti cikk konklúziója miszerint:A cikk írója később commentben megerősíti, hogy írása csak saját tapasztalatain alapszik (külön mókásnak találom, hogy mivel nem volt permalink az oldalon Firebug + urlbar-ba pötyögéssel állítottam elő a linket :P)
Az, hogy a google megpróbálja az URL-ket fogyaszthatóbb formában megjeleníteni (ha már ennek apropóján született a cikk) lehet csak arra utal, hogy szerintük most nem elég lényegretörőek vagy olvashatóak - és lenne az ami lehet sokak "hibája" és ami ellen fejlesztő megpróbálhat tenni valamit - nem arra, hogy úgy általában értéktelenek felhasználóknak, de ez már csak találgatás a részemről.
Információérték
De miután megnyitok egy oldalt, a "baj már megtörtént", és nem leszek attól okosabb, ha a böngésző tetején ott van a teljes cím. Mivel eszközök nélkül nehézkes a használata (eleve minden browserben az első kattintásra kijelöli az egészet, tehát minimum kétszer kell ráböknöm, ha módosítani szeretném, a betűk pedig kicsik, azaz idővel egyre nehezebb benne kijelölni), nem véletlen, hogy funkcióját összevonták a keresőmezőével, sorvad. Így viszont nem több, mint egy egyre kevésbé használható elem, ami csak a helyet foglalja.
Innentől kezdve el lehet gondolkodni, hogy egy URL összeállítására, kozmetikájára mennyi erőforrást érdemes áldozni. Szerintem minimálisat, a kezeléséhez szükséges eszközök hiánya miatt a lapos struktúra (domain.hu/akarmi.html) pont ugyanolyan megfelelő, mintha megpróbálnám hierarchiába szervezni.
Ha mégis az utóbbi mellett döntök, akkor mind szerver-, mind pedig kliensoldalon kezelni kell, azaz például az
origo.hu/gazdasag/akarmi.htmlcímből következően azorigo.hu/gazdasag/-nak is élőnek kell lenni, és erre linket is el kell helyezni. Rossz példa erre a blog.hu, ahol bár "szép" url-ek vannak, és élnek is, azaz visszatörléssel lehet benne navigálni, példáulhttp://szemantikus.blog.hu/2011/02/28/szemantika_a_html_ben, de a jobb oldali archívumban a februári összes bejegyjés már ahttp://szemantikus.blog.hu/2011/2címre mutat (egy nulla eltűnt, azaz nem konzekvens), míg ha 2011 összes írását szeretném megnézni, erre nem lehet találni hivatkozást.Az URL kiírásának két helyen van értelme: a keresőben, valamint az állapotsorban, amikor felé viszem az egeret.
Ráadásul a tipikus "szép" URL-ek, amelyek arra a sablonra épülnek, amit fentebb a blog.hu kapcsán illesztettem be, csak az emberek számára hordoznak információt, mert ránézünk, és vagyunk olyan intelligensek, hogy tudjuk, a bejegyzés címe előtt egy dátumot látunk. Ezt egy gép jóval kisebb eséllyel ismeri fel, három egymást követő szám lehet dátum, de akár egy akta száma is. Emiatt, bár az angol szakirodalom szemantikusnak nevezi, valójában jóval kevesebb információt hordoz gépek számára, mint a következő:
szemantikus.blog.hu?bejegyzes=szemantika_a_html_ben&datum=2011-02-28. Mivel egy kereső sosem tudhatja, hogy a perjelekkel elválasztott hierarchia valóban létezik, magától nem fogja kitalálni, hogy azakarmi.blog.hu/2014url létezik-e, csak akkor, ha van rá a HTML-ben link.Tehát szerintem a querystringes (vagy azzal ekvivalens) megoldás mind a gépek, mind pedig a humán olvasók számára többletinformációt hordoz a jelenleg elterjedt "clean" URL sémákhoz képest. Márpedig nekünk, fejlesztőknek a keresőket is ugyanúgy ki kell szolgálnunk, mint a látogatókat, mivel az interneten található oldalak egyre növekvő számát csak ezek tudják feltérképezni, számunkra ez lehetetlen feladat.
eleve minden browserben az
Rohadt idegesítő.
works4me
Lehet, hogy vissza kellene
Windowson is lehet
browser.urlbar.clickSelectsAll-tfalse-ra állítani és megoldódott a probléma.Mondjuk én azt szeretem, ha kijelöli az egészet, de ez a pap és papné esete.
Sok felhasználónak fogalma sincs az ilyenekről.
Nem tudom, mennyire megrendezett, de szerintem nem az, és jól tükrözi az átlag felhasználót. Mert az átlag felhasználót egyáltalán miért érdekelné az URL? És miért akarna különbséget tenni a böngésző és a kereső motor között?
Újságot sem úgy vesznek, hogy elmennek a 1146 Budapest, Thököly út 127. szám alá (URL), és ott kérnek egy aktuális számot, hanem elmennek az újságárushoz (Google) és kérnek egy Népszavát.
+1, ismerek én is olyat,
Ettől függetlenül nincs elég statisztikai adatunk, hogy kijelentsük, hogy ez az átlag, de szerintem is közelít hozzá.
+1, szerintem is speciális
A doksi alapján nem kifejtős
A doksi alapján nem kifejtős kérdések voltak, hanem ilyen 1-től 7-ig pontozható "jellemző/nem jellemző rám" így ez sajnos nem derül ki ebből (magukat a kérdéseket nem látom, hogy csatolták volna).
Hmm ez érdekes. És
Nem releváns
Akkor nem értem, mi bajod
Semmi, tedd azt. Csak arra próbáltam felhívni a figyelmedet, hogy létezik olyan, hogy URI specifikáció, amiben világosan le vannak írva, hogy mik a megkötések ezzel kapcsolatban. Tehát létezik szabály a dologra.
Pontatlanul fogalmaztam, az innerHTML-t értettem cím alatt egy-egy anchor-on belül.
Milyen helyzetben teszed ezt? Nálam leggyakrabban akkor, ha google-ben az ismerős, illetve megbízhatónak ítélt oldalak tartalmait akarom csak megnézni.
Hát ez elég erős állítás, hogy ez az egyedüli oka. A címezhetőség fontos, de a linkek ugyanúgy fontosak. Linkek nélkül gyakorlatilag nem létezne a böngésző, mint olyan, hanem csak célalkalmazásokra lehetne klienseket írni. Fielding nem épített át semmit a disszertációjában, a resource identifier-ek ugyanúgy szerepelnek benne, mint eddig.
Csak arra próbáltam felhívni
Hidd el, olvasgattam eleget RFC-t :) És az előbb tisztáztuk, hogy nem létezik rá szabály. Tényleg nem értem, hogy mi akarsz ezzel.
Az az, amit az átlagfelhasználók nem szoktak megadni (általában nincs is rá lehetőségük, lásd például Facebook).
Folyamatosan. Mielőtt egy hivatkozásra kattintok, meg szoktam nézni, hova vezet (ugyanitt kiborítónak tartom, hogy divat lett kitakarni a közepét, hogy az állapotsort is megspórolják), többek közt azt is, hogy milyen formátumra, egyáltalán, valódi link-e, és meg tudom-e nyitni új lapon; ha egy CDN-en látok egy bélyegképet, akkor átírom, hogy megnézhessem a nagyot; ha kapok egy deep linket, és érdekel, honnan van, akkor feljebb lépek az URL-szerkesztve; ha megosztok egy címet, akkor a felesleges paramétereket törlöm belőle…
Ugyanúgy működne a web, ha HTML helyett txt fájlokat használnánk, csak kényelmetlenebb volna, hogy át kell másolni a címsorba a hivatkozásokat, nem elég kattintani.
Arra céloztam, hogy a hypertext sokkal régebb óta létezik, mint a web, a web pedig régebb óta, mint a REST fogalma, így akármilyen fontos jelentőséget is tulajdonít utólag Fielding – akinek tudom, hogy a REST kapcsán a nézeteit ismered – a címektől független linkeknek, az sokat nem mond ezek valódi szerepéről a web sikerében.
Ugyanúgy működne a web, ha
Kíváncsian várom, hogy mondjuk egy űrlap küldést hogy oldanál meg így...
Lehetne éppenséggel egy
Nagyjából ugyanaz a funkciója
Elég érdekes világ lenne mindenesetre, ha kézzel kéne bepötyögni az URL-t, illetve az űrlapoknál az input mezők neveit és értékeit, maradjunk ennyiben... :D
Szerintem volna egy steampunk
Az egésszel csak azt akartam alátámasztani, hogy ami megkülönbözteti a webet az összes más grafikus alkalmazásplatformtól (ami mind alkalmas a kattintgatós navigálásra és űrlapkitöltésre) az a címezhetőség, ez az, ami miatt a web és nem más platform a legsikeresebb.
Juhé
Végre nem vagyok egyedül :D
Simán lehetne:
http://example.com/products/category:2/pid:25tadamm :DSzerintem az részletkérdés,
A specifikáció szerint nem, a
Hierarchia
Az, hogy mit tekintesz
Persze, hogy az. Ezért látni
/users/name:Anna/count:25/offset:50/users?name="Anna"&count=25&offset=50/users?name="Anna"Mindegyik teljesen valid. Az egyik szerint a map reduce hierarchikus, és a reukált felhasználó lista az eredeti sub-resource-a, a másik meg úgy értelmezi a map reduce-t ebben az esetben, hogy nem hierarchikus, és a redukált felhasználó lista az eredeti resource egy eltérő reprezentációja, semmi több. Nyilván ez utóbbi kihasználja, hogy egy resource-hoz több eltérő IRI is tartozhat. A harmadik ennél is tovább megy, és a pagination-t range header-ekre bízza.
Csak hogy valami építő
Zakas nem hülye, szoktam
Én az elején úgy vettem le, hogy Gábor egyik megszokott témáját, a "szép url"-ek feleslegességét igyekszik a cikkel alátámasztani, szerintem a cikk nem erről szól. Attól hogy az emberek nem nézik mondjuk a változóneveimet, csak jobb beszédes neveket használni. Ugyanígy az URL is szerencsésebb, ha olvasható, plusz információt hordoz, általánosan elfogadott elvekre épül.
Ami a cikket illeti, én nem örülök az URL eltüntetésének, nekem információt hordoz (jó esetben). Ha opcionális, az belefér, csak tudjam visszakapcsolni. Ha a tömegek szokásaira alapozunk, akkor a Word funkcióinak 99%-át ki lehetne venni, úgyis szpésszel zárnak középre és enterrel csinálnak térközt.
Én az elején úgy vettem le,
Az egyetemen terméktervezőnek tanultam, és ergonómiából az első órán elmondták, hogy a mérnökök által legtöbbször elkövetett hiba az, hogy a termékeket igazából maguknak készítik, és nem kérdezik meg a felhasználókat, hogy nekik mire van szükségük. Mi, webes programozók pontosan ugyanígy viselkedünk, egy rózsaszín burokban alkotunk, de arról nem sokunknak van fogalma, hogy az általunk készített oldalak látogatói mit szeretnének.
Érdemes elolvasni a kontroverziális írásaimra kapott kommenteket. Amikor feltettem a kérdést, hogy mire jók a HTML5-ben bevezetett új elemek, tipikusan olyan válaszokat írtak a kollegák, hogy "jobban olvashatóvá, strukturálhatóvá teszi a kódot", és erre feltettem a kérdést, hogy "kit érdekel, hogy neked mennyire olvasható?", hisz nem neked készül az oldal, hanem a látogatóknak, ettől függetlenül arra még senki sem tett komolyabb erőfeszítést a HTML-lel kapcsolatban, hogy az interneten található mérhetetlenül sok információban könnyebben lehessen keresni a látogatóknak. Ugyanez volt, amikor felvetettem az animációk kikapcsolásának lehetőségét, vagy azt, hogy vigyázni kell az AJAX-szal.
Nagyon jó a Gixx által belinkelt videó, abban elmondják, hogy az emberek 8%-a tudta megmondani, mi az a böngésző. Ők a felhasználók, a többség.
Persze, hogy így gondolkozom.
Egyetértek azzal, hogy kisebbség vagyunk, és ezt el is fogadom. Azért a fejlesztőkön túl vannak még bőven, akik tudják, mi az az URL és társai, nem csak zombiként nyomkodják a gombokat. Velük együtt azért már vagyunk annyian (pár százalék is már fontos mennyiség), hogy érdemes legyen minket figyelembe venni. Ráadásul ezek az emberek hajlandóak tanulni, szeretnek felfedezni. Tőlük is elvesszük a lehetőséget, hogy esetleg megértsék a működést (azért valljuk be, az alapok nem atomfizika). Felmerülhessen legalább a kérdés, hogy az ott mi és mire jó.
Értem az érveidet, részben egyet is értek, de nem csak a teljesen hülyéknek kéne tervezni az "internet"-et, elvéve a tanulás, fejlődés lehetőségét. A középút lenne itt is az ideális.
A HTML5-öt meg a többit ne keverjük ide, az teljesen más téma :). A fejlesztő dolgát sem hülyeség megkönnyíteni, mindenki által ismert okokból, de ezt ott elegen kifejtették, igen jól.
Ezt én is így látom. Ha
Vigyük tovább a fonalat
Ennek a témának a címe
http://weblabor.hu/blogmarkok/129314. Amikor ezt a választ pötyögöm, a címsorban azt látom, hogyhttp://weblabor.hu/blogmarkok/129314/hozzaszolas/109706. Tudom azt, hogy ha másik hozzászólásra szeretnék válaszolni, akkor az utolsó számot kell átírnom. Ehhez nem kell mást tennem, mint a permalinkben megkeresni a másik hozzászólás azonosítóját, kijelölni, kimásolni a vágólapra és beilleszteni. Jó lenne, ha a címsort jobban kiemelnék, vonzaná a tekintetet, így ilyen műveleteket sokkal könnyebben el tudnék végezni.Az ironikus hangnemért elnézést kérek, remélem, érthető, mire szerettem volna célozni.
Úgy vélem, elkerülte a
Nem kerülte el. Számomra az a
Akkor itt be is fejeztük :).
A HTML5-öt meg a többit ne
A HTML5-ről szerintem nem sok
Az olyan elemek, mint nav vagy section könnyebb gépi feldolgozást tesznek lehetővé, ami könnyebb kereshetőséget és mondjuk látás sérülteknél könnyebb felolvasást jelentenek.
Van továbbá egy csomó olyan elem, amit régebben flash-el, vagy silverlight-al lehetett csak használható módon megoldani, most viszont a HTML részei lettek, így nem kell külső plugin, hogy lejátsz egy videot vagy hangot, tegyél alá feliratot, stb... A grafikus elemek, mint az svg és a canvas meg tetszőleges, az oldalhoz kapcsolódó vektorgrafika és egyéb grafikai elem beágyazását teszik lehetővé. Szóval például ahhoz, hogy egy játékot írj webre, már nem kell többé flash, bőven elég a canvas. És ez akár az olyan 3d játékokra is vonatkozik, mint pl a quake vagy a doom (az újakat nem ismerem), nem csak a gagyi 2d átlag flash megoldásokra.
A hatékonyabb keresést már rég megoldották RDFa-val, annyi a probléma, hogy az átlag fejlesztőnek fogalma sincs arról, hogy mi az, hogy RDF, linked data, vagy RDFa, így nem is használja. Született emelett még egy csomó másik megoldás is, microdata, microformats, stb... Bármelyiket lehet használni, ha valaki jól kereshető oldalt akar csinálni.
Az általad felhozott érvekről
Kérlek, ha nem a témába illőt
Gondolom ezt magadnak írtad, mert te kezdtél el HTML5-ről beszélni, amikor teljesen más volt a téma.
Mint te is írtad senkit nem érdekel a fejlesztők kényelme. Ha nem tudnak megtanulni létező, google által támogatott, és egyébként jól működő technológiákat, akkor jobb, ha másik állást keresnek maguknak.
2010-ben a flash elterjedtsége 1% volt. (Nekem sem muszáj hivatkozást írni, hidd el bemondásra.)
A canvast és svg-t egyáltalán meg sem említetted. Gondolom nehéz ellenük bármit érvelni. A pluginok közül talán a silverlight ütötte meg azt a szintet, amit képviselnek, a flash valószínűleg a közelében sem volt, bár ez csak benyomás, nem használtam ténylegesen egyiket sem.
Nem tudom nálad hogy megy ez, de általában a vitáknál érvelni szoktak, nem azt bizonygatni, hogy kis gondolokodással majd találsz a saját álláspontod ellen érveket... Dehát az ember mindig tanul valami újat. Az általad felhozott érvekről kis gondolkodás után beláthatod, hogy falsok...
2010-ben a flash
Olvasd el akkor ismét, mit
Továbbra sem értem, hogy jött oda a HTML5. A te fejedben bizonyára legitim és létező a kapocs, ezzel nem is tudok mit tenni. Kértem is, hogy ne menjünk el ebbe az irányba.
Engem zavart. A HTML5 végre lefektetett egy rakás olyan dolgot, amit már nagyon régen le kellett volna. Nem mondom, hogy kiválóan sikerült, de már ideje volt.
RDF(a)-t kutya nem fog
Attól, hogy nem vetted a fáradságot, és szántál rá egy napot, hogy megtanuld, még nem bonyolult. Sima RDF kötéseket csapsz hozzá a tartalomhoz néhány attribútummal ill. URI-k használatával. Egyébként pont te érveltél azzal a HTML5 újításai ellen, hogy tök feleslegesek, és csak a szoftverfejlesztők kényelmét szolgálják. Akkor nem értem, hogy miért panaszkodsz...
Jelenleg 300 millióból olyan 3 millió domain használ microdata-t vagy RDFa-t. Mindkettő körülbelül ugyanazt tudja, az arány fele-fele. A microdata használata egyre növekszik, és valószínűleg idővel ki fogja szorítani, mert valamivel egyszerűbb scope-al használni a vocab-ot, és nem mindig kiírni a névteret.
Engem mindig is zavart, mert a webre szeretnék fejleszteni, és nem egy pluginra. Ezért is örülök a HTML5-nek, meg annak, hogy végre belátták a böngésző gyártók, hogy a pluginek és saját külön formátumok készítése nem járható út a weben, és helyettük a HTML-t kell fejleszteni, mert azt kénytelen az összes böngésző támogatni. Ez legjobban a silverlight-nál látszott meg, a microsoft beleölt egy csomó energiát, de nem tudta keresztülverni, hogy minden böngésző alapból támogassa. De ugyanígy voltak próbálkozások firefox részéről is pl xforms-al, stb...
Ha valóban egy nap lenne a
<nav>begépelése is elég, az<ul role="nav">-ot már sokallják, akkor a<span rel="foaf:interest" resource="urn:ISBN:0752820907">-tól menekülni fognak. Amíg nem találnak erre egy olyan faék egyszerűségű szintaktikát, mint amilyen a HTML, addig nem fog működni a dolog.Amíg nem találnak erre egy
Csak megjegyzésként teszem hozzá, hogy a microdata-hoz is ugyanúgy össze kell vadászni a vocab-ot, szóval semmivel sem egyszerűbb ilyen szempontból.
Nem fognak találni hozzá, mert az URI-t mindenképp meg kell adni, mint erőforrás azonosítót. Nélküle gépileg nem feldolgozható a dolog, mert a kereső csak szavakat lát, de nem képes összerakni a jelentésüket, mert nem ismeri a kontextust. Majd ha lesz mesterséges intelligencia, akkor más lesz a helyzet, de jelenleg csak ez működik.
A google próbálkozhat mással, de nem fog összejönni neki. Az elmúlt 25 év legalábbis ezt mutatja.
HG ne már...
Legalább annyit tegyél meg legközelebb, hogy a keresőeszközökben bekapcsolod "Az elmúlt hónapban" szűrőt. Nekem az első oldalon 2012 júliusi a legfrissebb link. Az IT-ban ez már a történelem kategória manapság.
Engem mindig is zavart, mert
- "webre szeretnék fejleszteni, nem pluginra"
- "Az olyan elemek, mint nav vagy section könnyebb gépi feldolgozást tesznek lehetővé, ami könnyebb kereshetőséget és mondjuk látás sérülteknél könnyebb felolvasást jelentenek." - a
roleattribútumok ezt már évekkel a HTML 5 megjelenése előtt tudták- "Szóval például ahhoz, hogy egy játékot írj webre, már nem kell többé flash"
És hol maradnak, kérem, a felhasználók? Nekik nem mindegy, hogy egy grafikai elem natív vagy plugin? Erre hoztam a példát, hogy 2009-ben 98% számára mindegy volt. Számukra milyen előnyöket hoz a HTML5? Pedig belőlük élünk, hisz ők veszik meg a megrendelőink termékeit, így közvetve tőlük kapjuk a fizetésünket. Az általad felhozott RDFa és microformats 1% alatti elterjedtsége nem túl kielégítő. Ha valóban hasznosak, mert hatékonyabb keresést tesznek lehetővé, akkor miért nem ezek fejlesztésével foglalkozunk?
Én, mint felhasználó
* szeretem a <video>-t, mert tudok videót nézni Flash nélkül is: kezdetben ugyan volt flash, de az akkori technológiai szinten megette, sőt felfalta a telefont, és egy kőkorszaki kavicsot varázsolt belőle. Ma már lehet, hogy jobban bírnák, de nem hiányzik senkinek se.
* szeretem az <input type="number">-t, mert egyből a numerikus billentyűzet jön fel, ha csak számot kell begépelni (pl irányítószám)
* szeretem az <input type="email">-t, mert megjelenik a @ a billentyűzeten, nem kell bemenni a speciális listára.
* szeretem a többi HTML5 inputot is, mert, ha az oldalon jól van használva, akkor FELHASZNÁLÓKÉNT sokkal könnyebben tudok böngészni.
* ha látássérült lennék, és ismernék jó felolvasó programokat, amik ismerik a HTML5-öt, akkor FELHASZNÁLÓKÉNT biztosan örülnék a sok új szemantikus csodának, mert a program helyén tudná kezelni a dolgokat (navigáció, fejléc, tartalom stb.) és nem venné egy kalap alá a menüt és a tartalomba helyezett felsorolást, mert mindkettő <ul><li>
FEJLESZTŐKÉNT szeretem a HTML5-öt, mert
* a sok új tagre sokkal egyszerűbben tudom ráültetni a CSS-t és a JS-t is
* könnyebb olyan oldalakat készíteni, ami sokkal több ember igényeit kielégíti (még a mobilozó látássérültekét is)...
* szeretem az <input
Azért vannak hátrányai is. Ha ugyanis a szám 0-val kezdődik, akkor az (mármint a 0) nem kerül(t) elküldésre. Ezek kívül, van más nem kívánatos tulajdonsága is a
"number"-nek, például növelés/csökkentés gombok, amivel növelni, csökkenteni lehet az értéket, és egyes böngészők másként kezelik ezt (fel/le gombok és egérgörgő esetleg növelik illetve csökkentik az értéket). Sajnos sokszor marad a"tel".akkor lehet, nem number-t használnak
Mondjuk az nem lenne hátrány, ha JS-ből definiálhatnád a keyboard layoutot egy-egy inputhoz :)
Azaz helyesbítek. Ismerve magamat, és sok sok feljelsztő kolléga (a múltban és jelenben) munkamódszerét, valószínűleg néhány esetben hátrány lenne. A felhasználó számára. Aztán jönnek a hotfix-ek, meg a frissítések, amíg végül vagy visszaáll minden a rendszer által támogatottra, vagy csak szimplán működni fog :)
- Korábban volt flash és
- A különböző új input type-ok bár biztosan hasznosak, de nem indokolnak főverzióváltást.
- N-szer leírtam, de leírom n+1-edszer is szívesen: ha tényleg érdekel, hogy sérültek is megnézhessék az oldalad, évekkel a HTML 5 előtt ott volt az XHTML
roleattribútuma, ami, ha utánajársz, ráadásul jóval több lehetőséget biztosít, mint az új tag-ek. Kíváncsi vagyok, hogy amikor ezt valaki felhozza mint érvet a HTML 5 mellett, vajon ezt az attribútumot használta-e korábban, és használja-e azokat az értékeket, amire nincs HTML tag? Van egy olyan érzésem, hogy 99%-ban a válasz nem lenne.A legegyszerűbb leellenőrizni a dolgot, ha előveszel egy-két 2006 körüli html kódot, és ha benne vannak a role attribútumok, akkor már azidőtájt is érdekelt a téma. Ha nem, akkor meg ez az egész nem más, mint disszonanciacsökkentés (ti. az új tag-ek mellett való érvelés).
De ha már a kisebbségnél tartunk, kíváncsi lennék, hogy vajon az 1-2%-nyi látogatót is ugyanígy támogatod, akik kikapcsolt javascripttel érkeznek az oldalaidra, azaz számukra is elérhető minden szolgáltatás? Mert ők nagyjából ugyanannyian vannak átlagosan, mint a sérültek.
-
$('.article')helyett$('article')ez valóban jóval egyszerűbb, nem kell annyit gépelniAmiket felhoztál érvként, az vagy elhanyagolható számú felhasználót érint vagy pedig csak kicsit lesz tőle kényelmesebb a böngészés. De a legfontosabb dologgal, annak a problémának a megoldásával nem foglalkoztál (sem te, sem a HTML kitalálói), ami minden felhasználót érint, méghozzá a kereshetőség javítása. És ha azt vesszük, hogy ezen minorális javulást hozó fejlesztések bevezetése is hány évet vett igénybe, akkor abból kiszámolható, hogy itt évtizedeket, évszázadokat vesz majd igénybe, hogy normálisan kereshető legyen a net, köszönhetően a fejlesztők kényelemszeretetének.
Kíváncsi vagyok, ha az
Nem rávenni kellene őket,
És ez alapján pedig közösen (!!!) lenne megírva az általam már többször említett render (és JS) engine, amit csak használni kellene a böngészők gyártóinak. Innentől mindjárt ketté is válik a böngészőket fejlesztők és az engine-eket fejlesztők tábora, továbbá könnyű dolga lenne a frontend fejlesztőknek, ugyanis, ha a validator azt mondja, hogy ok a HTML vagy a CSS, akkor minden, azaz minden eszközön, platformon egyformán jelenne meg a site. Nem kellene tesztelni millió helyen, mert az egyetlen közös engine miatt borítékolt, hogy bárhol ugyanazt látom.
Ez az egyetlen értelmes, és járandó út. Ehhez viszont az kellene, hogy értékközpontúan gondolkodjanak a piac szereplői. Ide viszont fel kell nőni, de nem úgy néz ki, hogy képesek lennének a közeljövőben megugrani ezt a lécet a fiúk és lányok... 5 év alatt meg lehetne reformálni a webfejlesztést és a webet magát, mert az emberiség képes rá, csak hát ugye az érdekek...
Ez az egy renderer ugyanolyan
Ennél jobb megoldás nincsen.
Kár ide keverni egyéb ideológiákat, mert a történet nagyon egyszerű. Adott egy valami, amit webnek hívunk. Adott egy rakás felhasználó, akik igényelnek valamit. Adott egy rakás fejlesztő és piaci szereplő, aki szolgáltatna. Adott számos jó koponya, kiváló ötletekkel. Adott egy együttműködő közösség, aki meghatározza, hogy mi az, aminek értelme van a gyakorlatban. Vagyis mi az, amire lehet értékteremtő megoldásokat építeni. Gondolok itt a HTML, a CSS és a JS lehetőségeire. Hogy aztán a valóságban ki használja x tag-et, CSS tulajdonságot, JS varázslatot, az már egy másik lapra tartozik. Aki éppen nem ért egyet egy ötlettel, de abból kára nem származik, hogy megvalósul, annak nem fáj a feje attól, hogy bekerül az engine-be.
Nem olyan bonyolúlt ez, csak az érték nézőpontjából kell megközelíteni a munkát, és az együttműködés. Mi az érték? Ami olyan lehetőséget teremt, amivel másoknak segíteni lehet, szintet lehet lépni. Ha egy megoldás jó a programozónak, és nem sérül a felhasználói teljesítmény, akkor kódolják le. És viszont.
Azt elfogadom, hogy nem tudtok hinni ebben a dologban, de mint ahogyan az egykulcsos adószrendszernél igazságosabb nincsen, úgy ennél a megközelítésnél sincsen jobb. Hogy itt és most az emberiség legnagyobb része alkalmatlan a megvalósításra, egy másik történet.
„Ennél jobb megoldás nincsen.
– Vlagyimir Iljics Uljanov
Te szeretnél egy olyan társadalomban élni, ahol nincsen választásod?
Miben nem lenne választásod?
Motor-fejlesztőként semmiben
Böngésző-fejlesztőként rám volna kényszerítve egy motor, annak funkciói, felülete, technológiája, teljesítménye.
Webfejlesztőként ki lennék szolgáltatva egy monopol helyzetben lévő gyártónak.
Felhasználóként ki lennék szolgáltatva egy monopol helyzetben lévő gyártónak.
Láttuk már azt, amit javasolsz, a motor neve Internet Explorer 6 volt.
Na itt a probléma. Nem érted,
Ha tetszik, OpenSource engine-t írna a világ legjobb programozóinak csapata, azzal a szent céllal, hogy a lehető legjobb engine készüljön el. Nincsen teljesítmény probléma, mert ha van, akkor azt megoldja seperc alatt a csoport, ami magába tömörít több 100 vagy 1.000 kiválónál-kiválóbb programozót a világ minden pontjáról.
Ne piaci értékrenddel közelíts. Itt arról van szól, hogy pénzorientáltságtól függetlenül építünk egy alapot, amire aztán mindenki építheti a megoldásást, amiért pénzt kér(het).
Egy nagy közösség van, ami
Ki vezeti ezt a közösséget?
Ki dönti el, hogy ki kerülhet be ebbe a csapatba?
Ha egy megoldásról megoszlanak a vélemények, hogyan dől el, hogy melyik lesz kivitelezve?
Hogy jön ide a pénz? Én egy szóval sem beszéltem pénzről.
Senkinek nem lenne senki
A technológia egy másik kérdés, most arról nem beszélünk. Ha más kódbázist kíván meg az ARM rendszerrel üzemelő mobil, mint az x86-tal üzemelő, akkor lesz két különböző kódbázis, de 100%-ban azonos algoritmusok futnak le a háttérben. Ez ma nem garantált, ebből van a mérhetetlen nagyon szopás a webfejlesztésben (is).
Senkinek nem lenne senki
Mi a közös érdek? Úgy gondolod, hogy mindenki érdeke ugyanaz? Hogy különböző embereknek nincsenek különböző igényeik?
Kénytelenek vagyunk.
Ugye tisztában vagy vele, hogy ez lehetetlen? Márpedig két különböző kódbázissal ugyanott tartasz, ahol most, hogy nem lehetsz biztos a megjelenésben.
Mi a közös érdek? Úgy
De ez már messze vezet, gondolataim a spiritualitásból táplálkoznak, aki pedig ezen értékrendet nem tudja magáénak vallani, soha nem fogja megérteni az irányt, amerre én nézek...
A technológiai kivitelezést
A technológiai szakemberek pedig erre ingerülten kezdenek beszélni csalán és nemiszervek vonatkozásában :)
Vannak elméleti és nem
Az elméleti és alkalmazott
Néhány évvel idősebb vagy nálam, Norbi, de úgy érzem, hogy úgy gondolkodsz, mint én pont ugyanennyi évvel fiatalabban.
Ha jobbá akarod tenni a világot, akkor először el kell fogadd, hogy hogyan működik.
Az, hogy fizikia minőségem
Én a távolba tekintek, olyan messzire, ahova a legtöbb ember nem képes. Ez a mindennapi életben is jelen van. Amikor megkeresnek egy projecttel, ők még csak az ötletet fogalmazzák meg, én már azonnal látom, hogy hova juthat el 1-3-5 év távlatában, azonnal megfogalmazon a nagyobb léptékű összefüggéseket, kapcsolódási pontokat (mit lehet kihozni a projectből, amire az ötletgazda nem is gondolt; pl. társadalmi szerepvállalás témaköre, pedig ő pénztermelő gépezetet építene).
Nem dolgom a múlttal és jelennel foglalkozni, én az vagyok, aki a távoli jövőt alapozom. Fény vagyok az éjszakában, de ezt sokan nem értik tudasan, de azt a pozitív energiát, amit közvetítetek, tudattalanul is felfogják, beépítik. Számos visszajelzést kaptam már ezzel kapcsolatban.
Megosztó vagyok, gondolataim, nézeteim is azok, közlésmódom kritikus, biztosítékot kicsapó. De ma már látom, hogy ez is az egyik feladatom, hogy piszkáljam az embereket, hogy a komfort zónából kilépjenek. Van akit ez nagyon irritál és nem történik semmi, van akinél elindítja a folyamatot, mert már kellően készen van.
Példaként a Mátrix trilógiát tudom hozni. A való életben (ami virtuálisabb, mint azt a legtöbben gondolnák) éppen az történik, mint a filmben. Egy kis (de egyre növekvő) csoport azon dolgozik, hogy minél többen ébredjenek. A gát már átszakadt, a nagy(nak tűnő hatalmi) rendszer nem képes már visszatartani az új kor eljövetelét. A kérdés csak az, hogy mennyi időbe telik az új világ megteremtődése.
Nem dolgom tehát azzal foglalkozni, hogy mi van, mert az a múlt következménye. Én itt és most a jövőt alapozom... Szoktam volt mondani: nem érdekel, hogy mi van, csak az, hogy mi lehet(ne).
Azt hiszem, Ádám említette
Aki valamennyire is
Idézet a wikiszotar.hu-ról:
Nem látom be, hogy miért jobb
Nem látom be, hogy miért jobb
Úgy gondolod, hogy a szabad verseny nem jó?
Azt gondolom, hogy a szabad
Megdöbbentő, hogy negyven év
Őszinte leszek, nem
Egy dologban hiszek: összefogás, értékteremtés.
Az összefogásra ékes példa volt 1,5 éve a március 15-ei hóvihar. Megmozdult az ország, csak azóta ismét elfelejtették, hogy mit és hogyan csánáltak...
Értékteremtés pedig az, amikor valami jobb lesz, mint volt, több ember fér hozzá dolgokhoz, egyszerűbb, minőségibb az élet, stb.
Az egy render engine mind a böngészőgyártók életét, mind az enegine fejlesztők életét, mind pedig a frontend fejlesztők életét megkönnyítené. Előbbi csportnak nem kellene erőforrásokat allokálni az engine-ekre, második csoport fókuszálhatna kizárólag az engine-re, az utolsó csoport pedig szabvány szerint ír kódot, és ha nem teszelni böngészőben, akkor is 100% biztonsággal tudja, hogy a kódja azt csinálja, amit csinálnia kell.
Őszinte leszek, nem
Furcsa, mert szinte csak politikai hozzászólásaid vannak.
A politika az emberi történelem meghatározója, a történelem pedig az élet tanítómestere. Én ajánlom, hogy kezdd el tanulmányozni, és biztos vagyok benne, hogy felül fogod vizsgálni az emberekről és a társadalomról alkotott nézeteidet.
Utópiákról álmodsz, és a történelem megmutatta, hogy valahányszor emberek nekifogtak egy utópia megvalósításának, jó esetben nem lett belőle semmi, túl sokszor pedig a legsötétebb disztópia vált valóra.
Az a baj, hogy a
A politikára az emberiségnek nincsen szüksége. Ma még jelen van, de már haldoklik...
Fogalmazzunk úgy, hogy nézeteim túlmutatnak az átlagember nézetein. Ez volt itt, és máshol az utolsó ilyen jellegű megnyilvánulásom. Az utóbbi évek során elég feedback-et kaptam, látom, hogy értékrendemet nem kell, nem is tudom megvitatni másokkal (mármint a nézeteimet nem értőkkel). Tennem kell, mit érzek, hogy dolgom tenni, és teszem mindezt a legtisztább pozitív, segítő, építő, teremtő energiából táplálkozva.
Az a baj, hogy a
Nem én azonosítom, a gondolataid politikai gondolatok. Amikor véleményt nyilvánítasz arról, hogyan kellene működjön a társadalom, akkor politizálsz.
Az, hogy politizálsz, ezt nem zárja ki.
Remélem, hogy nem, mert anarchiának hívják azt az állapotot, amihez a halála vezet.
Mindig veszélyes, ha úgy érzed, hogy a gondolataid túlmutatnak másokén, és ha vitába szállnak veled, az azért van, mert nem értenek. Lehet, hogy tökéletesen értenek, egyszerűen csak nem értenek veled egyet. Persze, lehet, hogy tényleg neked van igazad, de ne felejts el kételkedni benne.
Ezen túl a leghelyesebb valóban az, ha teszed, amiről úgy gondolod, a legjobb – csak néha vizsgáld felül, amit teszel, mert csak egy életed van, és szar dolog túl későn jönni rá, hogy a grál valójában sosem létezett. (A felülvizsgálás vonatkozik az életek számáról alkotott véleményre is. Just in case.)
Remélem, hogy nem, mert
Folyton megteszem, hogy megkérdőjelezem a saját nézeteim valódiságát. Aztán amikor elfeledek minden gondolatot, ami valójában ítélkezés, akkor ha békét érzek belül, jó úton vagyok. A belső visszajelző rendszerem (pl. intuíció) azt súgja, hogy jó úton játok. Ami pedig az életek számát illeti, nem hiszem, érzem és tudom, hogy nem egy van. (Minden energia, így hát mi magunk is. Az emberi létforma csak egy ruha, a lélek ruhája, azért, hogy meg tudja tapasztalni milyen az anyag.)
hangoztassa
Mindkét oldal mellett lehet pro és kontra érveket felsorolni. Múltkor olvastam egy cikket, majd megkeresem és beküldöm blogmarkba, hogy 2014-re eljutottunk odáig, hogy a böngészők a szabványokat eléggé hasonlóan értelmezik, azaz ugyanaz a kód nagyjából ugyanúgy néz ki minden böngészőben. Innentől kezdve legfeljebb sebességben és kezelhetőségben van a legtöbb eltérés (bár a mai minimál UI-k mellett még itt se nagyon), és ennyi erővel lehetne akár egy motor is.
A másik oldalról nézve a verseny is jó, például múltkor olvastam, hogy Raspberry Pi-re hoztak ki Epiphany alapú böngészőt, márpedig az a hardver nagyon sovány.
Ez azért sérti a fülemet :
Együttérzek. De kötőmódnak hívják :)
Nyelvész, grammar-nazi, szóval offtopic
A "... van aki ..." helyett szerintem inkább "... legyen aki ..." kellett volna.
Persze ez csak érzés, helyesírási szabályzattal nem tudnám alátámasztani. Az általad használt szerkezetbe inkább a "hangoztatja" illene. Szerintem.
(jelzem, nem is oly rég mondta "tudjukki" :D, hogy itt munka alapú társadalom lesz, ha beledöglünk - ő nem, csak mi - is ;) )
Most tényleg? Kísérjétek ki
– Halottvirrasztáskor
– Gróf Zichy Jenő levele gróf Károlyi Gyulához. Nemere. 1879. 65. sz.
– Mikszáth Kálmán: A kultusz-tárcza. Országos Hirlap, 1898, 55. sz.
– Zoványi Jenő: A világ vallásai. Nyugat, 1927. 23. sz.
– Bazsányi Sándor: Mi is az, hogy humor? Alföld, 1996. 5. sz.
Mondom: értem, mit akartál,
Legalábbis XX., XXI. századi nyelvben nem jellemző. És ezt az idézeteid sem cáfolták.
Kötőmód?
Mindazonáltal lehet, hogy helyes, ahogy írtad, de egyelőre még gyanús.
Ellentmondás?
Kötőmód?
hangoztassa
Igaz
Nyilván nem felszólító
Kötőmód?
Igen
Annyit írnak, hogy az ige melyik módját (tehát alakját) kell használni bizonyos esetekben. Mivel nincsenek saját alakjai a különböző kötőmódi eseteknek (mert egybeesnek jobbára a felszólító és feltételes móddal) ezért ezeken a nevükön említik a használandó alakot.
A függő beszéd második példamondatában is felszólító módban szerepel az ige, mégis kijelentő a mondat.
Idézet a Nyelv és Tudományból (kiemelések tőlem):
Kötőmód?
Igen
Folytatom az idézést a nyestről az első idézetemnél (más kiemeléssel):
A megdöbbentő szerintem probléma nélkül beleillik az értékelő csoportba (olyan szinten biztos, hogy megengedje a kötőmódot, ha nem is követeli meg).
De a bizonytalanság is fellelhető benne a beszélő szempontjából. Egy másik cikkből:
A kérdéses mondatban a bizonytalanság a tényállás beszélő szerinti valószinűtlenségéből fakadhat (ha egyáltalán szükséges ez; bár ez a bizonytalanság dolog szerintem inkább csak iránymutató a kötőmód felismeréséhez - a cikk jellegéből fakadóan).
Illetve itt van még egy írás arról, hogy a kötőmódú tagmondatos mondatnak nem kell szükségszerűen sem felszólítónak, sem bizonytalannak lennie.
Köszönöm.
Hogy stílusos legyek: örömömre szolgál, hogy vannak, akik elsőre átlássák a dolgokat.
Nem kötőmód.
Cserébe H.Z. kollegának igaza van abban, hogy ha Ádám úgy fogalmazott volna, hogy "Megdöbbentő, hogy negyven év szocializmus után még mindig legyen, aki pont ugyanazokat a gondolatokat hangoztassa." Itt a "legyen" már nem konkrét, mint a "van", mert benne van, hogy nincs senki (aki azokat a mondatokat hangoztatta volna).
A böngészők között azért
Ha már politikáról van szó, a szabványkészítés maga is aktív politikai terep, a nagy cégek képviselői a saját (céges) érdekeiket próbálják meg érvényesíteni, egymást fúrják. Kiváló példa erre a Microsoft-féle pointer events, amiben egyesíteni szerették volna az egér és az érintőképernyős vezérlés eseménykezelését, ami jelentősen leegyszerűsítette volna a fejlesztők munkáját, de ezt a Google nemrég megfúrta, és már nem támogatják.
A CSS ajánlása tele van
Bocs, Gábor, de mégis hogyan jutsz ilyen következtetésekre? Úgy gondolod, hogy az Internet Explorer, a Firefox, a Safari és a Chrome/Opera (nemrég a perjel még eggyel odébb volt) azért használ különböző renderert, mert úgy gondolják, hogy más a helyes default font-size?
És ezek mind konvencionális böngészők, amik így vagy úgy, de C-ben íródnak. Mi van, ha valaki más nyelvű környezetben dolgozik? Mi van ha egy beágyazott rendszerről beszélünk?
A szabványosítás pedig természetesen politika, erről a magyar szabványügyi testületben az elmúlt években szerzett tapasztalaim alapján kellően gyomorforgató tapasztalataim vannak.
Ha a szabvány minden esetben
Jelenleg egy dolognak köszönhetjük a különböző böngészőmotorok létezését: a kis keresődobozénak, mivel közvetve ezen keresztül jutnak pénzhez a fejlesztők.
minden, azaz minden eszközön,
Ugye az eszközöknek különböznek a képességei, ezért nem láthatom ugyanolyannak a kimenentet. Különbözik a képernyő mérete, felbontása (valós és virtuális), színek száma (16 szinű e-Ink, 48-bites professzionális kijelző). Ezen kívül különbözik a beviteli forma (érintés, egér, billentyűzet, stylus, távirányító, gamepad stb.), ami szintén befolyásolhatja, hogyan kell megjeleníteni a tartalmat.
Mert hiába nézem én Full HD kijelzőn a weboldalt, ha az eszközöm egy mobiltelefon, egy PC monitora, egy tablet, egy TV, mindehol másként illik megközelíteni a kérdést, mert máshogy fogyasztom a tartalmat.
Itt az lenne a lényeg, hogy
XHTML
Már korábban írtam inf3rnonak, akkor fog bármi igazán szemantikus elterjedni, ha ugyanolyan faék egyszerűségű lesz, mint a HTML.
Addig még megyegetett a
Nem, épp ez az, hogy nem ment.
Minél jobb eszközöket adsz a
Milyen kutatás támasztja alá, hogy a felhasználóknak mindennél fontosabb a hatékony keresés?
Ami meg a Flasht (Silverlight, stb.) illeti, a puszta létezése és népszerűsége is azt mutatta, hogy igen komoly problémák vannak. Ha a web komolyan akarta venni magát, lépni kellett valamit.
Ok, tegyük félre a
Tegyük fel, hogy komoly. Az
Hidvégi Gábor véleménye itt épp annyira nem lényeges, mint bamegakapáé. Mi valószínűleg mindketten szeretnénk hatékonyabb keresést.
Tegyük fel, hogy komolyEz
Ha megnézed ezt a statisztikát, akkor láthatod, milyen mértékben nő a website-ok és az internet felhasználóinak száma, de a legfontosabb oszlop a táblázatban a felhasználók száma per website: 2013-ra oldalanként csak 4 látogató jut. Ez azt jelenti, hogy az interneten lévő mérhetetlen (és egyre inkább növekvő tömegű) információ egyre kevesebbekhez jut el.
Következmények:
1, a site-ok tulajdonosainak egyre többet kell költeniük marketingre
2, cserébe a site-ok fejlesztésére arányosan kevesebbet tudnak költeni, azaz idővel csökkenni fog a te fizetésed is
Ez az ára a kényelmes fejlesztésnek, amit neked kell kicsengetned. Ezért kellett volna a keresés hatékonyságát növelni, hogy az általad létrehozott website-on lévő információk eljuthassanak a célcsoporthoz.
Ez engem nem elégít ki
Még fontosabb: egyáltalán képesek lennének-e az amúgy is techanalfabéta, de mesterségesen még tovább butított felhasználók (a 92%, akik elől mindent gondosan elrejtünk, ami bonyolultabb egy faéknél) keresni? Képesek lennének-e bármilyen, gép által értelmezhető formára hozni az agyukban feltoluló, maguk számára is alig értelmezhető igényeket és gondolatfoszlányokat? Lehet készíteni egy rendszert, amivel a 8% (egyszerűség kedvéért használjuk ezeket a számokat), akik jelenleg is nagyrészt megtalálják, amit keresnek, gyorsabban és hatékonyabban jutnak információhoz, de ugyanitt lennénk, a 8%-nak dolgoznánk (ami ugye, mint megbeszéltük, pazarlás). A probléma az, hogy a 92% jellemzően kérdéseket sem képes feltenni, ami sokkal fontosabb képesség, mint gondolnánk.
Abból, hogy az embereknek
Vegyük az egyszerű dolgokat, például lakás. Mivel nem szöveges információról van szó (tudom, hogy mekkorát szeretnék venni, mennyi pénzem van rá, és hogy helyileg hol legyen), a google és a többi szöveges kereső azonnal elbukik. Ilyenkor nincs más választásom, végig kell nyálaznom n darab ingatlanos site-ot, ha meg szeretném találni a számomra megfelelőt. Ahogy az internet nő, egyre több időt kell eltöltenem a keresgéléssel.
Könnyebben megfogható termékeknél és szolgáltatásoknál egyre népszerűbbek a gyűjtőoldalak, mint például az árukereső.hu, de van ilyen biztosításokra szakosodott site is. Viszont ezeket nem feltétlenül találja meg minden oldaltulajdonos, vagy esetleg nincs is pénze a havidíjra. Innentől kezdve az idő előrehaladtával egyre kevesebben fogják megtalálni az oldalát.
Nehezebben megfogható dolgoknál, mint például útleírások blogokban, ahol még ilyen gyűjtőoldalak sem nagyon léteznek, még rosszabb a helyzet.
Ebből következik, hogy minél több időt töltünk magunkkal (a kényelmes programozás fejlesztésével, szabványosítgatással), annál több pénzt veszünk ki a megrendelőink és a magunk zsebéből, és annál inkább pazaroljuk az internet használóinak idejét.
Megint arról a részről
Szerintem hagyjuk az egészet, csak millióegyedszer is leírjuk, ami már milliószor leiratott itt, körbe-körbe rohangálva.
Ez célközönség függő is
ettől függetlenül arra még
El vagy tévedve ezzel kapcsolatban.
Csak néhány a létező megoldások közül.
Ha már URL a téma...
Adott két, találomra kiválasztott URL:
http://www.portfolio.hu/vallalatok/norbi_a_hu_az_komoly_kategoriaba_akartam_kerulni.203457.html
http://www.edigital.hu/Kartyaolvaso/Kingston_MicroSD_Reader_G2_kartyaolvaso-p405043.html
Mindkettő esetén látszik, hogy gyúrnak a szépnek ható URL-re, de ott egy kód is. A „legszebb” a dologban, hogy ha átírom a kód mellett lévő szöveget, mindkét URL működőképes marad, az ID miatt ugyanazt a tartalmat kapom (nem pedig 404-et).
Ha a kereső megeszi a szép(nek ható) URL-eket, és valamilyen formában ez alapján súlyozza a találati listát, akkor ezzel a megoldással kb. tökönlőtték magukat ezek a site-ok...
Redirect
ezzel a megoldással
A probléma az, hogy ezzel a
Nem értem, hogy miért kellene
A tökönlövés részét nem igazán értem, kifejtenéd?
Lásd 94-es hozzászólásom.
A másik kérdésben pedig lásd 94-es hozzászólásom.
Nem az, ha kiteszel egy
főleg nem egy konkurens
Vegyük úgy, hogy nem
A lényeg, hogy ez szerintem logikai hiba, system error, én biztosan nem engedném. Ha másnak nem gond, azt persze elfogadom.
Egyébként sem valószínű, hogy
De ha csak az elvi részét nézzük, akkor is minimum redirect-elni kellene az eredeti és egyetlen URL-re, mert az én nézőpontom szerint domain-en belül egy adott tartalom csak egyetlen címen legyen elérhető.
Ahogy már említve lett,