-
Notifications
You must be signed in to change notification settings - Fork 43
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Equaliser #307
Equaliser #307
Conversation
@cornae can you clarify this sentence: "Each direct child element then content height of the content height of the tallest measured direct child element." |
It was badly phrased. I rephrased to "pat-equaliser would measure it's direct child elements. Each direct child element then gets the height equal to the content height of the tallest measured direct child element." |
Can you confirm you envision this working as follows:
Step 1 is necessary to make sure we can remeasure on resize/update, but it does mean any existing height style set in CSS will be ignored. |
That, but without step 1. I don't understand why that would be necessary even after resize. Can you clarify that? |
In order to redo the height calculation I must re-measure the height of all children. But I can not do that if they already have their height fixed by this pattern. If I skip step 1 I will always get the same height again and an update will never do anything useful. |
But couldn't you simply remove the applied inline height instead of setting it to auto? Also, why would the tallest one get a fixed height is its already the tallest? |
Implemented in a new |
The demo looks good as far as I can see now. I experimented with an animated column height, but as soon as I put a CSS transition on the column, it doesn't recalc the height anymore. Possibly because the with the height auto, the transition hasn't finished before the new height is calculated. Would it be a better idea to animate the height with .js? Alternately, you could put a class 'equalised' on the equalised elements that is temporarily removed also when you put the height auto on it. Op 11 jun. 2013, om 14:12 heeft Wichert Akkerman notifications@github.com het volgende geschreven:
|
We could make it an option that defaults to not being animated. I think I would find animation here very annoying. |
What about my suggestion with the class? Would it work? Then it would be an 'option' you set in the CSS which is the best place for it if possible. Op 12 jun. 2013, om 11:32 heeft Wichert Akkerman notifications@github.com het volgende geschreven:
|
I don't set |
Then forget the auto height in my sentence. Does my theory still make sense? Or do you see another reason why it doesn't work now. Op 12 jun. 2013, om 11:34 heeft Wichert Akkerman notifications@github.com het volgende geschreven:
|
CSS animations will indeed break our measurements since we'll effectively be measuring an element while it is just starting its animation, so Don't Do That(tm). We could use a temporarily |
Does this mean that my suggestion to do it the other way around wouldn't work? Op 12 jun. 2013, om 11:53 heeft Wichert Akkerman notifications@github.com het volgende geschreven:
|
The other way around being javascript animations? |
"Alternately, you could put a class 'equalised' on the equalised elements that is temporarily removed also when you put the height auto on it. " So when you remeasure, remove the class equalised and put it back when you have a new height. Op 12 jun. 2013, om 12:02 heeft Wichert Akkerman notifications@github.com het volgende geschreven:
|
I pushed JS animations. Can you check if they work correctly? |
Looks great. I assume works with depends as well in the same way? Of another note: I can't get 'swing' to work for easing. Also, the default looks linear (Or a very small ease-out) to me more than swing. And the other values are missing in the values column. Is swing and linear available now only? Op 12 jun. 2013, om 16:03 heeft Wichert Akkerman notifications@github.com het volgende geschreven:
|
The documentation is explicit about what is supported:
Since the list of possible options depends on what javascript a user has loaded we can't document it any better than that. |
Whatever is called 'swing' here doesn't look like one. Swing in when the movement is exaggerated. But maybe jQuery is holding on to its own names? It looks like ease-in-out in a very subtle way, or just linear to me. Remains the fact that I don't see a difference between swing and linear. We can't rely on any JavaScript a user has loaded. In fact, the value proposition of Patterns for a designer is that it's the only script you'll have to load. So if we want more animations, we would have to pack that Patterns. For now I would stick with what we have, provided that they actually work. Op 12 jun. 2013, om 17:51 heeft Wichert Akkerman notifications@github.com het volgende geschreven:
|
A common layout problem is that one like to have a group columns that are visually outlined to be of equal height, regardless the content in the columns. In CSS this is often difficult to achieve.
I propose an equaliser pattern for this.
Consider the following markup:
pat-equaliser would measure it's direct child elements. Each direct child element then gets the height equal to the content height of the tallest measured direct child element.
The calculation is repeated upon:
This CSS is required to make .panel take the of a column that has an absolute height on it: