SelenIT
-
Posts
4,327 -
Joined
-
Last visited
-
Days Won
140
Content Type
Profiles
Forums
Calendar
Store
Everything posted by SelenIT
-
Задачка сомнительная, но может кого заинтересует?
SelenIT replied to swetlana's topic in Goods and Services
Фигня, а не меню. Вся прелесть яваскриптовых менюшек, которая не скоро светит CSSным — возможность задержки исчезновения вложенных подуровней при случайном уводе на миллиметр за границу родителя (юзабилити улучшается на порядок). А тут как в худших примерах выпендрежа с :hover-ами: шаг вправо, шаг влево — расстрел начинай сначала, с самого верхнего уровня. И как в еще более кошмарных примерах, всё на атрибутах onmouseover/onmouseout в каждом пункте, прямо в разметке. Низачот -
И таки очень похоже, что да . В т.ч. с точки зрения "утиной типизации", имхо.
-
psywalker, Практически от балды . Моей идеей было, чтобы для HTML5-парсера получилась примерно такая outline: ? Главная ?? Важный раздел ?? Интересный подраздел ?? Какая-то страница изолированная от основной outline страницы. Код чисто иллюстративный. Это не значит, что я рекомендую именно такую схему для реальных проектов, скорее наоборот . s0rr0w, Да, всё так: проекция на одну ось, банальный одномерный массив. Но это одно измерение — именно глубина, а не ширина. И, на мой взгляд, для крошек это существенно. Простой список этого не передает совсем. А передать очень хочется...
-
Имхо, "что-то иное". Не nav, т.к. смена вида представления — никак не основная навигация на этой странице. Но и вряд ли menu, т.к. магазин — "не настолько" веб-приложение, да и меню из двух кнопок, отвечающих по сути за один признак — как-то "куце". Вот если б там же была полная настройка представления — число товаров на страницу, тип сортировки и т.п. — тогда можно было бы сильнее поколебаться в пользу menu...
-
Говорят, что с однопиксельными полосками тормозят старые IE. Сам особо не наблюдал, но с тех времен взял за привычку нарезать полоски пикселей по 10-20. Возможно, сегодня это и не актуально, но разница размера файла настолько смешная, что я не вижу для себя резонов переучиваться
-
Задачка сомнительная, но может кого заинтересует?
SelenIT replied to swetlana's topic in Goods and Services
Вот такое готовое решение (проверенное временем, автора знаю как одного из компетентнейших JS-спецов в Рунете) не сгодится? ТЗ, на первый взгляд, удовлетворяет... -
Ничего устанавливать не надо. На том сайте по ссылке "@font-face Kit" есть генератор, создающий необходимые файлы и CSS для всех браузеров. А потом можно что-то типа такого (точно не подгонял, чисто показать принцип): <!DOCTYPE html> <title>Noah Lubin</title> <style> @font-face { font-family: 'TeXGyreAdventorRegular'; src: url('texgyreadventor-regular-webfont.eot'); src: url('texgyreadventor-regular-webfont.eot?#iefix') format('eot'), url('texgyreadventor-regular-webfont.woff') format('woff'), url('texgyreadventor-regular-webfont.ttf') format('truetype'), url('texgyreadventor-regular-webfont.svg#webfontVNQ4fiYu') format('svg'); font-weight: normal; font-style: normal; } html, body { margin: 0; padding: 0; } h1 { font: 60px/68px 'TeXGyreAdventorRegular', Arial, sans-serif; letter-spacing: 0; color: #888; width: 1000px; margin: 0 auto; } .header { min-width: 1000px; background: #888; padding: 2px 0; text-align: center; font: 14px/18px 'Times New Roman', serif; text-transform: uppercase; } .header ul, .header li { display: inline; list-style: none; } .header form { display: inline; } .header a { display: inline-block; color: #888; background: #fff; padding: 0 10px; text-decoration: none; margin: 0 5px; } .header a:hover { color: #fff; background: #ccc; } .header label { display: inline-block; color: #fff; background: #ccc; padding: 0 5px; } .header input { height: 14px; font: 12px/14px Arial, sans-serif; padding: 0; border: 0; vertical-align: 1px; margin: 0 0 0 5px; } </style> <h1>Noah Lubin</h1> <div class="header"> <ul> <li><a href="#">Home</a></li> <li><a href="#">Gallry</a></li> <li><a href="#">About</a></li> <li><a href="#">My Videos</a></li> <li><a href="#">Contact</a></li> </ul> <form action="#"> <label>Search <input name="q"> </label> </form> </div>
-
Вот статья, куда я каждый раз сам подглядываю за этими примерами: http://cssing.org.ua/2007/12/06/expression-optimization/ Еще красивый (хоть и уже неактуальный) пример эмуляции :before/:after был здесь. Просто тут я рассуждал не как верстальщик, отдающий работу "в пространство", а как кодер, прикручивающий верстку к собственному движку. И тут мне проще добавить в админку поле "картинка для украшения главной страницы", а в код страницы — что-нибудь типа <?php $image = $page->decorativeImage; $size = getImageSize($image); if ($size) echo ' style="background-image:url(/images/'.$image.');padding-right:'.$size[0].'px"'; ?> а визивига секретарше вообще не давать . Но это уже глубоко уходящая в оффтоп философия...
-
Честно говоря, вообще не вижу тут картинок, кроме этого красного логотипа. Для заголовка есть прекрасный бесплатный веб-шрифт, остальное — однотонные прямоугольники, прекрасно делающиеся обычным background-color...
-
Буквально начав набирать ответ, понял, что не список по еще одной причине: элементы пути не однородны, отношения между ними — не просто последовательность, а именно иерархия, подчиненность последующего предыдущему. Если (по аналогии с грубым, но верным замечанием sorrow) страдать секцие- и аутлайнозадр... в общем, фанатизмом , "семантичнее" должна быть структура примерно такого плана (знаю, что это бред, но чисто в порядке мозгового штурма...): <figure role="breadcrumbs"> <!-- figure изолирует outline крошек от основного outline страницы, role="breadcrumbs" сейчас не существует и приведено просто для примера "было бы хорошо, если..." --> <figcaption>Вы здесь:</figcaption> <section> <h6><a href="/">Главная</a></h6> / <section> <h6><a href="/section/">Важный раздел</a></h6> / <section> <h6><a href="/section/subsection/">Интересный подраздел</a></h6> / <section> <h6>Какая-то страница</h6> </section> </section> </section> </section> </figure> Поскольку этой иерархичности в полной мере не раскрывают как список, так и обычная строка — имхо, вполне применим подход "если не видно <существенной> разницы, зачем платить писать больше". Плюс у обычной строки преимущество большей наглядности при отключенных/недоступных стилях (о чем я упоминал в исходной теме). Еще я подумал, что для иерархических отношений между ссылками просто обязано существовать специательное значение атрибута rel, но, похоже, с этим атрибутом вообще какая-то свистопляска (были какие-то предложения еще в HTML4, но от них, судя по всему, давно отказались, потом в HTML5 хотели сделать по-другому — и о5 не сделали). А жалко — по-моему, семантике отношений между ссылками в крошках в этом атрибуте как раз самое место... Имхо, вся прелесть обычных ссылок в строке — что ими и управлять практически не надо, они сразу ведут себя как нужно . К тому же ссылка — сама по себе контейнер, а концевой элемент можно обернуть чем-нибудь слабосемантично-выделяющим, типа b/i. Общий контейнер, конечно, будет — например, p, как предлагает Serlutin. И стиль этого контейнера будет определять вид разделителей. С Li-шками же эти разделители сразу становятся источниками проблем. Между Li-шками их не всунуть, вставлять внутрь — непонятно с какой стати, плюс разделители становятся ассиметричными, что сразу усложняет стилизацию, генерировать CSS-ом — все те же проблемы плюс костыли для браузеров... Причем ваще неупорядоченных. Они там точно того...
-
Ключевые слова для поиска: ЧПУ ("человекопонятный URL"), mod_rewrite.
-
Это называется "конфликт бордеров" и разруливается он по следующим правилам: Здесь как раз работает последний пункт...
- 1 reply
-
- 1
-
-
psywalker, спасибо за развернутый ответ! Честно говоря, я пока не увидел достаточных аргументов за список в данной ситуации (кроме неких отвлеченных абстракций). С точки зрения т.н. "утиной типизации" (aka здравого смысла), списком должно быть нечто, что выглядит как список и ведет себя как список — но строка навигации с разделителями явно под этот критерий не подходит... В принципе, для добавления палочек достаточно "одноразовых" экспрешнов, напрягающих браузер лишь при загрузке. Но я согласен, что экспрешны в этой задаче не нужны — как и, имхо, списки, порождающие новую семантическую дилемму ("куда девать палки") и необходимость либо нетривиальных финтов, либо досадных компромиссов для ее решения. Так что экспрешны я упомянул скорее, чтоб довести пример до абсурда, прошу прощения за такой троллинговый прием Можно посмотреть и так, что текст сделан коротким для удобства чтения (слишком длинные строки ломают глаза), а как раз картинка затыкает собой получившуюся дырку, заодно визуально уравновешивая композицию . Я не вижу нужды тексту расширяться. И картинку я бы всё-таки поставил фоном на контейнер. Но если требование расширения текста критично, можно описать фоновую картинку и правый отступ в одном классе .decorated-with-friends-picture, и в зависимости от нужды в картинке или ее отсутствия добавлять/убирать контейнеру этот класс. А если владелец сайта захочет поставить другую картинку, другой ширины — сделать для нее другой аналогичный класс с соотв. параметрами. И никакой добавочной разметки вообще! Но это в идеальном мире, с идеальной CMS, заточенной спецом под этот сайт. В реальном мире, где странички правятся WYSIWYGами, твой вариант, пожалуй, лучший. Хотя секретарша, которую заставят менять картинку, скорее всего, всё равно сделает просто и железно — таблицей...
-
Я тоже сталкивался. Но, во-первых, ссылка и форма — разные вещи, во-вторых, понятно, что это "рыба", в рабочем сайте так не останется. Хотя согласен, в HTML5 невалидно (но в XHTML1/HTML4, про которые речь — нормально). Про nav понятно, а про остальное — можно пояснить? Я приводил доводы против того, чтоб делать "хлебные крошки" списком. Если я в упор не вижу чего-то важного — прошу подсказки, чего именно. В случае обычной строки со ссылками оба требования выполняются автоматом . Но, если гнаться за абстрактным совершенством, :before/:after легко эмулируются экспрешнами. А что не так у них с масштабированием? Меня несколько сбило с толку следующее: Как рассуждаю я: если картинка не является частью содержания, чисто декоративная, то зачем тексту ее обтекать — пусть себе занимает место под отступом в качестве фона самого контейнера текста, и не надо вообще дополнительных блоков. Если же ее наличие/отсутствие как-то сказывается на тексте — волей-неволей приходится признать ее частью контента. И, поскольку отсутствовать картинка может по разным причинам (банально недогрузилась, выключены в браузере и т.п.), то самое простое средство обеспечить сжатие/растяжение текста в зависимости от этого — именно <img> с float и без указания размеров (с искусственной пустышкой возможна ситуация, когда картинки нет, а отступ есть — так за что боролись?). Кроме того, фоновые картинки не печатаются, а это как бы сплеш-страница, на которой графика — часть фирменного стиля. В общем, с моей точки зрения под каким углом не посмотреть, отдельная пустышка с картинкой оказывается ни к селу (правильному поведению контента в зависимости от нее), ни к городу (чистоте разметки)... хотя, возможно, это проблема моей точки зрения
-
Макс, по п.6-7 — это я посоветовал в другой теме. Блок новостей на этой странице вообще второстепенная вещь, одной кастрюли для него, имхо, вполне достаточно. Для HTML5-парсера на секции, заносящиеся в outline, он делится как раз заголовками (именно за этим они там). А в рамках HTML4 (по ТЗ предполагалось ограничиться им) лично я не вижу, как оборачивание каждой новости в отдельный пакетик добавит ей какой-либо семантики (особенно в отсутствие заголовка), только увеличит кол-во п. 22 . Разве что для оформительских целей, но по макету я и в этом не видел необходимости (тут каюсь, моя невнимательность — недоучел нижнюю черту под последней новостью). Насчет обертки уже вижу, что я ошибался. Насчет прочего — буду благодарен за расширение кругозора и избавление от заблуждений. П. 10 — по-моему, вполне легитимный вариант для отправки формы "самой себе". Ясно, что в боевом проекте там будет конкретный адрес скрипта, на мой взгляд, для верстки это не недостаток. П. 13 — имхо, список к бредкрамбсам притянут за уши. Да, иерархия вроде как предлагает последовательность, но само название "строка навигации" говорит о его строковой природе. В HTML5, имхо, он вполне может быть <nav>-ом с обычной строкой ссылок внутри. Вообще, имхо, хороший тест на семантику разметки — обычное отключение стилей в браузере. Если юзер читает, к примеру, на маленьком мобильнике: имхо, вместо ожидаемой ясности первой реакцией будет растерянность "ну и где же именно я нахожусь среди этой кучи ссылок?". Тогда как с традиционной строкой, похожей на привычный файловый путь что со стилями, что без, своё местонахождение на конце цепочки будет очевидно в любом случае. А уж вносить разделитель в <li>... Если выпендриваться, для него в тему было бы припахать :before/:after. Но, опять же, не вижу необходимости. П. 20 — тоже прошу пояснить, чем пустой несемантичный спан засоряет структуру меньше, чем непустая слабосемантичная картинка?
-
Насколько я понимаю, они его не совсем изменили, а сузили понятие "источник". И в этом есть логика — теперь "цитировать" можно только реально существующие работы, которые можно проверить, а не людей, насчет которых поди проверь, говорил этот человек такое или нет . Библиографии в научных/технических документах, использовавшие этот тег в HTML4, останутся правильными и в HTML5. Стандартам теперь противоречит только предложенный Тантеком Челиком паттерн для комментариев (в т.ч., по иронии судьбы, на html5doctor.com ).
-
Нет, оно предназначено для превращения элементов списка в аналог span-ов, вливающихся в обычную текстовую строку. С неизбежной потерей всех блочных свойств (напр., текст в таком элементе может переноситься на новую строку с разрывом border-ов). Компромисс, при котором элементы выстраиваются в строку, не теряя блочных свойств — это как раз inline-block.
-
Я довольно давно пришел к подобным выводам. А насчет nav в футере, похоже, в спеке нашлись взаимоисключающие параграфы. С одной стороны, в разделе про nav написано, что но при этом в примере из раздела про footer именно в таком случае в footer-е (правда, глобальном, для всей страницы) как раз использован nav... и эти люди запрещают нам ковыряться в носу и оборачивать имена в <cite>? Что очень много субъективных моментов оставлены на вкус автора. Например, во многих случаях <header> и <footer> могут быть взаимозаменяемыми.
-
Да, у Брюса Лоусона давняя выстраданная симпатия к <cite> для обозначения автора/собеседника. Поэтому он до последнего надеется, что семантику <cite> расширят. Но в замечании из спеки, что "Имя человека не является названием работы — даже если люди называют этого человека частью работы — поэтому этот элемент не должен использоваться для разметки имен людей", тоже есть своя важная логика. Уж такая зыбкая материя эта семантика. Не случайно в спеке то и дело встречаются замечания типа как здесь в конце: "Notice the use of footer to give the information for each comment (such as who wrote it and when): the footer element can appear at the start of its section when appropriate, such as in this case. (Using header in this case wouldn't be wrong either; it's mostly a matter of authoring preference)".
-
В старых IE z-index "своеобразный". Подробности здесь.
-
Вот по спеке: В примерах к нему и к article в футер часто засовывают линк на автора и дату публикации, так что применительно к сообщению на форуме туда напрашивается "Отправлено Сегодня, 20:20", даром что оно вверху Ну и пагинация, имхо, тоже вполне имеет право там быть. А вот имя автора в <cite> в ЖHTML пихать нельзя, он теперь только для названий цитируемых работ. Даже авторитет Тантека Челика, похоже, не убедил авторов спеки в обратном...
-
Почему?
-
Имхо, пагинация просится в footer статьи/раздела (на правах "links to related documents")...
-
Вот тут я немножко не соглашусь . Label, да, привязывает подпись к полю логически и поведенчески (передает клик, в этом label схож со ссылкой на якорь), но ничего не говорит о структурной организации формы — формально он может болтаться вообще на другом конце кода и экрана. А все копья на тему "верстать форму таблицей/списком/абзацами/whatever-ом" ломаются именно вокруг этой структурной стороны. Поскольку и label, и контролы форм по дефолту инлайновые, то какая-то структурная обвязка напрашивается, иначе при отключенных стилях получится неразборчивая "колбаса" из подписей и полей в одну строку сплошняком — явно не то, чего ожидает юзер от формы с ее четкой парной структурой "подпись — поле". Филдсет для каждой пары — никак не вариант, он для группировки нескольких логически связанных полей. Абзац... ну не знаю, имхо, не похожа форма на обычный связный текст (против списка это соображение, кстати, тоже работает). Разрывы дефолтной "колбасы" <br>-ками — вообще бяка, к тому же плохо управляемая стилями. Вот как быть? Сейчас я пришел к выводу, что для структурирования формы, как ни странно, минимальным злом (или даже вынужденно необходимым добром) является, как ни странно... таблица (кроме прочего, ее гораздо проще, чем что-то иное, модифицировать для чуть нестанартных случаев, напр., для составных полей, да и W3C, судя по примерам, вроде как давно не против). И на втором месте с приличным отрывом — dl-ка (для нечастых случаев, когда у формы четкая структура "а-ля словарик").
-
Формы — имхо, да (на мой взгляд, отношение определяемое-определение между подписью поля формы и его значением вполне себе выражено, хотя форма — вообще особый случай, тут очень зыбкая грань между парами "имя-значение" и настоящей таблицей 2?n). Диалоги — имхо, определенно нет. В HTML5 это прямо запрещено (Note в самом конце), и аргументы, что разрешение на это в HTML4 было ошибкой, имхо, убеждают...