SelenIT
-
Posts
4,327 -
Joined
-
Last visited
-
Days Won
140
Content Type
Profiles
Forums
Calendar
Store
Everything posted by SelenIT
-
Не льстите себе, неуловимый Джо . Чтобы контент начали воровать, нужно, чтоб сперва его нашли. А для этого его должны прочитать честные поисковики. И им такие выкрутасы ох как мешают...
-
Css. изображения выстроились лесенкой, хотя мне нужно в один ряд.
SelenIT replied to knopka3's question in HTML Coding
Возможно, оно осталось как пережиток времен IE5-6, когда это было лекарством от одного из его багов (удвоения margin-ов). -
box-shadow с нулевым размытием, подвинуть куда надо на сколько надо?
-
1) Это произвол почтового сервиса (речь ведь о веб-интерфейсе, верно?). Почтовики нещадно режут стили (не говоря уже о скриптах) в HTML-письмах — как бы ради безопасности. 2) По стандарту HTML можно указывать ширину в безразмерных единицах (width="600" и т.п.), они должны интерпретироваться как пиксели. Пропустит ли конкретный почтовый сервис — другой вопрос, надо проверять. Вообще вёрстка писем связана с кучей ограничений. Неплохие статьи по теме бывают на Хабре (вот буквально сегодня пример).
-
Всё зависит от парсера. Для XML-парсера закрывающий слеш — признак «самозакрытия» тега. Для строгого SGML-парсера (такого, как у W3C-шного валидатора HTML 4 — к счастью, в реальном мире это единственный случай) слеш сам по себе считается концом тега, а знак «>» после него считается текстом. Для парсеров браузеров и их «общего знаменателя» — парсера HTML5 — этот слеш не значит совсем ничего (никак не связан с закрытостью/открытостью тега, но и не приводит к неоднозначности/ошибке). IDE, вероятно, использует XML-парсер (в чем есть смысл, поскольку он быстрее, а IDE приходится парсить в реальном времени). Так что вполне можно пользоваться XML-подобным синтаксисом. Но время от времени нужно проверять себя и HTML5-валидатором — не все XML-фичи одинаково полезны. В частности, ставить закрывающий слеш есть смысл только для пустых элементов (у которых никогда не бывает контента). Писать по аналогии <div /> или <span /> нельзя — поскольку для браузеров слеш ничего не значит, они воспримут это как обычный незакрытый тег.
-
А придется...
-
Если абстрагироваться от IE9-, можно попробовать использовать column-width (правда, блоки пойдут не по горизонтали, а по вертикали, по столбцам, но визуально будет как надо). Для кроссбраузерности, имхо, проще и (пока) надежнее всего использовать jQuery Masonry. Банально получается картинка слева
-
Насчет английского — это зря, он в IT-отрасли в любом случае пригодится. Надмозг, да, слабый помощник В общем, там принципы, которых придерживались сами разработчики стандарта: совместимость с имеющимся контентом, «мостить проторенные тропы», т.е. узаконивать устоявшиеся решения вместо выдумывания чего-то «с потолка», эволюция вместо революции (т.е. не отбрасывать старое, если оно еще используется, а лишь уточнить его), решать реальные проблемы, а не надуманные, и т.п. Т.е. именно упор на прагматику, а не на «сектантство», как бывало во времена прошлых спек. В частности, говорится, что удобство для пользователей важнее удобства для верстальщиков, удобство для верстальщиков важнее удобства для разработчиков браузеров, удобство для разработчиков браузеров важнее удобства для авторов спеки, и всё это важнее абстрактной «теоретической чистоты». Оно не совсем равносильно по спецификации, в этом-то всё и дело. Но пользоваться можно всем, что явно не запрещено спецификацией — если, конечно, это решает больше проблем (напр. удобочитаемость кода), чем создает (напр. приводит к путанице с экранными читалками для слепых)
-
Нет, просто стараюсь в мере своих сил противостоять распространению расхожих заблуждений, включая мои собственные (я вполне допускаю, что я могу быть неправ, но прошу доказать это конкретными ссылками ). Кстати, вот еще неплохой документ на тему, «зачем и как придуман HTML5».
-
HTML тег, удовлетворяющий последним спецификациям HTML
SelenIT replied to Guesto's question in HTML Coding
Как определить, стандартна та или иная фича того или иного веб-языка или нет: совет Лии Веру. -
Вы не поверите, но <!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Strict//EN" "http://www.w3.org/TR...l1-strict.dtd"> — тоже (хоть и не является рекомендуемым для HTML5). Ибо нет больше HTML, кроме HTML5 . На здоровье, стандарт этого не запрещает . Но прагматически, <!doctype html> — всего лишь способ гарантированно получить стандартный (без всяких «почти-шмочти») режим во всех браузерах, начиная с IE6, минимальным количеством байт. А вот это, к сожалению, похоже на горькую правду . Насколько я в курсе, практически ни один агент не интерпретирует их «семантику» по спецификации, так что их практическая польза стремится к нулю. Разве что для самодокументирования кода...
-
Ну и чем добавить пару нужных в конкр. задаче тегов/атрибутов + короткие доктайп и мету с кодировкой к обычной дивной верстке — не эволюционное расширение? Нет, чистая прагматика. Зачем пользоваться тем, что не приносит никакой практической пользы (ни поисковикам, ни скринридерам и т.п.) и почему не пользоваться тем, что работает (как минимум в новых браузерах) и решает практические задачи?
-
В UL/OL могуть быть только LI. А уже в них — что угодно, включая вложенные списки любого типа. То, что есть — ошибка построения DOM, которую браузер имеет право обработать как попало
-
А юзер без мышки сможет заполнить эту «форму»? А слепой юзер со скринридером? хотя о чем это я — тут и юзер с мышкой ничего не заполнит
-
О, холиворчик! Кого именно из 100500 взаимоисключающих авторитетов (и «авторитетов») по вопросу? Насколько я знаю — изначально HTML5 создавался как основа эволюционного расширения существующей веб-платформы новыми плюшками, прежде всего для веб-приложений (о чем говорит его «девичья фамилия» WebApplications 1.0). А потом пошло-поехало. С фига ли вдруг?
-
По симптомам — практически 100% BOM-метка. Вот в каком файле — сходу не скажу.
-
Не совсем. Попробуйте открыть несколько разных ссылок сначала с одним, а потом с другим target-ом
-
А вот постом выше — живой пример
-
Если не ошибаюсь, в статистике посещений под «хостами» обычно подразумевают уникальные айпишники.
-
Сглаживание (в т.ч. субпиксельное), кернинг... Работа со шрифтами в фотошопе и браузерах разная и, насколько я в курсе, ничего с этим не поделать. Такие небольшие расхождения — это неизбежно и нормально, имхо.
-
Знак вопроса вместо русского текста.Для опытных верстальщиков
SelenIT replied to Doctor_Chil's question in HTML Coding
Хм, а откуда вообще взялся такой гибрид? Ладно бы старинный <meta http-equiv='Content-Type' content='text/html; charset=utf-8' />... но зачем, если достаточно просто <meta charset="utf-8"> ? -
Только не в CSS А в фотошопе всё зависит от DPI макета, заданного при его создании. При 72 — да, 1:1, при 300 (типа стандарт для полиграфии) — аж 1:4 с лишком. При 96dpi, в теории, будет соотношение как в браузерах, но полагаться на это я бы не стал — нюансов округления, сглаживания, хинтинга и т.п., к сожалению, пока не отменили.
-
Он используется в микроданных. Клеится практически к чему угодно, но должен быть внутри элемента с itemscope, частью описания которого является. Спецификация этих микроданных (в версии W3C ее отделили от основной спецификации HTML5, в версии WHATWG пока всё в куче) разрешает использовать и meta в body, но только при наличии того самого itemprop и внутри элемента с itemscope, в соответствии с опред. словарём.
-
По большому счету действительно ни при чем, имхо . Но как минимум Firefox и Chrome по умолчанию стилизовали заголовки <h1> не одинаково, а с учетом вложенности секций/артиклов/навов/асайдов. Имхо, это можно назвать «поддержкой алгоритма для порядка в семантике». Насколько я в курсе, там прежде всего со скринридерами для слепых (в частности, JAWS) возникли какие-то проблемы...
-
То письмо Фолкнера я привел исключительно для примера, что по многим вещам в этих outline-ах даже авторам спеки еще далеко до согласия. Наверняка оно не последнее по теме, просто лень было гуглить глубже . Описал этот алгоритм Хикси действительно так, что черт ногу сломит. Перехода от <h1> ... <h6> к универсальному <h> не будет, я гарантирую это (в XHTML2 уже пытались, и где тот XHTML2?). Но вот отказаться полностью от путаницы с sectioning content-ом и вернуться к старой доброй иерархии одних лишь заголовков (в волне «поминок по <hgroup>» звучали такие призывы, жаль, сходу не нагугливаются конкретные примеры)... кто знает, лично я такой вероятности не исключаю
