In general CTC makes a tradeoff between supporting every edge case in the CSS spec with performance and utility.
1. Comments.
CTC is designed to make it much easier to identify styles in the parent and apply them to the child stylesheet. To do this it must be able to quickly parse and process the styles in both the parent and child stylesheets.
Being able to parse comments in the child stylesheet would add an enormous overhead to the program. We hope to have a solution that will not affect performance but it is not currently supported.
2. Variations of the same attribute.
Multiple versions of the same rule in a single selector are not supported, with a few exceptions. The Child Theme Configurator plugin will automatically generate vendor-prefix variations for background-image, border-radius, transform, transition, and others.
3. Shorthand Syntax
CTC supports shorthand for background, font, margin and padding.
The example shown in the OP comment is actually parsed and normalized correctly when we tested it:
.site-header {
background-color: #0073aa;
padding-top: 4.6140%;
padding-right: 0;
padding-bottom: 4.6140%;
padding-left: 7.6923%;
}
as well as
.site-header {
background-color: #0073AA;
padding: 4.6140% 0px 4.6140% 7.6923%;
}
are both normalized to:
.site-header {
background-color: #0073aa;
padding: 4.6140% 0 4.6140% 7.6923%;
}
If maintaining comments and using attribute variations is mission critical to your projects, then I would recommend hand-coding your styles.
If maintaining comments and using attribute variations is mission critical to your projects, then I would recommend hand-coding your styles.
I had hand-coded my styles. 😉
I was only having a browse over your plugin as I had just finished playing your second tutorial video about selectors and lookup.
What shocked me was the plugin playing with the code when I hadn’t even clicked save or chosen to make any changes.
No issue with its need to parse in order to show me selectors etc, but it should be read-only parsing until a user says [commit] via save button.
Multiple versions of the same rule in a single selector are not supported, with a few exceptions.
This is a weakness, as many responsive themes including those shipped with wordpress use multiple rules for fall-back browser support. The style example in this ticket came from TWENTY FIFTEEN theme.
CTC supports shorthand for background, font, margin and padding.
I can see it parses the shorthand notation fine, but what is annoying is the way it deconstructs and writes it back out in long-hand which would add bulk to the CSS file.
Thanks for replying so promptly, I was hoping to take advantage of some of the plugins cool CSS features but in my case it won’t suit as I need to keep multiple attributes like the parent theme has and need to keep comments to remind me why I was changing the parents settings.
Like the rest of the plugin 😉
snaphappyme,
My point was that it deconstructs shorthand for the internal configuration data and the “Query/Selector” tab inputs, but uses shorthand when it writes the child css. If you check the “Child CSS” tab you will see it is normalized correctly.
As for the other two issues, these have both been requested by several users, but have not been implemented because of their impact on performance. There will be a solution, just not at this time.
So, you are saying I have to commit and [save changes] (even though I made no changes and was only looking through the tabs in your plugin), for my stylesheet to be returned to its original short-hand normalised state?
The state it was before I ventured to look at the CSS tab options in your plugin?
The take away for @lilaeamedia from this discussion, is a user suggestion and request the plugin:
1. make a copy of the stylesheet before it parses and changes the code.
2. restore the stylesheet to “before” condition using the backup if user DOES NOT proceed to commit/save changes.
3. make backup available in file directory for users who *freak* at looking their comments like I did…
I am not hassling you about the methods and decisions made for parsing or deconstructing/reconstruction the stylesheet more my issue is:
1. LACK of prior warning you will loose comments
AND
2. reasonable usability expectation that browsing a software interface is non-destructive and safe (i.e. no changes made unless I say so).
Thanks
Kat
Kat,
v1.7.5 addresses many of these topics. CTC now supports multiple fallback styles and we added a warning on first run for existing child themes.
Still working on supporting arbitrary comments but currently the parser and data structures would be overloaded if we also mapped comments.
