Styling Issues with Standard Variables

[mediamole]

In version 12 standard variables now have embedded styling in them

For example, FragmentTitle has

<actinic:variable formatting="h2" name="FragmentTitle" />

Which would basically create <h2>Title Text</h2> when HTML page created. This application is not helpful to bespoke sites. As it means bespoke websites that have custom fragments that might have for example:

<h3><actinic:variable name="FragmentTitle" /></h3>

would affectively become on upgrades

<h3><actinic:variable formatting="h2" name="FragmentTitle" />my header</h3>

Producing invalid code of:

<h3><h2>My Header</h2></h3>

Furthermore, if for FragmentText variables you have applied formatting of P tag but in the fragment text box a user has added loads of HTML code this will then surely cause problems?

This gripe comes after spending 2 hours trying to fix a CSS issue only to discover the reason for the styling issue is because of nested TAGs created by this new approach as stated above.

[brucet]

This change was made as a result of some field reports of the inverse scenario – merchants using the Design tab toolbar to apply heading styles to variables which already had them. This also creates the same problem of invalid code due to nested heading tags.

We are trying to work towards making the SellerDeck design ecosystem more consistent, more useable and more integrated for everyone. I'm sorry this particular change caused you a problem, but hopefully it's something you will be able to adjust to.

[mediamole]

When remove the formatting within the variable need to remove it from each instance of that variable in a fragment layout.

e.g.

<actinic:variable formatting="h2" name="FragmentTitle" />

The concern arises when upgrade does it reset those variables again? Getting mixed results at moment

[Mike Hughes]

We are trying to work towards making the SellerDeck design ecosystem more consistent, more useable and more integrated for everyone. I'm sorry this particular change caused you a problem, but hopefully it's something you will be able to adjust to.

I'm a bit confused on what's happening here.

Surely, the whole aim of the game here is to keep the design separate from the underlying variables. So Sellerdeck defines the underlying elements and we use layouts to say where we want things to appear and css to apply the styling.

What's the point of applying styling in the variable itself?

a) It means applying styling in the layout will break the design.
b) It means we then have to start applying and controlling styling in multiple places.
c) It means if we change the styling then an upgrade is going to reset everything back to where it was before and break the design again.

This sounds like a big backward step to me.

Mike

[mediamole]

I personally think this new in-line style method in variables creates more problems than it resolves.

For instance, SellerDeck very big advocate of SEO yet this new variable styling method is dictating when and where tags like H1 to H3 tags etc should be placed and when they should used.

I always held the software in high regard, and see the value and great usability it provides to customers - my frustration is the scope of impact changes like this have to developers and customers in terms of time and cost of implementing such changes.

[Artisan]

A big +1 from me too... as Mike points out, if the formatting is removed from the variable, every minor upgrade is going to put it back! The majority of my work is upgrading sites so this is a potential nightmare.

[brucet]

Just to clarify, the method is not new, it has been around since v8 and is used by the Design tab toolbar to add formatting. We have just used it in a handful of new places; mainly (and I think exclusively) where heading tags are recommended from an SEO perspective, particularly where some customers had created nested heading tags by adding them using the toolbar. As far as I am aware it's only ever used for section, product and fragment names

We didn't add the tags to any pre-existing layouts, so I don't think there are any upgrade instructions for them. I haven't tested and I'm not certain, but I don't think the upgrader will put them back if you take them out.

In SellerDeck 2013 we did extend the functionality to support div tags. We have used this for one or two elements that can be repositioned via the UI and where it's important that the class attribute moves with the element, because the SellerDeck themes incorporate contextual style definitions that modify the orientation and appearance according to the position on the page.

[brucet]

I don't think the upgrader will put them back if you take them out.

I've now tested this and confirmed that it is the case, at least between sites of the same minor release. I will try to check between releases when I get the chance but I'm confident it will be the same.

The upgrader will not add the tags to any custom layouts of your own.

[Mike Hughes]

Hi Bruce,

Good news if the upgrader doesn't change any edit to the tags in variables. But this is a two edged sword because surely it implies that once sellerdeck have applied a styling tag to a variable it's fixed that way for life unless the user changes it themselves.

From an SEO perspective this is bad. What makes sense at one point in time can often be seen as bad practice later on. The overuse of H2 tags is one of the things under the spotlight at the moment and something that may come back to bite users who aren't aware of what's going on behind the scenes.

I'd still argue that the most logical, consistent and maintainable approach is for the styling to be defined in the layouts. I can understand that allowing elements to be moved using a graphical interface faces challenges with keeping the styling associated with the right elements. But all the more reason to make sure the styling can be seen by looking at the underlying design layout. Not hidden away in the the elements themselves.

Mike

[brucet]

That's a fair comment WRT to layouts, and I will certainly bear it in mind in future.

I think there are only a few place where we used formatting codes for layouts. Generally it's where an old layout is inserted into a new one. It enables us to lock the old layout to the new style, without having to upgrade the old layout (which we try to avoid as far as possible, for obvious reasons).

Otherwise, I think we have used it only with variables, and only with <actinic:variable name="ProductName"/>, <actinic:variable name="SectionName"/> and <actinic:variable name="FragmentTitle" />. There really is no other way of locking an attribute to those.

In future, some kind of semantic markup will probably become the standard. Maybe some hybrid between HTML5 and the schema.org definitions. That should eliminate all debate IWHT, because there won't be much dispute that product names should be tagged as product names etc... That's a change the upgrader could handle very easily.

Where a layout contains nothing but a style and a variable, the embedded formatting would actually enable us to eliminate the layout entirely. I reckon we could almost halve the number of layouts using that and a few other tricks. We probably won't, though, because of the upgrade implications.

As a general observation, SD 2013 was the biggest ever upgrade to our templates, some of which dated back to 1996. There is a bit more to do in SD 2014, but it's unlikely we will do anything of the same scale for many years.