I don't get the priority attribute, or the prefix tag. Almost everything else has been  tested and works quite well at least for infoboxes.

Notices

Perhaps  notices should behave more like meta-data, and never show up in the page much like how the title of a page doesn't. 

Sideboxes

Sideboxes may not really be necessary, they seem more like a miniature infobox. In fact all the markup is almost the same as an infobox, aside from template-name, and layout. In particular, the layout for infoboxes is generally dependent on localization although one could also change it to show-up anywhere else.  Perhaps a better option is to add features to the infobox that make the side-box obsolete.

The navbox  could use DPL like functionality to display items from categories, at least that's how I coded mine to work, and maybe include the ability to get page title automatically without parser functions.

Priority = In a notice with multiple possible <data> segments, which should be shown if (for example) the size of the box is reduced by something like "small = "? Or, which should be shown on mobile? In other words, what is primary information in the notice, and what is supplemental? Prefix = This is the "sect = " function of Amboxes. Crucial in a lot of cases.

You want to eliminate Message boxes and hatnotes? I don't understand. That's what "Notices" are.

Uh, no. This is far too common a use case, and Infoboxes and Side boxes are completely different in scope and design. Most commonly, they're used for supplemental information that you don't want to be recognized in an infobox, and aren't label / value pairs. Navboxes

That's going to be part of the datastore, most likely.

You want to eliminate Message boxes and hatnotes? I don't understand. That's what "Notices" are.

Sure, "Message boxes" could be part of flags. Although flags don't display in the middle or end of an article. Maybe flags could be designed to change/appear as one scrolls through the article content. The problem is that currently some readers see message boxes and hatnotes that are completely irrelevant to them, e.g. section stub.

This is far too common a use case, and Infoboxes and Side boxes are completely different in scope and design.

That's a good point. Hopefully it'll be easy to re-use the infobox markup for this.

Sure, "Message boxes" could be part of flags. Although flags don't display in the middle or end of an article. Maybe flags could be designed to change/appear as one scrolls through the article content. The problem is that currently some readers see message boxes and hatnotes that are completely irrelevant to them, e.g. section stub.

Flags are an application / organization of templates. Flags aren't a markup language. You still have to MAKE the templates WITH something, and each individual Flag is still associated with a wikitext or Lua Template. You're equating a recipe and a restaurant.

The suggestions about are about Template markup. While we can add metadata to the syntax to tell a Template how we want it to act as a Flag, we can't tell a Flag how to create itself.

Hopefully it'll be easy to re-use the infobox markup for this.

Or (as above) create a new markup, which is the point of this thread. I'm sure the existing under-the-hood-PHP code can (and should) be reused to interpret other tags. But cutting out and limiting options doesn't make much sense.

Flags are an application / organization of templates. Flags aren't a markup language.

Yes, I meant that it could be markup that is mainly in templates  used by Flags rather than template code that can end up anywhere. Hatnotes need to be differentiated from regular notices because they are meant for readers not editors.

Basically, message boxes for editors should never be part of the page markup and should not appear in searches or search engines. That is the difference between a draft (something missing in wikis), and a published document. A well written book, for example, will never contain any comment for editors, but a draft will.

Or (as above) create a new markup, which is the point of this thread.

In Wikipedia they claim it is used by 500000 articles, so it seems popular. But adding more markup is always something to consider carefully and in most cases making a generic tag is better than having so many different ones, especially when numerous bugs start showing up.

One thing I haven't seen brought up - instead of wrapping HTML5 with XML syntax, why not just enable HTML5 in wikitext and let users improve things along side whatever Wikia produces? Navbox templates could be converted to use nav tags much quicker than it would take for an appropriate XML syntax to be proposed, discussed, implemented and then rolled out.

I think that deliberately allowing lots of html5 tags is a mistake. For one thing, it makes the awful assumption that wiki editors are hmtl5 literate and will use these properly. That's what caused the problem in the first place. A lot of these html5 tags come with inline styling that will continue reinforcing the problem. Some of these metatools can simply be created and changed using a GUI, or by storing page metadata separately from the page (e.g storing notices / editor notes about a specific paragraph).

Having these widely used components (notice, navbox, et al) built  by editors as html5 defeats the purpose, and prevents a uniform way of developing, and improving them. For example, infoboxes often have half a dozen or more meta-templates and breaking one element in a related template can break them all.

The portable infobox prevents this by  creating an infobox in a single page, by using semantic tags instead of the curly brackets soup, and by doing some background processing (e.g {{#if). This is something that an aside / figure / footer wouldn't be able to do without a lot of template / css and maybe JS hacks)

Having everything in wikitext is the wrong path. 

 

On the contrary, not having access to HTML5 has caused this problem. We have been unable to create content that is truly accessible or semantically structured. The reason we have vast amounts of outdated HTML is because MediaWiki only allows HTML4 tags. There's been clean up initiatives over the years to eradicate use of font, s, etc. and move the required formatting to CSS, but access to the new tags could alleviate the issues even further.

I'm not sure where the assertion that HTML5 tags come with new styling has come from - HTML5 was designed to be separate from styling. The only styles that come with it are those your browser supplies which are usually limited to some padding, margins and whether it's an inline or block element.

Only the poorly designed templates have the structure you're talking about. No sane editor designs an infobox to be made up of meta templates like that. Splitting certain logic up into other templates/modules is common practice but I've yet to come across something that would break from changing a div to a nav, aside, etc.

On the contrary, not having access to HTML5 has caused this problem.

I doubt that. The problem comes from people attempting to make wikitext and html5 into a programming language. They are both markup languages meant to only format text without programming logic (while parser functions violated that rule). Anyway, I'm sure whitelisting some html5 tags would certainly be useful, but not in cases where they are used to create new page components.

I'm not sure where the assertion that HTML5 tags come with new styling has come from - HTML5 was designed to be separate from styling

The inline style is a global attribute, so it ("style = xxx") can be used in any html tag [1].  Ultimately the concept of infoboxes doesn't exist in html, it was inefficiently created by editors with a messy mix of parser functions, templates, and css.

No sane editor designs an infobox to be made up of meta templates like that.

Perhaps no single sane editor would make such a thing, but a group of sane people can certainly create insane inefficient monsters :

• http://fallout.wikia.com/wiki/Template:Infobox?oldid=2146434, 
• https://en.wikipedia.org/w/index.php?title=Template:Taxobox/core

They could certainly break because they are unbalanced templates which sometimes store an opening div in one template, and a closing one in another. One common example is a scrollbox.

I guess this just kinda died out and nothing became of it huh? It's a shame but maybe it was just a boot too early. I was surprised that even Wikipeida only looked to do something about it as recently as 2018.
Wikimedia:Reading/Web/Projects/Mobile_Page_Issues

I'm hoping that after the implementation of UCP that the focus will then switch to portability and how to make a conststant browsing experience experience across both mobile and desktop platforms.