Codecov Report

All modified and coverable lines are covered by tests ✅

Project coverage is 52.80%. Comparing base (da87da1) to head (542e92f).

@@           Coverage Diff            @@
##           master    #2689    +/-   ##
========================================
  Coverage   52.80%   52.80%            
========================================
  Files         130      130            
  Lines        7162     7162            
  Branches     1503     1480    -23     
========================================
  Hits         3782     3782            
- Misses       3075     3225   +150     
+ Partials      305      155   -150     

☔ View full report in Codecov by Sentry.
📢 Have feedback on the report? Share it here.

Here's a side by side comparison of the effect of changing this style:

• The indentation of bullet points gets pushed "inside" the bullet content:

Sublists:

Left - New (this PR), Right - Old (master-netlify)

While this fix does indeed solve the issue, I wonder if there is a more stylish way to go about it, as it does increase the indentation substantially...

Here's a side by side comparison of the effect of changing this style:

• The indentation of bullet points gets pushed "inside" the bullet content:
  
  Left - New, Right - Old

While this fix does indeed solve the issue, I wonder if there is a more stylish way to go about it...

This is likely due to the list-style-position property applying to both ordered and unordered lists.

@gerteck I have updated the css style to retain the original positioning for unordered lists.

Thanks for the quick change! Does anyone else have any opinions on the increased indent on the numbered lists?

I'm worried about this indentation disappearing. It affects the readability of the list :-(

This seems more like a user issue that doesn't need a markbind fix.

I see that the main.css in the 2103 website has

.website-content {
     margin: 12px auto 40px auto;
     max-width: 800px;
     overflow: hidden;
     text-align:justify
 }

which is not contained in our default main.css. The wrapper we provide (for similar effect) is

#content-wrapper {
    flex: 1;
    margin: 0 auto;
    min-width: 0;
    max-width: 1000px;
    overflow-x: auto;
    padding: 0.8rem 20px 0;
    transition: 0.4s;
}

@damithc Adjusting (or removing entirely) the .website-content css should fix the issue. I tested simply removing the overflow-hidden in this custom css and the list issue is gone:

• to still achieve similar styling, perhaps remove the "website-content" wrapper, and add css directly under content-wrapper. this might be a legacy migration issue
  

I tested simply removing the overflow-hidden in this custom css and the list issue is gone:

I tried this and it fixed the problem in the list. Thanks for the tip @tlylt 💯

Soon I will try replacing the .website-content entirely.

I think the issue is still relevant here. I tested this with using the markbind userGuide where removing padding defined in main.css using markbind layouts still causes the hundreth place of the list to be missing.

I think the issue is still relevant here. I tested this with using the markbind userGuide where removing padding defined in main.css using markbind layouts still causes the hundreth place of the list to be missing.

Why do we need to remove the padding defined in main.css?

Why do we need to remove the padding defined in main.css?

I was thinking maybe in a case where authors define their own layouts but did not add any padding. With main.css, the numbered lists only gets hidden when the number of items in the list >10k

I was thinking maybe in a case where authors define their own layouts but did not add any padding. With main.css, the numbered lists only gets hidden when the number of items in the list >10k

In my opinion it's a known risk that styles might break if users choose to update the default css, any other styling might also break if done incorrectly. Not that there's no need to improve the feature itself, but the approach this PR is going for doesn't resolve the problem nicely without introducing "new problems":

• list-style-position: inside; styling wise I would prefer to keep it outside, so there's no "misaligned" issue

In my opinion it's a known risk that styles might break if users choose to update the default css, any other styling might also break if done incorrectly. Not that there's no need to improve the feature itself, but the approach this PR is going for doesn't resolve the problem nicely without introducing "new problems":

• list-style-position: inside; styling wise I would prefer to keep it outside, so there's no "misaligned" issue

I agree that keeping styling outside should be preferred as it keeps the alignment of the list elements. Perhaps we can add it as a known issue/ warning to users who are trying to insert custom css stylesheets into their documents?

I also came across this thread on stack overflow where the accepted answer suggested using the browser's table layout algorithm to achieve the same effect. I've tried it out and it does preserve the outside property and keeps the indentation while avoiding the hidden list numbers.

I have not found any regressions yet. Have yet to test it out on macOS. @tlylt what do you thhink? I have pushed the commit if you want to try it out.

Perhaps we can add it as a known issue/ warning to users who are trying to insert custom css stylesheets into their documents?

i don't see any mention of how custom css can be used in our UG, perhaps we can add some details of that (and the potential pitfalls) in https://markbind-master.netlify.app/userguide/usinghtmljavascriptcss

Regarding the new proposed changes, I have a preference to keep the current simple version as is since the existing layout css works well enough, but thanks @Incogdino for the investigation and finding out the root cause🚀

i don't see any mention of how custom css can be used in our UG, perhaps we can add some details of that (and the potential pitfalls) in https://markbind-master.netlify.app/userguide/usinghtmljavascriptcss

Regarding the new proposed changes, I have a preference to keep the current simple version as is since the existing layout css works well enough, but thanks @Incogdino for the investigation and finding out the root cause🚀

Okay in that case I shall close this PR and raise an issue to update the documentation