Обновить
aps@apsread⁠-⁠only

Пользователь

Отправить сообщение
>Так то для печати. Это немножко из другой оперы.
Пока только для печати. Но люди работают. Скоро говносайты говнодизайнеров будут тянуть до кучу по мегабайту говношрифтов.
>Не совсем понимаю зачем вся эта многоуровневая возня со шрифтами
Возьмите какую-нибудь бесплатную газету объявлений. Половина графических модулей содержит десяток изуродованных деформацией шрифтов и картинок из кореловского клипарта.
Вот таким говнодизайнерам без кучи спизженных акцидентных шрифтов никак нельзя.
Для них и стараются.
Тоже без недостатка. Если полей много — лишнее движение глаз для того, чтобы поймать начало строки.
Если присмотреться к истории развития броузеров, можно сделать более перспективный прогноз. Например.
MS IE понадобилось 4-5 лет на то чтобы практически с нуля занять 90% рынка и столько же чтобы просрать эту монополию.
5 лет назад только один единственный броузер поддерживал Ajax,WYSIWYG, XSLT
5 лет назад любимой дискуссией верстальщиков было DIV contra Table
Через пять лет вам будет 35. Вполне нормальный возраст.
Хотя бы для того, чтобы боты адекватно индексировали сайт.
Хорошо или плохо, но XSLT пока никто из них выполнять не может.
Это кстати одна из видимых причин почему клиентское преобразование не пошло. Я кстати не знаю, предусмотрено ли в UMI,HostsCMS и т.п. цепочки преобразований или только одна финальная обработка большого XML.
Правильно. Сначала нужно внедрить на сервере, а уже потом на клиенте :)

В интернете все быстро устаревает. Кроме мифов об XSLT.
А новую UMI обязательно посмотрю. Может еще что полезного найду для себя.
Меня очень напрягли две вещи:
1. очень тяжелый бэкофис.
2. достаточно сложный интерфейс. Вряд ли юзабилитисты там работали. Хотя для системы такого уровня как UMI, наверное имело смысл пригласить.
Я год назад сравнивал по этим параметрам разные движки здесь: erum.ru/article/33
Еще раз спасибо за статью «Реабилитация» и за «Другую книгу» тоже. Хотя последняя не ах :)
>Какое отношение это имеет к клиентскому преобразованию
Самое прямое. О клиентском XSLT говорят только те, у кого нет никаких проблем с внедрением серверного. Или точнее те, кому серверного становится мало.
К примеру, если есть проблемы с валидностью в HTML, как у UMI, о клиентском преобразовании надо забыть — броузеры не понимают disable-output-escaping.

>и причём тут php не понимаю
php-программисты _в_массе_своей (я не говорю о всех, но о массе) менее квалифицированные чем прочие, поэтому у них и возникают проблемы с переходом на XSLT, и при этом их в России на порядок больше чем всех прочих, поэтому они и задают тон в болталках типа хабра
Большая часть php-программистов до сих пор бодается что лучше — Smarty или голый php, вы удивляетесь почему клиентское преобразование не пошло.
Не знаю почему. Наверное слишком много мифов выросло вокруг этой темы. И в основном в среде php-разработчиков. Те кто работает с Java и .NET как-то более продвинуты.
Имхо, это какая-то неправильная кнопка.
Для неопытного юзера необходимо минимизировать возможность вляпаться в ошибки и заодно при помощи tidy принудительно вычистить всякую ерунду типа MS Word из HTML. А вот для опытного пользователя, да еще и имещего доступ у исходникам можно дать возможность самостоятельно под себя играть с HTML и чистить его по своим правилам.
В процитированной вами статье Кэя про это сказано:
«Не используйте disable-output-escaping. Некоторые люди используют эту магическую приправу, но не понимают, что она делает. Они надеются, что это может заставить код работать лучше. Этот атрибут только для профессионалов, и профессионалы используют это только как последнее средство спасения. В 95% случаях, если вы встретили в преобразовании disable-output-escaping, это говорит о том, что автор был новичком, не понимающим, что он делает»
UMI вообще странная система. Мне очень понравилась сама идеология пользовательского интерфейса, которую вы заложили. Но реализовано это (в той части что меня интересовала) уж больно страшно. Хотя бывает и хуже :)
> xsl:for
xsl:for-each. Вы успокоились?
> Вы еще не включили в список вредных инструкций xsl:value
Вы еще не доросли до крайней степени xslt-пуризма. Поэтому объясню. xsl:value в ваших примерах выводит то же самое что и xsl:apply-templates, но в случае если элемент по-ходу мзменится (например наченет содержать дочерние элементы) вам придется вносить дополнительную правку в том месте где вы вляпали xsl:value
Это то о чем вы талдычите, не понимая смысла «most basic fundamental»
Вы превратно поняли слова гуру.
В приведенном вами тексте я не увидел здесь ни одного слова о безусловном запрете xsl:if, xsl:choose, xsl:for, xsl:value. Но я хорошо помню, в книге М.Кэя«XSLT: руководство программиста» в конце девятой главы «Образцы проектирования таблицы стилей», говорилось, что в реальная практика далека от шаблонов мышления пуристов.
«Все действительное разумно, все разумное действительно» (с) Гегель.
>Помню когда пробовал xslt поддерживало
Последним из броузеров не поддерживающих XSLT была Опера ~ 8.5
Имхо интуиция вас подвела. Так же как и автора книги.
«Все действительное разумно, все разумное действительно» (с) Гегель.

А вы что хотите, [strike]бежить впереди паравоза[/strike] пользоваться бетой или работать?
>писать код тоже нужно уметь
В машинных кодах и в двоичной системе.
Или наоброт. Что-нибудь типа Ajax, который поддерживал только IE, а остальные чухались 5-8 лет.
2-3 года назад ваше замечание имело смысл. Но сейчас уже очевидно, что следующим стандартом (к сожалению) будет HTML5.
Я понимаю, что вы не в состоянии прочитать спецификацию на языке оригинала, поэтому вам остается верить только на слово. Фраза «This specification is Editor's Draft» означает — «Это ни разу не стандарт, а суйня всякая»

Информация

В рейтинге
Не участвует
Зарегистрирован
Активность