Хабр Курсы для всех
РЕКЛАМА
Практикум, Хекслет, SkyPro, авторские курсы — собрали всех и попросили скидки. Осталось выбрать!
Хабр доступен 24/7 благодаря поддержке друзей
Комментарии 178
Вертикальное позиционирование без извращений и pivot points для позиционированных элементов тоже бы не помешали, а то конструкции типа left: 50%, margin-left: -50% слегка напрягают…
Поработайте с DOM деревом с учетом del и ins, и поймете в чем претензия. Мало того, вы знаете хоть одну систему, которая использует данные теги? Лично я не видел ни одной.
По поводу contenteditable, draggable. Им самое место в css.
Во поводу div'ов вместо конкретных тегов. Да, конечно же, можно так использовать, но читабельность такого кода ниже, чем чистый XML. Работа с DOM сложнее. Шанс на ошибку валидации выше. Попробуйте хоть раз поработать с XML в качестве оформления страниц, поймете разницу.
Шаблонная разметка не учитывает современные тенденции. Разместить все по шаблону не есть плохо. Плохо то, что это только статика. Да, и если я перенесу какой-то блок с одного места дерева DOM, в другое, он визуально поменяет свою позицию, если у него будет стоять position: a?
По поводу contenteditable, draggable. Им самое место в css.
Во поводу div'ов вместо конкретных тегов. Да, конечно же, можно так использовать, но читабельность такого кода ниже, чем чистый XML. Работа с DOM сложнее. Шанс на ошибку валидации выше. Попробуйте хоть раз поработать с XML в качестве оформления страниц, поймете разницу.
Шаблонная разметка не учитывает современные тенденции. Разместить все по шаблону не есть плохо. Плохо то, что это только статика. Да, и если я перенесу какой-то блок с одного места дерева DOM, в другое, он визуально поменяет свою позицию, если у него будет стоять position: a?
А в чём претензия, сказать не можете? Зачем с ними только работать в динамике, ума не приложу. Они предназначены для отображения каких-то изменений, например, между разными версиями документа. Откуда там динамика?
Хоть одну систему знаю. Да и сам использовал для внутренних инструментов сайта.
Конечно могу. Эти два тега имеют двоякую суть, могут быть блочными или строчными. Это вроде бы не проблема, но любой CSS, который будет учитывать позицию элемента в дереве, должен учитывать и этот элемент. Например, если у вас есть :first-child>b, то когда вы первый контейнер обернете в ins, наступит коллапс. Если скрипт обходил детей ноды, и там всегда предполагался какой-то один элемент, то с учетом del/ins все может поломаться, и придется использовать другие варианты работы с деревом, которые могут быть не самыми быстрыми в реализации.
А это с какой ещё стати? Это поведение, а не отображение. Вы ещё скажите, что каким-нибудь атрибутам вроде onclick место в CSS.
А чем position: fixed не поведение? Вот в чем разница? position: draggable — аналогичное свойство. Псевдоклассами управляем состояние наведения на таргет, DOM будет работать так же как и сейчас.
Шанс ошибки валидации, говорите, выше? А что вам говорит бизнес, когда сайт не работает (страница вообще не отображается) из-за ошибки в XML из-за какого-нибудь неэкранированного амперсанда? А современные методы DOM (например, querySelector и др.) вполне способны справится.
Выше шанс. Пропустить div проще, чем пропустить отсутствие четко именованного тега. Доказанный факт. Валидацию XML проще сделать перед публикацией, чем валидацию HTML.
Вы отрицаете технологию в общем, из-за того что в каком-то частном случае она не так удобна. Во-первых, предложите лучше, во-вторых, когда в браузерах появится хоть что-то подобное, это будет уже большой прогресс.
Конечно отрицаю, потому что если изначально технология не справилась с современными задачами, то дальше пойдут или хаки, или полное переписывание спецификации в данном вопросе. Это будет ад для разработчиков браузеров и для веб-разработчиков. Если лопата не поможет быстро перекопать 1 гектар земли, то любые нанопокрытия, улучшенные формы для снижения трения и другие примочки не исправят ситуацию. Нужно заведомо более гибкое решение, чтобы не было потом как с menu, то его отменяют, то обратно возвращают.
> если у вас есть :first-child>b, то когда вы первый контейнер обернете в ins, наступит коллапс
span, i/em туда же?
span, i/em туда же?
Скорее всего у нас разные подходы к пониманию того, что такое HTML, CSS, DOM. Для меня это не статические вещи, это некая живая абстракция, которая может мутировать, видоизменяться под конкретные условия, выполнять вполне конкретные задачи, решать поставленные цели. Это как инструмент. Я никогда не беру в рассчет тот факт, что некий веб-документ является статической сущностью, для меня это некий живой организм, в котором постоянно происходят процессы изменения, развития и так далее. Эти изменения вызваны модификацией кода разработчиком, либо модификацией некой части документа пользователем, либо работой некоего скрипта. Это другой уровень абстракции, который использует не частности, а общие принципы взаимодействия структур. Это тяжело без подготовки описать словами.
мне как-то рассказали как разграничить HTML и CSS. Так вот: то что нужно браузеру для слепых должно быть в HTML, а всё остальное в CSS. Если придерживаться этой точки зрения, то contentEditable должен быть в HTML, а draggable в CSS.
> Так вот: то что нужно браузеру для слепых должно быть в HTML, а всё остальное в CSS.
Короче, всё в CSS?
Короче, всё в CSS?
драгабла вообще нигде быть не должно %-) объект должен быть перемещаемым когда на него вешают обаботчик события. если обработчик не задан — не перемещаем.
также как, лапка над элементом должна появляться когда объект реагирует на клик (это ссылка, кнопка или задан обработчик). иначе — лапки быть не должно. и задаваться это должно отнюдь не в css
также как, лапка над элементом должна появляться когда объект реагирует на клик (это ссылка, кнопка или задан обработчик). иначе — лапки быть не должно. и задаваться это должно отнюдь не в css
Единственный неэкранированный амперсанд в ссылке, что не редкость, способен поломать страницу, и это будет обнаружено скорее всего в самый неподходящий момент.
Ну а если генерить XML не как текст, а как XML, используя DOM или какой-нибудь потоковый генератор?
Поствалидация XML, перед публикацией в веб, решает эту проблему. Генерировать код программой не особо выгодно, так как трудно интегрировать с темплейт-системами, труднее поддерживать код, изменять его.
Какая разница, кто матюгнётся: сервер на этапе поствалидации или браузер? А то, что темплейт-системы генерируют текст, а не XML — это очень прискорбно.
Был бы аппаратный XML процессор, было бы легче. На данном этапе работать со строками гораздо дешевле по ресурсам.
А с чего это шаблонизатор, выдающий XML, должен быть тяжелее текстового шаблонизатора? Ведь всё отличие XML-ного шаблонизатора в том, что на входе он потребует well-formed XML-документ, а на выходе заэкранирует что нужно. В текстовом шаблонизаторе на выходе получится тот же код, но за правильностью исходного шаблона с точки зрения XML и за экранирование вывода отвечает программист, а не шаблонизатор.
Потому что работа с объектами в памяти сложнее, чем работа со строками в памяти. К примеру, XSLT преобразование в php примерно в 4 раза медленнее, чем аналогичный функционал на Smarty.
Строка в памяти — это и есть объект. Про XSLT-преобразование речи никто и не ведёт. XSLT, помимо низкой производительности, плох ещё и тем, что исходные данные для него задаются в XML. Вот если шаблонизатор в качестве исходных данных принимает объекты, то он же сможет дёргать их методы или передавать их методам других объектам (или, например, статическим методам некоторых классов). При этом никто не мешает скомпилировать XML-шаблон непосредственно в код виртуальной машины соотв. языка (если язык такое позволяет). Кстати, надо сказать, что PHP проблемы с XSLT ещё и в том, что при каждом запросе надо компилировать сам XSLT-шаблон, тогда как в других языка достаточно скомпилировать шаблон при старте сервера.
XML-нода в памяти не простой объект, а DOM-нода со всеми вытекающими. Но, я вашу мысль понял. Надо над ней подумать, в этом есть свои плюсы.
XSLT, помимо низкой производительности, плох ещё и тем, что исходные данные для него задаются в XML.
Это как-то вашим собственным опытом подтверждено или же просто подпеваете народным мифам? :-)
Имея качественную обёртку, есть ли принципиальная разница — передавать данные в шаблонизатор через ассоциативный массив или же DOM? Да, может это займёт не 1, а целых 2-3 строчки кода… А если данные для шаблонизатора структурированы чуть сложнее, чем одноуровневый список?
Не, ну никто конечно не мешает через какой-нибудь механизм привязки данных к XML вроде JAXB данные для XSLT подгонять. Но ради чего, если проще работать с шаблонизатором, который сразу данные в виде объектов принимает? Тем более, что есть ряд удобств в именно таком подходе. Что если, например, у нас есть строки в camelCase и нужно проставить подчёркивание между словами? В XSLT геморрой. В случае с объектами мы просто пишем метод, выполняющий соответствующее преобразование и дёргаем его из шаблона. Ну и моя личная практика показывает: XSLT тяжёлый. Вообще, я пришёл к убеждению, что не следует пихать XSLT во все дыры, как это делают некоторые. Ибо не только медленно, но и неудобно. Кстати, пример, когда XSLT мне показался ну очень неуместным (и жутко прожорливым) — Sandcastle
Вот странно, почему когда заходит речь об XSLT — в первую очередь начинают вспоминать Java и всё с ней связанное, будто это чуть ли не единственная среда, в которой можно им пользоваться. Не отсюда ли растут ноги мифа о «тормознутости» XSLT?
Мне кажется, это далеко не самая востребованная функция в «шаблонизаторах», если уж зашёл разговор о способах вывода: сразу HTML или XML+преобразование. :)
В конце концов первостепенная цель — привести данные к конечной структуре, а не полностью отказаться от написания преобразующего кода, перенеся его на плечи шаблона, лишь бы побольше дешёвой магии.
Про Sandcastle ничего не могу сказать, не приходилось иметь дело.
А моя личная практика показывает: XSLT почти везде показывает себя лучше, чем традиционные костыли на интерпретируемых языках, работает нисколько не медленее (хотя, конечно, можно как s0rr0w бессмысленно попугать мифическими шаблонами весом в мегабайты), удобен, гибок и поддерживается кучей платформ. Profit.
Одна из немногих адекватных статей в пользу XSLT, на мой взгляд: blog.umi-cms.ru/sergej2/reabilitaciya_xmlxslt_tehnologij/
Реальных примеров, конечно, не хватает.
Что если, например, у нас есть строки в camelCase и нужно проставить подчёркивание между словами? В XSLT геморрой.
Мне кажется, это далеко не самая востребованная функция в «шаблонизаторах», если уж зашёл разговор о способах вывода: сразу HTML или XML+преобразование. :)
В конце концов первостепенная цель — привести данные к конечной структуре, а не полностью отказаться от написания преобразующего кода, перенеся его на плечи шаблона, лишь бы побольше дешёвой магии.
Про Sandcastle ничего не могу сказать, не приходилось иметь дело.
Ну и моя личная практика показывает: XSLT тяжёлый.
А моя личная практика показывает: XSLT почти везде показывает себя лучше, чем традиционные костыли на интерпретируемых языках, работает нисколько не медленее (хотя, конечно, можно как s0rr0w бессмысленно попугать мифическими шаблонами весом в мегабайты), удобен, гибок и поддерживается кучей платформ. Profit.
Одна из немногих адекватных статей в пользу XSLT, на мой взгляд: blog.umi-cms.ru/sergej2/reabilitaciya_xmlxslt_tehnologij/
Реальных примеров, конечно, не хватает.
Мне кажется, это далеко не самая востребованная функция в «шаблонизаторах»
Тем не менее, когда всё-таки нужно что-то подобное, с XSLT приходится использовать костыли. Да и необходимость генерить XML, чтобы подать его на вход XSLT-шаблону несколько удручает. Ибо в случае даже с JAXB необходимо прописывать XML-схему и аннотации. Конечно, можно придумать свой костыль для простенького преобразования объектов в XML, но зачем, когда можно и без этого?
Вот странно, почему когда заходит речь об XSLT — в первую очередь начинают вспоминать Java и всё с ней связанное, будто это чуть ли не единственная среда, в которой можно им пользоваться.
Да нет, как раз более популярным в вебе является PHP, потому и про XSLT говорят, наверное, в контексте PHP. Так вот: в Java (Ruby, Python, C#) как раз с производительностью XSLT несколько лучше, ибо можно при старте сервера скомпилировать XSLT, а не парсить его каждый раз при HTTP-запросе. XSLT в Java и PHP теоретически может работать одинаково, т.к. скорее всего и там и там дёргается нативная реализация XSLT (хотя, возможно, в Java XSLT-процессор написан на Java, но от этого хуже не становится). Вот только если насчёт Java я уверен, что Java-код работает не медленее XSLT-процессора, то от PHP можно ждать чего угодно.
XSLT почти везде показывает себя лучше, чем традиционные костыли на интерпретируемых языках
А кто говорит про интерпретируемые? Я например, говорю больше про Java и .NET. Так вот там производительность шаблонизатора без XSLT должна быть выше, ибо в конечном итоге все сводится к нативным инструкция процессора, которые не работают с DOM-деревом в памяти, а сразу выводят текст. Ах да, им ещё не надо парсить входной XML.
Одна из немногих адекватных статей в пользу XSLT, на мой взгляд: blog.umi-cms.ru/sergej2/reabilitaciya_xmlxslt_tehnologij/
А ничего адекватного в статье нет. Только лозунги. И сравнение со Smarty в кривых руках. Ну например:
Правка XSLT шаблона не предполагает вмешательства в бизнес-логику и анализ структуры связей, которые могли бы использоваться в шаблоне будь он на Smarty.
Правда? Чего бы это вдруг шаблонизатор начал вмешиваться в бизнес-логику? А как XSLT от этого спасает? Во втором случае я вижу единственный вариант: в бизнес-логику лезет не сам шаблон, а некий слой, который вытаскивает данные и преобразует в XML. Для этого слоя даже есть название: presenter в паттерне MVP. Так вот если не устраивает MVC, то может стоит перейти на MVP? И в случае шаблонизатора без XSLT всё отличие presenter'а будет заключаться в том, что он просто вытащит данные, а не будет ещё преобразовывать их в XML.
К примеру, XSLT преобразование в php примерно в 4 раза медленнее, чем аналогичный функционал на Smarty.
Пруф-линком не поделитесь? А то что-то сомнения большие одолевают.
Не могу, собственные тесты. Объем базового XML — примерно пару мегабайт. Преобразование XML в RTF.
Что ж, было весьма ожидаемо. Вспомнили бы сразу тогда и WordML… :-D
Только как это соотносится с возможностями традиционных шаблонизаторов, построенных поверх PHP? С помощью Smarty вы тоже RTF создаёте семь раз на дню?
Не встретил на Хабре пока ещё ни единой контр-позиции с чёткими доказательствами, чем же XSLT так страшен и тормознут. Всё как один уповают на некогда услышанный миф. И, как оказалось, в большинстве своём хаящие даже представления не имеют, как создать простейший лаконичный XSL шаблон для преобразования и подготавливать для него данные.
Только как это соотносится с возможностями традиционных шаблонизаторов, построенных поверх PHP? С помощью Smarty вы тоже RTF создаёте семь раз на дню?
Не встретил на Хабре пока ещё ни единой контр-позиции с чёткими доказательствами, чем же XSLT так страшен и тормознут. Всё как один уповают на некогда услышанный миф. И, как оказалось, в большинстве своём хаящие даже представления не имеют, как создать простейший лаконичный XSL шаблон для преобразования и подготавливать для него данные.
Давайте сделаем проще. Берем некий XML, с какого-нибудь сервиса, вы делаете свое преобразование при помощи XSLT, я — свое на смарти. Меряем скорость. Идет?
Вам пример с XML был совершенно несопоставим. Теперь пытаетесь отыграться хоть в чём-то?
Извините, моё время мне пока дороже. И применение XSLT где бы то ни было его точно не отнимает, по сравнению с остальными многочисленными костылями-велосипедами.
Если вам настолько принципиальны разницы в производительности (а всё остальное, стало быть, не имеет значения?) — тестируйте и поделитесь результатами на Хабре. А мы обсудим. :)
Извините, моё время мне пока дороже. И применение XSLT где бы то ни было его точно не отнимает, по сравнению с остальными многочисленными костылями-велосипедами.
Если вам настолько принципиальны разницы в производительности (а всё остальное, стало быть, не имеет значения?) — тестируйте и поделитесь результатами на Хабре. А мы обсудим. :)
Свежие данные. Переписывание парсера с XML->XSL->RTF на XML->Smarty->RTF дало прирост примерно раз в 10 на документах страниц под 200. Исходный XML тупой что двери, тексты да пара табличек.
покажи тесты
Согласен, на HTML5 возлагают слишком большие надежды, пока его допилят до финальной версии и он станет поддерживатся большинством браузеров, скорее всего у рынка будут уже другие требования.
Перенесите, кстати, в тематический блог, этому место на главной.
Перенесите, кстати, в тематический блог, этому место на главной.
> Нужно всего лишь позволить придумывать свои теги! XML для оформления страницы, HTML — для оформления контента. Почему бы сразу не использовать XML?
Ну так кто не дает? Откройте для себя XSLT ;)
p.s. Сорри, что в 2 коммента — ктрл-ентер случайно нажал.
p.s. Сорри, что в 2 коммента — ктрл-ентер случайно нажал.
XML — вольное изложение темы. Какие теги придумаешь, какую структуру создашь, то и твое. HTML — жестко очерченные рамки и названия. Если использовать только XML, то поисковые системы сойдут с ума. Потому что один назвал заголовок HEADER_LEVEL_ONE, а второй — H1. Как догадаться, что это одно и то же? Поэтому я и смешиваю два разных языка, выбирая для разных задач лучшее.
XSLT не решает эту проблему.
XSLT не решает эту проблему.
Он и не должен ее решать. Просто автор сетовал, что нельзя придумать свои теги. А я о том и писал, что если придумывать их «свои», то пропадает семантический подтекст HTML (ну или для полной корректности сравнения возьмем XHTML). Однако если очень уж хочется свое придумать — можно взять базой XML, и через XSLT транслировать его в HTML для браузеров и поисковиков.
Это дорого по ресурсам, и нисколько не эффективно. Зачем что-то делать два раза, если можно сделать один? Да и работать с CSS, DOM в XML будет в разы легче и проще. Попробовав раз, трудно от этого сладкого запретного плода отказаться.
Ну… гзип по ресурсам гораздо дороже, но все-таки его пользуют там где нужно :) Так что это не показатель. К тому же не факт, какие еще ресурсы будут дороже: xml может быть меньше по размеру, а xsl трансляцию можно делать у клиента. В общем, всему свое применение ;)
на тему семантики: habrahabr.ru/blogs/css/96426/
а вообще, xml — это просто синтаксис и на его основе существует множество _стандартных_ языков: xhtml, mathml, atom, foaf, vcard… и некоторые из них _уже_ понимают поисковики.
а вообще, xml — это просто синтаксис и на его основе существует множество _стандартных_ языков: xhtml, mathml, atom, foaf, vcard… и некоторые из них _уже_ понимают поисковики.
Открою вам секрет, что custom tags в ИЕ поддерживаются с версии 5.0 или 5.5, точно не помню. Ищите в инете это ключевое слово. Там все не безоблачно, но использовать в проектах можно.
Открою вам секрет, эти кастом теги без хаков не потдерживают стили.
Поддерживают. Даже пример на сайте MS есть.
Можно ссылку? Мои експерименты показывают обратное.
Спасибо, это реально полезная инфа. Итересно что этот способ работает во всех браузерах.
Я ессно имел ввиду теги типа Tag. Такая штука потдерживается всеми браузерами за исключением ИЕ.
Я ессно имел ввиду теги типа Tag. Такая штука потдерживается всеми браузерами за исключением ИЕ.
от header вместо div#header никто с ума не сойдёт, кроме разве что ff2 ;-)
> Веб разработкой я занимаюсь давно, и помню еще IE3 и NN4.xx.
> Начало разработки спецификаций HTML5 и CSS3 уже не вызывала у меня щенячьего восторга и бурной радости, а воспринималась как вполне эволюционное событие.
Может быть вы просто повзрослели? ;)
> Начало разработки спецификаций HTML5 и CSS3 уже не вызывала у меня щенячьего восторга и бурной радости, а воспринималась как вполне эволюционное событие.
Может быть вы просто повзрослели? ;)
Возьмем вполне нормальную ситуацию: у нас есть четыре блока, которые, в зависимости от ширины контента или окна браузера, должны выстраиваться друг за другом, и занимать или одну строку, или две, три, четыре строчки.
Существует достаточно простое, но не совсем очевидное решение — использование inline-block (подробнее)
У которого есть основное ограничение: внутри инлайн блока не должно быть блочных элементов.
Найдите в спецификации указание на этот факт, что внутри инлайн-блока можно использовать блоки. Мне это не удалось, может плохо искал.
Вот что написано про блоки в CSS3
A block-level box is a box that has a used value for ‘display’ of ‘block’, ‘list-item’, ‘table’, ‘table-*’ (i.e., all table boxes) or <template>. A block-level element is an element all of whose top-level non-anonymous boxes are block-level.
An inline-level box is a box that has a used value for ‘display’ of ‘inline’, ‘inline-block’, ‘inline-table’ or ‘ruby’.
В описании блочных элементов отсутствует inline-block, поэтому дуализм этого типа, я думаю, не может применяться в чистом виде как отдельная сущность.
A block-level box is a box that has a used value for ‘display’ of ‘block’, ‘list-item’, ‘table’, ‘table-*’ (i.e., all table boxes) or <template>. A block-level element is an element all of whose top-level non-anonymous boxes are block-level.
An inline-level box is a box that has a used value for ‘display’ of ‘inline’, ‘inline-block’, ‘inline-table’ or ‘ruby’.
В описании блочных элементов отсутствует inline-block, поэтому дуализм этого типа, я думаю, не может применяться в чистом виде как отдельная сущность.
Я вот когда смотрю на семантическую состоявляющую ШТМЛ5, становится смешно. Это ж надо было сделать нерасширябельный словарь. О чем думали? Это же тупик. Никаких отличий от HTML4.
When people say «i want to extend HTML in arbitrary, private, and probably proprietary ways,» the appropriate answer is «fuck you»— Mark Pilgrim, krijnhoetmer.nl/irc-logs/whatwg/20091205#l-330
Меня вот реально бесит, что в CSS нужно указывать браузер… К чему эта лабуда из неймспейсов -moz, -opera, -webkit раздувающая файл?! Похоже на костыли к ещё не сломанным ногам…
Это не нужно делать, это можно делать для работы с экспериментальными свойствами, поддержка которых в будущих версиях браузера может: а) исчезнуть б) измениться в) очень сильно измениться.
Opera, IE9, Chrome, Safari — последние версии этих браузеров уже поддерживают некоторые свойства без префиксов в ответ на устаканившуюся спецификацию.
Opera, IE9, Chrome, Safari — последние версии этих браузеров уже поддерживают некоторые свойства без префиксов в ответ на устаканившуюся спецификацию.
На практике 100% работает ТОЛЬКО с префиксами нейспейсов. Даже базовый opacity. Приходиться делать проекты для web/wap и если web работает на ура, то с мобильными устройствами всё гораздо хуже.
100% работает ТОЛЬКО с префиксами нейспейсов. Даже базовый opacity
Вы про какую практику — opacity чудесно работает и всегда работало (с лохматых годов) без префиксов, а в IE приходилось эмулировать это свойство через фильтры. Вы кажется весьма плохо знакомы с темой разговора.
И это никакие не неймспейсы, даже близко не лежат.
Это временная реализация свойств, которая похожа то, что описано в спецификации CSS3, но не удовлетворяет всем требованиям спецификации. Со временем их заменяют оригинальные свойства без префиксов.
Не стоит забывать теория!=практика…
…порассуждаем о том, зачем же нужен HTML. А нужен он для того, чтобы сделать разметку некой информации
Он нужен для того, чтобы делать сайты здесь и сейчас, в соответствии с текущим задачам и методам работы. Поэтому список новых элементов был взят из словаря самых популярных имён элементов, а новая функциональность языка до боли смахивает на то, что мы до сих пор делали при помощи костылей.
А вообще — вброс профессиональный получился.
По мне, сколько бы ни было недостатков в новых семействах технологий, этот путь развития гораздо лучше, чем Flash-AIR-Silverlight-безумие. И ребятам из WHAT WG и W3C нужно ставить памятники.
А чем вам не нравится Silverlight?
Аргументирую — 1 технология для веба с широким набором устройств.
Вам нравится тыкать пальцами в интерфейс, заточенный под стилус или мышь?
Странно, но мне тоже нет. Интерфейс должен быть заточен под конкретное устройство, т.е. каждый форм-фактор требует индивидуального подхода.
ЗЫ. Silverlight — может нравится хотя бы тем, что на десктопе — это производительная (HTML5 даже рядом не валялся), бесплатная, удобная, кроссплатформенная технология как для десктопов, так и для веба. 90% ваших пользователей смогут использовать богатые возможности, остальным 10% можно скормить поделку на JS/HTML.
Учите матчасть.
Вам нравится тыкать пальцами в интерфейс, заточенный под стилус или мышь?
Странно, но мне тоже нет. Интерфейс должен быть заточен под конкретное устройство, т.е. каждый форм-фактор требует индивидуального подхода.
ЗЫ. Silverlight — может нравится хотя бы тем, что на десктопе — это производительная (HTML5 даже рядом не валялся), бесплатная, удобная, кроссплатформенная технология как для десктопов, так и для веба. 90% ваших пользователей смогут использовать богатые возможности, остальным 10% можно скормить поделку на JS/HTML.
Учите матчасть.
Symbian — есть. WP7 — есть. Остальные подтянутся.
На десктопе — Windows 90%, OSX остальные 10% (самые быстрые Опера и Хром — это 1% от этих 10%), о каком линуксе на десктопах вы говорили? Истого получаем, если нужен десктоп — берем Silverlight и голова не болит.
Если нужны мобильники — берем SL для WP7/Nokia, остальным даем JS/HTML. Ну или мудрим что-нить нативное, полюбому лучше HTML5 будет.
Таким образом, на десктопе 99% кроссплатформенность, на мобилах — ждем полгода.
Может SL удобный? Блин, да HTML со браузером там рядом не валялся. Ембедим полностраничнще SL/oob приложение, забываем весь геморой с HTML/CSS/браузером. По правой кнопке свое меню, без всякого браузерного хлама.
Удобство для разработчика? Куда уже больше. Нормальный отладчик, номальный язык программирования, нормальная дока, нормальные библиотеки от передовиков производства.
Проблемы с SEO, так робот.тхт никто не отменял, не помогает — RTFM.
Бесплатная? Конечно, качаем VS.NET express edition. Или у вас Windows нет? Ааа, голодаете… На детях экономите, нехорошо…
Технология несвободная, неоткрытая, удобная, хорошо документированная, бесплатная, производительная.
Весь мир в зависимости от Microsoft уже 25 лет и ничего, живет себе, пользуется, деньги зарабатывает.
Откуда паранойя? Совковое прошлое?
Избавьтесь от предрассудков насчет продукции Microsoft, никому вы не нужны со своей наркозависимостью.
На десктопе — Windows 90%, OSX остальные 10% (самые быстрые Опера и Хром — это 1% от этих 10%), о каком линуксе на десктопах вы говорили? Истого получаем, если нужен десктоп — берем Silverlight и голова не болит.
Если нужны мобильники — берем SL для WP7/Nokia, остальным даем JS/HTML. Ну или мудрим что-нить нативное, полюбому лучше HTML5 будет.
Таким образом, на десктопе 99% кроссплатформенность, на мобилах — ждем полгода.
Может SL удобный? Блин, да HTML со браузером там рядом не валялся. Ембедим полностраничнще SL/oob приложение, забываем весь геморой с HTML/CSS/браузером. По правой кнопке свое меню, без всякого браузерного хлама.
Удобство для разработчика? Куда уже больше. Нормальный отладчик, номальный язык программирования, нормальная дока, нормальные библиотеки от передовиков производства.
Проблемы с SEO, так робот.тхт никто не отменял, не помогает — RTFM.
Бесплатная? Конечно, качаем VS.NET express edition. Или у вас Windows нет? Ааа, голодаете… На детях экономите, нехорошо…
Технология несвободная, неоткрытая, удобная, хорошо документированная, бесплатная, производительная.
Весь мир в зависимости от Microsoft уже 25 лет и ничего, живет себе, пользуется, деньги зарабатывает.
Откуда паранойя? Совковое прошлое?
Избавьтесь от предрассудков насчет продукции Microsoft, никому вы не нужны со своей наркозависимостью.
Не знаю, кто куда бежит, но седьмерка продается на ура.
SL на десктопе установлен на 65% машин. (см. riastats.com)
Установить SL плагин — не сложнее любого другого из сотни ваших браузерных плагинов.
Избавляться от flash — это разумно, устаревшая технология. Но HTML5 нету даже на 65% десктопов и в ближайшие 2 года не будет (пока выйдет 9-ка, пока его все поставят).
И никакого выбора — ДА!
Выбор — это бред сивой кобылы. Лучше одна IDE, но отличная, чем 10 — но говёных. Лучше один язык — отличный, чем 10 — на любителя. Лучше один фреймворк, но сделанный с умом, чем куча третьесортного хлама.
Посмотрите на iPhone — там есть выбор? Или нормальные нативные приложения сделаные на XCode (то еще фуфло), или поделки на HTML, которые и приложениями трудно назвать, веб-странички разве что.
Откуда такая аллергия на Windows? Что есть такого полезного в (вписать по своему усмотрению), чего нет в Windows?
Отзывы о WP7 — самые положительные. Проще iPhone — это даже лучше…
SL на десктопе установлен на 65% машин. (см. riastats.com)
Установить SL плагин — не сложнее любого другого из сотни ваших браузерных плагинов.
Избавляться от flash — это разумно, устаревшая технология. Но HTML5 нету даже на 65% десктопов и в ближайшие 2 года не будет (пока выйдет 9-ка, пока его все поставят).
И никакого выбора — ДА!
Выбор — это бред сивой кобылы. Лучше одна IDE, но отличная, чем 10 — но говёных. Лучше один язык — отличный, чем 10 — на любителя. Лучше один фреймворк, но сделанный с умом, чем куча третьесортного хлама.
Посмотрите на iPhone — там есть выбор? Или нормальные нативные приложения сделаные на XCode (то еще фуфло), или поделки на HTML, которые и приложениями трудно назвать, веб-странички разве что.
Откуда такая аллергия на Windows? Что есть такого полезного в (вписать по своему усмотрению), чего нет в Windows?
Отзывы о WP7 — самые положительные. Проще iPhone — это даже лучше…
SL на десктопе установлен на 65% маши
Статистика — очень интересная штука, вот у меня номинально установлен Silverlight, но примеры с сайта MS я посмотреть не могу, просит обновления :)
меньше слов – больше дела: сколько у тебя сайтов на Сильверлайте сделано? сколько они принесли денег? а сколько сейчас пользователей у WP7? сколько тебе денег принесли приложения написанные для WP7?
У меня лицензионный Windows 7, и на нем нет Silverlight. И, скорее всего, никогда не будет. Как и у большинства. ;)
У меня лицензионный Windows 7 и на нем уже есть Silverlight. Как у большинства :)
Скрипач не нужен. :)
PS И много раз вам приходилось им пользоваться?
PS И много раз вам приходилось им пользоваться?
Сколько корпоративных продуктов на SL вы знаете? Не поделок на коленках, а реальных корпоративных продуктов?
WP7 — есть
Простите, но, если я не ошибаюсь, то в браузере там Silverlight не будет, только в качестве приложений.
OSX остальные 10%
Под OS X можно установить Silverlight, да, но, если я не путаю, то в стандарте он там толи не установлен, толи в комплекте дается старая версия. Сейчас я зашел в галерею примеров Silverlight на сайте MS и меня просят установить обновление плагина — далеко не самое элегантное решение. Устанавливать что-то дополнительное ради непонятно чего? Нет, спасибо.
>Бесплатная? Конечно, качаем VS.NET express edition. Или у вас Windows нет? Ааа, голодаете… На детях экономите, нехорошо…
Смотрю на свой макбук по «нереально завышеной цене и переплатой за бренд» и не понимаю о чем вы. SL это Windows-only и разработка там тольео на Windows-only. (не нада тут про iOS SDK, CocoaTouch не претендует на то, что претендует SL) И разве express edition позволяет создавать коммерческие продукты? И зачем мне этот ваш виндовз?
>Symbian — есть. WP7 — есть. Остальные подтянутся.
Угу, сейчас все все бросят и будут делать.
p.s.
покормил :3
Смотрю на свой макбук по «нереально завышеной цене и переплатой за бренд» и не понимаю о чем вы. SL это Windows-only и разработка там тольео на Windows-only. (не нада тут про iOS SDK, CocoaTouch не претендует на то, что претендует SL) И разве express edition позволяет создавать коммерческие продукты? И зачем мне этот ваш виндовз?
>Symbian — есть. WP7 — есть. Остальные подтянутся.
Угу, сейчас все все бросят и будут делать.
p.s.
покормил :3
Перечисленные проблемы — это не проблемы Silverlight, а проблемы политики MS и сложившейся инфраструктуры. Как технология Silvelight гораздо продвинутее.
Symbian — нет, RIM — нет, Android — нет, Apple — нет.
Это не минусы технологии как таковой, а минусы политики MS.
Может она удобная? Тоже нет, в отличие от HTML5 это чуждый браузеру элемент со всеми вытекающими последствиями: фокус на странице и фокус на приложении разные, текст и там, и там одновременно не выделишь, по правой кнопке не будет меню браузера.
Удобство для разработчика? Проблемы с SEO и с той же чужеродностью.
А что, уже rich internet application, написанные на extjs (или как его теперь переименовали) с этим эффективно борются? Лично моё впечатление, что там с данным моментом не меньше граблей. Особенно радует пляска с бубном вокруг контекстного меню, которое в опере вообще никак нельзя переопределить, а нужно (ну очень нужно в каких-нибудь WYSIWYG-редакторах). И чего это хлопцы из W3C никак не придумают механизм для встраивания своих пунктов меню в контекстное меню «агента пользователя»?
Бесплатная? Нет, чтобы посмотреть надо купить Windows или переплачивать за Мак.
Дык, всё же документировано и стандартизировано. Никто не мешает взять и написать свою реализацию. Вон, чуваки из Novel замутили свою с блэк-джеком. Правда, мешает политика самих MS и политика других компаний в отношении продукции MS, ведь за еду никто не будет писать реализацию, а спонсировать не хотят. Кстати, сюда же и вопросы про удобство разработчика. Есть VS, очень хорошая но платная, есть SharpDevelop, которая недо-IDE (но всё равно, значительно удобнее, чем Eclipse/Netbeans/ещё-что-нибудь для JS). Никто не мешает написать свою IDE, как это сделано в случае с Java. Но ведь не пишут. А кто виноват? Может, хомячки, возглавляемые W3C, которые везде пихают свой любимый HTML+CSS+JS, и даже не пытаются смотреть по сторонам и делать мир лучше?
Тем, что это закрытый плагин к браузеру, одна из тупиковых ветвей развития интернета.
Где же он закрытый? А тупиковая весть развития «интернета» — это как раз веб в его нынешнем состоянии, ибо убог и по своим возможностям и жутко медлителен, и вообще, как бы не очень подходит для построения rich internet application, ибо по сути своей был придуман для описания гипертекста.
Ну что же, у Silverlight очевидные преимущества перед HTML+CSS+JS. Это и производительность, и гораздо более мощный и выразительный язык, и, как следствие, лучшая поддержка со стороны IDE, и огромный функционал, доступный в .NET Framework. Например, видели WPF? Куда какому-нибудь Sencha до него по возможностям? Или ещё пример: 21 век на дворе, а W3C только начинает возиться с web sockets, когда в принципе и Java-апплеты, и Flash и Silverlight могут нормально общаться с сервером. Ну пройдёт ещё 10 лет и устареет последний браузер, не поддерживающий web sockets. А в «закрытых плагинах к браузеру» всё реализовано уже давно, но не кошерноЪ, как говорят мужики.
Преимущества кратко озвучены. Подробнее см. на просторах интернета. А что значит «сильверлайта нет»? Сокеты нужны в RIA. Собтвенно, мне всегда казалось, что сильверлайт для них и предназначен. Или я ошибался?
Я тут как раз воюю с противниками «закрытых плагинов к браузеру». Ну для любителей открытых плагинов к браузеру есть Java Applets. А так, ну да, есть во флеше аналог web sockets, уже давно работающий на старых браузерах. Ну есть он и в сильверлайте. Только вот сильверлайт технически попродвинутее будет. А так да набезрыбье HTML5 и рак Flash — рыба.
На современных машинах? А ничего, что есть немалый такой контингент пользователей, юзающих IE6 и IE7, который хвалёный HTML5 не поддерживают? И они даже не могут посмотреть видео/послушать музыку без «закрытых плагинов для браузера». То же и с сокетами. Пока пошевелится w3c, пока разработчики наваяют/протестируют, пока все перейдут на IE9… Вот вам и прогресс, вот вам и развитие интернета.
Я тут как раз воюю с противниками «закрытых плагинов к браузеру». Ну для любителей открытых плагинов к браузеру есть Java Applets. А так, ну да, есть во флеше аналог web sockets, уже давно работающий на старых браузерах. Ну есть он и в сильверлайте. Только вот сильверлайт технически попродвинутее будет. А так да на
На современных машинах? А ничего, что есть немалый такой контингент пользователей, юзающих IE6 и IE7, который хвалёный HTML5 не поддерживают? И они даже не могут посмотреть видео/послушать музыку без «закрытых плагинов для браузера». То же и с сокетами. Пока пошевелится w3c, пока разработчики наваяют/протестируют, пока все перейдут на IE9… Вот вам и прогресс, вот вам и развитие интернета.
Увы, это не те преимущества, которые нужны.
А какие нужны? Работа на всех устройствах? Ну так и HTML4 прекрасно работает на многих устройствах. Зачем нам ещё какие-то HTML5 и плагины?
Плагины к браузеру сами по себе ущербны своей чужеродностью, небезопасностью
Что значит «чужеродность» и чем она ущербна? Дыры в безопасности могут быть и в браузере.
IE6 и IE7 — это старьё и занимает от силы треть. Силверлайта нет на гораздо большем числе машин.
Сильверлайт реализован в виде плагина, и его потому нетрудно скачать и установить, будучи даже полным профаном (в последнее время подобная операция делается в два клика). При этом пользователь кликнет куда надо, ибо у него будет красоваться сообщение c просьбой установить. Установка браузера для человека неискушённого — задача более нетривиальная.
HTML уже есть на телефонах и любых компьютерах в более-менее приличном виде.
А это «более-менее приличный вид» — это уровень цветных буковок. К тому времени, как в нём появится функционал, имеющийся в Silverlight, или хотя бы в JavaFX и Flash, может да, Silverlight успеет достаточно распространиться.
Вброс отличный. Хабраюзеры плюсуют просто за вброс, даже не думая о том, как, например, поместить contenteditable во (внимание!) DOM, как это предлагает автор. DOM, которая про отображение ничего не знает.
Несуразностей вообще полная статья, но фраза «где инновации, зачем нам новый стандарт, когда он уже устарел» действует на молодых людей как тряпка на быка. Ведь они то знают — все что было сделано до того, как он об этом узнал — устарело ;)
Несуразностей вообще полная статья, но фраза «где инновации, зачем нам новый стандарт, когда он уже устарел» действует на молодых людей как тряпка на быка. Ведь они то знают — все что было сделано до того, как он об этом узнал — устарело ;)
А что, собственно, вас смущает? Давайте говорить предметно, и без вырезания отдельных фраз.
Меня смущает ваша невнятная аргументация, несвязность текста и позиция «Да несогласен я!» (- Простите, с Энгельсом или Каутским? — Да с обоими! (с) Собачье сердце). Аргументация гиперэмоциональна и несодержательна. Приходится еле-еле догадываться что вы там хотели сказать.
Вы описали стандартный float:left и совершенно не объяснили толком, что там за коллапс у вас с ними возник. И только путем долгого вчитывания стало понятно, что вы либо торопились, либо некорректно объяснили, что хотели не просто float:left, а интеллектуальный флоат (да и это только мои догадки). Но зато КОЛЛАПС не забыли!
От разметки тут же прыгаете к дизайну. Я верю, что вам очень надо было вкрутить CSS3 к статье, но это не повод обсирать хорошие идея с веб-формами. Как бы по-вашему рынок не требовал кастомных чекбоксов, стандартный элемент «календарь» он требует на два порядка сильнее.
Да и с del ins — совершенно очевидно зачем были сделаны эти теги. Даже на Хабре постоянно можно увидеть надпись в топике update: спасибо за карму, перенес в тематический блог. А вы говорите что это надо какому-то там мифическому васе пол-сотых-процента. Стандарт описания изменений user-generated контента напрашивается со всей очевидностью.
Из всей статьи относительно полно и беспристрастно лишь абзац с точкой отсчёта (идея действительно не нова), тем не менее совершенно не ясно зачем на этом фоне делать истерику. Или по-вашему все так просто — ха, перевернём ось икс и ура? Не думая как изменится поведение верстки. Подумайте об одном float:left.
у нас есть четыре блока, которые, в зависимости от ширины контента или окна браузера, должны выстраиваться друг за другом, и занимать или одну строку, или две, три, четыре строчки. Обычные float'ы. Все, коллапс.
Вы описали стандартный float:left и совершенно не объяснили толком, что там за коллапс у вас с ними возник. И только путем долгого вчитывания стало понятно, что вы либо торопились, либо некорректно объяснили, что хотели не просто float:left, а интеллектуальный флоат (да и это только мои догадки). Но зато КОЛЛАПС не забыли!
От разметки тут же прыгаете к дизайну. Я верю, что вам очень надо было вкрутить CSS3 к статье, но это не повод обсирать хорошие идея с веб-формами. Как бы по-вашему рынок не требовал кастомных чекбоксов, стандартный элемент «календарь» он требует на два порядка сильнее.
Да и с del ins — совершенно очевидно зачем были сделаны эти теги. Даже на Хабре постоянно можно увидеть надпись в топике update: спасибо за карму, перенес в тематический блог. А вы говорите что это надо какому-то там мифическому васе пол-сотых-процента. Стандарт описания изменений user-generated контента напрашивается со всей очевидностью.
Из всей статьи относительно полно и беспристрастно лишь абзац с точкой отсчёта (идея действительно не нова), тем не менее совершенно не ясно зачем на этом фоне делать истерику. Или по-вашему все так просто — ха, перевернём ось икс и ура? Не думая как изменится поведение верстки. Подумайте об одном float:left.
Вы описали стандартный float:left и совершенно не объяснили толком, что там за коллапс у вас с ними возник
Если бы вы не вырывали слова из контекста, то изначально бы прочитали, что речь идет про Темплейты отображения.
Темплейты отображения помогут создать некую ячеиструю структуру, которая позволит дизайнерам расставлять блоки в определенные места. Эта технология повторяет старые добрые таблицы и взята, по моим ощущениям, из полиграфиии. Эта технология прекрасна, понятна, вроде бы даже как удобна, но только для статических страниц. Если применять адаптивную разметку, при которой блоки подстраиваются под контент и могут менять свое местоположение, то это поведение невозможно реализовать при помощи текущей спецификации. Мало того, вообще непонятен механизм перестановки блоков в DOM-дереве (динамика и приложения), когда блок имеет строго указанную позицию в отображении. Фактически, упущено главное — как это все может изменяться. Теперь понятнее?
Я верю, что вам очень надо было вкрутить CSS3 к статье, но это не повод обсирать хорошие идея с веб-формами. Как бы по-вашему рынок не требовал кастомных чекбоксов, стандартный элемент «календарь» он требует на два порядка сильнее.
Веб-формы нужны, важны, и моя основная мысль была не про это. Вот есть замечательный атрибут placeholder. Идея — супер. А как его стилизовать? Или второй вопрос, что делает progress элемент в формах? Его хоть кто-то сможет заполнить и отправить на сервер? Почему нельзя было сделать option обычным block-level элементом, чтобы можно было создавать свои структуры, например текст + краткое описание? Где combo-box, так называемый, который сейчас все реализуют вручную?
Да и с del ins — совершенно очевидно зачем были сделаны эти теги
Да, очевидно. Но их эффект стремится к нулю. Многие теги были сделаны с явными целями, но это не изменяет их полезность.
Я новичок тут, не привык еще и не освоился.
Послушайте уважаемый. Вы там можете себе вообразить что угодно, но вы объясняете непонятно, говорю вам как пользователь вашего контента.
1. почему
2. этого
3. нет
4. в статье?
Вы придумали себе какой-то там термин и решили что все его знают? Почему я должен угадывать? Я же ведь читаю вас. Вы же хотели что-то донести.
Отсюда и негатив к статье и вам лично.
При чем тут это? Объясняйте свою позицию с толком и расстановкой. Просто непонятно ничего и сумбурно. Ясно что есть критика, а в чем суть критики — ускользает как песок сквозь пальцы.
Вот читаю я
И не понимаю как связана позиция в отображении и позиция в дом дереве. И посл о непонятности механизма лично для меня остается темнотой.
Может я, конечно, туплю, из-за того что сижу на море в отпуске, но вот ответьте на последний этот вопрос: как связана позиция в отображении и позиция в дом дереве? Учитывая то, что в дом дереве блок может быть как в начале так и в конце, а в отображении быть тоже где угодно.
Темплейты отображения помогут создать некую ячеиструю структуру, которая позволит дизайнерам расставлять блоки в
1. почему
2. этого
3. нет
4. в статье?
Вы придумали себе какой-то там термин и решили что все его знают? Почему я должен угадывать? Я же ведь читаю вас. Вы же хотели что-то донести.
Отсюда и негатив к статье и вам лично.
Я новичок тут, не привык еще и не освоился.
При чем тут это? Объясняйте свою позицию с толком и расстановкой. Просто непонятно ничего и сумбурно. Ясно что есть критика, а в чем суть критики — ускользает как песок сквозь пальцы.
Вот читаю я
вообще непонятен механизм перестановки блоков в DOM-дереве (динамика и приложения), когда блок имеет строго указанную позицию в отображении
И не понимаю как связана позиция в отображении и позиция в дом дереве. И посл о непонятности механизма лично для меня остается темнотой.
Может я, конечно, туплю, из-за того что сижу на море в отпуске, но вот ответьте на последний этот вопрос: как связана позиция в отображении и позиция в дом дереве? Учитывая то, что в дом дереве блок может быть как в начале так и в конце, а в отображении быть тоже где угодно.
1. почему этого нет в статье?
Вы придумали себе какой-то там термин и решили что все его знают? Почему я должен угадывать?
Уже есть. Вообще-то статья направлена на тех разработчиков, которые хотя бы раз заглядывали в спецификацию, и интересовались новинками не на поверхностном уровне, а пытались подстраивать мышление под новые правила разработки. Извините, что понадеялся, что читатель знает, про что идет речь.
И не понимаю как связана позиция в отображении и позиция в дом дереве. И посл о непонятности механизма лично для меня остается темнотой.
В текущей спецификации CSS2 есть только ряд элементов, которые выпадают из общего потока (normal flow). Для элементов, которые находятся в потоке, порядок их отображения ровно такой, как и в тексте документа. При применении технологии темплейтов отображения, которая описана в CSS3, блоку можно присваивать позицию в некой заведомо составленной сетке, где он будет отображаться.
Примеры можно посмотреть тут www.w3.org/TR/2010/WD-css3-layout-20100429/
Так вот, переставление блока в DOM дереве сейчас влияет на отображение этого блока в потоке. Например, был первым, стал последним в списке. А вот с темплейтами этот фокус не пройдет. Ему бесполезно менять позицию в потоке, он будет отображаться только в той позиции темплейта, которая описана в CSS. Динамическое изменение отображения такого блока станет нереальным.
Так понятнее?
Да. Спасибо за ответ и время. Так понятнее. Мне следовало сразу понять, что расчет шел на тех, кто серьезно знаком со спеками.
p.s. Я давних web-разработчик. Поэтому вопросы мои не на пустом месте. Мне действительно было непонятно и интересно в чем суть критики.
Вам не кажется что темплейты смешивают DOM и CSS в кучу? Или вы считаете что так было бы лучше?
Вам не кажется что темплейты смешивают DOM и CSS в кучу? Или вы считаете что так было бы лучше?
Три технологии уже давно тесно завязаны друг на друга. Чистый HTML почти никому не интересен, интересен тот продукт, который при помощи него можно сделать. w3c декларировала при старте разработки HTML5, что основное внимание будет уделено веб-приложениям. Но на практике оказывается все далеко не так. Добавили фактически то, что уже используется на рынке и реализовано в браузерах. А принципиально нового почти ничего не сделали.
Темплейты в данном виде в спецификации — чистое статическое отображение. Веб-приложения требуют интерактива и динамики, расположение элементов должно быть контроллируемым. А этого нет. Я, лично, ожидал большего.
Темплейты в данном виде в спецификации — чистое статическое отображение. Веб-приложения требуют интерактива и динамики, расположение элементов должно быть контроллируемым. А этого нет. Я, лично, ожидал большего.
Простите, что лезу в середину дискуссии, но уж очень интересно:
Я так понимаю, что при использовании вот этих самых темплейтов отображения, если мы хотим, скажем, взять элемент, перенести его в другое место и дропнуть в другое место, то рассчитанный под нынешние реалии скрипт D'n'D не справится, потому что если элемент был, скажем first-child, а стал nth-child, это ничего не изменит, потому что ему четко задано расположение?
Но тогда вроде бы проблема решается простейшим апдейтом данного скрипта с тем, чтобы он не только положение элемента в DOM менял, но и слегка правил его css (скажем, другой класс присваивал ему и соседям). В чем сложность? Или я не так все понял?
Я так понимаю, что при использовании вот этих самых темплейтов отображения, если мы хотим, скажем, взять элемент, перенести его в другое место и дропнуть в другое место, то рассчитанный под нынешние реалии скрипт D'n'D не справится, потому что если элемент был, скажем first-child, а стал nth-child, это ничего не изменит, потому что ему четко задано расположение?
Но тогда вроде бы проблема решается простейшим апдейтом данного скрипта с тем, чтобы он не только положение элемента в DOM менял, но и слегка правил его css (скажем, другой класс присваивал ему и соседям). В чем сложность? Или я не так все понял?
Все верно. Сложность в том, что вместо одного простого действия с предсказуемым результатом, вам придется делать два действия с непредсказуемым результатом. Почему непредсказуемый? У вас строго размечена страница. Но вам нужно перенести это блок, скажем, между двумя позициями. В какой слот нужно переносить элемент? Создавать на лету слоты и новый темплейт? Это не облегчение работы, а серьезное усложнение.
невозможность в пятнашках переложить на свободное место любую фишку — это серьёзное усложнение :—)
template layout — это возможность, а не требование. не надо использовать его в ситуациях, для которых он не предназначен. откуда в приложении, использующем template layout, возможность вставки элемента между позициями layout'a?
template layout — это возможность, а не требование. не надо использовать его в ситуациях, для которых он не предназначен. откуда в приложении, использующем template layout, возможность вставки элемента между позициями layout'a?
Это просто замечательно, что появляется куча специализированных полей ввода. И не стоит сетовать, что у input[type=number] не задашь рисунок на кнопках — не надо.
Не понимаю, откуда такая мания менять вид стандартных элементов управления. Хром, Опера и Файрфокс рисуют замечательные поля ввода, да еще их вид и от темы оформления системы зависит. Старайтесь не трогать то, что уже отлично сделано до вас. На Хабре был пост о том, как дизайнеры меняют цвет в инпутах на веселенький синий, а потом у всех людей с темным UI этот синий на темном фоне не виден.
В принципе, это относится не только к оформлению веб-страниц, но и написанию UI.
PS. Я очень рад, что шаловливые ручки дизайнеров редко доходят до чекбоксов, потому что в Linux Mint очень красивые чекбоксы.
Не понимаю, откуда такая мания менять вид стандартных элементов управления. Хром, Опера и Файрфокс рисуют замечательные поля ввода, да еще их вид и от темы оформления системы зависит. Старайтесь не трогать то, что уже отлично сделано до вас. На Хабре был пост о том, как дизайнеры меняют цвет в инпутах на веселенький синий, а потом у всех людей с темным UI этот синий на темном фоне не виден.
В принципе, это относится не только к оформлению веб-страниц, но и написанию UI.
PS. Я очень рад, что шаловливые ручки дизайнеров редко доходят до чекбоксов, потому что в Linux Mint очень красивые чекбоксы.
редактируемость контента — совершенно семантическое свойство этого самого контента, поэтому contentEditable самое место в html. возможность таскать контент по странице — это аспект поведения приложения, поэтому draggable место не в html, а в js.
Не согласен. Редактируемость является одним из поведенческих свойств контента и зависит от медиа-типа и устройства вывода. Почему разбивку страниц для принтера вынесли в CSS, а редактирование занесли в HTML? Это свойство не влияет на семантику ни коим образом. В CSS3 начали вводить понятие behavior, но еще не до конца сформировалось понимание того, что это должно быть. Например, свойство формы disabled считаю тоже чистым поведенческим свойством, наравне с :hover.
разбивка на страницы — это представление.
изменяемость контента — это логика самого содержания, это семантика.
конкретные механизмы изменения контента — это поведение, зависящее от медиа-типа и устройства.
два одинаковых документа, в первом из которых некий фрагмент редактируем, а во втором — нет, — это разные документы. семантически разные.
изменяемость контента — это логика самого содержания, это семантика.
конкретные механизмы изменения контента — это поведение, зависящее от медиа-типа и устройства.
два одинаковых документа, в первом из которых некий фрагмент редактируем, а во втором — нет, — это разные документы. семантически разные.
Изменяемость контента — это поведение, а не содержание. Это надстройка над семантикой, но не семантика.
Семантика (фр. sémantique от др.-греч. σημαντικός — обозначающий), также семасиология — наука о понимании (значении) определённых знаков, последовательностей символов и других условных обозначений
Изменяемость контента не изменяет смысл самого тега, а меняет всего лишь его поведение на определенном типе устройств. Акроним как был акронимом, так и останется, суть его не изменится вне зависимости от того, может его редактировать пользователь, или нет.
Семантика (фр. sémantique от др.-греч. σημαντικός — обозначающий), также семасиология — наука о понимании (значении) определённых знаков, последовательностей символов и других условных обозначений
Изменяемость контента не изменяет смысл самого тега, а меняет всего лишь его поведение на определенном типе устройств. Акроним как был акронимом, так и останется, суть его не изменится вне зависимости от того, может его редактировать пользователь, или нет.
…именно поэтому contentEditable — это атрибут, а не тэг.
скажите, в чём, на ваш взгляд, семантическая разница между span contentEditable=«true» и input? или между div contentEditable=«true» и textarea?
скажите, в чём, на ваш взгляд, семантическая разница между span contentEditable=«true» и input? или между div contentEditable=«true» и textarea?
А я и не говорил, что он должен быть тегом. Ему самое место в CSS.
Разница очень большая. TEXTAREA и INPUT имеют свой вполне четкий смысл. А SPAN и DIV безлики по задумке авторов. Одинаковость их поведения не значит семантическую одинаковость.
Вот скажите, это нормальный код?
b { font-weight: normal; font-style: italic }
i { font-weight: bold; font-style: normal }
Разница очень большая. TEXTAREA и INPUT имеют свой вполне четкий смысл. А SPAN и DIV безлики по задумке авторов. Одинаковость их поведения не значит семантическую одинаковость.
Вот скажите, это нормальный код?
b { font-weight: normal; font-style: italic }
i { font-weight: bold; font-style: normal }
А я жду, когда в браузеры научаться растягивать фоновое изображение, как это делает HTMLayout (5 пункт). Одним свойством можно разом заменить и скруглённые углы, и тени, и оформление границ.
Не стоит заменять, стоит дополнять. Если вам понадобится бокс с закругленными углами, то нужно будет картинку рисовать. А если понадобится поиграться цветом, то придется снова же изменять картинку. Обычный бордер удобнее. Но мысль не лишена смысла, так как это позволит спокойно создавать множественные эффекты и довести технологию текстурирования до ума.
В том-то и дело, что выше упомянутые свойства хороши по отдельности. А растяжением фонового изображения можно добиться такого оформления, что обзавидуется даже матёрый дизайнер )
«Замену» я подразумевал в применении, а не ради исключения имеющихся свойств.
HTMLayout ещё много чего может. Когда я делал верстку под него, было ощущение, что мне развязали руки, до этого момента связанные. Не хватало только Javascript'а в нём.
«Замену» я подразумевал в применении, а не ради исключения имеющихся свойств.
HTMLayout ещё много чего может. Когда я делал верстку под него, было ощущение, что мне развязали руки, до этого момента связанные. Не хватало только Javascript'а в нём.
На пост главы W3C выдвигаю кандидатуру автора!
Не хотите переехать в Симферополь и работать в Яндексе разработчиком интерфейсов?
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
Чего я ждал от HTML5 и CSS3