<section> tag name collides with HTML5 <section> tag, thus should be renamed - suggesting <sect> instead...
Version: unspecified
Severity: major
See Also:
T49936: Implement <section> natively in Parsoid, possibly as plain HTML5 content
Description
Description
Details
Details
- Reference
- bz30597
| Status | Subtype | Assigned | Task | ||
|---|---|---|---|---|---|
| Open | None | T25932 Allow use of semantic HTML5 elements in wikitext | |||
| Open | BUG REPORT | None | T32597 <section> tag name collides with HTML5 <section> tag |
Event Timeline
Comment Actions
Actually, inspired by the documentation, I think <sectioninclude> or <includesection> as complement to wikitext include tags seems to be even better way than my original suggestion.
(In reply to comment #1)
Why do we care? Wikitext is not html.
But you can enable HTML tags. And <section> is quite important one.
Comment Actions
HTML5's <section> is something I'd really like to support. Though at the same time I don't want to just break all the wikis currently who have already been using LST with the previous tag name.
It's a bit of a hack but I did think of one way to handle this.
In HTML you use: <section>...</section>
In LST you use: <section begin=... />
This is actually perfect. An opening/closing tag has no meaning in LST. And we don't support self-closing non self-closing elements in WikiText (if you write <div ... /> it just gets escaped and output as plaintext).
So it might be a tiny little parser hack but it would be possible (even if we recommend LST users to change their wikitext to use a new name) to make HTML5 section and LST section to work on the same wiki.
Comment Actions
(In reply to comment #3)
It's a bit of a hack but I did think of one way to handle this.
In HTML you use: <section>...</section>
In LST you use: <section begin=... />This is actually perfect. An opening/closing tag has no meaning in LST. And we
don't support self-closing non self-closing elements in WikiText (if you write
<div ... /> it just gets escaped and output as plaintext).
Ugh. Since when we don't support self-closing elements?
So it might be a tiny little parser hack but it would be possible (even if we
recommend LST users to change their wikitext to use a new name) to make HTML5
section and LST section to work on the same wiki.
It's quite easy to run bot on all wikis to rename the tag and then drop its original meaning in favour of HTML5.
Comment Actions
(In reply to comment #4)
(In reply to comment #3)
It's a bit of a hack but I did think of one way to handle this.
In HTML you use: <section>...</section>
In LST you use: <section begin=... />This is actually perfect. An opening/closing tag has no meaning in LST. And we
don't support self-closing non self-closing elements in WikiText (if you write
<div ... /> it just gets escaped and output as plaintext).Ugh. Since when we don't support self-closing elements?
I didn't know either. Until I saw someone add a parser test for that behaviour.
Though it looks like en.wp doesn't work that way right now. Either that's tidy screwing around
Either way <section /> in html is meaningless. There wouldn't be any harm in letting LST have it.
So it might be a tiny little parser hack but it would be possible (even if we
recommend LST users to change their wikitext to use a new name) to make HTML5
section and LST section to work on the same wiki.It's quite easy to run bot on all wikis to rename the tag and then drop its
original meaning in favour of HTML5.
That assumes that every single wiki using LST knows how to use bots and how to do this replacement properly. Bots are not simple to use. Frankly I know how to use them and it would be really annoying for me to have to do that if I still use LST.
Comment Actions
A simple pywikibot script could be run as a global bot on Wikimedia wikis--if it is a pywikibot script, others outside can use it as well when they upgrade to whatever version of LST drops support.
This is actually a really simple change if the social impetus exists (and I think it does since we should defer to HTML 5 on its tag names and makes the parser work Much Easier(TM)).
I think the self-closing tag use will just confuse end users. The naming of the tag on MediaWiki was never great to begin with since it doesn't indicate anything about the section.
Comment Actions
<section> meaning LST is widely used on Wikisource.
Is the tag <fragment> used anywhere else in HTML5?
Other possibilities...
<portion context=start id="heading1">
..content...
<portion context=end id="heading1"> which looks more like XML. Currently it's possible to overlap section begin and section end which although useful isn't good structuring...
Comment Actions
You could just as easily prepend "lst" to the name of the tag as in "lstsection", or something like "labeledsection" or "transcludedsection" (lengthiest name but I'm sure someone can come up with something else). Gets the point across.
Anyway, removing from Tidy. Self-closing HTML being invalid in some cases (HTML 5) is not a Tidy problem--and this is not HTML.
Comment Actions
I don't know how much of a concern length would be; we already have syntaxhighlight, which is only three characters shorter than transcludedsection. I also like the above suggestions of includesection or sectioninclude to parallel includeonly et al, though I don't have any firsthand experience with LST so there might be valid non-length-related reasons for none of these names to be preferable.
Comment Actions
They have nothing to do with include, they are start and end markers only. The inclusion or exclusion part comes with their transclusion methodology elsewhere be it either through #LST (directly) or through ProofreadPage (indirectly) extensions