// upozorenje: dugačko, smoreno i ne preterano pametno.. slobodno preskočiti, osim ako baš uživate u textovima gde se "standardi" pominju 40+ puta.. ;)
Citat:
ivanhoe:
slazem se 100%, i nije mi ideja bila da kazem da je bolje da nema standarda, nego da su pojedini standardi loshe osmisljeni...ne generalnio , nego razne sitnice...
pa pazi.. nisam ni ja tvrdio da je svaki standard idealan.. i njih pišu ljudi, a ljudi greše..
uz to, standardi uglavnom predstavljaju "lowest common denominator" između dve implementacije iste/slične tehnologije, tako da i po definiciji teško mogu da budu nešto "epohalno", "genijalno" i slično..
ono što je epohalno i genijalno oko standarda je da lepo možeš da uzmeš pročitaš standard, i odradiš posao.. bez proučavanja dokumentacije svakog mogućeg vendora (konkretno browsera), i
naročito bez isprobavanja rezultata u svakoj mogućoj implementaciji koja se ikada pojavila na tržištu..
na žalost, (neki) standardi nisu još ispunili to obećanje, ali smo generalno na dobrom putu, bar dok se većina nas bude trudila da tamo i stignemo..
Citat:
naveo sam par stvari, a sad mi je palo na pamet i jos nesto recimo sintaxa za CSS koja se razlikuje od svih ostalih sintaxi na ovom svetu kad je u pitanju upotreba - i _ . Zar ne bi bilo mnogo logicnije da su napravili sintaxu slicnu recimo javascriptu, pa da mozes da imas ista imena propertija i u javascriptu i u CSS???
prvo, JS nije bio mnogo bitan kada su projektovali CSS, a ionako postoji lepo jedan-na-jedan preslikavanje između imena CSS i JS osobina..
uz to, ne znam koje si sve to sintaxe "na ovom svetu" ti u životu radio, ali CSS baš i nije nešto naročito jedinstveno po tom pitanju.. uz to, mogu i da pretpostavim zašto je odabrana crtica za razdvajanje reči..
// ovo odlazi offtopic, i možete ga slobodno preskočiti.. a i ne zasniva na ničemu sem na mom pukom "pogađanju", mada više kao "educated guess"
naime, CSS je pravljen (primarno) za HTML, koji je case-insensitive, pa bi npr bilo malo glupo da jedan deo CSS jezka (selektori koji pominju imena tagova) bude case insensitive, a drugi (osobine) da bude case sensitive..
tako da su odabrali case-insensitive, ali su morali da smisle način kako razdvajati reči u imenima osobina, jer za razliku od HTMLa, gde su imena tagova uglavnom samostalne reči (ili čak slova), CSS ima mnogo osobina tipa border-top-width.
a možda je i stvar ukusa, ali meni je to čitljivije nego bordertopwidth ili pak BORDERTOPWIDTH. naravno, ti ćeš reći da je moguće pisati i borderTopWidth, ali pošto je case-insensitive, neko bi pisao i na prva dva načina, a ja bi to morao da tumačim kada bih radio na sajtu sa njim/posle njega..
znači, da ne davim, zaključak je da za većinu odluka postoji (bolji ili gori) razlog, a to što ga ti ili ja ne znamo, ne čini ga ništa manje validnim..
(neka me neko pita zašto je XML case-sensitive, što se meni lično ne sviđa, ali sam naknadno naučio da itekako ima smisla..)
Citat:
pa ja upravo i kazem da su ta PRAVILA osmisljena ako ne glupo, onda sa dosta propusta...sto ne znaci da XML nista ne valja, XML je jako zgodna stvar...ja se samo bunim oko onoga sto mi pravi realne probleme u radu...to sto je nesto "standard" ne znaci da je strogo zabranjeno razmisljati o tome da se promeni na bolje ako postoji prostor za tako nesto...izvini ako tebe to pogadja na bilo koji nacin :)
a ja ponavljam, to što ti ne znaš razloge koji stoje iza nekih PRAVILA ne znači da oni ne postoje..
takođe, ako ti se jedan standard (XML) ne sviđa, a ti si slobodan da koristiš bilo koji drugi (SGML?). to je i jedna od
lepota standarda, što ih ima toliko
mnogo..
i naravno da me ne pogađa diskusija o ovom (ili bilo kojem) pitanju, nego si baš našao da diskutiješ o nečemu (xml) u šta se ipak bar malo razumem.
Citat:
Zato sto je neko tako smislio u standardu....pretpostavljam da se radi o resenju koje ili uproscava implementaciju parsera ili omogucava bolju kontrolu gresaka...ali zato ako hoces da u atribut nabijes komad js koda recimo onda treba da pises nesto tipa: if(a<5 && b<4){...}
Vrlo pregledno i ocigledno, idealno za konfiguracione fajlove...:)
Po meni je to cist za*** u osmisljavanu specifikacije... trebalo bi da se sve sto se nalazi u atributima uposte ne parsira od strane XML parsera, jer to i nije njegov posao...
xml parser mora da parsira i vrednosti atributa, zbog entiteta koji se mogu pojaviti unutra..
// sledi malo skretanje u istoriju XMLa, slobodno preskočiti ako smaram..
naime, xml je nastao kao uprošćavanje SGML formata, ali uprošćavanje ne u smislu da ga je lakše "koristiti" ili "pisati" (ručno), već da je lakše napraviti parser/generator za XML. jedan od ciljeva XMLa je bio da svaki prosečan BSc student CSa može da sklepa XML parser za (valjda) jedan dan (u suštini, dovoljno je osnovno poznavanje CFGa).
(mada i za (ručno) pisanje XMLa postoje vrlo prosta pravila. treba eskejpovati samo 2 (i slovima
dva) karaktera, a to su < i " sa < i "e;)
a iako ću se složiti sa tobom da je xml savršeno mogao da ima i formalnu gramatiku koja bi dozvoljavala korišćenje < unutar vrednosti atributa, to bi zakomplikovalo parser, jer ovako znak < skoro uvek (sem u par spec. slučajeva) označava početak novog taga..
ali recimo, zašto stati tu? zašto ne dozvoliti i vrednosti atributa
bez navodnika ako ona ne sadrži spejs, ili čak ako atribut prihvata samo numeričke vrednosti (što je vrlo čest slučaj). znaš li koliko bi bilo lakše pisati kod tipa: <element width=7 height=20 itd=..>
i kada kreneš tako da razmišljaš, vrlo lako stigneš do SGMLa (nisam ga džabe pomenuo malopre), formata koji je nesumnjivo mnogo moćniji od XMLa (npr, koji dozvoljava sve ovo nabrojano, i još mnogo toga), i koji je postojao decenijama pre XMLa, ali koji je bio toliko obiman, komplikovan za parsiranje i skup za implementaciju, da nikada nije doživeo širu primenu (izvan vladinih organizacija i ultra-velikih kompanija), i za koji ti verovatno ne bi ni čuo, da nije "reinkarniran" u vidu XMLa..
znači, poJenta je (opet): iza ovih standarda uglavnom stoje ljudi koji su dosta pametni (bar pametniji od mene), i iza svake odluke i pravila stoje neki razlozi, i mada ja verovatno ne mogu da znam (a tek razumem) baš svaki razlog, generalno nastojim da im verujem da to što su osmislili ima nekog smisla..
(a nekada se dešavaju i baš gluposti, tipa da IETF ne može nešto da proglasi RFC standardom dok ga ne implementiraju bar dva nezavisna vendora.. tako su neke (prilično korisne) stvarčice izbačene iz HTTP/1.1 standarda, jer ih je implementirao samo Netscape (ali ne i IE))
Citat:
currentStyle jeli nije po "standardu"....kao ni parentLeft, mada ga svi podrzavaju jer je praktican i masovno koristen...a za DOM3 getComputedStyle skidam kapu to je prava stvar...ali to je DOM3, sto znaci da je falio u DOM1 i DOM2...dakle da preformulisem tvrdnju standardi su BILI glupi :)
// prvo da se malo ispravim, getComputedStyle() je deo DOM level 2..
ne, opet si mašio pojentu.. ni jedan standard niti pretenduje, niti može da reši sva moguća (a tek buduća) pitanja.. standard nastaje tako što se prvo uočava problem koji zahteva rešenje.. onda se lepo striktno definiše koji problem jedan standard rešava, i pristupi se mozganju kako to učiniti najbolje pod datim okolnostima..
sledeći korak u životu standarda je implementacija istog, pa zatim korišćenje/primena.. i tek u ovoj poslednjoj fazi se mogu uočiti baš sve dobre strane, kao i nedostatci jednog standarda (kojih neminovno mora biti, jer kao što rekoh na početku, i standarde pišu ljudi).
zato je logično da posle određenog vremena može da se osmisli nova verzija standarda, ili pak potpuno novi standard ako je problem totalno nov i nije logički nastavak već postojećeg..
(kao taj primer sa computedStyle, koji je faktički "izmislio" MS, ali na žalost implementirao na svoju ruku, tj nije konsultovao konzorcijum da to pretoči u standard)
Citat:
Logicno je da ce se vremenom iskristalisati standardi koji ce biti stvarno ok...ja sam se samo bunio oko toga kakvi su sad...
ne, logično je da će vremenom standardi rešavati sve više i više problema, i da će neki u tome biti više ili manje "ok", ali ni jedan standard nikada neće biti "stvarno ok" u smilu da će rešiti/zadovoljiti sve (tvoje) probleme/potrebe..
Citat:
recimo(kolko je meni u znanju) ne postoji elegantno reseno kako da ubacis veci komad HTML -a odjednom u stranicu (kao sa innerHTML)...mozes jedino da ubacujes node po node, sto je kranje glupo kad browser vec ima ugradjen parser koji to ume lepo da pretvori u DOM...samo se pravi dupli posao za programera...
ne, nije standard loš zato što ne rešava neki problem, već baš obrnuto, on je dobar zato što rešava neke (druge) probleme. neke stvari ne znaš unapred da će ti trebati dok ne počneš da koristiš neki standard, i dok ti faktički ne zatrebaju (MS je shvatio potrebu za innerHTML
nakon kreiranja DOM standarda).
nemoj da me držiš za reč (nisam baš stigao da u detalje proučim DOM level 3), ali sam prilično siguran da tvoj problem rešava baš ovo
http://www.w3.org/TR/2004/REC-...l#LS-LSParser-parseWithContext (mada ćeš verovatno morati da prostudiraš i ostatak tog dokumenta).
(inače DOM Level 3 load and save modul je (bar delom) implementiran u mozili)
očigledno nisi shvatio moju alegoriju "ovaj XML ne valja jer ne ume da čuva decu", tj ne postoji "magic bullet" koji rešava sve probleme, a i da postoji, on se sigurno ne nalazi među standardima. najbolje što se možeš nadati je da ti (jedan) standard reši jedan (ili deo) problema.. sve ostalo je iluzorno očekivati od bilo čega, a naročito od standarda..
standardi nastaju kada potreba za nečim postane očigledna (knpr ovaj ekvivalent innerHTML-a). očigledno za APSOLUTNO sve što je tebi do sada zatrebalo VEĆ POSTOJI standard (to što ti toga nisi svestan ne menja situaciju), tako da ne znam na osnovu čega kukaš na standarde.. ako već hoćeš, bolje kukaj MSu da ih konačno implementira u IE..