Да вроде может. Если не путаю, LESS как раз может функционировать как на front-end (через JS), так и на back-end. В последнем случае он просто генерит CSS, а вот в первом, да, еще и придает динамику.
Да, CSS в текущем виде несколько архаичен. В идеале, HTML следовало бы превратить в «голый» data-container, а все представление передать в CSS, но тормозит здесь именно последний, он явно не дорос до этих целей.
Кстати, интересный вопрос. Я вот почти загорелся мыслью написать такой шаблонизатор. Реализуется довольно тривиально, HTML-скелет с дополнительной метаразметкой на основе атрибутов data-* + данные в формате json в отдельном js-файле. Будет намного проще и интуитивно понятнее, чем мозгодробилка XSLT. JSON генерируется в две-три строчки на любом серверном языке, так что никаких особых танцев с бубнами не потребуется.
Но вот лично вы — будете пользоваться? Я все же не уверен, что такая функциональность в принципе нужна.
Ну проблема-то не в том, что это странно. Чего-чего, а промежуточных звеньев и наслоения уровней абстракции в веб-разработке хватает. Да и в разработке вообще.
Тут два варианта — либо не нужно, либо связка XML + XSLT настолько неудобна. В принципе, второй вариант тоже выглядит правдоподобно. Если бы вместо XSLT был некий PHP-подобный шаблонизатор для front-end, вероятно, он бы нашел свое применение.
Так вы путаете front-end и back-end. XSLT — это front-end, поэтому он в одной линейке с HTML/JS/CSS. Шаблонизаторы — это back-end.
Из XML+XSLT мы получаем только HTML (если, конечно, правильно все делаем), CSS и JS — отдельно. А то, что лишнее звено — ну да, так и есть, но о том и речь: разделение между данными и структурой на стороне front-end, видимо, просто не особенно востребовано.
WinXP давно пора на свалку отправить. Как только выйдет Win8 + IE10, и Google откажется от поддержки IE8 (а случится это меньше, чем через полгода), о линейке IE до 9 версии можно будет забыть, как о кошмарном сне.
Я об этом написал тредом выше, можно же использовать XML + XSLT, вот там будет строгое разделение данных и представления. Но так никто не делает, потому что это разделение на стороне front-end никому не нужно, вполне достаточно разделения на стороне back-end.
Еще раз — речь о концепции, а не о реализации. Тут человек высказался в том ключе, что три инструмента решают одну задачу, это неверно, задачи разные, и разделение уместно. То, что CSS сильно недоработан — факт, ну так JS-костыли я уже упомянул.
Там, конечно, не вполне верное соответствие, но уж точно не просто V.
HTML = M + V, JavaScript — C, CSS не имеет точного соответствия в MVC-схеме, но в целом, это часть V.
Более строгого разделения на M и V можно достичь, используя XSLT, но этот подход не приобрел популярности, видимо, потому что это разделение проще сделать на этапе препроцессинга.
Напротив, на концептуальном уровне прекрасное разделение. Если вынести за скобки всевозможные JS-костыли для недостающих и некорректно работающих CSS-свойств, то каждый инструмент решает собственную задачу. Или вы предлагаете данные, представление и логику в одном формате хранить? Вот это анахронизм как раз.
Конкретная реализация не всегда на высоте, но со смертью IE8 жизнь веб-разработчика заметно облегчится.
Хотя вроде Google уже начал индексировать JS, нет?
Но вот лично вы — будете пользоваться? Я все же не уверен, что такая функциональность в принципе нужна.
Тут два варианта — либо не нужно, либо связка XML + XSLT настолько неудобна. В принципе, второй вариант тоже выглядит правдоподобно. Если бы вместо XSLT был некий PHP-подобный шаблонизатор для front-end, вероятно, он бы нашел свое применение.
Из XML+XSLT мы получаем только HTML (если, конечно, правильно все делаем), CSS и JS — отдельно. А то, что лишнее звено — ну да, так и есть, но о том и речь: разделение между данными и структурой на стороне front-end, видимо, просто не особенно востребовано.
HTML = M + V, JavaScript — C, CSS не имеет точного соответствия в MVC-схеме, но в целом, это часть V.
Более строгого разделения на M и V можно достичь, используя XSLT, но этот подход не приобрел популярности, видимо, потому что это разделение проще сделать на этапе препроцессинга.
Конкретная реализация не всегда на высоте, но со смертью IE8 жизнь веб-разработчика заметно облегчится.