SelenIT
-
Posts
4,327 -
Joined
-
Last visited
-
Days Won
140
Content Type
Profiles
Forums
Calendar
Store
Everything posted by SelenIT
-
Обнулили — вот и пропали, разве нет? И, кстати, зачем выписывать одни и те же свойства дважды свойства дважды? Ну и отлаживать код будет проще, если не путать себя ручной расстановкой префиксов, а расставлять их автоматически (и только нужные) в самом конце, наверное...
-
Маркер строки в виде точек от текста до цены
SelenIT replied to Konstantin99's question in HTML Coding
С модными штучками можно и для произвольного фона: https://jsfiddle.net/eyyj8mxj/2/ -
При наведении на ссылка подсвечивается по содержимому
SelenIT replied to volshebnyi's question in HTML Coding
Вообще, если нет аллергии на слово table, то самое простое и, имхо, прямое решение — display:table для ссылок (вместо block). Делает ровно то, что надо — сохраняет поведение блочным, но ширину ужимает до содержимого. Из побочек — разве что с max-height могут быть проблемы. Если такая аллергия есть, можно задать ссылкам float: left; clear: left; а панелям — .clearfix или (имхо, лучше) overflow:hidden, чтоб эти флоаты не «цеплялись» за соседей. -
При наведении на ссылка подсвечивается по содержимому
SelenIT replied to volshebnyi's question in HTML Coding
А реагировать на наведение тоже должно только содержимое? -
Типа такого?
-
Причем в любом месте может быть не любой <meta>, а только несущий атрибуты метаданных. И только в WHATWG-версии, потому что из W3C HTML5.1 эти несчастные метаданные выпилили. А конкретно viewport — кстати, до сих пор не стандартизированный! — ввели как <meta> именно потому, что эта информация должна во что бы то ни стало быть в <head> (до начала какой-либо отрисовки), а элемент <meta> — по сути единственное, что можно добавить в %3Chead%3E, не закрыв его неявно. Так что <meta viewport> должен быть в <head>, и браузеры всё правильно делают!
-
Точное количество расширений мониторов (и в общем вопрос по адаптивной верстке)
SelenIT replied to Igoritaly's question in HTML Coding
Данный вариант отправляется на свалку возможностью открыть окно браузера не на весь экран (каким бы он ни был). Лучше думать не об экранах, а о контенте — как разместить его оптимальным образом и в какой момент лучше перестроить его иначе. Осмысленных вариантов размещения контента наверняка меньше, чем всех мыслимых размеров окна. -
В январе 2013-го Алексей с Хабра (и Анджей Мазур со Смэшингмэгэзина, которого он перевел) думали совершенно правильно. Но всё меняется, а черновики CSS-спек делают это с особым циниз постоянством. В теперешней версии черновика понятие «субъект селектора» (тот самый восклицательный знак) ушло, но к родителю (а также к предшествующему соседу, например) можно обращаться через :has(). Но с оговорками (см. мой ответ выше) и пока лишь в теории... P.S. И да: CSS-модуль 4 (5, 6...) уровня != CSS4 (CSS5, CSS6...)
-
К родителю, в теории, можно обратиться через :has(). Но W3C настолько от страха за быстродействие, что выделил этот :has() в отдельный «статический профиль», доступный скриптовым API, но не рендереру. Правда, с оговоркой, что «если кто-то из браузеров реализует его без страшных издержек для скорости, то, так и быть, выделять его в этот профиль не будут». Вся надежда на Edge! А вот :nth-child(An + B of что-то) уже почти год как работает в Safari, что радует:)
-
А в Фоксе (даже ночном) дефолтный инпут. Ну, в принципе, за прогрессивное улучшение покатит...
-
А в каких браузерах это работает? Вебкитята?
-
Забудьте про -moz! Не тревожьте покой мертвеца. Те редкие случаи, когда он нужен (в основном шаманства с формами, типа пресловутого ::-moz-focus-inner) обычно уже учтены во всяких ресетах-нормалайзах и трогать их руками не нужно. И вообще эпоха префиксов прошла года три назад, сейчас эпоха флагов (надолго ли — другой вопрос). Сейчас, чтоб что-то заработало, надо не добавлять префиксы, а убирать их (как минимум — дублировать -webkit-вариант беспрефиксным аналогом). Кстати, как раз беспрефиксный вариант бедняге Фоксу всё-таки пришлось с 49-й версии поддержать. Так что если делать не «для вебкитов» и «для фокса», а для браузеров (т.е. не с -moz/-shmoz, а вообще без префиксов — и для @keyframes, что важно, тоже!), то через пару месяцев должно волшебным образом заработать. А пока есть стандартный альтернативный вариант (как минимум для белого/черного фона).
-
Как всегда, вопрос в терминологии:). Для меня наставник — как раз тот, кто наставляет (на путь истинный:), неважно, словом или примером. А тот, кто полностью имеет контроль и не дает сделать шаг туда-сюда — это, наверное... начальник (притом фиговатый:).
-
Есть, имхо, еще одна серьезная проблема — определиться с направлением, куда совершенствоваться дальше, когда количество новой информации зашкаливает. Особенно когда со всех сторон крутые спецы холиворят, принижая любимые инструменты и подходы друг друга, и даже основополагающая спека — HTML5.x/ЖHTML — существует в двух противоречащих друг другу вариантах, сторонники каждого из которых обвиняют другой лагерь в ереси:). Да, можно перепробовать всё самому и сделать выбор лично — но за это время всё перепробованное успеет уйти в историю, на его место придут новые модные штуки, и в итоге ученик рискует навечно застрять в фазе ознакомления, так и не став крутым профи хотя бы в чем-то одном из перепробованного. Вот тут, имхо, может быть очень полезно некоторое время побыть ведомым в связке с крутым мастером чего угодно — чтобы успеть перенять «маленькие хитрости», секреты продуктивности именно этого инструмента/подхода и т.п., в ускоренном режиме и с минимумом шишек пройти «краткий курс ознакомления с типичными граблями» этого подхода, и т.д. В общем, сократить период полной растерянности и выходить из зоны комфорта постепенно, не оказываясь в зоне паники. На мой взгляд, на этом этапе грамотный авторитет рядом, у которого можно что-то подсмотреть и перенять, готовый ответить на вопрос, в т.ч. дурацкий (причем посылом не абстрактно в гугл, а в конкретный раздел документации, либо встречным наводящим вопросом, помогающим самому ухватить логику), и вообще обсудить технические вопросы с высоты практического опыта — ресурс абсолютно незаменимый (и огромное везение).
-
Возможно, в этом случае считается, что высота у блока уже «не совсем auto». А это — одно из условий, препятствующих «раздутию» текста (по текущему черновику спеки). Хотя полностью могут ответить лишь разработчики браузеров (в частности вебкита)...
-
По описанию похоже на эту проблему. Должно помочь body { -webkit-text-size-adjust: none; }. Но, думаю, лучше всё-таки поставить meta viewport с width=device-width и предусмотреть адаптивность)
-
Пардон, но разве в запросах INSERT вообще бывает условие WHERE? По крайней мере, если запрос к одной таблице, как тут? По идее, запрос на вставку должен выглядеть как-то наподобие "INSERT INTO `coments` (`id`, `otvet`) VALUES(".(int)$id_com.", '".mysql_real_escape_string($write)."')" Но вообще вот так напрямую работать руками с запросом, да еще через устаревшую функцию mysql_query — какой-то каменный век, лучше сразу учиться делать это более продвинуто.
-
Всё так... Просто эти маркеры списков — давнее больное место и CSS-стандарта, и браузеров. Они практически неуправляемы, требований к их отрисовке в стандарте практически нет — вот браузеры и делают, как им проще. Поэтому на практике от list-style-image толку очень мало, для мало-мальски предсказуемого результата приходится идти обходным путем. Вроде того, что подсказали выше.
-
Насколько я сам понял, Снук говорит о том, что имена вида .что_то--какое_то должны использоваться для разновидностей и модификаций более общей сущности .что-то. А в том примере речь идет о равноправных и по смыслу похожих, но визуально разных штуковинах.
-
В закомментаренной строке wrire вместо write.
-
Как вариант — object-fit: contain; object-position: top center.
-
Похоже, пример взят из какого-то очень архаичного руководства, чуть ли не от PHP3 (а сегодня актуален PHP7). Лучше держаться от таких музейных экспонатов подальше. Для старта стоит смотреть как минимум сюда.
-
Например, как-то так.
-
А для браузера разницы нет, за </html> или перед </body>. Закрывающие теги для <html> и <body> вообще нужны чисто для красоты успокоения совести кодера, по факту браузер их игнорирует и фактически эти элементы заканчиваются там, где заканчивается последнее содержимое.
-
Да, в данном случае в выборе между формальным соблюдением стандарта и быстротой первичной отрисовки страницы Гугл рекомендует второе. Да, формальное нарушение спеки, но в некоторых случаях оправданное. Да, удовлетворить валидатор и PageSpeed Insights одновременно не всегда возможно — выбирайте приоритеты. Справедливости ради, сейчас WHATWG-шная спека разрешает <link rel="stylesheet"> внутри <body>, так что можно делать как-то так. По W3C-версии это по-прежнему невалидно, но... кого она волнует?)
