rash
-
Content Count
1,953 -
Joined
-
Last visited
-
Days Won
3
Recent Profile Visitors
7,939 profile views
-
Как-то пользовался таким, он был довольно большим, с крупными пикселями, еще 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 зло, и да, если в нем возникает необходимость — значит раньше что-то пошло не так. К сожалению, это иногда происходит и на средних по масштабу проекта
-
Потому что после поочередного вызова функций у вашего блока .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");С
-
Если очень хочется, можно и совместить. <div class="block"> <h2 class="header block__header">Заголовок блока</h2> <div class="block__content"> Содержимое блока </div></div>Если это нужно в вашем случае.
-
Ну если уж так все сурово и ни пикселя в сторону — может таблицей?
