> Браузеры запутались в блочной модели для таблиц
Немудрено. Еще в прошлом веке W3C заварил дурацкую кашу с дурацкой боксовой моделью. Потом зачем-то ввел дополнительно к своей дурацкой микрософтовскую, и вот результат через 13 лет — «Браузеры запутались в блочной модели»
> А никто его не ломает, он сам ломается) при чем тут edit in place?
При том, что результатом его работы является поломка валидатора. Можно было сделать без этого, но разработчики UMI сделали именно так. Плохой валидатор или хороший — другой разговор.
Об остальном тоже не буду. Речь идет не о jQuery, и не о том что лишний xsl:if при включенном кэше — проблема высосанная из пальца.
==
мы ушли далеко в офтопик. Но суть остается — CMS не должна осложнять работу разработчика. И это недоработка разработчиков UMI. Не критичная, не самая неприятная (и без того хватает недоработок), но недоработка.
> Можно пробовать использовать другой валидатор,
Скиньте плиз адрес на плагин без дополнительных примочек в виде Java или выхода на сторонний ресурс. Я пока не нашел.
> В любом случае, бороться с ложными срабатываниями
> мне тоже кажется несколько странным.
Вы кажется не поняли о чем я пишу. Я пишу о том что при отладке кода в идеале не должно быть никаких ошибок. Все равно каких. Потому что если ошибки есть, с ними все равно нужно разбираться и тратить на это время. А его и так мало.
> Выгода очевидна — edit in place в юми,
Извините, я не понял зачем ломать валидатор ради edit in place. Можно сделать ровно то же не ломая ничего.
> jQuery тоже использует собственные атрибуты и ничего страшного.
> Это удобно и по стандарту.
jQuery использует свои атрибуты вопреки стандарту. Но делает это в динамике. После загрузки страницы. При этом Кац в своей Библии предостерегает разработчиков от использования «собственных атрибутов».
> Почему я должен отказываться
Вы никому ничего не должны.
Просто выгода от использования своего пространства имен кажется мне совершенно не очевидной, а наличие нескольких сотен ложных предупреждений об ошибке вполне очевидны. На их фоне сложно искать реальные баги, и сопровождение большого проекта (сотни шаблонов), который много лет пилят разные верстальщики и программисты превращается в ад.
Если вы сами сопровождаетет/модифицируете свой код — то нет вопросов, но если ваш код отдается на сторону — как-то уж очень неприлично.
И почему «версткодрочеров»? Сдавать любой код (не только HTML) с предупреждениями, ошибками, и соплями — моветон. Хоть в Java, хоть в PHP, хоть где.
И если в коде 100 ложных срабатываний, пропустить 101 реальное — вполне обычное дело.
> То что w3c-валидатор не понимает определенный пользователем неймспейс, так это проблема валидатора
Нет. Это проблема не w3c, а вполне конкретного верстальщика, который обязан проверять все баги верстки на фоне ложного срабатывания валидатора.
Имхо проблема не то что на сервере лежит, а то что на клиента грузится. А с этим у UMI (у других не лучше) — традиционно задница. У них крайне громоздкий бэкофис, грузящий кучу файлов очень большого объема.
2-3 года назад чтобы отедактировать страничку требовалось загрузить несколько сотен файлов на 1-2 Мб. сейчас вроде чуть-чуть сократили. Но не радикально.
> Почему CMS на базе популярных (среди программистов) фреймворков
Кстати, почему на базе популярных фреймворков, нет ни одной CMS, которая могла бы пользоваться спросом?
> на таком уровне его знают, а тем более используют,
> относительно малое число людей
А что уже исчезли ie6-ie8, а оставшиеся безоговорочно поддерживают все фичи HTML5?
Угу. До 8-9 версии с Оперой геморроя было на порядок больше чем с ie5-ie6.
Любимый оперный фокус — пофиксить баг и в новой версии откатить откатить его назад.
> А чем VK отличается от админки CMS?
Тем, что никому не придет в голову админить сайт через мобильник с оплатой трафика по 10р/Мб (без учета роуминга)
Это же надо. Всего за два дня число фейсбучных рукопожатий сократилось с 4,37 до 3.74
См. www.bbc.co.uk/news/technology-15844230
.
Еще неделю и скоро будет некому руку подать, в минуту душевной тревоги
Ниша ModX — небольшие и дешевые сайты для самой широкой клиентуры, которая слов таких не знает как ExtJS и ModX Revolution.
Впрочем, это беда общая. UMI к примеру без ExtJS на слабых комп. не живет.
> Возможности дает — широчайшие.
разработчику дает. у юзера отнимает
> Как правило, людям в админке нужны удобство и функционал
оно сводится на нет потребляемыми ресурсами.
> а скорость нужна на фронтенде.
скорость нужна везде. спросите у любого, кому приходится постоянно и много забивать данные в админку.
Мне приходится. А вам?
> На мой взгляд, такая админка все равно быстрее
Ну да. Можно сделать еще хуже. Разве я спорю?
Только кто мешает сделать лучше?
==
CMS типа ModX предназначена для средней паршивости сайтов-визиток и магазинчиков. Контент-менеджеры и секретарши, которые их админят везеде и всюду имеют самые дохлые компьютеры.
По крайней мере за много лет работы никогда не видел у них хорошего комп.
Более 10 лет проработал в больших конторах типа Rabota.Ru. Магазинчики и визитки для мелких конторок тоже делал.
И нигде и никогда не видел нормального комп. у контент-менеджера. Только самые плохие и самые дохлые.
==
Забудьте наконец про [noindex]
Яндекс давно уже сделал валидный вариант. help.yandex.ru/webmaster/?id=1111858
[!--noindex--]текст, индексирование которого нужно запретить[!--/noindex--]
Немудрено. Еще в прошлом веке W3C заварил дурацкую кашу с дурацкой боксовой моделью. Потом зачем-то ввел дополнительно к своей дурацкой микрософтовскую, и вот результат через 13 лет — «Браузеры запутались в блочной модели»
При том, что результатом его работы является поломка валидатора. Можно было сделать без этого, но разработчики UMI сделали именно так. Плохой валидатор или хороший — другой разговор.
Об остальном тоже не буду. Речь идет не о jQuery, и не о том что лишний xsl:if при включенном кэше — проблема высосанная из пальца.
==
мы ушли далеко в офтопик. Но суть остается — CMS не должна осложнять работу разработчика. И это недоработка разработчиков UMI. Не критичная, не самая неприятная (и без того хватает недоработок), но недоработка.
Скиньте плиз адрес на плагин без дополнительных примочек в виде Java или выхода на сторонний ресурс. Я пока не нашел.
> В любом случае, бороться с ложными срабатываниями
> мне тоже кажется несколько странным.
Вы кажется не поняли о чем я пишу. Я пишу о том что при отладке кода в идеале не должно быть никаких ошибок. Все равно каких. Потому что если ошибки есть, с ними все равно нужно разбираться и тратить на это время. А его и так мало.
Извините, я не понял зачем ломать валидатор ради edit in place. Можно сделать ровно то же не ломая ничего.
> jQuery тоже использует собственные атрибуты и ничего страшного.
> Это удобно и по стандарту.
jQuery использует свои атрибуты вопреки стандарту. Но делает это в динамике. После загрузки страницы. При этом Кац в своей Библии предостерегает разработчиков от использования «собственных атрибутов».
Вы никому ничего не должны.
Просто выгода от использования своего пространства имен кажется мне совершенно не очевидной, а наличие нескольких сотен ложных предупреждений об ошибке вполне очевидны. На их фоне сложно искать реальные баги, и сопровождение большого проекта (сотни шаблонов), который много лет пилят разные верстальщики и программисты превращается в ад.
И почему «версткодрочеров»? Сдавать любой код (не только HTML) с предупреждениями, ошибками, и соплями — моветон. Хоть в Java, хоть в PHP, хоть где.
И если в коде 100 ложных срабатываний, пропустить 101 реальное — вполне обычное дело.
Нет. Это проблема не w3c, а вполне конкретного верстальщика, который обязан проверять все баги верстки на фоне ложного срабатывания валидатора.
2-3 года назад чтобы отедактировать страничку требовалось загрузить несколько сотен файлов на 1-2 Мб. сейчас вроде чуть-чуть сократили. Но не радикально.
Кстати, почему на базе популярных фреймворков, нет ни одной CMS, которая могла бы пользоваться спросом?
> относительно малое число людей
А что уже исчезли ie6-ie8, а оставшиеся безоговорочно поддерживают все фичи HTML5?
3) Использование вместо паспорта?
Любимый оперный фокус — пофиксить баг и в новой версии откатить откатить его назад.
Тем, что никому не придет в голову админить сайт через мобильник с оплатой трафика по 10р/Мб (без учета роуминга)
См. www.bbc.co.uk/news/technology-15844230
.
Еще неделю и скоро будет некому руку подать, в минуту душевной тревоги
Впрочем, это беда общая. UMI к примеру без ExtJS на слабых комп. не живет.
разработчику дает. у юзера отнимает
> Как правило, людям в админке нужны удобство и функционал
оно сводится на нет потребляемыми ресурсами.
> а скорость нужна на фронтенде.
скорость нужна везде. спросите у любого, кому приходится постоянно и много забивать данные в админку.
Мне приходится. А вам?
> На мой взгляд, такая админка все равно быстрее
Ну да. Можно сделать еще хуже. Разве я спорю?
Только кто мешает сделать лучше?
==
CMS типа ModX предназначена для средней паршивости сайтов-визиток и магазинчиков. Контент-менеджеры и секретарши, которые их админят везеде и всюду имеют самые дохлые компьютеры.
По крайней мере за много лет работы никогда не видел у них хорошего комп.
Более 10 лет проработал в больших конторах типа Rabota.Ru. Магазинчики и визитки для мелких конторок тоже делал.
И нигде и никогда не видел нормального комп. у контент-менеджера. Только самые плохие и самые дохлые.
==
Админка CMS на EXT — это очень жестоко по отношению к тем, кому придется админить.
Яндекс давно уже сделал валидный вариант.
help.yandex.ru/webmaster/?id=1111858
[!--noindex--]текст, индексирование которого нужно запретить[!--/noindex--]