Нищо ново няма по света де, едно време същото се казваше за desktop приложенията – “аз си мислех, че е много лесно”

Също така за групирането в един файл ползвам в Rails проектите sprockets / http://getsprockets.org/ / което много ми помага при менажирането на js кода. За PHP проектите ползвам това http://gist.github.com/212303

Специално за зареждане на javascript Стоян Стефанов има много добър пост http://www.phpied.com/javascript-loading-strategies/ ( част от серията му постове преди Коледа )

Самия regex е ултра прост и е сигурно 20 реда с коментарите.

Важи същото и за скриптовете, макар аз самия да предпочитам да са впълния си вид, че ако ми се налага да дебъгвам нещо на live сайт си е ебало майка.

Междудругото съм върл привържаник на твоята теза, че с паралелните връзи (parallel connections) вече не е задължително всичкото скрипт да стои най накрая. Би било добре, но не е задължително. Най-малкото един Bootstap ще ми се наложи да набухам в хеда.

Пък за дизайнерите и filter — само в екстремни случаи и то вероятно автоматизирано с JS Поне дотам се пораснали във фирмата, че да убеждаваме клиентите в превъзходството на пълноцветното PNG пред GIF.

Аз предпочитам да го правя с условни коментари.

Относно мачкането на CSS – не вярвам да си пишеш файловете на един ред без нито един интервал. Също не намирам за удобно преди да кача нещо на сървъра, ръчно да минавам да трия интервали и нови редове. По-лесно е това да става с един шел скрипт или като част от build-прцедура заедно с мачкането на JavaScript.

За кратката форма на font – мдаа, и на мен не би ми харесало да отнесе line-height. Не съм забелязал yuicompressor да чупи височината на реда, ще тествам специално.

А, бях забравил и за JavaScript в края на документа. В повечето съвременни браузъри изтеглянето на скриптове не блокира зареждането на останалите елементи от страницата, но се изпълняват в последователността, в която са в документа. За това вече не е толкова важно да се поставят на края на документа, аз лично си ги слагам в head. Проблем са естествено inline скриптовете, особено, ако правят document.write(;<script…, тогава става страшно!

Хаковете за ИЕ за доволно малки, даже бих казал пренебрежително малки и не всяко нещо се пише по два пъти. Обикновено е едно нещо min-height: 0; _zoom: 1; и рядко друго нещо такова. Предвид, че deflate търси повторения теглото, което се добавя е малко.

Защо му е на човек да прави различни стилове за ИЕ не мога да разбера, но за целта на спора ще приема, че му трябва. В такъв случай съм съгласен, че условните коментари биха свършили работа. Само че аз би го решил със снифене за accept хедър, а не с условни коменари. Много по-елегантно и не се генерира излишен HTML.

За компресиите… Нека само за секунда се замислим — при положение, че сам си пиша ситловете, дали ще ми се случи да има дълга форма вместо къса, освен ако не е умишлено? Не. Този тип компресори за хора, които нямат изградени навици.

Допълнително, ако видя някой компресор да ми направи кратка форма на font просто минавам и го бия през ръцете. Защо? Защото кратката форма нулира line-height и я връща към подразбиращата за браузъра т.е. между 1.3 и 1.4 мисля.

Което ме връща в изходна позиция (предвид, че имам навици при писане на ЦСС) — когато се прави заявка към ЦСС и сървъра е в release режим, чисти интервалите и прочее гадове и по-добра компресия няма.

За малко да забравя.. точно защото deflate търси повторения, има много голямо значение как ще си подредиш стиловете. При малък фаил от (примерно 100-на ред т.е. около 10-20 правила) кирията беше около половин кило(байт). При по-големи файлове разликата отива към кило и нещо две. Ето на това му казвам аз компресиране

Междудругото, за писане на ЦСС можем си чешем езиците мноооого дълго време. Ти само дай тон за песен.

@Радослав — тая сесия много бързо изтича.

Когато стиловете за IE са в отделен файл, поставен в условен коментар, файлът се тегли само от IE, за остналите браузъри е просто коментар и не се отразява на зареждането на страницата. Допълнителната заявка за изтегляне на файла тежи само на IE. Освен това съвременните браузъри могат да отварят повече едновременни връзки – по подразбиране Firefox е ограничен на 6 към един хост.

Друга причина да предпочитам отделните файлове за IE, е че по-лесно да направиш съвсем различни стилове за IE. Не се налага да пишеш всяко нещо по два пъти (щото не става да сложиш хаковете са IE6 и IE7 заедно) и е по-ясно защо тези стилове са там.

Относно смачкването на CSS – най-добре е да ползваш някой инструмент за това. Аз предпочитам YUICompressor. А, и като говорим за намаляване на обема на файла, стигаме и до кратките декларации на свойства. Ясно е, че

padding: 1px 2px 3px 4px;

е доста по-малко от

padding-top: 1px;
padding-right: 2px;
padding-bottom: 3px;
padding-left:4px;

А според мен е и доста по-ясно.

@Иван за (-) преди време наистина ги предпочитах, и в контекста на css стоят по-добре. Но напоследък (_) по лесно се мапват в html/javacript контекста. Но това е малко като дали скобата трябва да е същия или на долния ред. Важното да е се избере единия вариант и да се работи с него (докато е полезен разбира се) за да не стават мазаници

Но си е въпрос на вкус

@Марио, човек ако знеш колко съм го зяпал монитора, ама с часове и кур не става от само себе си. Най-лесно клиентите разбират, че нещата не стават от само себе си, като им се направи аналогия с пари. Въобще парите са един много хубав пример / аналогия за всичко

Аз имах точно обратния проблем пък — че фронт-а не е скатавка.

Иначе си напълно прав, че винаги си зависи от конкретния сайт и от изискванията на клиента

п.п. Добре че повечето хора вече тотално са забравили M$ Frontpage

1) Абсолютно задължително е хаковете за ИЕ 6 / 7 да НЕ стоят в отделен файл. Проклетите браузъри имат пуснати смао 2 / 4 конекции и това още повече се забавят. Хаковете стоят в същия фаил, непосредствено под пропъртито, което хакваш с представка _ или * респективно. Ако ползваш -moz, -webkit и прочее представки, CSS така или иначе е невалиден. Приеми, че _ и * са представки за ИЕ, нещо като -ms, но специално за 6 и 7;
2) Да кажеш, че е добре да подреждаш стиловете по азбучен ред, е като да кажеш “добре е да подреждаш класовете в азбучен ред” — невярно. Много по-добра идея е да групираш пропъртита по предназначение. Само се запитай къде стоят font- и text- респективно;
3) За предпочитане са тирета (-) вместо подчертавки (_) в имената на класовете по ред прични.
4) Кратките селектори са утопия, която не съществува, освен в контекста на минималистичните сайтове. Важи и за кратките стилови блокове;
5) Колко е голям DOM / колко са вложени нещата зависи от самата страница, нейното приложение и целева група (демек браузър, с който отварят). Като ти дойдат Ройтерс и ти кажат “Ние имам един продукт, за който сме платили Х милиона пауна и той използва ядро ИЕ 5.5, така че сайта трябва да работи на него”, ще слагаш не само допълнителни wrap-ъри, ами и таблици;
6) За компресиране на CSS е достатъчно да се махнат всички ненужни коментари, интервали, табове и нови редова. Останлото идва от gzip / deflate;

Та така.

Виж прав си, че като видят клиентите Dreamweaver и вече си мислт “бахти колко е лесно” или “тез само ме мотат” и други мисли пръкнати из дълбините на съзнанието им…

Сега като се замисля за сигурността не съм писал, но там нещата са много дълбоки и мътни (за някои хора) а и аз исках само на за frontend страна да се съсредоточа.

Плюс че за мен web developer и frontend engineer са 2 различни професии, който може и да си покриват част от работата и функциите имат и доста различни неща на които трябва да се фокусират.

инче в статията си заложил основно на best practices, вместо да огромния брой на инструментите и целевите платформи – 5 браусъра по 3 операциони системи + поне 10 мобилни умни телефони … абе въобще абсолютна лудница :Д

иначе преди година писах нещо подобно и аз, но говорих за целия пакет – фронт енд, бакенд, архитектура и т.н. http://weboholic.de/what-is-being-a-web-developer.html