Parsys markup causes layout problems with floating components
Description
Gliffy Diagrams
Activity
Igor Sechyn December 2, 2014 at 10:47 PM
Thanks, works great.
Stefan Seifert December 1, 2014 at 4:18 PM
master 3016276
i updated the markup to:
without the @ context attribute the conditional css was stripped away. context='unsafe' is not nice, but for unknown reasons context='styleString' did not work.
Igor Sechyn November 28, 2014 at 1:43 PM
I did not come up with anything better than this:
unfortunately conditional style attribute did not work with sightly. the initial idea was to do something like this:
but neither this nor
worked
this markup will still remain backwards compatible.
Stefan Seifert November 24, 2014 at 3:37 PM
the goal was to have a default markup in the parsys which matches the common usecases. it will never match all usecases, in this case the markup can be overlayed as described here.
still the question if if the default markup as it is used currently is the best one, or if we should change it (although this will break backward compatibility). the markup should work standalone without the need to have special CSS in place.
afaik the "new" class name cannot be changed, the authoring GUI relies on it.
do you have a proposal for a better default markup?
Igor Sechyn November 21, 2014 at 1:18 PM
one of the possible solutions would be to remove the clearing div and add a client lib css and apply the style to the css class of the new area. it is currently "new" to avoid any possible conflicts, maybe it should be prefixed, unless cq relies on this class as well.
Details
Details
Assignee
Stefan SeifertReporter
Igor SechynComponents
Fix versions
Priority
Major
Current markup for the parsys contains a div, which clears floating before the new area. this approach has several disadvantages in various szenarios:
i guess the reasons for this div was to force the new area to be displayed at the very bottom of the parsys container. this is especially important, if the components within the parsys are floating. this works fine for the first page load, but will fail on adding a further floating componet, because its markup is injected under the clearing div
due to this injections it also causes wrong behavior, when floating components in edit mode are shown as blocks under each other to simplify the editing (especially in the responsive context). On switch into preview mode the components should be floating again, which can be achieved with css, but it only works for components which were already in dom on page load. newly added components will be injected under the clearing div, which breaks the flow of the markup.