SelenIT
-
Posts
4,327 -
Joined
-
Last visited
-
Days Won
140
Content Type
Profiles
Forums
Calendar
Store
Everything posted by SelenIT
-
Еще бы ему не смещаться, если он поднят на фиксированную высоту над нижним краем блока .news. Уберите вот это безобразие: из кода для .news, а взамен укажите Ну и снизу там порядок наведите по ситуации...
-
Ultimate Generator генерирует много лишнего. Как минимум, -ms-linear-gradient не нужен вообще, а из -webkit-вариантов, по-моему, вполне достаточно одного (лично я за первый).
-
Имхо, br-ки тут тупо для демонстрации ненулевой высоты блоков, по сути вместо "lorem ipsum" и подобного. А вот дубликаты id-шек — этого оставлять безнаказанным низзя
-
А в визивиге нет функции установки обтекания (хотя бы по-дореволюционному, через атрибут align)? Если есть, то на мегакрайний случай можно а-ля img[align="left"] { float: left; margin: 3px 10px 3px 0; } img[align="right"] { float: right; margin: 3px 0 3px 10px; } Хотя лучше попробовать допилить сам визивиг, чтобы он при выборе обтекания ставил именно класс...
-
Зачем правым блокам clear: both? Пусть clear-ят только предшественников по своей стороне (т.е. чтоб clear совпадал c float-ом, left для left_line и right для right_line соответственно). И еще, дублирующиеся IDшники — большой грех. Исправьте на классы поскорее, пока гугл не увидел.
-
<meta viewport> не используется?
-
Крабы не различают цветов. Многие из них сидят за монохромными или 8-битными мониторами эры трилобитов. Поэтому поддержкой для них будет не отрисовать градиент любой ценой, а «изящно деградировать» до контрастной и не сливающейся с текстом однотонной заливки.
-
А подложить одну из картинок под кнопку, и делать кнопку то непрозрачной, то прозрачной — не вариант?
-
В "ослах" (5.5 — 9) есть фильтр Matrix (очень похож на матрицы трансформаций в CSS3, только сдвиг надо задавать отдельно), есть генераторы, выдающие их заодно с браузерными префиксами. Но при указанной постановке задачи лично я бы, пожалуй, малодушно сделал по старинке, через image map c <area shape="poly">
-
верстка блока, который появляется только при наличии более 3 заголовков
SelenIT replied to beliy's question in HTML Coding
Оказывается, я неправильно представлял себе работу :nth-last-of-type(). Прошу прощения, что невольно ввел в заблуждение, в котором пребывал сам. Тогда, боюсь, на чистом CSS пока никак не сделать. Только скрипты... -
Замените $('#view').text(val) на $('#view').html(val)
-
Честно говоря, не одобряю такой подход для элементов, у которых предполагается отличная от нуля нативная функциональность. Т.к. браузеры нынче обновляются куда быстрее, чем раз в год, и возможны сюрпризы. Вот, скажем, был неподдерживаемый details с яваскриптовой эмуляцией, а браузер ВНЕЗАПНО111 добавил нативную поддержку, и опа — юзер кликнул, браузер раскрыл, а скрипт инвертировал текущее состояние и закрыл обратно... и всё Для цитированного подхода, имхо, нет ничего лучше заведомо безопасных старых добрых div-ов и span-ов (если им еще логичные aria role — вообще супер).
-
Как я понимаю, предполагалась следующая ситуация. Например, есть приложение, позволяющее что-то делать с картинками. Тогда можно сделать "абстрактную" команду, например, вызывающую какое-то действие с картинкой (скажем, наложение спецэффекта): <command id="doStuffWithImg" onclick="doSomeCoolFullyHTML5izedAndCSS3edShinyAndAnimatedStuffWithImage()"/>положить ее в <head> и обращаться к ней из разных интерактивных элементов: <button command="doStuffWithImg">Суперэффект для картинки</button> <img src="картинка-без-эффекта.jpg" contextmenu="menuForImg" title="Кликни правой кнопкой и посмотри, что тут есть!" /> <menu type="context" id="menuForImg"> <command label="Применить суперэффект по правой кнопке" command="doStuffWithImg" /> </menu> <button command="doStuffWithImg">А можно вызвать эффект и отсюда</button> А потом, например, если картинка не активна, можно сделать $('#doStuffWithImg').disable() — и тем самым задизейблить обе кнопки и пункт контекстного меню, связанные с этой командой, в одно действие. Но это пока лишь в теории (точнее, в голове Хикси)...
-
Насколько я понял, в HTML5 решили унифицировать работу с интерактивными штуковинами (ссылками, кнопками, чекбоксами и т.п.), особенно в контексте веб-приложений. И ввели абстракцию "команда", которую можно применить к любой из этих штуковин, со специальным DOM API. А заодно, раз пошла такая пьянка, завели отдельный элемент, позволяющий юзать это API напрямую. Т.е. элемент <command> (обычно размещаемый в <head> и не отображаемый), по задумке, хранит некую команду (напр. вызов JS-обработчика), эту команду можно повторно юзать в разных интерактивных штуковинах (напр. в виде <button command="id_команды">), инейблить/дизейблить в одном месте для всего приложения сразу и т.п. Ну а раз все интерактивные штуки могут встречаться в меню (которое тулбар и которое контекстное), то поневоле (в силу единого API) там может встречаться и сама <command> (и это единственный случай, когда она рисуется непосредственно). А вот дальше всё стало еще страньше и чудесатее. Мозилловцы реализовали-таки контекстные меню, но... решили, что имя "command" неинтуитивно и приводит к путанице (особенно в варианте <command command="id_другой_команды"> — когда одна команда, отображаемая в меню, ссылается на другую, невидимую), и ввели вместо него собственный элемент <menuitem> (который, насколько я понял, уже использовался в их языке описания интерфейсов, XUL). А "HTML5-диктатор" Хикси не захотел внимать мозиллиным доводам. И, насколько я понял, на сегодняшний день получается бредовая ситуация, когда единственная (известная мне) реализация работает не по спеке (и формально невалидна!), а примеры из спеки не работают-таки нигде, и вряд ли спека с реальностью в скором времени сойдутся. Посмотрим, куда этот маразм вырулит в итоге...
-
В забугорнете для этой траблы есть хорошее название "Containing floats", адекватного русского варианта не знаю (кроме длинного "борьба с вываливанием float-ов"). Есть два подхода к решению — вышеупомянутая «очистка потока» и создание отдельного контекста форматирования. Надеюсь, вот это слегка поможет разобраться
-
верстка блока, который появляется только при наличии более 3 заголовков
SelenIT replied to beliy's question in HTML Coding
Для новых браузеров (IE9+) получается так. Приходится указать общий класс заголовкам и этому блочку, чтобы nth-last-of-type мог посчитать их вместе. В старых браузерах типа IE8 блочок будет всегда виден — имхо, вполне "изящная деградация". Ну и красивых закруглений/теней в старых не будет... Заблуждался. Приношу извинения. -
Между ними — никакой. Но в первом случае, чтобы сделать опцию снова видимой, нужно явно переопределить display и "не промахнуться" (чтобы не поставить браузер в неловкое положение), а во втором достаточно просто убрать класс, и опция сама вернется в нормальное видимое состояние.
-
У меня 16.0.1, по моим данным, она последняя и есть. Я бы просто не ставил display: none тем опциям, которые скрывать не надо — пусть браузер выводит их так, как привык (хороший способ — завести класс навроде .invisible { display:none; } и присваивать/убирать его нужным опциям при необходимости).
-
Graceful degradation всё-таки получше у бордера. В IE8 будет хоть угловато, но хоть разлиновано, а с тенью — белое на белом. Размеры можно через box-sizing укротить, если критично. Вот вместо outline тень — то что надо (и даже для старых IE легко эмулируется через filter:glow). А от collapse в данном случае зависит не бордер, а радиус, так что закругления будут или не будут независимо от того, чем их рисовать. UPD. Век живи, век учись. Действительность оказалась сложнее и интереснее моих представлений. Закругление самих border-ов, действительно, от border-collapse во всех браузерах, кроме IE9 (пример), но в Опере уголки ячеек получаются целиком квадратными, а в Firefox и Chrome прямые линии табличной сетки накладываются на закругленные границы padding-ов ячеек! На мой взгляд, Опера ведет себя честнее и последовательнее всех, но стандарт говорит лишь, что браузерам "предпочтительно игнорировать border-radius для внутренних элементов таблиц с border-collapse:collapse", а не "требуется" (т.е. в определенных случаях при веской причине этим можно пренебречь, и такой причиной вполне может быть обратная совместимость)...
-
То, что в Firefox (громадная белая простыня, уходящая за край окна, в самом верху которой сиротливо жмутся в одну строчку опции)... это точно нормально? Зачем вообще насиловать опции чуждым им display:inline-ом?
-
Имхо, в таком случае лучше помочь человеку "распаниковать" и разобраться. Что для нужного результата нужно всего-навсего, чтобы радиус закругления был больше толщины border-а (т.к. по стандарту меряется этот радиус по внешнему краю border-а), причем не только для ячеек, а вообще. А в таблице единственное, что может "сломать" закругление углов — это border-collapse: collapse.
-
Насколько я в курсе, в большинстве случаев критичнее количество запросов. Оттуда объединение скриптов и стилей в монолитные файлы (с последующим gzip'ованием), объединение картинок в спрайты и запихивание этих спрайтов в data-url в тот же CSS, и подобные выкрутасы. Лично я стараюсь оптимизировать картинки "на глаз" при любой возможности. По моему опыту, для JPEG в большинстве случаев приемлемый результат получается при качестве 60-65 в фотошопе (а для превьюшки без резких переходов часто и 40 достаточно) и 93 в большинстве библиотечек для автоматизации (GD в PHP, Image.Save в .NET и т.п.). Для PNG хороший эффект дает Color Quantizer с ограничением кол-ва цветов до 512–2048. Запас по разрешению для "ретин" и нестандартных масштабов делаю, только если явно попросят.
-
Немножко не понял, а чем натуральный бордер хуже? По идее, если border-collapse: separate (а он по умолчанию такой), всё должно работать естественным образом...
-
Совсем-совсем малюсенький, плюс всего ничего 250 кБ (ну ладно, 32 кБ в сжатом виде) самого jQ
-
Зачем столько строк для вывода таблицы?
