Basis: Needs styling on Node links like "Read more" and "Comments"

[quicksketch]

Describe your issue or idea

The styling on the node links could use some work in Basis. Right now they stack on top of each other, rather than displaying one after the other:

Steps to reproduce (if reporting a bug)

• Install Backdrop.
• Enable comments on the first post.
• Add comments to the first post.
• View the homepage.

Recommended solution Remove the display: block style on .links.inline .node-readmore in basis/css/component/small-text-components.css

Status

Blocked until we find a better way to make backward compatible CSS Changes. https://github.com/backdrop/backdrop-issues/issues/4167

[ghost]

Confirmed; still an issue in the latest version:

[ghost]

The PR was simple enough: https://github.com/backdrop/backdrop/pull/4122

The implications of it, on the other hand, might be trickier to address...

[ghost]

[argiepiano]

I find the comma separator in "Read more, 1 comment, Add comment" rather confusing. The commas make them seem more semantically related than they are (not to mention that "Add" should not be capitalized after a comma, but this is not this PR's fault). Specifically "Read more, 1 comment" makes it seem like the Read more is somehow related to comments, but it's not.

[bugfolder]

For parallelness of construction, grammar, and punctuation, should it be

Read more; see 1 comment; add comment

?

[bugfolder]

I added another PR that fixes the capitalization of "Add" in addition to the CSS change of the existing PR.

There's still the question of whether inline links should be delimited with something "stronger" than commas (like semicolons, in my comment just above).

Even though semicolons are more grammatical in this example, since inline links are used in a lot of places, it's not clear that they should be replaced everywhere. If it's a good idea for here, then maybe should we support another CSS class that replaces the commas with semicolons in specific locations?

[bugfolder]

Meanwhile, tests need to be updated for this PR (to check for consistent capitalization).

[olafgrabienski]

I added another PR that fixes the capitalization of "Add" in addition to the CSS change of the existing PR.

The fix works for a post with comments (screenshot No. 1), but not for content without comments (No. 2).

No. 1, Post with comments

No. 2, Post without comments

[olafgrabienski]

There's still the question of whether inline links should be delimited with something "stronger" than commas (like semicolons, in my comment just above).

I agree, commas aren't the best option here, but I don't like semicolons either. In my opinion, both are misleading, suggesting that inline links are part of a grammatical sentence. I see them rather as independent elements. To make this more clear, they could be separated by an element which is normally not used grammatically (not as punctuation in the strict sense), and to keep the "Add" capitalized. Ideas:

Slash: Read more / 1 comment / Add comment

Pipe: Read more | 1 comment | Add comment

Middot: Read more · 1 comment · Add comment

Spacing (CSS margin): Read more 1 comment Add comment

My favorite: middot, or spacing

[avpaderno]

Commas are used for lists, but Read more, 1 comment, Add comment is not a list; it could be a list, if it listed actions to do on comments.

I prefer middots as separators; spacing is my second choice.

[olafgrabienski]

Read more, 1 comment, Add comment (...) could be a list, if it listed actions to do on comments.

Interesting! I guess, that was the reason for @bugfolder's addition of a verb ("see comment") here: https://github.com/backdrop/backdrop-issues/issues/2797#issuecomment-1173103844

[bugfolder]

Middot: Read more · 1 comment · Add comment

Middot is my favorite, too, and a nice thing about not using sentence punctuation is then capitalizing each element (current behavior) makes grammatical sense.

that was the reason for @bugfolder's addition of a verb ("see comment") here

Yes, that way they're all imperative sentences.

[bugfolder]

I modified the PR to go back to always capitalizing and use heavy dots for delimiters (which seemed better balanced to me):

Using diferent delimiters for inline links seems to makes sense here, but what about generally?

I did a search in core for 'links', 'inline' (to find instances of '#attributes' => array('class' => array('links', 'inline')), and see examples in:

• book.module
• comment.entity.inc
• comment.module
• file.entity.inc
• node.entity.inc
• redirect_handler-field_redirect_operations.inc

As for changing N comments to See N comments for links, I'd like to hear more of others' thoughts on that.

[olafgrabienski]

Using diferent delimiters for inline links seems to makes sense here, but what about generally?

I'd say it makes generally sense. It would be good to check with some examples, but I don't have the time at the moment.

Re changing N comments to See N comments, I prefer the first (less noisy). Actually, I think it deserves a separate issue.

[findlabnet]

I think things like different delimiters are a matter of user taste or styling rules, so it should be configurable just like breadcrumbs delimiters in some themes.

[bugfolder]

Here's an example using redirect_handler_field_redirect_operations.inc: create a View table of URL redirects, then add the Operations field. In Seven (in the View editor), it looks like this:

And in Basis, with the dot delimiters, it looks like this:

I don't think it needs the dots here, but they don't hurt. (Actually, I'd prefer that the "Operations" render as dropbuttons, as is done in so many other places for multiple operations, but that would be a different issue.)

[bugfolder]

For the usage in node.entity, this theming is used for the "Read more" link in teasers, but since there's only one link, there's no delimiter. But modules could (via hook_node_view or hook_entity_view add additional links.)

[bugfolder]

For the usage in file.entity, the links are themed inline, but the list of links is empty unless augmented via hook_file_view or hook_entity_view.

[olafgrabienski]

@bugfolder Thanks for the examples! Looks like your statement about one of them (dots not needed, but they don't hurt) is valid for most places. However, with different ideas like dropbuttons under consideration, I'm not sure if it's worth the effort to change all the places now.

[bugfolder]

I'm not sure if it's worth the effort to change all the places now.

If we change the CSS that affects the read more/comments display, it will automatically affect all the other places, so no additional effort is needed to change those. I think the reason for checking the other places was to make sure that this change didn't adversely affect other places. (And thus far, I don't think it does.)

I'd suggest we go ahead and make the CSS change to dots. It will improve the display of links for read more/comments, won't hurt anywhere else. And then as for the other things discussed:

• Changing redirect operations field in Views to dropbuttons could be a new issue (and then it wouldn't be affected by this change).
• Letting users change the delimiter from dots to something else is easily accomplished by subtheming Basis, and that avoids adding another setting to Basis; but if there was strong support for making that a Basis setting, it could then be another issue.

How's that sound?

[olafgrabienski]

Sounds goood! I guess, #4167 comes into play now. Time to agree on a solution there!

[izmeez]

I'm not sold on this. The "Read more" is functionaily related to the teaser and may be styled in relation to it. The number of comments, add a comment are additional actions, such as taxonomy links and others so they tend to be treated and styled differently. I think they belong on separate lines to at least begin this separation. Then leave it up to the site builders how they want to style it further. In my view, it ain't broke and should be left.

[olafgrabienski]

I agree, "Read more" is a different action than the comment links. However, they are equally part of the <ul class="links inline"> element. In contrast, taxonomy links of Post teasers are out of the box rendered in <div class="field-name-field-tags ...">. While they are rightly displayed separately, the inline links are better on one line, in my opinion.

[klonos]

I was under the impression that we were using pipes as link delimiters, but maybe I am remembering a specific theme, or perhaps somethings specific to GovCMS 🤔

[klonos]

...it is the Views UI!:

So you can say that that's an existing pattern we should retain I think.

[bugfolder]

So you can say that that's an existing pattern we should retain I think.

I agree. So, to recap...before:

Updated PR:

[olafgrabienski]

Hm, looks I was a bit slow and the PR is already updated: Personally I don't like the pipes, too obtrusive, and I like the dots much better.

Re consistency, the Views UI is a different thing, and it wasn't revised for a long time. We can follow its pattern, but in my opinion we don't have to.

[bugfolder]

I guess I don't have a strong opinion myself (though consistency, however tenuous, won the day for me here). Since we clearly have a difference of opinion, how shall we settle this? (Perhaps our designer, @dariusgarza, could chime in?)

[olafgrabienski]

Thanks @bugfolder, and thanks for all the work on this. In a way, I have a strong opinion, but it's also a personal preference, and I don't want to derail the issue. The pipe symbol is also fine for me.

[avpaderno]

I find the pipes in the last screenshot fine too. I guess it may be because they seem like the borders of table cells.
In the case the part after the delimiter could be rendered in the next line, I find the pipes more appropriate.

English does not use middle dots as punctuation anymore, but some languages use them. This could be a reason for avoiding middle dots to separate links.