Add valign helpers to css

[brettp]

.top, .bottom, and .middle would be a nice parallel to .left, .right, and .center

[cash]

We're actually getting rid of right and left and replacing them with .float and float-alt. This is to provide better support for RTL language sites.

Where are you finding a new for these (.top, .bottom, .middle)?

[brettp]

I don't remember specifically where I needed these, but it was in aligning text to an image.

I understand the reason for .left and .right with regard to RTL languages, but that doesn't apply to vertical positioning--You'll never want top to mean bottom regardless of language.

[brettp]

I suppose the argument still exists that it's location positioning, but I don't think there's a way around that. Sometimes you need something at the top.

[cash]

But that's not really a compelling argument for adding these to the CSS framework. Sometimes you need something to have a z-index of 100 but we're not about to add that as a primitive. Instead, we create a semantic class that captures the use case (and most likely includes some other mark-up).

We have added padding and margin as a necessarily evil. float and float-alt were added to support floating stuff and RTL languages (.left and .right are removed I think).

What we want is to identify patterns and then codify those patterns. We do not want plugin developers adding 20 different classes in HTML to set the positioning, color, fonts, etc.

[brettp]

I'll need to think about this more. I definitely see valign primitives as a viable use case for the same reason padding and margin are--they're used so often it makes sense and their use doesn't translate well to CSS objects. z-index isn't used nearly as often, so I don't know if that's comparing apples to apples.

I see the CSS objects as the patterns that are pulled out and the primitives as the available alterations on those patterns. In the same vein as not wanting 20 different classes in HTML, we don't want 20 different objects.

[cash]

We pulled out margin and padding because we saw tons of plugins including lots of margin and padding in their CSS views. I definitely have not seen that for vertical-align in plugins. Case in point, the core plugins for 1.7 included 5 cases of vertical-align (similar to z-index) and hundreds of padding and margin statements. That seems really conclusive that we don't need vertical-align primitives.

There is nothing wrong with plugins extending the CSS view to include CSS. The objective is not to completely do away with it. You said: "In the same vein as not wanting 20 different classes in HTML, we don't want 20 different objects." Exactly. We do not want CSS objects for a single use case in a plugin. That should go into a plugin's CSS view. There should be a high bar for both CSS objects and CSS primitives (which are evil).

I do not understand what you mean by "their use doesn't translate well to CSS objects".

You said: "I see the CSS objects as the patterns that are pulled out and the primitives as the available alterations on those patterns." I don't think that is a good way to think about this. The padding and margin primitives were just a necessary evil to do away with plugins including hundreds of padding/margin statements. They are independent of the objects and can be used anywhere.

[brettp]

I do not understand what you mean by "their use doesn't translate well to CSS objects".

We don't want to create objects for each use case. (elgg-module-valign-top, elgg-module-valign-bottom, etc)

You said: "I see the CSS objects as the patterns that are pulled out and the primitives as the available alterations on those patterns." I don't think that is a good way to think about this. The padding and margin primitives were just a necessary evil to do away with plugins including hundreds of padding/margin statements. They are independent of the objects and can be used anywhere.

That's my point for valign--It could be used anywhere and eliminates the need for authors to define it themselves.

I opened this ticket because in a number of plugins I wrote for clients I was constantly defining valign. It seemed a no-brainer to add to core instead expecting each plugin to extend the CSS for it. I'm fine with waiting to see more use cases for this before making a decision.

[cash]

• We have no current use cases.
• We had no use cases in 1.7
• Creating classes for a single property is a bad idea. The only reason we're doing that with padding and margin is that every plugin has creating a ton of CSS just to set spacing information. We need really good justification to add something similar.