SelenIT
-
Posts
4,327 -
Joined
-
Last visited
-
Days Won
140
Content Type
Profiles
Forums
Calendar
Store
Everything posted by SelenIT
-
Точнее, по новой спецификации все браузеры глючат одинаково
-
Можно я поотдуваюсь за даму? 1) "Phrasing content" — по сути новое название инлайновых элементов. Определяется как "текст и элементы, размечающие что-то в пределах абзаца". Как я понимаю, их политкорректно переименовали, чтобы не плодить путаницу между моделью контента и отображением в CSS: всё-таки инлайн — это больше про отображение, а смысл таких элементов — какая-то часть фразы. 2) Это "изолятор" схемы документа (которая "document outline" — то самое "как бы оглавление", которое строится по заголовкам секций, проверяется outliner-ом и показывает правильность семантической структуры). Главный sectioning root — это body. Но у всяких figure и т.п. есть своя собственная outline, изолированная от главной. Поэтому они тоже sectioning root-ы, только маленькие
-
Пардон: Validation Output: 1 Error Error Line 9, Column 4: Element li not allowed as child of element body in this context. (Suppressing further errors from this subtree.) <li>Test</li> Contexts in which element li may be used: Inside ol elements. Inside ul elements. Inside menu elements. Content model for element body: Flow content. То же самое с попыткой всунуть LI в div и т.п. C HTML4 тоже ошибка:
-
Хм, я когда-то такое решал? Забавно... совсем не помню Но на медиа-запросах действительно решается несложно (в опред. пределах, как и всё, с медиа-запросами связанное).
-
Именно так . Для этих 4-х — всегда, для всех остальных — по желанию.
-
Ну я и добавил "имхо". У меня в пользу "символов как есть" два чисто субъективных аргумента — "если не видно разницы, зачем тратить больше байт" (5-7 вместо 2-3 на символ) и не угадывать, "что имел в виду автор", читая исходник (я ж не помню все подстановки на память, особенно числовые). Но есть и объективные аргументы против — например, за Дримвивером я замечал противную черту при каждом удобном случае скукоживать неразрывные пробелы в обычные, использование подстановок от таких вольностей страхует (я-то Дримом не пользуюсь и молодых коллег тоже отучил, но в общем случае при командной работе с подстановками надежнее)...
-
Не надо бояться HTML-подстановок. Для вывода спецсимволов HTML (их всего 4 — <, >, " и &) соотв. подстановки (<, > " и &) — самый пуленепробиваемый вариант, выведутся в лучшем виде хоть в форму, хоть просто текстом, ни с чем не конфликтнут и дадут простейшую, но во многих случаях достаточную защиту от XSS. И не надо путаться в разномастных кавычках в коде. Плюс во всех веб-языках есть стандартные средства для такой замены (в PHP — htmlspecialchars). Вот другие символы, типа «» и даже неразрывного пробела, имхо, лучше выводить как есть — в кодировке UTF-8...
-
Совсем забивать не надо, graceful degradation — правильный подход. Ссылки должны остаться заметными и нажимабельными, но если бы вместо красивых квадратиков несчастные пользователи IE6 увидели просто цифры — я думаю, мир бы не перевернулся. К счастью, в данном случае и таких жертв не надо
-
Для span (и др. изначально инлайновых эл-тов) поддерживаются и без zoom. Но вообще "искать решение на HTML5" и при этом требовать попиксельной точности в IE6 — не многовато ли? Кстати, таблица тут тоже не особо нужна...
-
Таблицей некреативно . А вот домики Криса Хестера (2005-й, когда никакими градиентами в браузере, кроме глючных IEшных фильтров, и не пахло!) - это впечатляло (вот, нашел подборку с ними и еще десятками образцов для вдохновения).
-
Ставьте доктайп <!DOCTYPE html> (где валидны оба варианта) и не тратьте время на эти предрассудки.
- 1 reply
-
- 1
-
-
Имхо, здесь вполне подойдет старый, но надежный прием "раздвижных дверей".
-
Использование таблицы критично? По ячейке на уголок — слишком расточительно. И вообще без таблиц такие вещи делаются проще (даже если не брать новые фичи CSS3, позволяющие сделать такое даже без оформительских картинок).
-
Можно ли как нибудь сделать границы (border) полупрозрачными?
SelenIT replied to skoch244's question in HTML Coding
Теоретически можно выкрутиться через псевдоэлемент, но IE9, похоже, отказывается применять для него фильтр с градиентом. Еще можно поколдовать с наложением полупрозрачных теней (по бокам будет не ахти, но на невысоком блоке с закругленными углами, кажется, не так уж и страшно)... -
Это так было в 2001-м году, когда Крокфорд писал свою легендарную статью. Сейчас бросать косые взгляды на яваскриптеров, наоборот, не круто — этак можно расписаться в непонимании мощи синтеза функционального и ОО-подхода, да и вообще в том, что так в 2001-м и застрял. А ФП, по моим наблюдениям, сейчас вообще в моде...
-
Ну если аяксом, тогда не вижу проблемы измерить ее ширину JS-ом сразу после вставки данных, и задать эту ширину нижеследующему блоку.
-
Прямо так и изобразили несколько состояний — таблица узкая, блок за ней ужимается в узкую колонку, таблица широкая, блок расширяется вслед за ней? Имхо, вы зря себе жизнь усложняете. Ставьте внешнему блоку max-width: 45% (например), а таблице 100% ширины — и никто не будет придираться к зазорам в ячейках, я практически уверен.
-
Не знаю. Может разве что display:table для li...
-
Если пункты однострочные, то, может, хватит list-style-position: inside? А вообще сбросить list-style-type в none и задать что-то своё (можно даже не фоновыми картинками, а псевдоэлементами, а в IE7 и ниже оставить по дефолту) — вполне себе красиво, имхо.
-
Т.е. нужно ограничить ширину всей конструкции шириной таблицы, которая, в свою очередь, имеет размер по содержимому? Честно говоря, с трудом представляю, где такая задача может понадобиться. Обычно, если дается простор содержимому, то всему (для красоты можно таблицу растянуть по ширине нижнего блока), если задается ограничение — тоже всему (поставить разумную цифру в % или em и поджимать весь контейнер до нее). Единственный способ зафиксировать ширину блока по соседу, который приходит на ум — задать ему абс. позиционирования + left + right (типа такого), но это безвозвратно вырывает его из потока...
-
Я в принципе чисто еду имел в виду. Просто, по воспоминаниям 2003-го года, московские цены на еду отличались от минских ну максимум на 20-30% (а всякие йогурты и т.п. бывали и подешевле). И в Минске миллиона белрублей (где-то $110 по новому курсу) на еду на человека в мес. впритык, но хватает (и большая часть страны живет выживает как-то, после этой девальвации). Просто я, когда подумываю о смене работы с переездом, исхожу из минимума (на первые месяцы) в размере "цена съема жилья + расходы на транспорт + $150 на еду". В Москве, выходит, арифметика другая?
-
Интересует это направление Какой там потолок? И что, в МСК действительно такие дикие цены, что $100-150 не хватит на месяц на еду одному человеку?
-
Сильно раздражает необходимость применять свойства ради их побочного эффекта. Почему бы, к примеру, не ввести свойство типа blocks-context: auto (in-flow)/isolate, единственным эффектом которого было бы создание контекста (чтобы не приходилось судорожно выбирать, чем пожертвовать ради обтяжки контейнером поплавков — автошириной при display:table etc. или возможностью выносок из блока при overflow)?
-
Пробовали, на примере HTML3.2 ? HTML4/XHTML1.0 ? XHTML1.1/Basic ? XHTML2. На 3-м шаге вся красивая и абстрактно верная (для сфер. вакуума) теория катится в шредер из-за необходимости поддержки существующего контента. Другое дело, что по прагматичному пути WHATWG (начать с того, чтобы проанализировать, а что вообще сейчас поддерживают браузеры и как, а также какими "коровьими тропами" разработчики обходят популярные косяки, и привести весь этот массаракш к общему знаменателю) разработчики CSS тоже не пошли. Вот это жаль, имхо. Для начала, хотя бы, сделали бы вот эти штуки частью стандарта (а не "заметками на полях", как сейчас), чтобы относительно этих снэпшотов можно было "валидироваться". А то вообще бред — язык развивается по модульной безверсионной модели, а "валидатор" до сих пор этого не знает и мешает модули разной готовности в одну кучу Ну а что касается селекторов, то по модульной модели всё логично. Селекторы 3-го уровня готовы и заимплеменчены во всех браузерах, менять спеку больше нельзя — а нововведения требуются...
-
Нельзя. Все открывающие <form> до первой закрывающей </form> тупо отбрасываются при парсинге. Можно так: <form method="post" action="handler.php"> <input type='text' name='num'> <input type="submit" name="scenario1" value="Перейти на страницу 1"> <input type='text' name='res'> <input type="submit" name="scenario2" value="Перейти на страницу 2"> </form> а в handler.php: if (isset($_POST['scenario1'])) { // что-то делаем с переменной $_POST['num']; header('Location: http://'.$_SERVER['HTTP_HOST'].'/1.php'); exit(); } elseif (isset($_POST['scenario2'])) { // что-то делаем с переменными $_POST['num'] и $_POST['res']; header('Location: http://'.$_SERVER['HTTP_HOST'].'/2.php'); exit(); } else { // непонятно что нажали — какое-то дефолтное действие или ошибка } А еще всякие мелочи, не требующие отправки всей большой формы, можно обрабатывать аяксом.