HeadShot
Newbie-
Posts
26 -
Joined
-
Last visited
Content Type
Profiles
Forums
Calendar
Store
Everything posted by HeadShot
-
Не понял, о чём ты. Я пытаюсь представить, что ты там напилил за 2 года Да на самом деле практически ничего(( Это только цифра такая, а по факту я ничего там особо не делал. Понемножку тыркался периодически, да и всё(. Вот сейчас нужна помощь с текстом, например. Кинь линку посмотреть
-
Не понял, о чём ты. Я пытаюсь представить, что ты там напилил за 2 года
-
Сдается мне там нечто "Вах"
-
Мне разгребать не приходилось, но видеть — видел, конечно. А кто-то говорил, что технология сама по себе не допускает неправильного, неуместного или просто неумелого применения? Испортить можно любую идеологию. Если не понимать ее. То же ООП всегда правильно применяется и никогда не приносит проблем вместо решений? Значит ли это, что идеология плоха? Нет. Как бэ намекают на доступность, а не максимальный трэш, ради фана.
-
Выучить CSS и использовать БЭМ, ясное дело. Руку-то поднимете? )))
-
Что проще запомнить? Матрешку и потом пялиться на нее как в таблицу менделеева или выучить CSS? Что удобнее? Поставить класс в HTML или дописать CSS? Имхо, просто непонятное изобретение. Как это штука себя позиционирует? Как замена CSS или как оберка? Ладно, в случае с jQuery оно понятно и то не все принимают.
-
Оке, предположим, что у корпорации икс есть какой-то джедайский инструмент, которые все это делает. В таком случае, возможно, оно и к лучшему. В противном? (:
-
А ты его применял вообще, чтобы он тебе помог-то? Ага. Ровно столько, чтобы понять, что это не нужно. Возможно дело было в том, что фундамент делал другой человек и мне было ну очень не приятно в его code-style ковыряться. Делалось все руками(наследование, расстановка классов и прочее). Избыточность, запутанность и прочие нюансы, которые требовали постоянной уникализации. Собсно я понимаю, если проект большой и весь каркас с нуля. А если ты используешь какой-то фрэймворк с уже определенной структурой и начинаешь лезти со своим БЭМ, то получается далеко не всегда, то что надо. Так с нуля тоже проще свою методу по месту определить, чем брать вот это ассорти из чужих извращений(извините за резкость). Проще просто по тому, что в своем коде не заблудишься и свой стиль проверено эффективнее. Потому что он свой. Вот такие пироги. Но, если вы хотите в крупную компанию, например, Яндекс, то конечно-же с БЭМ вам придется подружиться. Не знаю, те же яйца, только в профиль. Все это локальные частности.
-
Поднаберитесь опыта. Руку то поднимете, о опытный? Я подниму. Но сказать, что БЭМ мне сильно помог, увы ...
-
Поднаберитесь опыта. Для кодера начального уровня, который не заботится ни о постоянной поддержке своих творений, ни о тестировании, ни о поддержании консистентности дизайна, ни о скорости разработки, данный подход выглядит действительно непонятно. Но каждый кодер, рано или поздно, приходит к аналогичному решению. Пусть со своими нюансами, но суть не меняется. Потому что это промышленный подход к разработке. Не стоит перекладывать свой опыт на всех и говорить за всех. Да, с точки зрения количества работы на начальных этапах этот подход более сложен. Но с точки зрения длительной его поддержки - он удешевляет стоимость разработки во многие разы. Для домашних страничек Василиев Пупкиных он избыточен. На всех никто не перекладывает. Почему не прислушаться к тем некоторым, которые говорят о лишнем? Все мы хотели\хотим в крупную компанию — это ведь не повод, верно?
-
Может я не прав, но мне кажется затея — фэйл. Единицы подпишутся это использовать. Сегодня как-то более востребовано оформление, а не варианты гридов и извращений с ними, ИМХО Это слишком концептуально извращено в положительном смысле слова. Люди не любят думать и усложнять себе жизнь.
-
Лютая ржака с этого топика Мне нравится эта метода с некоторыми своими коррективами: http://coding.smashingmagazine.com/2011/12/12/an-introduction-to-object-oriented-css-oocss/
-
Если найдешь, Iiyama ЭЛТ 22' Охренительный моник, с козырьком, с цвето-тестером. Чисто дизайнерская вещь. P.S. Правда прогрев занимает минут 10 Зато реально лучшие цвета, которые я видел. Из минусов - размер. Похож на этот - http://www.ixbt.com/video2/catalog-iiyama.shtml#hm204dt , тоже очень достойный аппарат, но не совсем тот. Взгляни на макс. разрешение А из ЖК тоже iiyama. Например такой - http://www.apitcomp.ru/shop/monitor_iiyama_prolite_b2712hds_b1_261022/ Стоит в районе 17.000 рублей. А как же глаза? ЭЛТ явно не способствует здоровью ):
-
Ммм... какой монитор стоит рассматривать как альтернативу маковскому?
-
вы, судя по всему, из з.п. выпали сразу с ровными руками(пояснять абрревеатуру видимо не надо, она вам ничего не скажет) все понятно ...
-
А мне выгоднее чтобы не стало оперы и ие, например, дальше что. по сравнению с чем? и да, хотелось бы знать вашу компанию, хотя бы по названию ... и пусть мне это ни о чем не скажет p.s.: хороший плевок в хабр
-
Это конструктор. Хочешь - собери гармошку, хочешь - пароплан. Все упирается в написание обработчиков. Сейчас подумываю сделать пример интерфейса с готовыми решениями, чтобы было интереснее исследовать код. Беря готовое решение разработчик обрекает себя на непонимание многих принципов, хотя и сокращает себе время первичной работы. Устоявшиеся паттерны могут быть ошибочными. Они как раз и приводят к часто распространенным ошибкам. Весь код jQuery вращается вокруг двух точек опоры: навешивании обработчиков на элементы по событию загрузки документа, и поиске элементов для работы. С одной стороны все выглядит вполне логично и понятно. Но как только потребовалось подгружать html автоматически на страницу, сразу потребовалось переписывать код jq, добавляя live-события. Что это значит для кодера? Что нужно еще больше следить за количеством элементов, которые выбираются в селекторах, иначе через время все будет еле-еле ворочаться. Кеширование сделать не получится ну вообще никак, это значит, что с ростом сложности селекторов и количестве функций, тормоза будут только расти. Паттерны, которые используются в SC - куда более распространены, чем те, которые используются в jq, потому что там используется событийная модель. jQuery в проекте даже не было, а событийная модель уже была. Самое смешное, но модель аналогичную SC можно построить и на jq, но это будет в пару раз медленнее. P.S. И я на критику не обижаюсь, потому что понимаю причины ее возникновения. Это полная чушь. Очень трудно написать такой код, который засыплет нафиг браузер на переборке или хотя бы даже как-то замедлит(никто не переворачивает дом тоннами). Нет предела совершенству и все такое, но на практике это обычно неактуально. Мне был был бы интересен SC или какой-то там мутулз если бы в этом был смысл. А так да, можно рассуждать ... just for fun & lulz.
-
Я ни в коем случае не хотел вас задеть. Но просто вот довольно часто приходится натыкаться на мнения подобного плана. Проблема SC не в том, что он есть, а в том, что он не нифига не умеет, извините за сарказм. И каждый раз игнорируя вот эту маленькую, но важную детальку, некоторые прямо любят говорить о том как надо делать. Помимо прочего есть какие-то устоявшиеся паттерны, которые игнорировать тоже глупо. Если это сделано так и это популярно, значит в этом есть некий смысл, несмотря на какие-то мифические недостатки. Еще раз извините.
-
Господа. Почему же вы так не любите jQuery, все таки совсем не ясно. В случае с господином sorrow все понятно. Он изобрел жутко замудреный велосипед, который кроме него самого никому не интересен. Лично я бы ни за что не подписался срать скобками на каждый чих, но по всей видимости именно промышленная модель формата неведомой фигни, некоторых устраивает гораздо больше. Так чем же так плохо? Кто нибудь из вас активно пишет серверный JS? На сколько эти ошибки библиотеки влияют на работоспособность сайта в глобальном смысле этого слова? Может стоит посмотреть правде в глаза? Хотя бы потому что SC что-то совсем непонятное, а тот же jQuery есть везде. Вот тут человек озвучил желание, чтобы j была в нативной поддержке. Что же в этом плохого и откуда негатив? Скоро это будет делать CSS, уже делает многное.