Ну так «сердце красавиц» — это песенный жанр, и при том очень легкая музыка, в общем-то, вполне на уровне какой-нибудь «Belle», которую тоже все, кому не лень, напевали 10 лет назад. Гиковости в ней ноль, хоть и «классическая».
А горожане тоже были относительно небольшой прослойкой, все же германоязычные страны были очень аграрными на тот момент, это не Англия. Так что спорный аргумент.
Современная эстрадная музыка в чем-то проще, в чем-то сложнее народной — тут долго можно анализировать. Тем более, если эстраду рассматривать в широком смысле, и включать сюда, скажем, Queen — тут большой вопрос, что сложнее окажется.
А вам не приходит в голову, что «любая книга про 19 век» — она про аристократию, скорее всего, написана? Да, опера и балет были основным развлечением аристократии — то есть тех еще гиков.
Погодите. Если бы у крестьянина в какой-нибудь деревеньке под Дрезденом в XIXв была возможность регулярно слушать Моцарта, стал бы он это делать? Нет, не хватило бы уровня образования, Моцарт был бы ему неинтересен. Поэтому не было никаких 100%, была музыка для гиков (классическая) и для масс (какие-нибудь ярморочные артисты, например), и никакой разницы с текущей ситуацией я не вижу.
Да, предвидя возражения — я тут специально заменил термин «массовая музыка» на «музыка для масс». Массовой музыки, действительно, не было полтора века назад, музыка для масс — была всегда.
А историческую часть я, конечно, упрощенно изложил (чтобы не вылезать за форматы коммента), поэтому тут есть, к чему придраться, но речь не о том, а о разграничении на гиковую и массовую музыку — которое было, есть и вряд ли куда-нибудь денется.
Так 3% — это и есть гиковый формат, в чем разница-то? Аристократия (основная «целевая аудитория» классической музыки) разве когда-то составляла больше 3% населения?
Как ни странно, именно про классическую музыку довольно поверхностно. Эстрадный песенный жанр к ней не имеет прямого отношения, он зародился из народной музыки (собтсвенно, классическая возникла из церковной, а та в свою очередь — тоже из народной, но разделение произошло уже очень давно). В свою очередь, академическая музыка никуда не исчезала и до сих пор существует в том же «гиковом» формате. Так что ничего здесь не изменилось.
Все же CSS изначально для несколько иных целей предназначался. Смотрите, разделение на данные, представление и логику — это классическая MVC-модель, о чем выше упоминалось. В текущем варианте, разбиение HTML/CSS/JS не тождественно разбиению M/V/C, т.к. в HTML слишком много V, а в CSS — слишком мало.
Но дело в том, что «представление» — в целом достаточно широкое понятие, если все его сплавить в CSS, то мешанина просто перекочует туда из HTML — что, собственно, уже происходит. Поэтому (тут я немного подискутирую сам с собой), возможно, более разумным вариантом было бы ввести дополнтительное разделение на собственно стили (цвета, эффекты и т.д.) и разметку. Но поскольку CSS все же эволюционирует в другую сторону (именно в сторону полного перетягивания представления на себя), это все, скорее, теоретизирование.
Да вроде может. Если не путаю, 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 жизнь веб-разработчика заметно облегчится.
А горожане тоже были относительно небольшой прослойкой, все же германоязычные страны были очень аграрными на тот момент, это не Англия. Так что спорный аргумент.
Современная эстрадная музыка в чем-то проще, в чем-то сложнее народной — тут долго можно анализировать. Тем более, если эстраду рассматривать в широком смысле, и включать сюда, скажем, Queen — тут большой вопрос, что сложнее окажется.
Да, предвидя возражения — я тут специально заменил термин «массовая музыка» на «музыка для масс». Массовой музыки, действительно, не было полтора века назад, музыка для масс — была всегда.
Но дело в том, что «представление» — в целом достаточно широкое понятие, если все его сплавить в CSS, то мешанина просто перекочует туда из HTML — что, собственно, уже происходит. Поэтому (тут я немного подискутирую сам с собой), возможно, более разумным вариантом было бы ввести дополнтительное разделение на собственно стили (цвета, эффекты и т.д.) и разметку. Но поскольку CSS все же эволюционирует в другую сторону (именно в сторону полного перетягивания представления на себя), это все, скорее, теоретизирование.
Хотя вроде 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 жизнь веб-разработчика заметно облегчится.