rash
-
Posts
1,953 -
Joined
-
Last visited
-
Days Won
3
Content Type
Profiles
Forums
Calendar
Store
Posts posted by rash
-
-
С непривычки на таких диагонялях действительно неудобно (я сейчас не конкретно про мак), сейчас нормально.
-
Вообще-то уже ответили =)))
input type="search" заменить на input type="text" и будет вам счастье. css тут не при чем. это html
Вообще-то нет.
Это почти то же самое, что использовать blockquote для того, чтобы в обычном тексте сделать левый отступ. То есть если у нас поле для поиска, то нужно использовать input search. Его ОС сможет нарисовать в соответствии с принятыми в ней соглашениями по интерфейсу. Может со скругленными углами, может еще с какими-то особенностями, отличающимися от системы к системе. Если в поисковом поле мешает кнопка очистки — нужно убрать кнопку очистки из поискового поля. И только если это невозможно — искать другие решения.
Можно хоть сделать поле полностью прозрачным а под него положить картинку, тоже будет выглядеть как надо. Поэтому и обратил внимание, что это _правильный_ подход. Если из-за особенностей реализации в некоторых браузерах его применить нельзя — только тогда и стоит искать другие подходы.
-
Подозреваю, можно сделать
.footer__search::-webkit-search-cancel-button { display: none;}
но для не-вебкита сходу не нашел решения. С другой стороны это было бы самым правильным подходом, как мне кажется.
-
https://vk.com/page-43634544_46147345 вот сегодня нашлось, может кому еще интересно… Просто в целом о браузере.
- 1
-
Если не ошибаюсь, w3c для валидации input type="email" предлагает использовать такую регулярку:
/^[a-zA-Z0-9.!#$%&’*+/=?^_`{|}~-]+@[a-zA-Z0-9-]+(?:\.[a-zA-Z0-9-]+)*$/
Только теперь еще кирилические домены появились
-
А что вам мешает просто вырезать изображение сразу без задней части?
- 2
-
С точки зрения результата, если не ошибаюсь, указание свойства без значения даст ошибку парсинга, в результате весь оставшийся css-код в файле, находящийся после строчки с ошибкой, может быть проигнорирован.
Хотя пример показывает обратное, будет проигнорировано только неверно указанное свойство.
Так и должно быть. Игнорируются ошибочные правила, на остальной код это не влияет. Очевидно, если парсер может определить, где закончилось ошибочное правило.
То есть опечатка в имени свойства или неправильное значение приведут к тому, что пропущено будет только это правило. А вот ошибки с точками с запятой и фигурными скобками могут привести к более серьезным последствиям.
Но приблизительно то же самое сказали комментарием выже. Просто хотел обратить внимание, что это не случайность, а определенное и задокументированное поведение.
- 1
-
Эх, поздно я сюда пришел
Есть разница между "удобен" и "необходим"?
Разумеется есть. Но я не пойму, к чему вы это здесь упомянули?
Для якорей id удобен, явно сейчас актуальнее, чем старая техника с name, вот для якорей и используйте, а для стилей незачем.
Если что, я не с вами спорю, просто непонятно, к чему это тут.
Главным преимуществом в использовании классов для оформления вижу более удобное переопределение стилей, меньшую специфичность класса по сравнению с id. important зло, и да, если в нем возникает необходимость — значит раньше что-то пошло не так.
К сожалению, это иногда происходит и на средних по масштабу проектах. Где-то изначально ошибся в архитектуре организации стилей, недооценил, насколько сильно будет развиваться код, насколько он усложнится — и вот уже !important иногда выскакивают то тут то там. Иногда это бывает вызвано и подключаемыми стилями сторонних компонент, но в любом случае это намекает на проблему.
Не всегда код, который потребовал important'ов, можно отрефакторить (ну то есть не всегда можно это себе позволить, технически возможно всегда, конечно), и поэтому чем меньше изначально есть «скользких» мест, тем лучше будет потом. Использование id — одно из них.
Ну и если в проекте 3—5 типов страниц, то наверное эта проблема будет чувствоваться не так остро. Но это не значит, что следует создавать проблему сознательно.
Насчет клонирования — нечасто, но иногда бывает нужно. «Добро пожаловать в наш дерьмовый мир обратно», как говорил один персонаж. В реальной жизни не все складывается идеально, «как должно быть».
-
Потому что после поочередного вызова функций у вашего блока .gamer оказываются указаны и right, и left, и ширина. Как это по-вашему должен отобразить браузер?
Может вы имели в виду что-то в этом роде? http://jsfiddle.net/8t4H8/
Здесь изменяется один и тот же стиль left, в зависимости от нажатой клавиши значение увеличивается или уменьшается.
-
rash, т.е. один html-элемент будет одновременно являться определённым блоком и элементом другого блока?
Да, это вполне допустимо и ничему не противоречит.
Я обычно делаю отдельный блок и вешаю на него модификатор:
Мне кажется это немного другой случай. Модификатор стоит использовать, когда есть несколько немного отличающихся разновидностей блоков, но они могут использоваться самостоятельно.
Подмешиваем элемент блока в том случае, когда изменения нужно сделать в контексте блока-родителя. То есть в общем случае тогда, когда без БЭМ мы бы использовали контекст ".block .header". По БЭМ-у мы доопределяем стили уже у элемента блока .block__header. Я например часто использую такой прием, когда нужно спозиционировать блок внутри блока-родителя, тогда я уже позиционирую его как элемент родительского блока. Ну или размеры задать, или как-то иначе адаптировать отображение всего блока внутри конкретного родителя.
- 1
-
По БЭМ не должно быть классов вне блоков. Поэтому повторяющийся заголовок оформляем отдельным блоком, если внутри какого-то другого блока он несколько отличается — подмешиваем к нему элемент блока. Ну или можно подмешать и заранее, «на всякий случай», ничего плохого не случится.
-
В плане логики нет никакой разницы между 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.
- 1
-
Если очень хочется, можно и совместить.
<div class="block"> <h2 class="header block__header">Заголовок блока</h2> <div class="block__content"> Содержимое блока </div></div>
Если это нужно в вашем случае.
-
Ну если уж так все сурово и ни пикселя в сторону — может таблицей?
-
Не смотря на то что в основе движка Blink и лежит код WebCore из WebKit, но это совсем другой движок...
Вроде же не так давно отделились? Уже сильно много различий?
Вообще да, блинк, но я пока не понял, насколько принципиально его рассматривать отдельно от вебкита...
-
Обычно оговаривается сразу при начале работы.
Как правило бывает IE8 и новее, но есть проекты (меньшинство) с IE9 и новее.
-
К сожалению, приемлемым решением (по надежности и кроссбраузерности) сейчас наверное можно назвать только использование контекста (все селекторы ограничить родителем-контекстом .body).
Да, я видел, что по условию стили менять нельзя. Но, к сожалению, других хорошо поддерживаемых средств для решения этой проблемы сейчас, похоже, не существует.
-
Сейчас широкого монитора под рукой нет, но если «отзумить» страницу вниз на несколько уровней - ничего не ломается. Разумеется, зум всей страницы, а не только текста.
-
-
Различия в основном бывают связаны с разными версиями вебкита. Обычно ничего серьезного, с ощутимой проблемой сталкивался один раз.
Проверяю, но без фанатизма.
-
Так делать можно, работать будет. Ну в старых ie придется явно скриптом теги посоздавать.
Не представляю, когда это может понадобиться (точнее, представляю, но случай крайне специфичный).
Технически — возможно, в общем случае — не нужно. Для этого есть теги общего назначения и классы.
-
Никак. Это не предусмотрено. Эти атрибуты предназначены для изображений в контенте страницы, а не для элементов оформления, которыми должны быть фоны.
Можно подставить костыль (некрасивый, но вашу задачу решит) — вставить поверх фона однопиксельное прозрачное изображение, растянутое по размеру элемента с фоном, и задать alt и title для него. Если alt не так важен, то title можно задать самому элементу с фоном (или ссылке, которая в нем, это вам должно быть виднее).
Ну это, конечно, и некрасиво, и не очень понятна задача, которую вы решаете. Может можно поступить совсем по-другому?
-
Ну и такую аргументацию я тоже могу понять.
Целенаправленно сломать можно что угодно. А если это по неосторожности — от от всех неосторожностей тоже не спастись.
-
равенство, это так ==
Поэтому я и сказал, что используется именно эквивалентность, а не равенство, и обратил внимание, как записывается эквивалентность.
Насчет переменной undefined
Не может, т.к. переменные в js имеют лексическую область видимостиРазумеется речь идет о глобальной переменной. Разумеется, мы не можем гарантировать, что скрипт работает в строгом режиме. Разумеется, встретить такое на практике — надо еще поискать. Но если есть способ, устойчивый к этой ошибке — почему бы не использовать его?
У кого-нибудь стоить на 90 градусов повернутый монитор?
in Flame
Posted
Как-то пользовался таким, он был довольно большим, с крупными пикселями, еще 1280x1024, кажется. Нравилось очень.
Сейчас или ноут (особо не повернешь) или монитор, к которому нужен кронштейн или стойка, чтобы поворачивался. Монитор большой и тяжелый, поэтому дорого, не поворачиваю. Но было бы удобно, я уверен. 1440 по ширине вполне достаточно было бы.