Applying a link to a block

Following on from this discussion:

I have done some further testing and confirmed the current behaviour in Cwicly.

When you link a Heading block, the structure will be:

<h1>
  <a href="#">
    [...contents...]
  </a>
</h1>

Wrapping the contents of the original tag with the link.

When you link a Paragraph or a Div block, the structure will be:

<a href="#">
  [...contents...]
</a>

Effectively replacing (and therefore losing) the original tag.

This inconsistency may not be apparent to new users and unless it happens to become an issue with any styles that target those particular tags, even seasoned Cwicly users may not notice it at first.

In some specific cases (e.g. with a Paragraph block) we could simply select the contents and link it, but the inline link feature misses the enhanced features of Cwicly blocks’ link dialog, so that is not necessarily equivalent.

I am requesting a new setting be added to Cwicly that enables a consistent behaviour (preferably following the same pattern as the Heading block).

Alternatively, a switch to toggle this behaviour could be added to the link dialog.

There are many good reasons for this, the biggest one being semantics. Tags have a purpose and a meaning and by replacing tags with the <a> tag, if we wish to retain the original meaningfulness we have to wrap it (in the same type of block we originally chose!). This feels very redundant and providing a consistent behaviour to retain the tags is more in line with the amazing spirit of Cwicly to simplify and speed up the developer experience.

Thank you for your consideration.

The best way to handle that is to link the appropriate words in the content and not the container itself. If you want to make the linked words expand out to the borders of the container element, then you would want to use something like this, which targets the link in the content and expands the clickable area out to the borders on whatever container you add the class to. This maintains the correct semantics and structure for which text is actually being linked, while maintaining the visual and clickable style of a linked container. Hope I understood your issue and hope this makes sense if I did.

<div class="link-overlay">
  <p>Lorem ipsum dolor sit amet, consectetur adipiscing elit, sed <a href="#">I'm a link</a> do eiusmod tempor incididunt ut labore et dolore magna aliqua.</p>
</div>

and…

.link-overlay {
  position: relative;
}

.link-overlay a {
  position: static;
}

.link-overlay a::after {
  content: "";
  cursor: pointer;
  display: flex;
  inset: 0;
  position: absolute;
}

I appreciate your comment, I did already mention this and the reasons why it is not a viable alternative in some cases:

Besides this, it doesn’t address the inconsistency or blocks that do not have text content (such as divs).

Also, for a final thought on this, we already have the Button block that is essentially a linkable container. So if we want to wrap our semantic blocks in a link we can do so and if we want to we can simply add a Button block within another container block.

This is not about a limitation in capability because Cwicly helpfully provides many ways to achieve the same task, it’s about highlighting a potential way to improve the link feature.

Maybe I’m not understanding then. Sorry about that. A link should amidst always be added to text for contextual meaning, so a button, or paragraph text, etc… sometimes you may want to link an image, so you would wrap the image in a link tag, where the alt attribute would act as the text. If you add a link to a div, you’re effectively saying you want the div to be a link, so it would replace the div tag with a link tag since it’s not appropriate to wrap divs with link tags. That’s not to say you can’t do it, but it’s not really how it should work. Now are we talking about the proper and accessible ways to link things in general, or just Cwicly’s implementation using the link icon? I think their link icon works exactly as it should unless, again, I’m not understanding. Haha, which is possible since it’s late where I am and I’m doing all of this on my phone. :sweat_smile:

I know the feeling, it has been a long few weeks!! :sweat_smile:

To clarify, I am not saying the <a> should wrap the <div>. As shown above, I am saying for Div blocks and Paragraph blocks ideally I want it to work like it does already for the Heading block:

Note: The <a> tag is wrapping the contents, not the <h1> tag.

Currently to achieve the same thing with a Paragraph block, you have to wrap the Paragraph you have applied the link to with another Paragraph block, which is fairly redundant and unintuitive.

Hopefully this makes what I am pointing out a bit clearer.

I’ll hop on the computer later and see what the default behaviors are for these things, which will probably help make more sense. In the meantime, have a good weekend! Sounds like we both need one :melting_face:

@Louis, I am curious about your thoughts on this, whether you believe this will be a worthwhile change.

As mentioned, Cwicly is great in terms of flexibility, so currently as technical users, we can be creative and add a Div block, change it’s tag to <p> then add a Button block inside it as an example of a way to achieve the same end result, however for someone new to Cwicly or a less technical client, this is not really a good option.

As Cwicly gives us a Button block with the same dynamic capabilities as the Paragraph block, I can’t see any downside to the change as long as backwards compatibility is handled.

Here are my 2 cents, please take this as an individual opinion only.

Cwicly is as consistent as it can be in that regard.
There is a reason for this behaviour.
To quickly summarize it, there is no inconsitency.

What you are describing would completely go against Cwicly’s philosophy and the process that @JohnD described should always be the (default) way.
While this might be an excellent fit for other builders, I just can’t potentially see something like that inside Cwicly.

It really is, but with this behaviour freedom would even be sacrificed (for no reason).

Nothing against an option to change the default behaviour to a quite opinionated approach, but to be honest, the disadvantages outweigh the advantages, especially from a contextual view. While it might make sense for some in the first place, the disadvantages which show up over time wouldn’t be worth it.
In the end, it would lead to problems which no one wants to deal with - not the user, not the dev and support team.

Not only do I believe that hardly anyone would use it, but also an additional layer of complexity would be added, and the vast majority of (new) users would be confused.
How should that even be implemented in an intuitive way?


I know my feedback lacks in depth, sorry for that (I’m short on time), just wanted to add some quick thoughts here.
Curious though what other users think here.

Hi @Marius,

Thanks for your reply, I appreciate you giving your feedback.

I believe that we may agree more on this than it first seemed based on your response to the thread you linked. What you describe there is exactly what I also like and this is exactly what I am proposing for the <div> and <p> tags for the reasons I already mentioned in previous comments.

As mentioned in my original message the Heading block behaves differently to the Paragraph and Div blocks, which is the inconsistency I am referring to.

With the Heading block, a Cwicly user can simply link it and retain the <h1-6> tag in a single step.

With the Paragraph block, to retain the <p> tag, a Cwicly user needs to do the following according to the recommendation from @JohnD:

  1. Apply the link to the Paragraph block
  2. Wrap the Paragraph block in a Div block
  3. Set the html tag of the Div block to <p>

These steps are greater in number than necessary and not intuitive for most non-technical users. None of our non-technical clients would even think to do these steps in practice. They could easily however, learn to use the Cwicly Link Dialog, which is very intuitive and user friendly.

I honestly believe that keeping the number of steps to a minimum and keeping behaviours between blocks consistent is very much in the spirit of Cwicly’s philosophy.