Parsys markup causes layout problems with floating components

Description

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.

Activity

Show:
Igor Sechyn
November 21, 2014, 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.

Stefan Seifert
November 24, 2014, 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 28, 2014, 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
December 1, 2014, 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
December 2, 2014, 10:47 PM

Thanks, works great.

Fixed

Assignee

Stefan Seifert

Reporter

Igor Sechyn

Labels

None

Components

Fix versions

Priority

Major