Есть ли деловая причина стремиться к чистому макету CSS?

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

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

, Это на самом деле не верно; программы экранного доступа как JAWS, Глаза Окна и HAL игнорируют таблицы расположения. Они работают действительно хорошо при контакте с реальной сетью.

Некоторые дополнительные причины, почему это - хорошая практика:

• Доступность - сеть должна идеально быть доступной всем
• , Производительность - сохраняет пропускную способность и загружается быстрее на мобильных устройствах (они испытывают недостаток в пропускной способности до некоторой степени, и не могут сложные таблицы расположения быстро). Помимо загрузки быстро всегда хорошая вещь...

*I позволил бы ему использовать то, что его WYSIWYG-РЕДАКТОР выкладывает
я просто бросание немного...
*ahh привет? Вы не думаете, что графический дизайнер пишет, что CSS вручную делает Вас?

Странно достаточно я работал с несколькими разработчиками, и лучшие среди них делают ручная тонкая настройка их css. Парень, о котором я думаю на самом деле, делает всю свою дизайнерскую работу как файл XHTML с несколькими файлами CSS и создает графические элементы на лету, поскольку ему нужны они. Он использует DreamWeaver, но только действительно как инструмент навигации. (Я изучил много от того парня)

, Как только Вы сделали инвестиции для изучения чисто основанного на CSS дизайна и имели немного опыта (узнал, где IE сосет [для ярмарки, это - улучшение]), это заканчивает тем, что было быстрее, я нашел. Я работал над Системами управления контентом, и приложение редко должно было изменяться для разработчиков для предложения радикально различного взгляда.

:: поклоны в palmsey и Jon Galloway::

я соглашаюсь с фактором пригодности для обслуживания. Это действительно берет меня немного дольше для получения моих начальных сделанных разметок (так как я - все еще ученик джедая в искусствах CSS), но выполнение полной модернизации веб-сайта на 15 страниц только путем обновления 1 файла является небесами.

Бизнес-причина расположения CSS: можно сдуть клиентов путем высказывания, что "наш портал полностью настраиваем/со сменными окнами, не пишущий код!"

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

Так, табличным данным лучше всего подарили бы таблицы, конечно. Разрабатывание главных стандартных блоков (таких как строка меню, тикер новостей, и т.д.) в их собственных таблицах должно быть в порядке также. Просто не полагайтесь на таблицы для полного макета страницы, и Вы будете в порядке, мне кажется.

идея состоит в том, что Разработчики могут Разработать, и Веб-разработчики могут реализовать. Это в особенности имеет место в динамических веб-приложениях, где Вы не хотите, чтобы Ваши Разработчики бездельничали в Вашем Исходном коде.

Теперь, в то время как там обрабатывают механизмы по шаблону, Разработчики, по-видимому, просто любят сходить с ума, и CSS позволяет вытягивать намного больше трюков, чем таблицы.

, Что быть сказанным: Как разработчик, я отказался от CSS Расположение главным образом, потому что мой Дизайн сосет так или иначе, так по крайней мере, это может высосать правильно:-), Но если бы я когда-либо нанимал бы Разработчика, я позволил бы ему использовать независимо от того, что его WYSIWYG-РЕДАКТОР выкладывает.

Разделите свое расположение, и Ваше содержание позволяет Вам перепроектировать или делать тонкие настройки и изменения в Вашем сайте легко. Это может взять немного более длинный честный, но самая длинная фаза разработки программного обеспечения является обслуживанием . css дружественный сайт с четким разделением между содержанием и дизайном является лучшим в течение обслуживания.

Если у Вас есть общедоступный веб-сайт направления, реальной экономической моделью является SEO.

Доступность важна и поддерживающая семантический (X), HTML намного легче, чем поддержание разметок таблицы, но то пятно № 1 на Google хорошо заработает.

, Например: Ежемесячный веб-отчет: 127 миллионов просмотров страницы на июль

Ежемесячный веб-отчет: 127 миллионов просмотров страницы на июль

...

Latimes.com сохраняет улучшение в SEO (оптимизация поисковой системы), что означает, что наши истории занимают место выше в Google и других поисковых системах. Мы также выполняем лучше на сайтах как Digg.com. Все, что составляет в целом больше воздействия и больше читателей чем когда-либо прежде.

, Если Вы смотрите на их сайт, у них есть довольно достойное движение расположения CSS.

Обычно Вы находите относительно немного разметок таблицы, работающих хорошо в SERPs в эти дни.

выполнение полной модернизации веб-сайта на 15 страниц только путем обновления 1 файла является небесами.

Это верно. К сожалению, использование одного файла CSS 15 000 сложных и сильно отличающихся страниц является Вашим худшим осуществленным кошмаром. Измените что-то - это повреждало тысячу страниц? Кто знает?

CSS является обоюдоострым мечом на больших сайтах как наши.

Еще одна вещь, которую я просто помнил, можно присвоить различную таблицу стилей странице для печати по сравнению с дисплеем.

В дополнение к Вашему нормальному определению таблицы стилей, можно добавить следующий тег

<link rel="stylesheet" type="text/css" media="print" href="PrintStyle.css" />

, Который представит документ согласно тому стилю, когда Вы отправите его на принтер. Это позволяет Вам разделять фоновые изображения, дополнительную информацию о заголовке/нижнем колонтитуле и просто печатать необработанную информацию, не создавая отдельный модуль.

Я имею мысль, что расположение CSS с как можно меньшим количеством таблиц является более чистым и лучше, но я соглашаюсь, что иногда просто необходимо использовать таблицу.

Бизнес-мудрый, это обычно, "что собирается получить сделанный самый быстрый и самый надежный путь". По моему опыту, использование нескольких таблиц обычно попадает в ту категорию.

я нашел, что очень эффективный способ смягчить различия перекрестного браузера в рендеринге CSS состоит в том, чтобы использовать "строгий" doctype наверху Вашей страницы:

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01//EN" "http://www.w3.org/TR/html4/strict.dtd">

кроме того, для страшных проблем IE6 CSS, можно использовать этот взлом:

.someClass {
    background-color:black; /*this is for most browsers*/
    _background-color:white; /*this is for IE6 only - all others will ignore it*/
}

Используя семантический HTML дизайн является одной из тех вещей, где Вы не знаете то, что Вы пропускаете, если Вы не делаете практику из него. Я работал над несколькими сайтами, где сайт был модернизирован после факта с минимальным влиянием на серверный код.

сайты Модернизации являются очень общим запросом, что-то, что я заметил больше теперь, когда я в состоянии сказать "да" вместо попытки говорить мой выход из.

И, как только Вы учились работать с системой макета страницы, это обычно не тяжелее, чем основанное на таблице расположение.

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

<забастовка> Пользователи, которые используют screenreaders, будут склонны иметь свою собственную высококонтрастную, таблицу стилей большого шрифта (если Ваш сайт не предоставит сам тот), который облегчает для screenreaders анализировать страницу.

<забастовка>, Когда screenreader читает страницу и видит таблицу, он скажет пользователю, что это - таблица. Следовательно при использовании таблицы для расположения это становится очень сбивающим с толку, потому что пользователь не знает, что содержание таблицы является на самом деле статьей вместо некоторых других табличных данных. меню должно быть списком или набором отделений, не таблицей с пунктами меню, снова это сбивает с толку. Необходимо удостовериться, что Вы используете блоки цитирования, атрибуты заголовка alt-tags, и т.д. для создания его более читаемым.

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

, В то время как я действительно чувствую, что обслуживание сделано легче для [приблизительно 110] вещи, когда Ваш сайт просто размечается с CSS, я не думаю, что имеет место для всех видов обслуживания - особенно, когда Вы имеете дело с CSS перекрестного браузера, который может, очевидно, быть кошмаром.