Întrebare despre ASP.NET

Având o oarecare experiență (și vârstă!), pot spune că am văzut multe. Cu siguranță nu tot ce se putea vedea (în materie de programare web, desigur), dar cu certitudine foarte multe.

După cum (probabil) știi, eu nu prea am legături prea strânse cu limbajele server side. Fie că e ASP.NET, PHP, RoR sau orice altceva, nu e pentru mine. Dacă din PHP mai înțeleg pe ici-pe colo câte ceva, fără prea mari probleme, pentru restul limbajelor trebuie să mă apuc să caut documentații pentru a putea face o modificare. Și nici măcar atunci nu aș fi sigur că fac ceea ce trebuie.

Așa, acum că am făcut introducerea, trecem la întrebarea magică :D

Lucruri Gratis este un site ce l-am prezentat în articolul anterior la exemple de „așa nu”, fiind „wrong on so many levels” încăt nu m-am obosit să-i fac o analiză mai amănunțită. (nu îi fac reclamă!)

Fiind scris în ASP, m-am uitat după o chestie ce am observat-o la vreo trei site-uri la care am lucrat în ultimele luni. Și există:

<body>
	<form action="URL" method="post">
		<!-- codul site-ului -->
	</form>
</body>

Tot site-ul este un formular imens. Asta așa, că tot vorbeam despre semantică! Evident, site-ul folosește js pentru a trimite formularele, prin urmare, nici vorbă de „degradare grațioasă”.

Întrebarea!

Întrebarea e foarte simplă: de ce se pune tot codul într-un formular uriaș? Care este avantajul?

Eu suspectez incompetența programatorilor. Tu?

Cod semantic și cod tableless

Chiar dacă a trecut mult timp de la buzz-ul cu renunțarea la tabele pentru designul unui site, am observat că încă sunt destui care nu înțeleg pe deplin acest … concept. Scriu acest post din două motive: am avut de curând un client (de fapt un intermediar) ce a cerut în mod express să NU folosesc tabele, chiar dacă datele erau tabulare și, mai deunăzi, m-a întrebat cineva pe messenger ce tag-uri ar putea folosi în locul table.

Wtf?! Tabele pentru design???

Dacă ești un pic mai vechi în domeniu sau ai avut tangențe constante cu dezvoltarea web, probabil ai observat că în urmă cu aproximativ 5-6 ani a început un adevărat jihad împotriva tabelelor. De ce? Pentru că un site era „modelat” pe un tabel uriaș în care erau inserate alte tabele, în care erau inserate alte tabele și tot așa, nefiind decât o limită a bunului simț în ceea ce privește nivelul tabelelor.

Avantajul major? 90% din browsere interpretau codul în mod identic (sau cu diferențe foarte mici). Desigur, asta se întâmpla când CSS-ul era ceva proaspăt, iar suportul în browserele momentului (IE 5.0/IE5.5/IE5 pentru Mac și Netscape 4) era la un nivel minim, făcând scrierea unui cod corect un adevărat chin.

Dezavantajele tabelelor se făceau simțite în diverse situații: persoanele cu probleme de vedere ce foloseau un screen reader aveau probleme în citirea paginii (un screen reader citește „cu voce tare” ce apare pe ecran), lățime de bandă consumată inutil (dimensiunea unei pagini cu tabele fiind considerabil mai mare; se spune că traficul – în kb – microsoft.com s-a înjumătățit după renunțarea la tabele pentru design ), întreținere greoaie (din moment ce nu se folosea CSS, stilizarea se făcea inline; atribute precum bgcolor încă mai există :D ) șamd.

CSS ce?

CSS-ul are avantaje din toate punctele de vedere, mai ales acum, când toate browserele oferă un suport cel puțin decent (da, inclusiv IE6!):

  • Trafic mai mic în kb (așa cum am zis mai sus. De ce? Majoritatea fișierelor externe (css, js) sunt descărcate o singură dată. După aceea sunt citite din cache. Desigur, cu mici excepții, în care utilizatorul/administratorul de rețea a setat browserul altfel. În plus, folosești mai puțin cod html.
  • Poți face rapid și foarte ușor modificări în fișierul CSS pentru tot site-ul.
  • Site-ul va fi mult mai accesibil persoanelor cu dizabilități.

Extrema!

Problema cea mai mare la css este următoarea: sunt mulți coderi care au sărit un pas. Acela în care învățau DE CE e bine să folosești css dar mai ales CUM. Prin urmare, au apărut tot felul de combinații: de la boldarea unui text folosind:
Citeste mai departe »

Weekend Links

Ok, postul de săptămâna trecută (cel în engleză) mi-a demonstrat două lucruri:

1) amestecarea limbilor pe același blog nu este o idee prea bună;
2) amestecarea limbilor pe același blog este o idee extrem de proastă.

Și asta din simplul motiv că derutezi comentatorul. Așadar, blogul va fi exclusiv în română. Sau în engleză, dacă mă voi supăra (ceea ce e puțin probabil). Așadar, iaca link-urile (mai puține decât săptămâna trecută) pentru weekend-ul ăsta:

Conversie PSD -> HTML

Chiar dacă nu îmi place rezultatul final, tutorialul reprezintă o resursă destul de bună pentru începători.

Fonturi!

Ce posibilități de a include fonturi proprii în pagini există? Păi… Sifr, Flir, Cufon, etc. Aici găsești o listă generoasă cu toate aceste metode, fiecare cu avantajele și dezavantajele sale.

jQuery

Știai că jQuery face 4 ani pe 14 ianuarie? Probabil nu, dar și mai probabil este că nu-ți pasă. Poate ar trebui să-ți pese, pentru că pe 14 ianuarie 2010 se așteaptă jQuery 1.4. Acesta va aduce:

  • $.require() – pentru a putea include alte fișiere js sau css fără probleme.
  • $.radioClass() – pentru a face mai multe elemente să se comporte ca un grup de butoane radio. Până acum trebuia să folosești un cod de genul $(foo).addClass('on').siblings().removeClass('on');.
  • Animații sincronizate
  • Noi event-uri live: change, submit, blur și focus
windows apple dropbox facebook twitter