When using the Collect into... feature on the search page, all elements of the 'field-name-collect-toggle'
class collapse into one position.
The 'field-name-collect-toggle'
class uses a 'position'
property value of 'absolute'
. According to CSS 2.1, the position of such elements is determined the following way:
The box's position (and possibly size) is specified with the ‘
top
’, ‘right
’, ‘bottom
’, and ‘left
’ properties. These properties specify offsets with respect to the box's containing block. Absolutely positioned boxes are taken out of the normal flow. This means they have no impact on the layout of later siblings. Though absolutely positioned boxes may have margins, those margins do not collapse with any other margins.
The containing block is defined as follows:
If the element has 'position: absolute', the containing block is established by the nearest ancestor with a 'position' of 'absolute', 'relative' or 'fixed', in the following way:
- In the case that the ancestor is an inline element, the containing block is the bounding box around the padding boxes of the first and the last inline boxes generated for that element. In CSS 2.1, if the inline element is split across multiple lines, the containing block is undefined.
- Otherwise, the containing block is formed by the padding edge of the ancestor.
If there is no such ancestor, the containing block is the initial containing block.
Unfortunately, the nearest ancestor with a 'position'
other than 'static'
is the 'block-system-main'
element.
'position'
of the 'view-mode-art_preview'
class to 'relativ'
.'field-name-collect-toggle'
class are inserted into their 'view-mode-art_preview'
parents after all their siblings.
I didn't see this back when you posted it. Can you post a screenshot of the actual issue?
Sure, here are two screenshots. In the first one, the Collect into... feature is enabled, but due to the broken CSS, all the plus buttons are in the lower right corner:
For the second screenshot, I've used chromium's builtin dev tools in order to add
"position: relative"
to the'view-mode-art_preview'
class. However, it is still not perfect, because the layout engine draws the preview images on top of the buttons:That's why you would also need to make sure that the plus buttons (the elements of the
'field-name-collect-toggle'
class) are inserted into their parents last.2014-04-05-011522_1440x900_scrot.png 192.5 Kb [0 download(s)]
2014-04-05-011744_1440x900_scrot.png 183.7 Kb [0 download(s)]
Okay. I've never actually seen all the buttons piled up like that -- they've always been in the correct place for me. Are you running anything that modifies the stylesheet in some way? I'm just wondering why it would be different for you, as I'm pretty sure I have another position:relative in there that should have caught it.
(Note: I added the position: relative, so it should work for you now anyway; I'm just curious what's going on. I know that in the past some people have made some custom javascript and CSS for OGA, and while I'm willing to work with people who want to do that, ultimately if there's a bug in it that's breaking necessary CSS, that's their responsibility to fix it. :)
I fixed the button being under the images with a z-index. It works for me now.
Note that recently I've had some issues with older versions of the theme occasionally coming back. I think this may be due to some of the web server optimizations that I've enabled, but it's been causing some weird things to happen, so if this appears not to be fixed, please post here and I'll flush the cache again.
Bart
> Are you running anything that modifies the stylesheet in some way?
No, I don't. However, the Archlinux build of chromium seems somewhat broken, maybe that's the reason? Or just different default stylesheets? Anyway, it works for me now. Thanks, bart :)
seems for me when i use collect into it works properly, however I cant seem to re-click on the - sign to remove a piece of art
=======
Full Steam Ahead! o/ <-- little ascii fist in the air holding a debugging hammer.