skvor

Вы не говорите об обратном, просто не отличаете понятия разметка и оформление. Забудьте про CSS, это мешает вам понять цели, задачи и суть HTML. Если не можете без стилей сделать сайт, значит вы не можете сделать сайт вообще.

-мешает отсутствие целесообразности. Когда создаётся информация, вопросы цвета, размера шрифтов и прочая фигня не должны решаться. Когда сумеете создать страницу, которая содержит полезную информацию и имеет обоснованную здравым смыслом разметку, вы получите ресурс с совершенной доступностью. После этого, уже можно заниматься тем, что неразумно в русском языке называется веб дизайном, если ограничиться только правками CSS, а не перешивать HTML, то результат этого мега-диза уже не помешает слабовидящим читать вашу страницу с отключенным стилем и собственными настроками браузера.

Эти стандарты являются косметическими, и цель этих разработок - привлечь внимание к W3C, а не обеспечить декларируемую доступность. Документ в интернете должен нести информацию, и эта информация и формат её представления не могут зависеть от того, чем получатель читает и воспринимает.

Ну, если не слепой, то это не очень и важно. А вообще, Виндуз давно поддерживает чтение. Для других систем, нужно установить приложение (КО). Ну и должны быть плагины для самих браузеров. Для Оперы эта хрень есть, но работает только с английским, и сделано всё в одном - чтение текста и голосовое управление. Фишка не столько для слепых, сколько для понта.

-Угу, именно это и хотелось бы увидеть, хотябы в кратком изложении. Не стоит этого делать. Стандарт разработан без целей обеспечения доступности. Практически, никакие стандарты для слепых не нужны. Всё решается на уровне HTML. Страница должна содержать два блока - навигация (список ссылок) и основное содержание (заголовки, текст разбитый на абзацы и внешние ссылки). Всё, что связано с графическим дизайном должно реализовываться без изменения HTML структуры. Тогда любой брайлевский дисплей позволит достаточно легко ориентироваться на странице. CSS не влияет на брайль. Внедрение стандартов доступности более вредно, чем полезно. Реально, никто не будет этим заниматься, ибо дорого, а с другой стороны, это отвлекает внимание от возможности решения вопросов системным подходом. Вот акустические стили было б легко применять для страниц с "правильным" дизайном.

Вот тут меня спросили, что делать для слепых, я с умным интерфейсом начал рассказывать, а потом понял, что не знаю куда человека послать по сабжу. Кажется, упущен этот момент или я не могу найти в учебнике. Надо б по-лёгкому провентилировать, хотя бы на уровне, что это есть и перечислить практически существующие правила.

Повелеваю - под 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 1) В Konqueror и Opera наличие padding'а схлопывание чёт не отменяет. Да и сомнительно, чтоб такое было, не вижу логики - зачем внутреннему полю влиять на работу со внешними полями? 2) Что значит "задана граница"? Что такое "граница"? Как она может быть задана или не-задана? Спасибо

Вопрос был - можно ли указать inherit вместе с font-size?

На странице http://htmlbook.ru/css/font запись 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> -прокрутка не появляется. Почему так? Это стандарт или фича браузеров?

"Честно не использовать" - ваше святое право за которое я готов отдать жизнь ТБЛ-а, клянусь Татьянычем.

Кроме собственно данных формы, м.б. удобно делать интерфейс к приложению, и одна форма может определять несколько действий, т.е. несколько кнопок, а на сервере существенным является то, какой кнопкой была отправлена форма. Типичный пример - почта через web-интерфейс В списке писем отмечаете письма с которыми надо что-то сделать, а удаление или жалоба на спам определяется тем по какой кнопке жмякнули. Если б была только одна кнопка отправки, то пришлось бы заставлять пользователя выбирать из списка или отмечать радиокнопкой то, какую команду надо выполнить, что неудобно.

Input часто не удобен тем, что value определяет и надпись на кнопке и отправляемые на сервер данные. Если, например, у вас будет несколько кнопок отправки формы, то при желании изменить надписи, придётся изменять и серверную программу.