Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Tweak list-group to show numbers on list items when used on an <ol> #32244

Closed
wants to merge 5 commits into from

Conversation

patrickhlauke
Copy link
Member

@patrickhlauke patrickhlauke commented Nov 24, 2020

Closes #26202

Per my comment there, I'm not sure which approach would be best/most palatable to take. This PR goes for the simplest/most surgical one, but I know this goes against the grain of targetting specific elements and using child selectors. Then again, the alternative becomes overly verbose...

the simplest would be modifying the list-group css styles to special-case if they're applied to <ol> rather than <ul>...something like

ol.list-group > .list-group-item {
  display: list-item;
  list-style-position: inside;
}

but i know we've been keen to avoid modifying the styles of bootstrap's classes based on which element they've been applied to. so...do we instead propose a whole separate set of styles? .list-group-ordered ? which replicates all the styles of .list-group, but then overrides this aspect?

.list-group-ordered > .list-group-item {
 display: list-item;
 list-style-position: inside;
}

or do we do a modifier hanging off of .list-group-item? .list-group-item-ordered? to be used perhaps in conjunction with .list-group-item, so you'd end up with lengthy constructs like <li class="list-group-item list-group-item-ordered"> ?

.list-group-item-ordered {
 display: list-item;
 list-style-position: inside;
}

basically, there's variations on how we want to get to it. depends on the philosophical approach you want to take (purity of the CSS no referencing elements/special casing based on markup? a whole new set of classes? a modifier?)

Preview: https://deploy-preview-32244--twbs-bootstrap.netlify.app/docs/5.0/components/list-group/#basic-example

@patrickhlauke
Copy link
Member Author

as expected, this fails linting because of the qualifying selector. if we feel this is acceptable, can add the extra comment that tells the linter to ignore it...

@XhmikosR
Copy link
Member

XhmikosR commented Nov 24, 2020

Please try and move all the lorem ipsum changes to a separate PR. :)

Also, I'm not sure if this should be backported; only if it the change isn't considered a breaking one.

@patrickhlauke patrickhlauke force-pushed the patrickhlauke-issue26202 branch from e07fd3b to 6f9d8d7 Compare November 24, 2020 13:22
@patrickhlauke
Copy link
Member Author

Please try and move all the lorem ipsum changes to a separate PR. :)

yeah that was an accident, hadn't switched branches... :)

Also, I'm not sure if this should be backported; only if it the changed isn't considered a breaking one.

fair enough, happy for this to be v5 only

@ffoodd
Copy link
Member

ffoodd commented Nov 24, 2020

If we add a new class to handle this as a variant, it could be backported. If we're using the qualifying selector, it should'nt.

Using one or another depends on whether we consider this as a design thing, or as a semantic thing:

  • should ol always show its counter when used as a list group? Could an ol not have any counter? In that case, why not use an ul
  • should ul be able to display counter? In that case, why not use ol?

I'd be in favor of enforcing semantic by applying it to ol (thus allow the qualifying selector, and not backport it).

@XhmikosR
Copy link
Member

Just to point out that unfortunately there are cases where people don't control the HTML (CMS etc).

@ffoodd
Copy link
Member

ffoodd commented Nov 24, 2020

Regarding CMSes, most of them allows to use (un)ordered lists since AFAIK all of them are using a WYSIWYG (like TinyMCE and/or Gutenberg for WordPress, or CKEditor for Drupal). Themes, plugins and modules can mess this up, but we can't consider all of them—and moreover, requiring a class is not easier than a specific element, in any case I can think of.

@patrickhlauke
Copy link
Member Author

patrickhlauke commented Nov 24, 2020

one option i did not mention in the opener (and the original comment): could also be an additional modifier .list-group-ordered that gets added to the list, so that you'd have to use <ol class="list-group list-group-ordered">

it just gets a bit verbose, but less verbose than hanging it off of individual list items i guess

i.e. this

.list-group-ordered > .list-group-item {
 display: list-item;
 list-style-position: inside;
}

but not ALSO having .list-group-ordered replicating all the base .list-group styles (which would have made the CSS overly verbose).

@XhmikosR
Copy link
Member

The above might be the best approach, indeed. 👍

@ffoodd
Copy link
Member

ffoodd commented Nov 24, 2020

I don't think so, since it'd basically allow any ul to get numbers, and won't solve the ol case since you'd still have to add this class by yourself (which isn't the expected result on the original issue).

BTW if you choose to use this approach, it'd be more relevant to create something like .list-ordered, which could be applied to any kind of list, wouldn't it?

@patrickhlauke
Copy link
Member Author

since it'd basically allow any ul to get numbers

well, if applied to <ul> it'll show the bullet (not numbers)

so, are we saying we want an entire set of .list-group-ordered that replicates the entirety of what .list-group currently does, rather than an additional class to use together with .list-group ?

(this is where the various philosophies on how this should best be handled clash ... i don't particularly care either way, as i'm not a purist ... adding it directly to ol.list-group > .list-group-item makes sense to me, personally)

@ffoodd
Copy link
Member

ffoodd commented Nov 24, 2020

I'd be for ol.list-group > .list-group-item too.

well, if applied to <ul> it'll show the bullet (not numbers)

Well, in that case .list-ordered feels wrong. Could be something like list-styled (as we have .list-unstyled but in that case it still feels wrong to me (since we could let list-style alone as a basis, and add .list-unstyled on .list-group if needed.

@mdo
Copy link
Member

mdo commented Nov 29, 2020

I'm not a fan of adding this since it would require even more work to make the numbers hanging inside the list items. If folks want a count, I feel we should encourage them to do it in other ways. As it stands now, this is an incomplete measure, and feels not very useful.

@patrickhlauke
Copy link
Member Author

patrickhlauke commented Nov 29, 2020

it would require even more work to make the numbers hanging inside the list items.

what do you mean? the styles in this PR (whichever way we go here in terms of approach) take care of that https://deploy-preview-32244--twbs-bootstrap.netlify.app/docs/5.0/components/list-group/#basic-example

If folks want a count, I feel we should encourage them to do it in other ways.

like, how then?

really struggling to understand why you're so set against this, @mdo

@MartijnCuppens
Copy link
Member

MartijnCuppens commented Nov 29, 2020

If folks want a count, I feel we should encourage them to do it in other ways.

like, how then?

I stand by Patrick. An <ol> feels like the most semantic approach.

I've tweaked the Scss a bit, and made more use of nesting in the last commit. Also fixed the linting issue.

@mdo
Copy link
Member

mdo commented Nov 30, 2020

Sorry, thought I added a screenshot to show you what I mean. The issue is with longer strings of text that wrap to new lines. Doesn't look good to me, nor does it account for other layouts inside the list group items.

Screen Shot 2020-11-28 at 8 55 29 PM

In my view, the list group is rarely a set of single-line text—our docs examples further down the page show this. It's intended to be a versatile component overall. This feels like an incomplete measure given it doesn't solve for that.

@patrickhlauke
Copy link
Member Author

ah, i see what you mean @mdo ... i still think though that, at least as a starting point, this SC / allowing to use <ol> and not actually suppressing the numbers when an author clearly intended to convey something numbered is good. it may not be super pretty, but that can be tackled in later updates if needed.

it's basically the choice of:

  • allow authors to use <ol> now, but they might need to do some more work to make it look a bit prettier in certain situations
  • prevent authors from using <ol> even in situations where it might be semantically correct for them to do so

I'd still lean towards the former.

@mdo
Copy link
Member

mdo commented Nov 30, 2020

I get that. I just want to see if we can do more than provide something that feels incomplete to me. We know folks will try to do more and run into this issue, and then we'll be expected to fix it. Let's at least hold on this until after beta 1.

@mdo
Copy link
Member

mdo commented Dec 1, 2020

Updated project to Beta 2 per last comment.

@mdo
Copy link
Member

mdo commented Jan 14, 2021

Coming back to this, hoping to take this CodePen demo from one-off to something customizable and workable for this. https://codepen.io/emdeoh/pen/abmQarE

Any immediate thoughts?

@patrickhlauke
Copy link
Member Author

Coming back to this, hoping to take this CodePen demo from one-off to something customizable and workable for this. https://codepen.io/emdeoh/pen/abmQarE

Any immediate thoughts?

quite liking the look of that. what customisation options were you thinking? variables to change the appearance of the counters (colour, font-weight, etc)?

@mdo
Copy link
Member

mdo commented Feb 12, 2021

Opened #33068. Safe to close this I think?

@patrickhlauke
Copy link
Member Author

Opened #33068. Safe to close this I think?

sure

@mdo mdo deleted the patrickhlauke-issue26202 branch February 13, 2021 00:02
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Projects
None yet
Development

Successfully merging this pull request may close these issues.

Why hide the numbers in an ordered list?
5 participants