Changes between Version 1 and Version 2 of Ticket #6290, comment 66
- Timestamp:
- 04/23/2015 07:24:24 AM (10 years ago)
Legend:
- Unmodified
- Added
- Removed
- Modified
-
Ticket #6290, comment 66
v1 v2 3 3 Also re-defined the avatar constants to check how things handle with varying sizes defined by users (I tend to define a new default as a matter of course up at around 250px as it allows more flexibility in sizing ) as things stand the difficulty here is that with horizontal implementations of the two main elements we need to float both and manage their widths explicitly, if one of these elements has an unknown width or width that may vary this becomes problematical, in these circumstances one would tend to not float one of these elements so it could simply clear the unknown width, a classic floated layout is one floated the other overflowed to force a new box context to clear the floated item. 4 4 5 Edit// One option I almost forgot about is that we don't actually allow the avatar-crop-pane to change in dimensions, after all it's a functional item that really just needs to represent the aspect ratio but doesn't have to show the final actual size, restricting this elements dimensions is the easiest option.6 5 7 6 There are two choices I may need to address element order in the templates to ensure floated elements are flowed first or we could try and get tricky and pass the new constant widths as a class token for floated element or parent or pass dimension properties to the style attr inline on the element, but that's as far as I've thought it through thus far - re-ordering elements and adjusting rules is probably best option. 7 8 Edit // One option I almost forgot about is that we don't actually allow the avatar-crop-pane to change in dimensions, after all it's a functional item that really just needs to represent the aspect ratio but doesn't have to show the final actual size, restricting this elements dimensions is the easiest option.