Старые мобильные браузеры действительно могут не поддерживать content. Я это упомянул среди минусов. Мобильные Хром и Сафари точно поддерживают. Насчет браузера, встроенного в Мобильную Винду не знаю. Не было пока возможности проверить.
Что до редактирования, если бы я всерьез озаботился подобным методом, то сделал бы редактирование полей через админку, чтобы цсс-файлы генерировались по шаблону автоматически. Но в целом с замечанием согласен.
Во-первых, на все цвета и случаи классов не напасешься.
Во-вторых, за пять лет работы с большими проектами я убедился, что удобнее все-таки мыслить блоками, а не свойствами элемента. Удобнее с точки зрения дальнейшей поддержки кода.
Использование подобных классов будет относительно оправдано на небольших проектах с небольшим количеством блоков и сущностей. Как мне кажется, возможно, я ошибаюсь.
Основной контент в него запихнуть и не получится. Хотя бы из-за разметки (болд, италик). А вот некоторые навигационные элементы… почему бы и нет? Если, например, названия классов сделать сокращенными, то вполне можно таким макаром сверстать какой-нибудь мобильный интерфейс в целях экономии траффика. Насколько мне известно, и мобильный Сафари, и мобильный Хром умеют кешировать CSS-файлы.
b-harmony.js занимается расчетом гармонии (тональность, основные ступени и так далее). Это только часть генератора аккордов. Остальные части пока не готовы, поэтому я их и не показываю.
Можно через канвас. Мне даже где-то на Хабре попадалась заметка на эту тему. Чистым же ХТМЛ наверное тоже можно извратиться, но слишком затратно получится, имхо.
Более того скажу: изначально номера ладов, пальцев и даже строй отбражались именно через списочный счетчик. Но из-за глюков в Опере и Хроме пришлось отказаться от этой затеи. Кроме того, я внезапно вспомнил, что строй может быть не только чистым. В общем, переделал на content.
Что до редактирования, если бы я всерьез озаботился подобным методом, то сделал бы редактирование полей через админку, чтобы цсс-файлы генерировались по шаблону автоматически. Но в целом с замечанием согласен.
Во-вторых, за пять лет работы с большими проектами я убедился, что удобнее все-таки мыслить блоками, а не свойствами элемента. Удобнее с точки зрения дальнейшей поддержки кода.
Использование подобных классов будет относительно оправдано на небольших проектах с небольшим количеством блоков и сущностей. Как мне кажется, возможно, я ошибаюсь.
А вообще глаз-алмаз.
Сначала не туда запостил.
Более того скажу: изначально номера ладов, пальцев и даже строй отбражались именно через списочный счетчик. Но из-за глюков в Опере и Хроме пришлось отказаться от этой затеи. Кроме того, я внезапно вспомнил, что строй может быть не только чистым. В общем, переделал на content.