skvor
-
Posts
80 -
Joined
-
Last visited
Content Type
Profiles
Forums
Calendar
Store
Posts posted by skvor
-
-
-мешает отсутствие целесообразности. Когда создаётся информация, вопросы цвета, размера шрифтов и прочая фигня не должны решаться. Когда сумеете создать страницу, которая содержит полезную информацию и имеет обоснованную здравым смыслом разметку, вы получите ресурс с совершенной доступностью. После этого, уже можно заниматься тем, что неразумно в русском языке называется веб дизайном, если ограничиться только правками CSS, а не перешивать HTML, то результат этого мега-диза уже не помешает слабовидящим читать вашу страницу с отключенным стилем и собственными настроками браузера.Но что мешает подумать о доступности внутри этого системного подхода?
- 1
-
Эти стандарты являются косметическими, и цель этих разработок - привлечь внимание к W3C, а не обеспечить декларируемую доступность. Документ в интернете должен нести информацию, и эта информация и формат её представления не могут зависеть от того, чем получатель читает и воспринимает.Почему не стоит? правильная разметка, в т.к. является частью стандарты. Не всякий список ссылок является навигацией или основной навигацией.
-
Ну, если не слепой, то это не очень и важно. А вообще, Виндуз давно поддерживает чтение. Для других систем, нужно установить приложение (КО). Ну и должны быть плагины для самих браузеров. Для Оперы эта хрень есть, но работает только с английским, и сделано всё в одном - чтение текста и голосовое управление. Фишка не столько для слепых, сколько для понта.А как такие акустические страницы тестировать?
-
-Угу, именно это и хотелось бы увидеть, хотябы в кратком изложении.TC имеет ввиду http://www.w3.org/TR/CSS2/aural.html
Не стоит этого делать. Стандарт разработан без целей обеспечения доступности. Практически, никакие стандарты для слепых не нужны. Всё решается на уровне HTML. Страница должна содержать два блока - навигация (список ссылок) и основное содержание (заголовки, текст разбитый на абзацы и внешние ссылки). Всё, что связано с графическим дизайном должно реализовываться без изменения HTML структуры. Тогда любой брайлевский дисплей позволит достаточно легко ориентироваться на странице. CSS не влияет на брайль.п.с. Для слепых, насколько я знаю, существуют не только стили, но и специальные атрибуты, которые даже более важные.
Внедрение стандартов доступности более вредно, чем полезно. Реально, никто не будет этим заниматься, ибо дорого, а с другой стороны, это отвлекает внимание от возможности решения вопросов системным подходом.
Вот акустические стили было б легко применять для страниц с "правильным" дизайном.
-
Вот тут меня спросили, что делать для слепых, я с умным интерфейсом начал рассказывать, а потом понял, что не знаю куда человека послать по сабжу.
Кажется, упущен этот момент или я не могу найти в учебнике. Надо б по-лёгкому провентилировать, хотя бы на уровне, что это есть и перечислить практически существующие правила.
-
Извините, а что в Firefox-е прикажите делать, сударь?
Повелеваю - под Fx не заморачиваться с вопросами не влияющими на доступность.
Впрочем, это относится ко всем браузерам. Дизайн д.б. - (1)доступным для 100% посетителей, (2)удовлетворительным для 80-90% и (3)ахренительным для 50-60%.
-
Спасибо
-
Размер в пикселах, это mauvais ton. Во-первых, сохранение основных размеров в дефолтном значении гарантирует, что посетителю не потребуется изменять масштаб для комфортного чтения. По этому, все размеры надо задавать отношением к базовым. Во-вторых, то что браузеры "умеют" не означает, что алгоритм масштабирования будет всегда срабатывать хорошо. Стили имеют довольно сложную взаимосвязь, и "просчитать" логически поведение всех элементов невозможно, а проверить на разных браузерах и устройствах - тем более.
-
Есть такое в справочнике или учебнике? Дайте ссылку, пожалуйста.
Спасибо
-
Спасибо, работает. Ещё один аргумент для табличной вёрстки и плевок в ТБЛ
-
С width тоже проблема, т.к. речь не о 100%, а о невозможности согласовать размеры.
Если задать ширину 50% для вложеных блоков, то они будут одинаковыми, и у второго варианта внутренний размер будет согласован с внутренним же размером родителя (а хочется, чтоб он (к примеру) по габаритам занимал половину ширины области для контента родителя). А вот первый вариант из-за хрени с padding'ом и позиционированием будет сломан.
-
Дано: <div><div></div></div>
Надо согласовать внешние размеры вложеного div'a с внутренними родительского.
<div style="border: 100px solid #f44; width: 80%; height: 500px; padding: 80px;">
<div style="border: 80px solid #44f; width: 100%; height: 100%; top: -80px; left: -80px; position: relative;">
Решено, но использование padding родителя и позиционирование дочернего элемента не логично, т.к. взаимосвязано с шириной border.
</div>
</div>
<div style="border: 100px solid #f44; width: 80%; height: 500px;">
<div style="border: 80px solid #44f; width: 100%; height: 100%;">
Не решено.
</div>
</div>Первый вариант внешне решает вопрос, но требует лишнего позиционирования с параметрами от родительского, которые логически не согласуются.
Суть проблемы - вложеному элементу надо назначать полные ширину и высоту в пропорциях от внутренних размеров родителя.
-
граница значит бордер
-сомнительно.
Границей следует обозначать то, где элемент заканчивается. Border - это просто графический элемент, который может отрисовываться по границе. Тут с терминологией ерунда, ну или я может с другого домена.
-
То, что я неправильно понял, это я понял, я не понял - что я должен был понять
Я так понимаю - padding дочернего элемента не схлопывается с margin'ом родительского. Но из статьи это не явствует, т.к. основное изложение относится к схлопыванию padding'ов у сиблингов.
-
Когда сайт делаешь за деьги, и когда возьню с ослами оплачивают
Вот не делал сайты за деньги и под осла. Но опыт работы в другой сфере показывает, что когда заказчик озабочен внешним видом и совершенно не хочет слушать про реальную эффективность - лучше сразу отказаться. Во-первых, по собственным затратам это будет тяжёлый проект. Во-вторых, когда заказчик наткнётся на реальные косяки, он будет предявлять претензии и будет пофиг, что его предупреждали. В-третьих - рекомендаций от таких клиентов будет не получить.
Вот вам кстати косяк - в Опере, редактор поста этого форума не хочет вводить строчный Ъ
Так что не предявляйте претензии к моему русскому.
-
Сделать можно, но только по-еврейски
<table dir=rtl style="border: solid 1px red;">
<tr><td dir=ltr style="border: solid 1px blue;">11 1 2 3 4 5</td>
<td rowspan="2" dir=ltr>12 1 2 3 4 5</td></tr>
<tr><td colspan="2" dir=ltr>21 1 2 3 4 5</td></tr>
</table>Вопрос в том - зачем оно так надо? Если речь идёт о вёрстке, то это не разумно, т.к. логичнее и проще - div. А для практических таблиц подобное обединение ячеек кажется бессмысленным.
-
По-мне, кроссбраузерно делать этого не стоит. Поставьте border-radius и ладно. Кто поддерживает - тот отрисует, а если браузер пользователя не поддерживает, то и ничего страшного. Главное не кроссбраузерность, а чтоб работал сайт и пользователь с любым пылесосом имел доступ к информации и функционалу.
-
Читаю
http://htmlbook.ru/samlayout/blochnaya-verstka/skhlopyvayushchiesya-otstupy
Схлопывание не срабатывает:для элементов, у которых установлено свойство padding.
для элементов, у которых на стороне схлопывания задана граница;
1) В Konqueror и Opera наличие padding'а схлопывание чёт не отменяет. Да и сомнительно, чтоб такое было, не вижу логики - зачем внутреннему полю влиять на работу со внешними полями?
2) Что значит "задана граница"? Что такое "граница"? Как она может быть задана или не-задана?
Спасибо
-
Вопрос был - можно ли указать inherit вместе с font-size?
-
На странице
запись
font: [font-style||font-variant||font-weight] font-size [/line-height] font-family | inherit
Что означает "| inherit"?
- inherit может быть указан вместо задания font-family?
- или вместо всех параметров?
-
<p style="position: absolute; right: -80%;">bla-bla-blah</p>
-появляется горизонтальная полоса прокрутки, можно прокрутить и увидеть.
<p style="position: absolute; left: -80%;">bla-bla-blah</p>
-прокрутка не появляется.
Почему так? Это стандарт или фича браузеров?
-
если честно я не так давно вообще кнопки не использую
"Честно не использовать" - ваше святое право за которое я готов отдать жизнь ТБЛ-а, клянусь Татьянычем.
-
а зачем в value у кнопке данные то хранить input type="hidden" есть для этого
Кроме собственно данных формы, м.б. удобно делать интерфейс к приложению, и одна форма может определять несколько действий, т.е. несколько кнопок, а на сервере существенным является то, какой кнопкой была отправлена форма.
Типичный пример - почта через web-интерфейс
В списке писем отмечаете письма с которыми надо что-то сделать, а удаление или жалоба на спам определяется тем по какой кнопке жмякнули. Если б была только одна кнопка отправки, то пришлось бы заставлять пользователя выбирать из списка или отмечать радиокнопкой то, какую команду надо выполнить, что неудобно.
-
Input часто не удобен тем, что value определяет и надпись на кнопке и отправляемые на сервер данные.
Если, например, у вас будет несколько кнопок отправки формы, то при желании изменить надписи, придётся изменять и серверную программу.
Акустические листы стилей
in HTML Coding
Posted