Page MenuHomePhabricator

<section> tag name collides with HTML 5 <section> tag
Open, NormalPublic

Description

<section> tag name collides with HTML 5 <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

Details

Reference
bz30597

Event Timeline

bzimport raised the priority of this task from to Normal.Nov 21 2014, 11:56 PM
bzimport set Reference to bz30597.
bzimport added a subscriber: Unknown Object (MLST).
Danny_B created this task.Aug 27 2011, 6:14 PM

Why do we care? Wikitext is not html.

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.

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.

(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.

(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.

He7d3r added a subscriber: He7d3r.Jan 19 2016, 11:49 AM
Restricted Application added a subscriber: Aklapper. · View Herald TranscriptJan 19 2016, 11:49 AM
Danny_B removed a subscriber: wikibugs-l-list.
Izno added a subscriber: Izno.Aug 17 2017, 3:58 PM

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.

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.

<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...

Izno added a comment.EditedAug 16 2018, 9:01 PM

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.

Izno removed a project: Tidy.Aug 16 2018, 9:02 PM

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).

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.