Developer forum

Hi Tina

Yes, it is on purpose that the look of the font is not the same as the underlying h-tag. The reason is that you only want one h1 but maybe have several headings with the same look. So we have sperated how it looks from how it 'behaves' in code. So the system is meant to make that decision.

Our experience from Rapido is that most ended up with too many h1's and that caused lots of issues.

So the idea here is that the first headline of the page is h1, the rest something else. If you re-sort the content, the h1 will shift to the first instance - and all text will still look correct.

But I can see that you have the lack of H1 on regular content pages. So only pages with product lists, details, maps etc. have H1.

We will discuss what the solution can be. We have considered 2 options - one for selecting the actual h-tag and one for selecting font style/weight like now.

BR Nicolai

Hi Nicolai

I understand your thoughts about this, but i think the way it is implemented now, will give a lot of confusion, as you would expect that when you choose a Headline 1, then the headline will be an h1, headline 2 an h2, etc.

Could the solution be, that the headline 1-6 decides what h-tag is added, and if you wan't another look than what is default for your heading, then you can choose to add a display 1-6 class to your heading? It will give the editors more control over their content, and we always tell the customers that they should always make sure there are only 1 h1 on a page. 

Another way to go, could also be to remove the buttons for Headline 1-6, and only have the Display 1-6 to change the look of the headlines, so the h-tags is fully autmoatically generated, making sure that there are always 1 h1 on a page.

Hi Tina,

I have read your comments and also Nicolai's comments and I agree I have had similar requests in the past.

Headings are probably one of the most controversial subjects since they have an impact on both SEO and design.

In our projects, we ended up separating the markup from the rendering. That's because, on the Product Detail page, I want an H1 heading but because of the length of the name, I might not be able to use the same font size as for the rest of the website. Also, on a hero banner, you might want to use an H2 heading with a more prominent display than how you usually use h2's.

That's what we ended up with heading classes instead of 1:1 relationships between styles and heading markups. And I believe that this approach worked very well for us ever since we ended up with this solution.

The markup is for SEO purposes and tells the search engine the priority or relevance of each heading while the rendering has an impact on the look and feel of the page. Having them disconnected, offers more flexibility. 

I hope this helps.

Thank you,
Adrian

Hi Tina

I am pretty sure we will not let the font size control the underlying markup. It might work on paper, but in every day life of ordinary editors who creates most of the content, they will forget and fail ultimately hurting their SEO. Also editors care about look and want the same size heading all the way down the page, and do not remember or understand the consequence. We know that because we tried it...

But the option to override the underlying markup could be useful.

A radio hidden in the settings

Heading markup (h-tag)

• Swift decides
• H1
• H2
• ..
• H6
• div?

Hi Nicolai

I'll try to explain a little more clear, as i think you misunderstodd me a little :) 

I'ts not that we want the font size to control if it should be an h1, h2 and so on, but when you choose that your headline should be a headline 1, you would also expect that it will be an h1 in the markup. There will be editors around with some knowledge about HTML markup, and for those people, it will be confusing with how it is implemented for now. It would also be these people who would ask to have full controll over if they want to add an h1, h2 etc. i think :) 

I agree that for users without knowledge about any HTML markup and so on, it could go wrong, if we don't guide them well in how to add content to their website, and they have to choose what h-tag to add. Then i think it would be better to remove the possibility to add the headline 1-6 and only have the Display 1-6 to change the look/size of the headlines, or make it really clear in the description, that headline 1-6 doesn't affect the HTML markup, but only the font-size of the heading.

For the cases where the customer want full controll, it's of course possible to extend the functionality. 

But i think we are more or less on the same page all three of us, but just explain it different ways :)

Hi Tina

>>when you choose that your headline should be a headline 1, you would also expect that it will be an h1 in the markup
You expect this because you understand. Most editors out in the companies do not understand this. They have no clue what H1 is and why it is important.
We have a lot of customers and made 100s of solutions on Rapido and we know that this is the case. We have researched a lot, including this. We are also aware that some editors (a select few) have a better understanding and want to control markup.

And yes you can guide regular users, and today they understand and remember, but in a month or 2 they have totally forgotten.

On Rapido it worked like you request. And users want the same size of headline all the way down the page, and they choose the same heading because of that - often giving many h1s in the markup. And then SEO 'experts' react.

Swift content editing is not a tool for frontend developers, seo experts or other web professionals. It is made for editors that has other capacities and Swift has to act as much as possible as a tool to support them with as little web specific knowledge as possible.

We understand that there are different types of editors, requirements, preferences and approaches out there and want to address that as much as possible. But not at the cost of overall simplicity and understanding for the largest group of end users. Right here in content editing, regular users is the focus.

But as I initially suggested, we will probably give you the option to choose H-tag in a seperate setting so you can have markup like this:

• <h1 class="display-5">
• <h2 class="h1">
• <h3 class="h1">

BR Nicolai

Hi Nicolai,

Checking in on this thread to see if anything was implemented as a workaround (as you suggested in your last response) if a particularly tech-savvy customer wants to manually control their content header tags natively, outside of using a rich text editor, as Tina suggested early in the thread.

Thanks!