Just wanted to let everyone know that I’ve posted a new video to our YouTube channel. This has to do with theme customization!
Skins ship with your Concrete theme. Skins are settable for your site without necessarily making a theme customizable. (For example, if you want to have different skins in your theme but you don’t want every aspect of that theme to be customizable, you can.)
Simpler approach to handling customizer variables – just name the variables in the styles.xml file exactly what you want.
All font related controls like Font Family, Text Transform, etc… are embeddable independently in the customizer panel. The type grouped control still exists, however, when you want to make two or more type-specific controls editable in the same area.
Web fonts that your skin ships with are specifiable within styles.xml, and are displayed properly within the new font selector.
SCSS is fully supported! As is LESS! (Although LESS support is currently broken at this time – it will be reinstated prior to version 9 shipping fully.)
Instead of saving all the data against pages and themes, data is saved against a new CustomSkin object. Custom skins are also built at save-time, making performance much much improved.
In general we try and leave the fonts up to the theme developer. The fonts that you see in the new v9 customizer are just added to the list in the following way: 1. All the standard browser fonts are added to the bottom of the list 2. The top of the list is populated with fonts that the theme developers add to the styles.xml file. The theme developer can include fonts in their theme any way they’d like – whether it’s through Google Fonts, Typekit, or just included in the theme. As long as the font is in the theme and can be rendered on the page, including it in the styles.xml file will show it properly and let it be selectable in the customizer.
Does that answer that question? Or maybe I’m not understanding what “native support for web fonts” means?
We do have plans in the future for better management of sample content installation. And I would eventually like to add the export of xml into the core itself, rather than having export be a part of the Migration Tool.