CSS Shorthand VS Longhand

CSS shorthand vs longhand?

You shouldn't worry about CSS performance unless you have profiled the page load and it has became the bottleneck (I doubt, it is almost always multiple HTTP requests and images).
Any competent developer can remember clockwise from top for the order of values.
Shorthand means less bytes to be sent, which a CSS minifier doesn't optimise itself (I don't think).
I'd only use the long method if setting one value, e.g. padding-left: 3px.

Shorthand CSS is not same as longhand

The syntax in the shorthand version is incorrect. It should be:

.settingsSelect {
  background: url('../images/Custom.Select.Background.png') no-repeat 97%, url('../images/Settings.Input.Background.png') repeat 0;
}

Think of it as this:

.selector {
  background: background1, background2, background3, etc;
}

where background1, background2, etc are each a shorthand background of:

url() repeat X%;

MEF, creating Import's tree when a branch is requested

Check my answer here.

http://codebetter.com/blogs/glenn.block/archive/2008/11/12/mvp-with-mef.aspx

EDIT: (Added from the link, to prevent not being flagged as low quality / LOA)

   1: using System.ComponentModel.Composition;
   2: using System.Reflection;
   3: using Microsoft.VisualStudio.TestTools.UnitTesting;
   4:  
   5: namespace MVPwithMEF
   6: {
   7:     /// <summary>
   8:     /// Summary description for MVPTriadFixture
   9:     /// </summary>
  10:     [TestClass]
  11:     public class MVPTriadFixture
  12:     {
  13:         [TestMethod]
  14:         public void MVPTriadShouldBeProperlyBuilt()
  15:         {
  16:             var catalog = new AttributedAssemblyPartCatalog(Assembly.GetExecutingAssembly());
  17:             var container = new CompositionContainer(catalog.CreateResolver());
  18:             var shell = container.GetExportedObject<Shell>();
  19:             Assert.IsNotNull(shell);
  20:             Assert.IsNotNull(shell.Presenter);
  21:             Assert.IsNotNull(shell.Presenter.View);
  22:             Assert.IsNotNull(shell.Presenter.Model);
  23:         }
  24:     }
  25:  
  26:     [Export]
  27:     public class Shell
  28:     {
  29:         private IPresenter _presenter = null;
  30:         
  31:         public IPresenter Presenter
  32:         {
  33:             get { return _presenter; }
  34:         }
  35:  
  36:         [ImportingConstructor]
  37:         public Shell(IPresenter presenter)
  38:         {
  39:             _presenter = presenter;
  40:         }
  41:     }
  42:  
  43:     public interface IModel
  44:     {
  45:     }
  46:  
  47:     [Export(typeof(IModel))]
  48:     public class Model : IModel
  49:     {
  50:         
  51:     }
  52:  
  53:     public interface IView
  54:     {
  55:     }
  56:  
  57:     [Export(typeof(IView))]
  58:     public class View : IView
  59:     {
  60:     }
  61:  
  62:     public interface IPresenter
  63:     {
  64:         IView View { get;}
  65:         IModel Model { get; }
  66:     }
  67:  
  68:     [Export(typeof(IPresenter))]
  69:     public class Presenter : IPresenter
  70:     {
  71:  
  72:         private IView _view;
  73:         private IModel _model;
  74:  
  75:         [ImportingConstructor]
  76:         public Presenter(IView view, IModel model)
  77:         {
  78:             _view = view;
  79:             _model = model;
  80:         }
  81:  
  82:         public IView View
  83:         {
  84:             get { return _view; }
  85:         }
  86:  
  87:         public IModel Model
  88:         {
  89:             get { return _model; }
  90:         }
  91:  
  92:     }
  93: }

So what’s going on here?

Shell gets injected with Presenter. Presenter gets injected with View and Model. Everything here is singletons, but doesn’t have to be.

The difference between our two examples is that the Presenter is getting injected into the shell rather than the View. If the Presenter is creating the View then you can’t just grab the View first (as he was doing), or the Presenter will not get created. Well you can do it, but you end up hacking it to bits. Cleaner is to just inject the Presenter and have it expose an IView. We did this in Prism and it worked quite well.

Under what circumstances do shorthand CSS properties REQUIRE separation of longhand components by spaces?

From the CSS2 spec you link to:

Component values are specified in terms of tokens, as described in Appendix G.2. As the grammar allows spaces between tokens in the components of the expr production, spaces may appear between tokens in property values.

In short, spaces are required in situations where leaving out a space would result in two tokens being parsed as one token. The obvious example of this is, of course, border: 1px solid red, where leaving out the spaces would result in a single dimension token, 1pxsolidred, which is invalid since there is no such unit "pxsolidred". This is true nearly all the time, which is why you see spaces separating component values nearly all the time.

In the CSS grammar, infinite.99s can always be parsed as two tokens: the ident, infinite, and the quantity, .99s, because a period cannot normally appear in an ident (unless escaped). Therefore, it is not necessary to separate these two values with a space.

Leaving certain values unchanged when using CSS shorthand properties

This isn't currently possible, unfortunately. You'll have to stick with assigning margin-top and margin-bottom respectively.

A shorthand property always changes the values of all its component (longhand) properties. Namely, any values omitted in a shorthand property will default to initial for their respective properties, unless resolved by cascading or by some other rules depending on the shorthand property. For example, the following results in auto margins on all sides except the bottom due to the margin-bottom longhand that appears after the shorthand:

#header {
    /* 
     * Note: this is short for margin: auto auto auto auto;
     * none of the longhands are set to initial! Different shorthands
     * have different rules, but a shorthand always changes the values
     * of all its longhands.
     */
    margin: auto;
    margin-bottom: 1em;
}

If there were separate shorthands for horizontal margins and vertical margins, you would be able to do this without having to worry about keeping specific longhand values, but no such shorthands exist at the moment.

As I mentioned in my comment, margin: 1em inherit is invalid as the CSS-wide keywords inherit (along with initial and others introduced in later standards) may only appear by themselves in property declarations, and this includes shorthand declarations. Even if margin: 1em inherit did work, the element would inherit horizontal margins from its parent element, and not from its own cascade (since that's not what inheritance means). It is not possible to retrieve a cascaded or specified value for a property on a given element, and being able to do this would almost certainly be error-prone due to the fact that the bottommost declaration from the most specific selector that contains the resolved value could be anywhere.

CSS Shorthand VS Longhand