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

    А вообще за продукт огромное спасибо, вы лучшие)
  • Почему лучше верстать в соответствии с БЭМ — практические примеры
    +1
    Согласен. Если брать всю методику разработки в целом, то, конечно, учитывать иерархию внутри элементов и делать многоуровневые вложенности папок в файловой системе абсолютно излишне и было бы полнейшим маразмом.

    Если же брать только метод именования (ну и, конечно же, независимость блоков), то в отрыве от вашего инструментария и системы разбивки всего внутри блока на папки — метод именования становится нелогичным. А, как мне кажется, в большинстве случаев верстальщики с небольших проектов как раз заимствуют только именование.
  • Почему лучше верстать в соответствии с БЭМ — практические примеры
    0
    Если вы говорите о том, какие классы используют в Яндексе, то это не так: схема именования элемента не зависит от его вложенности в другие элементы.

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

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

    Не о БЭМ в целом, а только о вашем, так сказать, дефолтном методе именования по БЭМ'у.
  • Почему лучше верстать в соответствии с БЭМ — практические примеры
    0
    Да я уже понял, что «чисто по БЭМ'овски, как Виталя прописал» все именно так, как вы говорите. Даже покаялся чуть ниже в комментах.
    Теперь же просто высказываю точку зрения о том, что оригинальное БЭМ-именование, на мой взгляд, нелогичное и трудное для восприятия, и объясняю как и почему, опять же на мой взгляд, было бы логичней и понятней.
  • Почему лучше верстать в соответствии с БЭМ — практические примеры
    0
    С категоричностью первого высказывания, конечно, погорячился, каюсь.
    Просто мне БЭМ представлялся более логичным, универсальным и понятным, чем он есть на самом деле. Раньше удивлялся тому, что многим он непонятен и монструозен для восприятия. Теперь же понимаю отчего это происходит.

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

    Замечу, что я говорю только о методе именования. Основополагающий же принцип БЭМ'а о независимости блоков бесспорен.
  • Почему лучше верстать в соответствии с БЭМ — практические примеры
    0
    Я прекрасно понимаю что имеется ввиду в записи Beyondtheclouds. Я же пытаюсь абстрагироваться от документации и следовать логике.
    И, думаю, бессмысленно доказывать, что белое — это белое, а в этой абстрактной разметке:

    <div class="news">
        <div class="list">
            <div class="item">…</div>
        </div>
    </div>
    

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

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

    Стили внутри блока не могут быть независимы. В большей или меньше степени, но они обязательно зависят от того, что рядом, во что обернуты и что внутри. А если элемент независим, то это уже блок.
  • Почему лучше верстать в соответствии с БЭМ — практические примеры
    0
    Очень правильный вопрос.
    Мы в своей команде решили, что отказываться от каскада в описанном вами случае — излишний фанатизм.
  • Почему лучше верстать в соответствии с БЭМ — практические примеры
    0
    Я, пожалуй, воздержусь от спора о фломастерах, а попробую описать чем лично меня не устраивает приведенный вами тип записи с точки зрения моей логики:

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

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

    Я ставлю разделитель "__элемент-блока", вложенный в "__другой-элемент-блока", так как в данном случае они неотделимы. Чуть подробней описал в комменте выше.
  • Почему лучше верстать в соответствии с БЭМ — практические примеры
    0
    Явного запрета на иерархию в именовании элементов блока в их доках я что-то не нашел, к тому же сами яндексоиды на почте верстают именно так.

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

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

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

    <div class="news">
    	<div class="news__tabs">
    		<div class="news__tabs__item">
    	</div>
    	<div class="news__list">
    		<div class="news__list__item">…</div>
    		<div class="news__list__item news__list__item_hiddable">…</div>
    		<div class="news__list__item news__list__item_hiddable">…</div>
    		<div class="w-news__list__item_project">
    			<div class="news__list__item">…</div>
    			<div class="news__list__item">…</div>
    			<div class="news__list__item">…</div>
    		</div>
    	</div>
    </div>
    

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


    Для нас в такой записи все прозрачно и очевидно, по стилям сразу видна вся структура блока и видно что и от чего зависит внутри него.
  • Почему лучше верстать в соответствии с БЭМ — практические примеры
    0
    Не хочу вас расстраивать, но это тоже не БЭМ.
    БЭМ выглядел бы так:

    .nav {}
    .nav__item {} 
    .nav__item__link {}
    
  • Считаем ширину экранов у посетителей сайта
    +1
    Как уже заметил pred8or, считать следует не только разрешения экранов пользователей.
    Информации только по разрешениям недостаточно, чтобы делать полноценные выводы о размере области экрана, в которой отобразится ваша страница у пользователя.
    habrahabr.ru/company/mailru/blog/142193/ — здесь чуть подробней описан ход мыслей и результаты похожих подсчетов на нашем проекте.
  • Новая Главная портала Mail.Ru
    0
    Я говорю только про доктайп HTML5 в IE6, а не про то, что вы отнесли к «несколько шире».
    Использование нового доктайпа никак не обязывает к использованию кастомных тегов, новых хитрых атрибутов и прочих прелестей HTML5. Поэтому, как я уже сказал, у нас от HTML5 только доктайп и пара малозначимых мелочей вроде атрибута autocomplete.
  • Warface — ОБТ в самом разгаре!
    0
    Благо, что это отключается.
  • Новая Главная портала Mail.Ru
    0
    Что вы подразумеваете под HTML5?
    Из HTML5 у нас только несколько малозначимых мелочей и доктайп, а его отлично поддерживают все популярные браузеры, даже IE6.
  • Warface — ОБТ в самом разгаре!
    0
    Точно не помню, но, по-моему, при установке игрового центра должны спрашивать ставить все это «добро» или нет. По крайней мере мне ничего лишнего не установилось.
  • Warface — ОБТ в самом разгаре!
    0
    Голосовой чат в игре точно есть, только сам я его не пробовал, поэтому сказать о его качестве ничего не могу.
  • Новая Главная портала Mail.Ru
    0
    И IE 7 туда же.
  • Warface — ОБТ в самом разгаре!
    –5
    И чем же конкретно вам не угодил Мейл в данном конкретном случае?
  • Warface — ОБТ в самом разгаре!
    +2
    Как по мне, так повод для радости все равно есть — тесное сотрудничество с Crytek и участие в таком, на мой взгляд, перспективном проекте явно должно пойти на пользу Mail.Ru и развитию собственных разработок. Да и радует то, что Мейл отлично справляется со своей частью — локализация и стабильность серверов на высоте.
  • Warface — ОБТ в самом разгаре!
    0
    Согласен, только вот все оффтоп хабы требуют задротского размера карму. Поэтому и выбрал самый близкий к играм блог. А для того, чтобы хоть как-то соответствовать тематике «Game Development», даж пришлось немного рассказать про разработчиков игры, хотя изначально вообще не планировал писать эту часть.
    Если когда-нибудь дорасту до оффтоп хабов, то сразу же перенесу пост туда.
  • JavaScript на сервере, 1ms на трансформацию
    +13
  • HTML/CSS-инъекция в почте Mail.Ru
    +1
    Вы получаете более качественный продукт :)

    Делая же обзоры любых уязвимостей до их исправления, вы повышаете вероятность попадания других пользователей в нехорошую ситуацию.

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

    Надеюсь, что наши старания будут вознаграждены отзывами довольных пользователей, баг-репортами не очень довольных и конструктивной критикой совсем недовольных :)
  • Opera Dragonfly 1.0
    +6
    Шикарный релиз!
    Правда очень не хватает инлайнового автодополнения в стилях, как в фаербаге, чтоб не нужно было каждый раз нажимать стрелку. И чтобы при добавлении нового свойства после написания названия свойства по табу переходило к значению, а не сбрасывало все написанное и прыгало на следующее свойство. Вобщем в этом плане хочется полный аналог фаербага.
    d → Tab → n = display:none;
    li → Tab → n = list-style:none;
    и т.п.
    Ну ведь удобно же до ужаса. Почему бы не сделать так же.

    Еще очень не хватает возможности быстрого добавления инлайновых стилей, опять же как в фаербаге. А то щас приходится вручную писать в дереве style=""

    Также очень не хватает работы с динамикой, как в фаербаге — подсвечивать изменения, разворачивать изменения, прокручивать к изменениям.

    Еще не хватает отображения строки, на которой находится css-свойство и, естественно, перехода на эту строку.

    Еще ооочень не хватает отображения всех свойств, а не только тех, которые опера смогла интерпретировать. Хочу как в хромом видеть все -moz, -webkit и т.п. Для удобства можно было бы сделать их отображение отключаемым.

    А еще почему-то драгонфлай так и не научился нормально работать с цветом CSS3 теней — он упорно не хочет показывать значение цвета.

    Еще стрекоза часто неадекватно ведет себя, когда переписываешь какое-либо свойство на другое.
    К примеру, мы хотим переписать у заголовка поста на хабре padding-right:30px; на margin-right:30px; — результат получается, мягко говоря, очень странный. Мало того, что в стилях по-прежнему будет отображаться padding-right:30px; (хотя его на самом деле нет и при повторном клике на элементе переписанное свойство исчезает), так драгонфлай еще и почему-то понял наш margin-right:30px; как margin:30px;. Очень досадный баг.

    Вобщем еще есть куда расти, а пока в целом очень доволен. Очень большой рывок по сравнению с предыдущей версией.
  • Оперный вернисаж: объявляем победителей
    +1
    Мое творение — Antilamo.
    То, что многие иконки были в уменьшенном формате — вина разработчиков, что они не позаботились о масштабировании.
    А то, что шрифты на скрине были не такие, как вы ожидали — разница в системном сглаживании. Именно такие, как вы говорите, смазанные шрифты и видят юзеры-линуксоиды. У маководов это, скорее всего, тоже иначе выглядит.
  • Оперный вернисаж: объявляем победителей
    0
    Неожиданные результаты. Был уверен, что победит милая коровка, которая просто не может не понравиться :)
    Второе место я отдавал лаконичной и аккуратной тунгуске.
    А сам надеялся хотя бы на третье место.

    Определившийся же победитель, мягко выражаясь, уныл чуть менее, чем полностью. Из всех представленных работ ячейка oggetto самая безликая и невзрачная, да еще и не читабельна даже в немного уменьшенном масштабе. На мой взгляд этот эскиз не мог претендовать на высокие оценки, особенно на фоне коровки :) Из чего я посмею выдвинуть предположение, что накрутка оценок победителем имела место быть. Буду только рад, если ошибаюсь и всё было честно.

    Даёшь бурёнке приз зрительских симпатий! По крайней мере моих :)
    Своим же результатом доволен, спасибо Опере за конкурс!
  • Оперный вернисаж: объявляем победителей
    +1
    А можно узнать ваше личное мнение какая должна быть тройка победителей? :)
  • Оперный вернисаж: финальное голосование
    0
    И все равно — я не понимаю, зачем мне закладка таких размеров.)
    Лично для себя я тоже не вижу ценности в такой фиче, а вот маме очень даже нравятся большие удобные кнопки :) Мне — закладки, ей — спиддиал. Все довольны.
  • Оперный вернисаж: финальное голосование
    +2
    Если кому интересно, то здесь можно глянуть работы участников из забугорья.
  • Оперный вернисаж: финальное голосование
    +1
    О превьюхе сайта antilamo.ru — занимает все выделенное пространство, отлично ресайзится под любой размер ячейки, обновляется каждый час и в зависимости от времени суток фон превью меняется на соответствующий.

    Как разработчик этого сайта готов принимать конструктивную критику как в отношении превью, так и в отношении всего сайта в целом.

    Спасибо.
  • Оперный вернисаж
    0
    Что теперь будет с голосованием, если релиз уже состоялся?
    Ведь планировалось, что 2-й этап будет длиться как раз до релиза.
  • Оперный вернисаж
    0
    Таки вот. Надеюсь, что я не опоздал :)
    Сделал в первый же день конкурса, да вот потом что-то времени не было дошаманить последние штрихи.
    О превьюхе — занимает все пространство ячейки, отлично ресайзится, обновляется каждый час и в зависимости от времени суток фон превью меняется на соответствующий.
  • Opera 11.10 — весенний релиз
    0
    О, у вас тут флэшмоб! Напишу-ка я тоже, что это делается в настройках.
  • Оперный вернисаж
    0
    Хм, неделя еще не прошла, а релиз уже состоялся.
    Работы еще принимаются до завтра или уже все?
  • Оперный вернисаж
    +1
    А я что-то не могу найти на оф сайте никакой информации по конкурсу.
    Я клоню не к тому, что не доверяю вам, а к тому, что мне интересно насколько широка эта всеобщность :)
    А то с зарубежными коллегами по цеху, по-моему, будет сложновато конкурировать — уж креатива им не занимать :)
  • Оперный вернисаж
    0
    А конкурс всеобщий или эксклюзивно только для читателей хабра? :)
  • Оперный вернисаж
    0
    А можно поподробнее узнать где и каким образом будет проходить голосование?
  • 1 апреля
    0
    Вобще убрали эту фишку :(
  • 1 апреля
    +1
    В каком смысле поподробнее прописать? Если нужен пример, то вот:
    В css добавляем класс-перевертыш:
    
    .turn-over {
        -webkit-transform:rotate(180deg);
        -moz-transform:rotate(180deg);
        -o-transform:rotate(180deg);
        transform:rotate(180deg);
    }
    


    В коде страницы нужному элементу добавляем наш класс. К примеру к картинке:
    
    <img src="jpg.jpg" class="turn-over" />
    


    Подробнее на доступном языке можете почитать здесь.