Pager pagination results should increment ordered list <ol> numbers

They're called Ordered and Unordered because that's what they're called in HTML. The browser actually does the numbering, so Views can't be held responsible for that. There's no really easy way to change that, I don't think, though maybe adding a style directive via theming I think CSS can tell the ordered list what number to start on.

Is there anyone know how to solve this problem by using CSS?

Thanks in advance!

Actually there is a deprecated property for < ol > to set the starting number: http://www.w3.org/TR/html401/struct/lists.html

But I don't know how to use it with the view output. Maybe you could try editing the output template for lists.

And I don't think this can be done using css since css is static and you would need something dynamic wich changes through the different view pages.

Regards.

+1 most definitely for this feature.

[The following was taken from http://stackoverflow.com/questions/1770482/set-values-of-li-tag-in-html]

True, the ul start and li value have been deprecated in HTML4.

<ol start="34">
    <li>apple</li>
    <li>pear</li>
    <li>car</li>
</ol>

However, they are included in HTML5:
http://www.w3.org/TR/html5/semantics.html#the-ol-element
http://www.w3.org/TR/html5/semantics.html#the-li-element

You could do the same using CSS, although I'm not sure of the browser nuances.

<style type="text/css">
    .mylist { counter-reset: mycounter 34; }
    .mylist li { counter-increment: mycounter; list-style-type: none; }
    .mylist li:before { content: counter(mycounter) ". "; }
</style>

<ol class="mylist">
    <li>apple</li> ...
</ol>

Does anybody know of a work-around for this? Is there some way to override the <ol start="xx"> that is generated for each page? (xx = page number - 1 * number of items per page) Any ideas on where to start?

Can you not simply use the $id variable in the template?

Something like this:

<ol start="<?php print $id; ?>">
<li>
<li>
...
</ol>

I have not tried it, though, but I assume the $id variable is not reset between pages.

If that doesn't work, you could probably use the page number from the URL and put it into your formula...

Just my thoughts.

Somebody does have another solution ?

I'll let my little workaround here, in case that could help anyone.

So basically, all you need to do is to create a specific view-view-list template for your view (for example view-view-list--my-view.tpl.php) and paste this code in it :

<?php
/**
 * @file views-view-list.tpl.php
 * Default simple view template to display a list of rows.
 *
 * - $title : The title of this group of rows.  May be empty.
 * - $options['type'] will either be ul or ol.
 * @ingroup views_templates
 */
?>
<div class="item-list">
  <?php if (!empty($title)) : ?>
    <h3><?php print $title; ?></h3>
  <?php endif; ?>
  <<?php print $options['type']; ?> start="<?php print $view->pager['items_per_page']*$view->pager['current_page']+1; ?>">
    <?php foreach ($rows as $id => $row): ?>
      <li class="<?php print $classes[$id]; ?>"><?php print $row; ?></li>
    <?php endforeach; ?>
  </<?php print $options['type']; ?>>
</div>

Try:

<style type="text/css">
    body { counter-reset: mycounter 34; }
    .mylist li { counter-increment: mycounter; list-style-type: none; }
    .mylist li:before { content: counter(mycounter) ". "; }
</style>

Adding "class" to all ol would continue the list number,
whereas adding "id" can help in resetting particular ol lists from rest.
See some of classreset examples here:
http://insteps.net/pr/a/pmwiki/Cookbook/Precode-sample4

Notice css entry:
body { counter-reset: linenum alpha beta rc1; }

Regards.

Thank you so much, it gives a new thing to learn and understand about views....:)

Solution for Drupal 8:

Copy views-view-list.html.twig into your theme and replace:

  <{{ list.type }}{{ list.attributes }}>

with:

  {% set list_attributes = (list.attributes) ?: create_attribute() %}
  {% if list.type == 'ol' %}
    {# Start the numbering of the ordered list from the correct result. #}
    {% set start = view.pager.current_page * view.pager.options.items_per_page + 1 %}
    {% set list_attributes = list_attributes.setAttribute('start', start) %}
  {% endif %}
  <{{ list.type }}{{ list_attributes }}>

In process of trying to get various things working, i ran into issue #2845400: Adding attributes to views-view-list.html.twig doesn't work if Views List class Style option is empty, and found a workaround using create_attribute() for when the list.attributes is empty.

Here is a complete solution with both example CSS classes, and the start="N" syntax. Hope you find it useful:

{#
/**
 * @file
 * Theme override for a view template to display a list of rows.
 *
 * Available variables:
 * - attributes: HTML attributes for the container.
 * - rows: A list of rows for this list.
 *   - attributes: The row's HTML attributes.
 *   - content: The row's contents.
 * - title: The title of this group of rows. May be empty.
 * - list: @todo.
 *   - type: Starting tag will be either a ul or ol.
 *   - attributes: HTML attributes for the list element.
 *
 * @see template_preprocess_views_view_list()
 */
#}
{% if attributes -%}
  <div{{ attributes }}>
{% endif %}
  {% if title %}
    <h3>{{ title }}</h3>
  {% endif %}

  {% set list_attributes = (list.attributes) ?: create_attribute() %}
  {% set list_attributes = list_attributes.addClass('custom-list-class') %}
  {% if list.type == 'ol' %}
    {# Start the numbering of the ordered list from the correct result. #}
    {% set start = view.pager.current_page * view.pager.options.items_per_page + 1 %}
    {% set list_attributes = list_attributes.setAttribute('start', start) %}
  {% endif %}
  <{{ list.type }}{{ list_attributes }}>
    {% for row in rows %}
      {% set row_attributes = (row.attributes) ?: create_attribute() %}
      {% set row_attributes = row_attributes.addClass('custom-list-item-class') %}
      <li{{ row_attributes }}>{{ row.content }}</li>
    {% endfor %}

  </{{ list.type }}>

{% if attributes -%}
  </div>
{% endif %}

Edit: I've modified the above to use setAttribute instead of addAttribute which was incorrect.

Thanks @jwilson - your template tweak for views-view-list.html.twig in 11 worked really well.

Awesome @robcarr!

It was closed years ago by Merlin of Chaos with this reasoning:

Views can't be held responsible for that. There's no really easy way to change that, I don't think, though maybe adding a style directive via theming I think CSS can tell the ordered list what number to start on.

However, the approach in #11 proves that this can (and should) be done really easily with an HTML attribute in the template, not in the theme's CSS.

Therefore, I'm thinking we could reopen this and switch it to the core Drupal issue queue's Views sub-system.

For the initial question in the IS, isn't this something you would use the 'View result counter' field for? That would not get it right on a HTML level but it would show the correct numbers right?

IS:

when the ordered (numbered) list option is used and pager displays a second page the items are numbered again from 1 ... rather than continuing at the next higher number. Is there somewhere to change this behaviour?

#15:

isn't this something you would use the 'View result counter' field for?

Sure, you could use view result counter, but not if you want semantic html list. Effectively, if you were to use the ordered (numbered) list option with the view result counter field, then you end up with two sets of numbers, one from the HTML <li> itself, and the other from the field value, and as described above, from page two onward the two values would start to diverge. Using view result counter with numbered list would only require further hacking the numbered list functionality to hide the ordinals/bullets in your theme's CSS. This workaround doesn't do any thing for the viability of the numbered list feature out of the box.

Seems to have a test failure.

Also could the issue summary be updated please

I've updated the IS. The test failure seemed to be unrelated so I re-ran tests, and they passed.

Leaving in needs work for two reasons:

1. Perhaps the implementation approach should be moved out of the template and into a preprocess hook, so that all themes will benefit from this fix.
2. This probably needs tests.

This feels like a feature request to me, and something that should be optional. It seems strange to have a page with an ordered list that starts from an arbitrary number? I don't think it's safe to assume that everyone using ordered lists would want it to work that way, which is also supported by the lack of activity on this issue in 15 years.

I'm having trouble making it all the way to your side to re-classify this as a feature request instead of a bug. (I'd honestly be very interested to see a use case where it makes sense to start ordered, paged output back at 1 on each subsequent page load.) That being said, it is a valid point that this should probably be refactored to be optional, and on by default for new new views, but off by default for existing views, so folks can make a decision whether to opt in on a case-by-case basis.

supported by the lack of activity on this issue in 15 years.

In my opinion, a better indicator would be to know real-life examples about how many views intentionally use the Ordered List on paged output (and state their use case), versus those that tried it but had to move away from it because the pagination didn't work intuitively in its current state and instead had to implement incremental ids inside the row data, because they didn't know HTML could do this on its own.

I'd honestly be very interested to see a use case where it makes sense to start ordered, paged output back at 1 on
each subsequent page load.

I think I just consider each page distinct, but it sounds like you are considering them states of a single page.

I will concede I haven’t used the ordered list formatter very much in my 12+ years of Drupaling but just because it was not needed. I use the results summary far more often. Just anecdotal but could be it’s not widely used generally and that’s why there isn't much demand for this.

I think I just consider each page distinct, but it sounds like you are considering them states of a single page.

I haven’t used the ordered list formatter very much

Anecdotally, I've had the need for this several times over the years. So much so that I decided to revive this issue and share my work. I use ordered lists on paged search results, where yes each page in the search results is part of a larger context. This fix is also really helpful when using "Views Load More" or "Views Infinite Scroll" module, where new results are loaded into the current page via ajax without a round trip to the server.

Keep in mind, I'm implementing designs from UX teams with limited knowledge of Drupal, and this pattern of incrementing the index of given search results across pages just makes sense intuitively. It is also worth noting that this issue was closed 16 years ago by Earl, the original author of Views, which could also explain why not more people are subscribed to this issue. The fact that there were 10 comments on the issue after it was originally closed and before I reopened it is a decent indicator that there is a need, however small, for this fix.

I rely on the method in #11 (the Twig template override) as the go-to solution on many projects because it is more semantic and properly announced and easily navigable by screen readers, as opposed to having to go with the "views result counter" approach in #15 inside each row and using the "Unformatted" Views display format, which then requires more theming effort to restore basic formatting styles that you get for free with an <ol> and <li>.

Infinite scroll is certainly a good use case :)

I guess I just haven't come across designs for numbered search. I sure wish I could say I was implementing designs from teams with knowledge of Drupal, do those exist? LOL. Just lucky I guess!

Perhaps the implementation approach should be moved out of the template and into a preprocess hook, so that all themes will benefit from this fix.

At one point Wim Leers had a number of issues which were moving logic from preprocess to templates, see [#701667] and #3260399: [meta] Theme/render system cleanup, which also fits with the way SDCs work. So having the logic in the template might be fine.

This probably needs tests.

This it does need yes.

This was a random issue for Bug Smash today. It has been recently updated so just adding tag.

Didn't test, but what happens on a View with no pager and you try to use view.pager.current_page? Should it check for a pager before using this? And does the Some pager have view.pager.current_page?

Just looked at existing coverage that might make testing this easier, but alas, there seems to be very little coverage for the list style, just \Drupal\Tests\views\Kernel\Plugin\StyleHtmlListTest as far as I could quickly find. No tests for 'ol' list at all.

Still needs tests but tried an alternative approach to add the attribute via code vs twig. Now we don't need a CR for the twig changes.

Goes it a shot with the tests.

This definitely looks a lot cleaner with the logic inside a preprocess function, although back in #28 it was stated that the logic might be better in twig IMO it makes sense here to be in a preprocess function.

Change looks straightforward.
Test only fails as expected.
I manually tested following the reproduction steps in the IS and it does not start at the right number after paging on 11.x but does start at the right point on this branch so this works.

For @lendude in 30, I also tested with no pager present and saw no issues so I think that is not an issue.
First glance I thought the class changes were out of scope but it's so the attributes exist even if a custom class isn't set.

RTBC

Thank everyone for pushing this forward.

First glance I thought the class changes were out of scope but it's so the attributes exist even if a custom class isn't set.

Good point. Also worth pointing out that initializing the Attributes may also have the positive knock-on effect of resolving #2845400-24: Adding attributes to views-view-list.html.twig doesn't work if Views List class Style option is empty 🙌 (which I mentioned way back in comment #11 above). This is worth confirming and double-checking because the patch there is similar to the work done here, but has one additional hunk not present in this issue. Even if it doesn't completely solve that issue, maintainers might consider bringing over issue credit from that issue for the parts that overlap?

Committed/pushed to 11.x, thanks!