Box shadow and border radius plugin updates

[ghost]

Currently the box shadow and border radius plugins output all vendor-specific syntax versions to all browsers, the changes i have made make it so the plugins just output the vender-specific version for the specific vender.

For example, perviously in firefox the rule of box-shadow:2px 2px 8px \#000 would result in:
box-shadow: 2px 2px 8px #000;
-moz-box-shadow: 2px 2px 8px #000;
-webkit-box-shadow: 2px 2px 8px #000;
-ms-filter: "progid:DXImageTransform.Microsoft.Shadow(Color='#000000',Direction=135,Strength=2)";
filter: progid:DXImageTransform.Microsoft.Shadow(Color='#000000',Direction=135,Strength=2);

The update now will output:
box-shadow: 2px 2px 8px #000;
-moz-box-shadow: 2px 2px 8px #000;

And for webkit it will output:
box-shadow: 2px 2px 8px #000;
-webkit-box-shadow: 2px 2px 8px #000;

[SirPepe]

Hi!

The current behavior of the two plugins is meant to make them more robust. Browser sniffing is inherently unreliable and if, with your changes, Turbine failes to detect to browser correctly, the design suffers.

Hovever some people might want to risk this to save some performance, so your idea has some merit. I think the best way to get your changes into Turbine would be to add it as optional behavior. In Turbine 1.1 plugins will have configuration options that work like this:

@turbine
    plugins:boxshadow
    boxshadow: option1, option2  // <- Changes the behavior of the plugin

It would be useful to have your modified behaviour as such an option. Take a look at how the "noie" option is implemented in the box shadow plugin in dev: http://github.com/SirPepe/Turbine/blob/dev/plugins/boxshadow.php#L39

[ghost]

Hi SirPepe,
Thanks for the feedback!
I agree with you, making this an option is a good idea but in saying that to have consistency across the core plugins it should have the same functionally as the background gradient plugin which by default uses browser sniffing to output vendor specific css. Should the background gradient plugin also have a similar option?

Also this option would be shared by many of the plugins, so maybe it would be a good idea to be able to set the option globally?

[SirPepe]

The gradient plugin will work without sniffing in version 1.1. We had to resort to sniffing because there was/is no way to put the same property into a single item multiple times.

#foo
    color:green
    color:blue

The color:green line will not appear in the final css code because color:blue would overrrule it anyway so it is was/is optimized away. This also meant we couldn't add multiple backgrounds with the different gradient values for different browsers, so sniffing was the only option. This has changed in dev so that now multiple properties in the input code will result in multiple properties in the output code: http://github.com/SirPepe/Turbine/commit/2565eb40d58ae6f5c749f6547e426907fd549722

This of course sucks in its own way because it makes the whole output code much more bloated. So I think a global option would really be the best way to let people choose their poison: reliable bloated code or optimized browser-specific output. So... let's build this thing!

[ghost]

Hey, so i have put together a proof of concept based on what we have been talking about. Check it out here: http://github.com/pieterv/Turbine/blob/dev/plugins/boxshadow.php

I have called the option "vendorSpecific" im sure you can think of a better name? any ideas?

I have a few questions around the plugin settings.
What is the best way to get global settings? In the code i am getting both the global and local plugin settings then merging them, do you think it would be better if the Plugin::get_settings() call did this automatically and returned the combined result?

Also in the example of the "noie" option it first check if the $settings variable is an array, do you think the Plugin::get_settings() function should handle this behavior rather than checking in every plugin? for example

static function get_settings($plugin){
    ...
    return is_array($settings) ? $settings : array();
}

Let me know what you think!

[SirPepe]

I thought of "global settings" as a stting in the config.php, so it would be $cssp->config['vendorSpecific']. I would not merge this with the plugin settings simply because i thought of this setting as something with much more impact. It would not only change the behaviour of some plugins, but would also influence how the core optimzies. It would mean the difference between

#foo {
    color:red;
    color:blue;
}

and the more optimized

#foo {
    color:red;
}

But "vendorSpecific" really isn't the right name... maybe " aggressiveOptimization" or something?

[commi]

i know this is super old, but the patch just became interesting to me. any chance to put this in a clean patch? there some irrelevant stuff in there, like config file.

[igorsantos07]

@commi are you still interested on it? I lost access to the Github repositories and saw your comment only now.
If you are, you could work on the patch and send me a new pull request, as I've been veeery busy to look at this.

[commi]

Nope, i worked around the issues with the prefixes/filter i had in my own fork.

[igorsantos07]

I took a look at the network panel now, you got a lot of fixes. Do you want to merge them here? (:
Send a pull request!

[commi]

i would, but i also changed some behaviour that would require changes in the docs. mostly that ie-filters are not used if they can lead to ugly bugs, and priority for expire-headers instead of etags.
also i'm lazy.
there is an old pull request for svg-gradient-feature, that should be ready to merge. other stuff could be cherry-picket, but i really would have to create a new branch with only 100% backwards-compatible fixes.

i shall do that the next time i clean up my projects/repos, promise:)

[igorsantos07]

Ok! Thank you. I'm not lazy but I'm completely out of time to see this
stuff for now.
I'll look for the svg-gradient and accept it (:

Igor Santos
Programador PHP / Ruby
igorsantos.com.br http://www.igorsantos.com.br || memelinks.com

On Fri, Nov 2, 2012 at 1:14 PM, commi [email protected] wrote:

i would, but i also changed some behaviour that would require changes in
the docs. mostly that ie-filters are not used if they can lead to ugly
bugs, and priority for expire-headers instead of etags.
also i'm lazy.
there is an old pull request for svg-gradient-feature, that should be
ready to merge. other stuff could be cherry-picket, but i really would have
to create a new branch with only 100% backwards-compatible fixes.

i shall do that the next time i clean up my projects/repos, promise:)

—
Reply to this email directly or view it on GitHubhttps://github.com//pull/119#issuecomment-10019607.