Filter .children class on nested comments list

[greenshady]

The start_lvl() method of Walker_Comment should have a filter hook to customize the .children class. This will allow theme authors to utilize their preferred system or CSS framework for handling nested comment lists. And, .children is generic and requires writing nested CSS selectors to target it.

This change would put the comment walker on par with the nav menu walker, where we have the nav_menu_submenu_css_class filter hook.

[joyously]

I'm all for parity, but when I tried to make my menu work with CSS only, I had to insert elements at the parent level of the submenu, not at the child level. So while this filter would be good for comments, it would have the same problem of not being able to inject something at the parent level, which is how you have to work with CSS.

In my case, I had to supply an entire nav walker class just to output a small piece of HTML to be able to trigger the submenus. Comments are a bit less dynamic, but same nested lists.

What I'm saying is: is a filter enough?

[greenshady]

Yes, a filter is plenty when all you need to do is alter a class.

It sounds like the issues you're describing are out of scope for this proposed enhancement.

[Shizumi]

I made a patch.
Because it is the first time, please let me know if there is a shortage.

[greenshady]

The filter hook might be more appropriately named comment_list_sublist_class or something to that effect. Other ideas?

Also, $class_names needs to be wrapped in esc_attr() when adding to the HTML.

[Shizumi]

Thank you for your comment.
I tried to rewrite it.

[kadamwhite]

Thank you for the patch. At WC Kansai contributor day we've discussed this, and aren't sure the best person to endorse inclusion of a new filter. tagging @davidbaumwald for opinions as the listed Comments maintainer. (Any change would be for 7.0 or later, at this point in the 6.9 cycle)

@Shizumi Thank you for your patch. My feedback is that including class="" in the filter makes it harder to escape; if you had the output code look like this,

<ol class="<?php echo esc_attr( $class_names ); ?>">

and then had the filter only apply to the string of class names, it would be simpler.

[dmsnell]

This comment doesn’t speak to the value or tradeoffs involve in creating this new filter, but I can propose one suggestion to avoid further HTML escaping issues, and that is to create the opening tag using the Tag Processor.

<?php
if ( 'div' === $args['style'] ) {
        return;
}

$class_names = apply_filters( 'comment_list_sublist_class', $classes, $args, $depth );

$html = 'ol' === $args['style'] ? '<ol>' : '<ul>';

if ( ! $class_names ) {
        return $html;
}

$processor = new WP_HTML_Tag_Processor( $html );
$processor->next_token();
foreach ( $class_names as $class_name ) {
        $processor->add_class( $class_name );
}

return $processor->get_updated_html();

This can also work, of course, if the filter output is a list of strings, but the array form is convenient and avoids syntax particulars about separating CSS class names (something explored in ​wordpress/wordpress-develop#10043 and in #63694)

[audrasjb]

As per today's 7.0 bug scrub:
There's recent discussion here, but the last patch is 7 years old. Let's move it to Future release for now.

Trac ticket: https://core.trac.wordpress.org/ticket/44923