What am I talking about?
I'm talking about a rather contentious debate over whether or not we should have stuff in the info file that does stuff, such as making a themers life easier, and not forcing them to learn advanced PHP, for example...
Allow a theme to set itself as an admin or frontend theme exclusively
Conditional Styles in .info files, since drupal_add_css has it
Overridden module stylesheets are loaded unconditionally
Regression: Themes can no longer remove stylesheets by overriding them in .info files
Right now the arguments for and against are split across the above issues and probably others I don't even know about, so how a bit of a chin wag over here? FYI the voicerious arguments are probably in #522006 and http://drupal.org/node/575298#comment-3506734...
As a designer themer who spends all day building Drupal themes I want all of this. Badly.
If someone could actually explain why this is bad thing I would really really love to know - I personally have no idea why we cannot use the info files in this way. We already abuse the crap out of them with Skinr and Conditional Styles in D6 and these things are universally loved by themers - because they make things easier.
One way I see this is that a big drive of D7 was to make theming easier, a lot easier (because its actually very hard), however right at the last minute it seems we're going to knee-cap this effort by forcing fledgling designers to get down with hook_css_alter and other nefarious tools.
Ok, enough bitching - what are the alternatives (no, I don't want my designers using hook_css_alter, ever...)?
Can we write little functions? Something like drupal_unset_css()?
Thoughts?
Comments
Is that order VS ease issue?
From having read it seems to be an order VS ease issue. One side is that don't want to abuse .info files, another that don't want to have theming learning curve even steeper.
IMHO strategically its better to have a certain ease preserved in *.info files so a themer would not have to learn Drupal API - too steep.
Another thing is that I fail to see what a logic would be for conditional css files to load when declared in .info files. Where's the mechanism to tell them when to load and when not?
does vs. says
I think "whether or not we should have stuff in the info file that does stuff," while it sounds incredibly vague, actually hits on the key point. The primary objection seems to be what Dries said: "info-files are not meant to be for programming." And even that seems too general.
I think what Dries is really objecting to is procedural programming (.info files do stuff) vs. declarative programming (.info files say stuff). This is further muddled by the fact that conditional comments declare procedural programming to be performed in the browser, so they look like procedural programming when they're actually declarative (except for earlier in the thread when the patches actually were a bit procedural).
The argument against introducing procedural programming in .info files is basically the same as the arguments against introducing actions in CSS or HTML, or the argument for modules in Drupal. Basically, separation of concerns is key to keeping any system from turning into a big mess. For better or worse, PHP is where we do procedural programming in Drupal. The 2 alternatives I see are improving the PHP interfaces for designers to make them more usable or find ways to accomplish these goals in a purely declarative manor (rather than doing stuff, simply give Drupal the information it needs to do stuff). The latter approach seems to be where most of those threads are already headed.
Hmmm, yes a good reflection
Hmmm, yes a good reflection on the arguments. I was deliberately vague about the "does stuff" because as you point out that's exactly the centre of the debate imo.