s0rr0w

Имеется некий XML-файл, результат работы системы. Клиент подключает xsl файл (вручную, добавляя одну строку в xml-файл), и открывает результат в браузере. Данные клиент видит в виде набора заголовков, таблиц, или других структур, в зависимости от типа данных. Пишите в личку, кто может это сделать, и за какую сумму. Интересует также стоимость будущей поддержки по модификации данного xsl-файла при изменении дизайна отображаемых данных или структуры xml-файла.

Прикручивать к IE5.5 CSS3, это все равно, что спойлер на детский велосипед ставить. Скорость рендеринга ИЕ9 уступает даже второму фоксу, не говоря уже про четвертый.

http://jsfiddle.net/5K6qW/10/ так точно работает

Бугага. Тогда лечится путем вырезания таблицы из контекста и вставкой ее обратно.

Убрать table-layout: fixed, подождать пару милисекунд и установить обратно.

Так, чтобы было понятно. Контент - значимая информация на странице, которая отображает суть самой страницы. В контент не влючается все, что несет интерактивную суть за исключением варианта, когда интерактив и является контентом (Список полезных ссылок, например). Данные - это все, что находится между тегов. Разметка - теги. Оформление - все, что не относится к разметке контента. Моя основная мысль заключена в том, что нужно строго разделять контент и оформление.

Ааа, так это не "связанный список" а указатели! Да, верно. Это изменяет суть семантики. Использование инстументов не по назначению никогда до добра не доводило. Приведу простой пример. Почему верстать таблицами плохо? Потому что.... почему? Вот что тут такого? Аргумент был железный - таблица не для оформления, а для данных. Со списками аналогичная аргументация у меня. Списки не для меню, не для навигации, не для оформления, а для данных.

Я могу сказать только одно - идиоты.

Разделитель не относится к контенту. Это визуальный элемент. Создание тега <interactive> для меню, навигаций, тулбоксов и прочих элементов и создание <tree> <ti /> </tree> Для многомерных и иерархичных интерактивных элементов. А если присмотреться к текстовой статье, то можно увидеть связанный массив абзацев. И тогда, следуя логике выше, статью нужно представлять как список, где в каждом LI должен быть свой P

Для тестирования совершенно не обязательно иметь аппарат. Можно использовать SDK для его эмуляции.

Этот пример - классика жанра. Спискозадроты не видят в нем ничего военного, их ничего не раздражает в этом примере. Потому что они не могут отказаться от одного заблуждения, что все что перечисляется, должно быть <ol/> или <ul/>. Не подверженный вирусу списка головного мозга разработчик отчетливо видит абсурдность примера. Семантика списков такова, что они вообще не подходят для оформления. Откуда вообще взялись списки? Из оформления документов, статей, короче, из печатного мира. Они органично выглядят в теле статьи. Интерактивная суть HTML требовала заполнить пустоту интерфейсных потребностей и плюшек, как то меню, навигация, тулбары и прочее, и, чье-то воспаленное сознание додумалось применить для этого списки. Это настолько укоренилось в сознании последователей, что никто теперь не видит ошибки логики, что оформление должно быть оформлением, а контент - контентом. Я не вижу твоей проблемы. Может она надумана? Что тебя беспокоит?

Тогда вот такой текст, по логике спискозадротов, правильно оформлять так: Несколько стран подписало ратифицировало договор. Среди них <ul><li>Германия, </li><li>Франция, </li><li>Испания</li></ul>. Готовятся ратифицировать следующие страны: <ul><li>Англия, </li><li>Польша, </li><li>Португалия</li></ul>. Визуально он должен выглядеть вот так: Несколько стран подписало ратифицировало договор. Среди них Германия, Франция, Испания. Готовятся ратифицировать следующие страны: Англия, Польша, Португалия.

С логической точки зрения - абсолютно верно. Он отделил контент одного элемента от другого. Поворот на 90 градусов делает глубину шириной Если очень сильно хочется, но не получается, то спасут кастом-теги <c:breadcrumbs> <a href ...> </c:breadcrumbs>

Ээээ <div class="breadcrumbs"> <a href="#">Main</a> / <a href="#">Page1</a> </div> Что тут нельзя закинуть или где париться? Темплейтирование - это процесс натягивания "html-шкурки" на серверный код. Фактически, это превращение шаблона и данных в готовый html код.

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

Абсолютно пофиг. Если спискозадрот, делай списками. Иначе делай обычными ссылками

Для этого придумали микроформаты. Качество индексации поисковиками представленного контента вырастет в разы! Выиграют все. Но w3c играется в какой-то песочнице.

Семантика не зыбкая материя, если дать пользователю самому выбирать себе теги. <book> <title>Отстрел дятлов для чайников</title> <publish_date>10.10.2010</publish_date> <publisher>Oh'really?</publisher> <illustrations> <img src="front_page.png" /> </illustrations> <context> <h1>Intro</h1> ... </context> <author>William Gates</author> <actions> <purchase> <label>Заказать</label> <uri>add_to_chart.cgi</uri> </purchase> <view_comments> <label>Комментарии</label> <uri>comments.cgi</uri> </view_comments> </actions> </book> Вот попробуйте теперь адекватно отобразить столь стройную и понятную струтуру в HTML.

Напридумывали новых тегов мешок, но ясности в семантике почти ноль. Потому что #$^@^&^#%... Это очень сильно рудиментарный тег. Единственное место, где его можно хоть как-то применять - Википедия. В коммерческих проектах он бесполезен.

На скорость передачи данных.

Если бы все браузеры поддерживали JS 1.7, то можно было бы написать [x, y, z] = absolutePosition();

Расскажу, пожалуй, к чему я пришел. Весь код бъется на секции переопределение стилей тегов основные классы модификаторы печатная версия другие медиа (если есть) Основные классы делятся на логические блоки. Весь код строится по принципу базис + модификаторы. Например, нужно сделать некую плашку .plateBlock { margin: 10px 0px;} .plateBox { padding: 10px } <div class="plateBlock"> <div class="plateBox"> Content </div> </div> Если плашка имеет специфический фон, то создаем модификатор, например .important { background: #900; } и добавляем этот класс plateBlock'у В итоге получается набор базисной верстки и мешок всевозможных модификаторов. Однако данный подход требует сократить до минимума использование специфичности. Уж очень она сильно мешает в больших проектах. Через время проводим рефакторинг и частоповторяемые вещи переносим в базис, выкидывая или видоизменяя модификаторы.

Возьмите прямо с приведенного сайта. Или закажите разработку.

Одна из компаний, где я работал. 2000й год.

http://viva-solutions.com/