Let's talk valid markup

Beta
#1

HI @alexander!

I know this will be off-topic from the next release, but I feel we should discuss this.

I am struggling keeping markup valid in many cases.

1.

For example, if I want the Row element to be ul, I’d expect its children to be able to be li elements. We can change columns to li, but then the ul is at the wrong place:

<ul class="x-row">
   <div class="x-row-inner">
       <li class="x-col">
       </li>
   </div>
</ul>

It should be on the x-row-inner container.

2.

We have the wonderful Navigation dropdown element, which can be turned into megamenus. However, in reality, we need a few navigation inline items and a few dropdown modals.

The problem is that the two aren’t connected. Navigation items should be nested inside the nav tag, and individual items should be li wrapped inside an ol or ul. This seems impossible with the dropdown element that is placed as part of the navigation. We should be able to add the li tag to any Toggle and we should be able to combine top navigation items and other containers inside a single ol or ul.

3.

We should be able to follow the standards laid out in the Storefront theme if we chose to, when building WooCommerce Archive and Single layouts. The goal is to maximize third-party compatibility. Many plugins and analytics solutions use native structure and classes.

Markup
For example, products container should be ul, and product items should beli, but the issue described above prevents this. We can only build it inside the div, but then we lose all the flexbox convenience of the Row element.

With regards of the h tags, we often need to combine data from different dynamic sources and still be able to wrap them inside an h1 for example. At least the Heading element should be able to wrap the subheading into the main h tag, or even better, a Div element should be able to output an h tag, or to be able to receive a custom tag of our choice.

Classes
Additionally, as soon as we add native WooCommerce classes to elements, WooCommerce CSS kicks in. These classes are often needed for compatibility reasons, and since we are building our own layouts, WooCommerce CSS isn’t needed. It will only create conflicts. A native way of removing it from layouts should be available.

Hooks
Lastly, many third-party plugins rely on WooCommerce hooks. Since we are building our own layouts, they are not present. There is no way to include them, as far as I know. I think there should be a Hook element that we can drop into appropriate places.

Please forgive me for making this thread so broad, but I feel that everything mentioned is connected.
Thanks!

7 Likes
#2

This. Currently working on a navigation structure that needs several mega menu items as well as regular nav items. It’s a bit hacky right now as you pointed out.

2 Likes
#3

likewise, mega menu and ‘normal’ menus combined here > https://ridgefieldconsulting.co.uk/

this would be much easier/better if they could be combined into a single navigation somehow

3 Likes
#4

Hi @Misho,

Thanks for bringing all of this up! No worries on it being broad, I may not address everything here but I’ve got a bunch of thoughts to share.

It’s still pretty early to discuss in depth, but it’s likely that we’ll be creating a new family of V3 elements. Historically, our V2 elements were focused on solving specific UI patterns (buttons, accordions, etc.) We also tried to build in lots of options, but like any product there’s always just one more thing that would make the element better or more useful. Our current Headline element is an example of packing in lots of different functionality - it’s nice to have, but comes with the baggage of extra markup and classes. We want to move away from having to chase all those feature requests which ultimately end up bloating the elements. Instead, we’re going to introduce a small set of utility elements and focus on showing ways they can be composed together to create just about anything. One of these elements will have the purpose of “Single Line Text” and serve to simply put text inside a given tag - no fluff, no extra tags.

Once we have those building blocks, there’s no limit to how many permutations of headings with sub headings or other augmentations that can be created and distributed. There’s much less friction for us to produce the equivalent of an element Preset and distribute that than there is creating new hardcoded functionality. Once you’ve had a chance to play around with Components and Parameters this might feel even more clear.

In regards to the row element, I believe our intention there originally was to remove that inner container once the CSS gap property became mature. I’ll check in with Kory about that to see if there’s any reason we can’t move forward there soon.

For number 2, the Toggle is always output as an anchor tag so wrapping a Dropdown in a “Div” would let you provide a wrapping li tag. The actual content is always output in the site footer and positioned with javascript near the toggle. Being a page builder, this is one of those decisions we made because people tend to care more about what the site looks like than how the markup is structured, and this lets us provide many more options that “just work” out of the box. If it was all contiguous markup, we wouldn’t be able to make those elements dropzones that just accept any other builder elements.

Regarding WooCommerce in general, it’s definitely something we’ll be doing a full audit on and looking for ways to make the Cornerstone Layout builder the best way to build WordPress shops. Keep an eye out for notes on our roadmap because there are a few key pieces we’re building as part of our Theme Options reboot that need to come before this.

I love what you’re thinking for hooks. I’ve actually got a bunch of notes written up there. Hooks are really powerful, and could pose issues to site security if not handled with care. There will have to be some kind of whitelist, but I love the idea of just being able to drop a hook anywhere in a design.

4 Likes
#5

Bumping this for the UI > DIV > LI issue @Misho – curious what your typical solution is for this?

#6

Hi @DoncoMarketing, The only usable solution I see is using CSS Grid as loopers.

Row element still has the invalid option to make it an <ul>, while it cannot have direct <li> children due to the x-row-inner that stands in the way.

@charlie , would it be possible to set the <ul> on the x-row-inner instead of the x-row?

I mean, it is not totally invalid because the semantic meaning is not lost, but it still goes against the HTML standards.

#7

Thanks! Ended up going the CSS grid route and it worked perfectly. Definitely would be cool to see the ul applied to the x-row-inner when that option is selected. Still love the simplicity of rows and columns for quick stuff like lists.

2 Likes
#8

We can add another control for that tag sometime next month. Happy holidays everybody!

1 Like