rash

Как-то пользовался таким, он был довольно большим, с крупными пикселями, еще 1280x1024, кажется. Нравилось очень. Сейчас или ноут (особо не повернешь) или монитор, к которому нужен кронштейн или стойка, чтобы поворачивался. Монитор большой и тяжелый, поэтому дорого, не поворачиваю. Но было бы удобно, я уверен. 1440 по ширине вполне достаточно было бы.

С непривычки на таких диагонялях действительно неудобно (я сейчас не конкретно про мак), сейчас нормально.

Вообще-то нет. Это почти то же самое, что использовать blockquote для того, чтобы в обычном тексте сделать левый отступ. То есть если у нас поле для поиска, то нужно использовать input search. Его ОС сможет нарисовать в соответствии с принятыми в ней соглашениями по интерфейсу. Может со скругленными углами, может еще с какими-то особенностями, отличающимися от системы к системе. Если в поисковом поле мешает кнопка очистки — нужно убрать кнопку очистки из поискового поля. И только если это невозможно — искать другие решения. Можно хоть сделать поле полностью прозрачным а под него положить картинку, тоже будет выглядеть как надо. Поэтому и обратил внимание, что это _правильный_ подход. Если из-за особенностей реализации в некоторых браузерах его применить нельзя — только тогда и стоит искать другие подходы.

Подозреваю, можно сделать .footer__search::-webkit-search-cancel-button { display: none;}но для не-вебкита сходу не нашел решения. С другой стороны это было бы самым правильным подходом, как мне кажется.

https://vk.com/page-43634544_46147345 вот сегодня нашлось, может кому еще интересно… Просто в целом о браузере.

Если не ошибаюсь, w3c для валидации input type="email" предлагает использовать такую регулярку: /^[a-zA-Z0-9.!#$%&’*+/=?^_`{|}~-]+@[a-zA-Z0-9-]+(?:\.[a-zA-Z0-9-]+)*$/Только теперь еще кирилические домены появились

А что вам мешает просто вырезать изображение сразу без задней части?

Так и должно быть. Игнорируются ошибочные правила, на остальной код это не влияет. Очевидно, если парсер может определить, где закончилось ошибочное правило. То есть опечатка в имени свойства или неправильное значение приведут к тому, что пропущено будет только это правило. А вот ошибки с точками с запятой и фигурными скобками могут привести к более серьезным последствиям. Но приблизительно то же самое сказали комментарием выже. Просто хотел обратить внимание, что это не случайность, а определенное и задокументированное поведение.

Эх, поздно я сюда пришел Разумеется есть. Но я не пойму, к чему вы это здесь упомянули? Для якорей id удобен, явно сейчас актуальнее, чем старая техника с name, вот для якорей и используйте, а для стилей незачем. Если что, я не с вами спорю, просто непонятно, к чему это тут. Главным преимуществом в использовании классов для оформления вижу более удобное переопределение стилей, меньшую специфичность класса по сравнению с id. important зло, и да, если в нем возникает необходимость — значит раньше что-то пошло не так. К сожалению, это иногда происходит и на средних по масштабу проектах. Где-то изначально ошибся в архитектуре организации стилей, недооценил, насколько сильно будет развиваться код, насколько он усложнится — и вот уже !important иногда выскакивают то тут то там. Иногда это бывает вызвано и подключаемыми стилями сторонних компонент, но в любом случае это намекает на проблему. Не всегда код, который потребовал important'ов, можно отрефакторить (ну то есть не всегда можно это себе позволить, технически возможно всегда, конечно), и поэтому чем меньше изначально есть «скользких» мест, тем лучше будет потом. Использование id — одно из них. Ну и если в проекте 3—5 типов страниц, то наверное эта проблема будет чувствоваться не так остро. Но это не значит, что следует создавать проблему сознательно. Насчет клонирования — нечасто, но иногда бывает нужно. «Добро пожаловать в наш дерьмовый мир обратно», как говорил один персонаж. В реальной жизни не все складывается идеально, «как должно быть».

Потому что после поочередного вызова функций у вашего блока .gamer оказываются указаны и right, и left, и ширина. Как это по-вашему должен отобразить браузер? Может вы имели в виду что-то в этом роде? http://jsfiddle.net/8t4H8/ Здесь изменяется один и тот же стиль left, в зависимости от нажатой клавиши значение увеличивается или уменьшается.

Да, это вполне допустимо и ничему не противоречит. Мне кажется это немного другой случай. Модификатор стоит использовать, когда есть несколько немного отличающихся разновидностей блоков, но они могут использоваться самостоятельно. Подмешиваем элемент блока в том случае, когда изменения нужно сделать в контексте блока-родителя. То есть в общем случае тогда, когда без БЭМ мы бы использовали контекст ".block .header". По БЭМ-у мы доопределяем стили уже у элемента блока .block__header. Я например часто использую такой прием, когда нужно спозиционировать блок внутри блока-родителя, тогда я уже позиционирую его как элемент родительского блока. Ну или размеры задать, или как-то иначе адаптировать отображение всего блока внутри конкретного родителя.

По БЭМ не должно быть классов вне блоков. Поэтому повторяющийся заголовок оформляем отдельным блоком, если внутри какого-то другого блока он несколько отличается — подмешиваем к нему элемент блока. Ну или можно подмешать и заранее, «на всякий случай», ничего плохого не случится.

В плане логики нет никакой разницы между x и $x. Насколько мне известно, в некоторых проектах просто существуют соглашения, предлагающие именовать переменные, в которых хранятся jquery-объекты (не знаю, насколько это правильный термин), используя префикс $. Таким образом если переменная имеет префикс $ (т. е. $variableName), то сразу становится понятно, что у нее можно вызывать методы jquery, например. Дело исключительно в наглядности, больше ни на что это не влияет. var x = $(".bxslider");Создали переменную x, в которую сохранили результат выборки по классу .bxslider var $x = $(".bxslider");Создали переменную $x, в которую сохранили результат выборки по классу .bxslider — от первого случая отличается только именем переменной. console.log(x);Вывели переменную x console.log($(x));Инициализировали jquery-объект, используя не имя класса, не ссылку на DOM-элемент, а уже существующий jquery-объект. Получили копию переменной x. Вывели ее. console.log($x); Вывели переменную $x, в которой содержатся те же данные, что и в x.

Если очень хочется, можно и совместить. <div class="block"> <h2 class="header block__header">Заголовок блока</h2> <div class="block__content"> Содержимое блока </div></div>Если это нужно в вашем случае.

Ну если уж так все сурово и ни пикселя в сторону — может таблицей?

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

Обычно оговаривается сразу при начале работы. Как правило бывает IE8 и новее, но есть проекты (меньшинство) с IE9 и новее.

К сожалению, приемлемым решением (по надежности и кроссбраузерности) сейчас наверное можно назвать только использование контекста (все селекторы ограничить родителем-контекстом .body). Да, я видел, что по условию стили менять нельзя. Но, к сожалению, других хорошо поддерживаемых средств для решения этой проблемы сейчас, похоже, не существует.

Сейчас широкого монитора под рукой нет, но если «отзумить» страницу вниз на несколько уровней - ничего не ломается. Разумеется, зум всей страницы, а не только текста.

Safari Version 7.0.3 http://s1.ipicture.ru/uploads/20140330/TJxrhfUS.png Ширина — 1280

Различия в основном бывают связаны с разными версиями вебкита. Обычно ничего серьезного, с ощутимой проблемой сталкивался один раз. Проверяю, но без фанатизма.

Так делать можно, работать будет. Ну в старых ie придется явно скриптом теги посоздавать. Не представляю, когда это может понадобиться (точнее, представляю, но случай крайне специфичный). Технически — возможно, в общем случае — не нужно. Для этого есть теги общего назначения и классы.

Никак. Это не предусмотрено. Эти атрибуты предназначены для изображений в контенте страницы, а не для элементов оформления, которыми должны быть фоны. Можно подставить костыль (некрасивый, но вашу задачу решит) — вставить поверх фона однопиксельное прозрачное изображение, растянутое по размеру элемента с фоном, и задать alt и title для него. Если alt не так важен, то title можно задать самому элементу с фоном (или ссылке, которая в нем, это вам должно быть виднее). Ну это, конечно, и некрасиво, и не очень понятна задача, которую вы решаете. Может можно поступить совсем по-другому?

Ну и такую аргументацию я тоже могу понять. Целенаправленно сломать можно что угодно. А если это по неосторожности — от от всех неосторожностей тоже не спастись.

Поэтому я и сказал, что используется именно эквивалентность, а не равенство, и обратил внимание, как записывается эквивалентность. Насчет переменной undefined Разумеется речь идет о глобальной переменной. Разумеется, мы не можем гарантировать, что скрипт работает в строгом режиме. Разумеется, встретить такое на практике — надо еще поискать. Но если есть способ, устойчивый к этой ошибке — почему бы не использовать его?