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

[IDEA] Render wikitext strikethrough as <s> instead of <strike> #8922

Closed
jn64 opened this issue Jan 31, 2025 · 4 comments
Closed

[IDEA] Render wikitext strikethrough as <s> instead of <strike> #8922

jn64 opened this issue Jan 31, 2025 · 4 comments

Comments

@jn64
Copy link

jn64 commented Jan 31, 2025

Is your feature request related to a problem? Please describe.
Currently, ~~foo~~ in wikitext renders to HTML <strike>foo</strike>

Describe the solution you'd like
Change it to <s>

Describe alternatives you've considered
None

Additional context
Other inline markup (from the first table here) is rendered to the same HTML by wikitext and Markdown. Only differences I could tell briefly are: Markdown renders s for strikethrough, and doesn't support highlight and underline. Regardless of semantics or specs, this should be changed for consistency, to bring the output of both types closer (better for testing, styling, and consuming TW output).

Wikitext already favours other semantic tags (strong instead of b, em instead of i) since 10+ years (?)

Browser support for both elements is the same (everyone has supported both for as long as anyone knows):
https://caniuse.com/mdn-html_elements_s
https://caniuse.com/mdn-html_elements_strike

strike is obsoleted in HTML5 the HTML Living Standard. Both were deprecated in HTML 4.0 and we kept using them, so this is the least important reason.

@pmario
Copy link
Member

pmario commented Jan 31, 2025

STRIKE is deprecated.

@Jermolene ... Since browser support is equal, I think it would be a valid change.

The only problem would be, if users have used strike in CSS definitions, which would invalidate that CSS. So in the end it may be a "breaking change".

What do you think?

@pmario
Copy link
Member

pmario commented Jan 31, 2025

@ericshulman ... What's your opinion?

@Jermolene
Copy link
Member

Hi @jn64 @pmario backwards compatibility is indeed the problem here. It would not be reasonable to break existing CSS rules that are in use in the field. I agree that it is jarring that we use an old school HTML element, but the HTML backwards compatibility guarantees are intended for exactly these kind of scenarios, and provide protection that nothing is going to break with the status quo.

@jn64
Copy link
Author

jn64 commented Feb 4, 2025

No problem, I'll patch on my end

@jn64 jn64 closed this as not planned Won't fix, can't repro, duplicate, stale Feb 4, 2025
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

3 participants