Should parsys, iparsys, parbase, etc. HTML elements be present in the markup of a published instance? | Community
Skip to main content
LinearGradient
LinearGradient
New Participant
October 16, 2015
Solved

Should parsys, iparsys, parbase, etc. HTML elements be present in the markup of a published instance?

  • October 16, 2015
  • 3 replies
  • 1830 views

Hi,

When I view the HTML source of a site on a published instance, I see markup like this:

<div class="parsys iparsys parsys-header"> <div class="header parbase section"> ...

Is this the norm? Or should these parsys, iparsys, parbase, etc. tags only be present in edit mode?

Thanks in advance.    

This post is no longer active and is closed to new replies. Need help? Start a new post to ask your question.
Best answer by XumaKJosh

I would say that the jist of it is that you shouldn't drastically modify the source DOM between runmodes. This is because your Authors are editing contextually, and tend to rely on the idea that what they see rendered in Author can be assumed to appear and behave as it would for users on the Publish instances. Modifying things in the delivered markup such as HTML tag hierarchies -- even slightly -- can introduce inconsistencies and bugs that are sometimes to subtle to be easily tracked down.

It's better to instead just account for these additions in your initial HTML. There are situations where you may not be able to easily do this because, for example, you inherited the markup, or it was delivered by an outside or otherwise disengaged party. In these cases, leveraging the cq:htmlTag feature of components, which can influence how the enclosing container is drawn, can lessen the impact these otherwise additional tags might have. This way you can -- in effect -- use the same markup to pull double-duty: it will be drawn as the container you expected in your static markup's DOM (including the tag name and any in-house styles you need) and still allow CQ to use it for its own needs.

As for whether the class names used by the author (parbase, parsys, etc.) should be stripped from the Publish version, I would tend to say no. At worst they're harmless remnants; but, more importantly, they may not be as vestigial as you might think. In fact, it's not an uncommon practice for components to use these class names for various things, even on the Publish.

Hope this helps!

-Josh/XumaK

3 replies

O
Ove_Lindström
New Participant
October 16, 2015

Hi,

It should, of course, be a part of the markup, regardless of what runmode you are running. The first ones there are instructions for the author environment, but does not do anything for the site markup. The named parsys is the one that should matter for the site css and no component, imho, should ever be called the same, unless they acutally should behave the same. The header-parsys and the footer-parsys will most likelly have different styles but they still are parsys. You will do your editors a disfavour if you mess with the auhoring environment.

/O

LinearGradient
LinearGradientAuthor
New Participant
October 16, 2015

Ove Lindström wrote...

Hi,

It should, of course, be a part of the markup, regardless of what runmode you are running. The first ones there are instructions for the author environment, but does not do anything for the site markup. The named parsys is the one that should matter for the site css and no component, imho, should ever be called the same, unless they acutally should behave the same. The header-parsys and the footer-parsys will most likelly have different styles but they still are parsys. You will do your editors a disfavour if you mess with the auhoring environment.

/O

 

Sorry, could you please explain again?

> he first ones there are instructions for the author environment, but does not do anything for the site markup.

If these are instructions for the author (editing, e.g. Touch UI) environment, doesn't that they are superfluous and unneeded in a published website? 

> The header-parsys and the footer-parsys will most likelly have different styles but they still are parsys. You will do your editors a disfavour if you mess with the auhoring environment.

If I am not wrong, you mean these parsys elements should not have custom style applied to them, is that correct?

I also think <div class="parbase..."> should only be present in the markup when we are in edit mode, (i.e. when WCMMode.fromRequest(request) == WCMMode.EDIT). But I gather this is not true, right?

Thanks.

X
XumaKJoshAccepted solution
New Participant
October 16, 2015

I would say that the jist of it is that you shouldn't drastically modify the source DOM between runmodes. This is because your Authors are editing contextually, and tend to rely on the idea that what they see rendered in Author can be assumed to appear and behave as it would for users on the Publish instances. Modifying things in the delivered markup such as HTML tag hierarchies -- even slightly -- can introduce inconsistencies and bugs that are sometimes to subtle to be easily tracked down.

It's better to instead just account for these additions in your initial HTML. There are situations where you may not be able to easily do this because, for example, you inherited the markup, or it was delivered by an outside or otherwise disengaged party. In these cases, leveraging the cq:htmlTag feature of components, which can influence how the enclosing container is drawn, can lessen the impact these otherwise additional tags might have. This way you can -- in effect -- use the same markup to pull double-duty: it will be drawn as the container you expected in your static markup's DOM (including the tag name and any in-house styles you need) and still allow CQ to use it for its own needs.

As for whether the class names used by the author (parbase, parsys, etc.) should be stripped from the Publish version, I would tend to say no. At worst they're harmless remnants; but, more importantly, they may not be as vestigial as you might think. In fact, it's not an uncommon practice for components to use these class names for various things, even on the Publish.

Hope this helps!

-Josh/XumaK

Terms & ConditionsAccessibility statement

Loading footer...