HTML writer: support parenthesis list delimeters #11335
Conversation
|
Ooh I've learned from the test matrix that older GHC can't tell when previous case analysis eliminated certain possibilities, neat. I'll make it compatible. |
|
Very slick! Here's the one thought I have. We have a distinction between DefaultStyle and Decimal, which gets effaced by your code. Would it be better to make counterStyle a Maybe, so that the explicit indication of a "decimal" style is left out of the ol tag when we have DefaultStyle? |
|
That's a good point on handling Default more appropriately, I'll work on that. |
silby
force-pushed
the
push-ylkyqnxzzzmo
branch
2 times, most recently
from
9806501 to
cfa2c8b
Compare
|
The phenomenon with the Default vs. Decimal counter styles is preexisting. I added a command test with some demonstrations of how things stand. |
|
Now passing CI on GHC 8.10. Somewhat distressingly I have to conditionally-compile the catchall branch in the offending case statement because it warns for redundancy (and thus would fail CI due to -Werror) in later GHCs. You dropped GHC 8.6 and 8.8 at 6182769 2.5 years ago and the last release of GHC 8.10 was a couple months after that with 8.10.7. No idea what your usual approach for dropping major versions is but this is a data point. |
|
CONTRIBUTING.md says that we aim to support at least the last 3 ghc versions, and often more (currently back to 8.10). So, I think it would be safe to drop ghc 8.10 support at this point. Indeed, we might even consider dropping everything less than 9.6. (9.6 is the version in Debian stable, which I always try to support; it's usually the oldest version in any Linux distro.) @tarleb what are your thoughts? |
|
Even Debian oldstable has GHC >= 9, so dropping 8.10 seems like a safe choice. And I don't mind making GHC 9.6 the minimum version. |
|
OK, I've dropped support for ghc < 9.6. Hopefully this allows us to streamline some things! |
|
Ok cool. I’m out of town til Tuesday so you could cherry-pick the main commit from this PR without the compatibility fix or if you have further feedback let me know and I’ll address it next when I’m back. |
silby
force-pushed
the
push-ylkyqnxzzzmo
branch
from
2937c73 to
cfa2c8b
Compare
Current browsers support defining custom @counter-styles to be used as
list-style-type values for lists. This change adds rules to the default
HTML styles, as needed, to support lists using the OneParen or TwoParens
style. The type="1" (etc.) attribute is retained, which means the
browser should do the next-best thing if the @counter-style rule goes
missing in somebody's workflow. The custom @counter-styles will not be
used in markup written without a template. ("Is there a template at all"
doesn't actualy answer the question "will the styles.html partial emit the
@counter-styles like we expect" but we resort to this sort of thing in
other places.)
This change unconditionally, and arguably redundantly, adds
style="list-style-type: decimal" (or "lower-alpha", etc.) to <ol>
elements where it didn't appear before, including in non-standalone
output.
silby
force-pushed
the
push-ylkyqnxzzzmo
branch
from
cfa2c8b to
f514f78
Compare
|
rebased and pushed with the Haskell 8.10 support dropped. Any further feedback on this? |
| With fancy_lists and parens in the markdown source, we don't try to use a | ||
| custom counter-style as the list-style-type in HTML output when no template is | ||
| used. |
There was a problem hiding this comment.
This is unusual -- the usual expectation is that the output you get without -s is the same you'll get with -s (save for the template). Do we need this feature ? What happens if we specify the custom list style type and it isn't defined in styles ?
3 participants
Current browsers support defining custom @counter-styles to be used as list-style-type values for lists. This change adds rules to the default HTML styles, as needed, to support lists using the OneParen or TwoParens style. The type="1" (etc.) attribute is retained, which means the browser should do the next-best thing if the @counter-style rule goes missing in somebody's workflow. The custom @counter-styles will not be used in markup written without a template. ("Is there a template at all" doesn't actualy answer the question "will the styles.html partial emit the @counter-styles like we expect" but we resort to this sort of thing in other places.)
This change unconditionally, and arguably redundantly, adds
style="list-style-type: decimal"(or "lower-alpha", etc.) to<ol>elements where it didn't appear before, including in non-standalone output.That last bit is somewhat unaesthetic (cf. the changed tests) but the code to eliminate the problem would've been conditional-heavy.
Fixes #11326.