Комментарии / Профиль note

05.12.2012 23:45:30

Wed, 05 Dec 2012 23:45:30 GMT

Есть древнющий баг с Undo/Redo, все никак не доберусь до трекера чтоб правильно сформулировать и зарепортить, если еще не зарепорчено) Поэтому зарепорчу здесь.
Суть бага в том, что, если история изменений файла большая и зажать Undo, так сказать, до упора, а потом попробовать все вернуть зажав Redo тоже до упора, то в какой-то момент код ломается и превращается в рандомную кашу и вернуть его обратно в корректный вид можно только с помощью локальной истории.
Не смертельно, но иногда поднаживает :)

А вообще за продукт огромное спасибо, вы лучшие)

25.11.2012 20:34:28

Sun, 25 Nov 2012 20:34:28 GMT

Товарищи, а может кто-нибудь что-то подобное рассказать про других гигантов IT-индустрии за рубежом (США, Европа), к примеру — Apple, Amazon, Microsoft и т.п?
Больше всего, конечно, интересует как там работается, а не как туда попасть, так как, если есть желание, то это лишь дело времени. Хотя, если есть на примете какие-либо хитрости и трюки по трудоустройству, то тоже будет интересно узнать :)

24.09.2012 14:58:57

Mon, 24 Sep 2012 14:58:57 GMT

Согласен. Если брать всю методику разработки в целом, то, конечно, учитывать иерархию внутри элементов и делать многоуровневые вложенности папок в файловой системе абсолютно излишне и было бы полнейшим маразмом.

Если же брать только метод именования (ну и, конечно же, независимость блоков), то в отрыве от вашего инструментария и системы разбивки всего внутри блока на папки — метод именования становится нелогичным. А, как мне кажется, в большинстве случаев верстальщики с небольших проектов как раз заимствуют только именование.

24.09.2012 14:33:00

Mon, 24 Sep 2012 14:33:00 GMT

Если вы говорите о том, какие классы используют в Яндексе, то это не так: схема именования элемента не зависит от его вложенности в другие элементы.

Я говорил о верстке Яндекс.Почты и, как мне думалось на тот момент, об именовании по БЭМ'у в целом. Выше я уже неоднократно признавал, что был не прав на этот счет.

Если вы говорите о БЭМ в целом, то это тоже не верно. БЭМ как методология не регламентирует именование классов, оставляя это за конкретной реализацией.

Не о БЭМ в целом, а только о вашем, так сказать, дефолтном методе именования по БЭМ'у.

24.09.2012 13:27:34

Mon, 24 Sep 2012 13:27:34 GMT

Да я уже понял, что «чисто по БЭМ'овски, как Виталя прописал» все именно так, как вы говорите. Даже покаялся чуть ниже в комментах.
Теперь же просто высказываю точку зрения о том, что оригинальное БЭМ-именование, на мой взгляд, нелогичное и трудное для восприятия, и объясняю как и почему, опять же на мой взгляд, было бы логичней и понятней.

23.09.2012 20:47:12

Sun, 23 Sep 2012 20:47:12 GMT

С категоричностью первого высказывания, конечно, погорячился, каюсь.
Просто мне БЭМ представлялся более логичным, универсальным и понятным, чем он есть на самом деле. Раньше удивлялся тому, что многим он непонятен и монструозен для восприятия. Теперь же понимаю отчего это происходит.

Так как, глядя на вашу почту, я был уверен, что в БЭМ именование происходит именно так, как уже описывал выше, я неоднократно давал своим друзьям начинающим верстальщикам ссылку на bem.info (хотя сам года 2-3 ничего не читал про БЭМ) и у всех без исключения после прочтения гайдов метод именования вызывал затруднения. После того же, как я объяснял все со своей колокольни, опять же все без исключения говорили «ааа, теперь все понятно, так бы сразу и сказал».

Замечу, что я говорю только о методе именования. Основополагающий же принцип БЭМ'а о независимости блоков бесспорен.

23.09.2012 10:52:43

Sun, 23 Sep 2012 10:52:43 GMT

Я прекрасно понимаю что имеется ввиду в записи Beyondtheclouds. Я же пытаюсь абстрагироваться от документации и следовать логике.
И, думаю, бессмысленно доказывать, что белое — это белое, а в этой абстрактной разметке:

…

… news — блок, list — элемент блока, а item — элемент блока, вложенный в другой элемент блока.

К тому же если иерархия плоская, а стили независимы — …

Стили внутри блока не могут быть независимы. В большей или меньше степени, но они обязательно зависят от того, что рядом, во что обернуты и что внутри. А если элемент независим, то это уже блок.

23.09.2012 10:16:23

Sun, 23 Sep 2012 10:16:23 GMT

Очень правильный вопрос.
Мы в своей команде решили, что отказываться от каскада в описанном вами случае — излишний фанатизм.

23.09.2012 10:11:49

Sun, 23 Sep 2012 10:11:49 GMT

Я, пожалуй, воздержусь от спора о фломастерах, а попробую описать чем лично меня не устраивает приведенный вами тип записи с точки зрения моей логики:

1. Вы в имени элемента так или иначе используете ту же самую иерархию именования, что я описал выше, только в качестве разделителя пишете абсолютно нелогичный с моей точки зрения символ дефиса.
«list» — это элемент? Да.
«item» — это элемент? Да.
Элементы по БЭМ отделяются так — "__элемент"? Да.
Так при чем здесь тогда дефис? И, интересно, как бы вы написали такое — «news__list__item__link__image»?

2. Именование модификаторов как "_ключ_значение", на мой взгляд, излишне. На практике для нормального понимания абсолютно всегда достаточно написать только "_значение". Или кому-то в строке "*_disabled *_hidden *_big" будет непонятно, что "_disabled" — это о состоянии, "_hidden" — о видимости, а "_big" о размерах? Зачем писать лишние "_state", "_visibility" и "_size", когда все и без них очевидно?

22.09.2012 15:18:39

Sat, 22 Sep 2012 15:18:39 GMT

В чем по-вашему заключается адовость? И как бы вы именовали такой пример?

22.09.2012 13:45:42

Sat, 22 Sep 2012 13:45:42 GMT

А вы внутри имени ставите разделитель «блок-элемент».

Я ставлю разделитель "__элемент-блока", вложенный в "__другой-элемент-блока", так как в данном случае они неотделимы. Чуть подробней описал в комменте выше.

22.09.2012 13:34:16

Sat, 22 Sep 2012 13:34:16 GMT

Явного запрета на иерархию в именовании элементов блока в их доках я что-то не нашел, к тому же сами яндексоиды на почте верстают именно так.

Да и с точки зрения логики это, по-моему, правильней, так как link — это по сути элемент, вложенный в другой элемент и не имеющий смысла вне родительского item'а. Если же link такой универсальный и существует потенциальная возможность его дальнейшего использования в другом месте, то он должен быть вынесен отдельно в качестве блока.

Но в любом случае, даже если ребята из яндекса имели ввиду то, о чем вы говорите — это все малозначительные нюансы и разные команды разработчиков могут с легкостью принимать свои откорректированные условия именования, с которыми им будет удобней работать на том или ином проекте. Главное — придерживаться одного стиля. Основополагающий же тезис методологии о независимости блоков от этого никак не страдает.

К примеру, у нас на проекте мы с коллегами отказались от всяческих предлагаемых яндексом префиксов, но добавили свой — префикс «w-», который мы добавляем к элементам-оберткам (так называемые wrappers, отсюда и название префикса). Таким образом мы отделяем вспомогательные обертки от участия в иерархии при именовании, о которой я писал выше. Вот типовой пример нашего кода:

.news {}
	.news__tabs {}
		.news__tabs__item {}
	.news__list {}
		.news__list__item {}
			.news__list__item_hiddable {}
		.w-news__list__item_project {}

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

22.09.2012 11:41:02

Sat, 22 Sep 2012 11:41:02 GMT

Не хочу вас расстраивать, но это тоже не БЭМ.
БЭМ выглядел бы так:

.nav {}
.nav__item {} 
.nav__item__link {}

22.09.2012 09:25:10

Sat, 22 Sep 2012 09:25:10 GMT

Как уже заметил pred8or, считать следует не только разрешения экранов пользователей.
Информации только по разрешениям недостаточно, чтобы делать полноценные выводы о размере области экрана, в которой отобразится ваша страница у пользователя.
habrahabr.ru/company/mailru/blog/142193/ — здесь чуть подробней описан ход мыслей и результаты похожих подсчетов на нашем проекте.

19.04.2012 05:48:33

Thu, 19 Apr 2012 05:48:33 GMT

Я говорю только про доктайп HTML5 в IE6, а не про то, что вы отнесли к «несколько шире».
Использование нового доктайпа никак не обязывает к использованию кастомных тегов, новых хитрых атрибутов и прочих прелестей HTML5. Поэтому, как я уже сказал, у нас от HTML5 только доктайп и пара малозначимых мелочей вроде атрибута autocomplete.

18.04.2012 18:36:47

Wed, 18 Apr 2012 18:36:47 GMT

Благо, что это отключается.

18.04.2012 09:57:10

Wed, 18 Apr 2012 09:57:10 GMT

Что вы подразумеваете под HTML5?
Из HTML5 у нас только несколько малозначимых мелочей и доктайп, а его отлично поддерживают все популярные браузеры, даже IE6.

18.04.2012 08:54:59

Wed, 18 Apr 2012 08:54:59 GMT

Точно не помню, но, по-моему, при установке игрового центра должны спрашивать ставить все это «добро» или нет. По крайней мере мне ничего лишнего не установилось.

18.04.2012 08:13:29

Wed, 18 Apr 2012 08:13:29 GMT

Голосовой чат в игре точно есть, только сам я его не пробовал, поэтому сказать о его качестве ничего не могу.

18.04.2012 07:50:02

Wed, 18 Apr 2012 07:50:02 GMT

И IE 7 туда же.