Fandom

Infobox Wikia

[Suggestion] Portable Elements, proposal syntaxes (beyond Infobox)

  • Notices

    The ideal HTML element for this to render as is (surprisingly) <figure> ("Specifies self-contained content, like illustrations, diagrams, photos, code listings, etc."). This term and syntax is for hatnotes, message boxes, and the thin variants like Asbox. I've included some categorization, some TemplateData-like syntax, alternate versions listings for redirects and sections, and a hint to Flags.

    <notice theme="editing" theme-source="mbox-type" layout="mbox(|hatnote|thin)">
       <data priority="main" source="issue">
          <default lang="en"> has serious editing issues.</default>
          <prefix source="sect">
            <default lang="en">This article</default>
            <hint lang="en">What has issues?</hint>
          </prefix>
          <format line-break="after">{{{sect}}}{{{issue}}}</format>
          <hint lang="en">What is wrong?</hint>
       </data>
       <data source="guideline">
          <default lang="en">Please fix them.</default>
          <hint lang="en">What guidelines apply to fix this?</hint>
       </data>
       <image layout="left" source="icon"><default>File:Editing</default></image>
     
       <category namespace="Main">Articles needing editing</category>
       <template-category lang="en">Editing Notices</template-category>
       <template-name priority="primary" lang="en">Template:Editing</template-name>
       <template-name priority="alternate" lang="en">Template:Copyedit</template-name>
       <template-name priority="portion" lang="en">Template:Copyedit_section</template-name>
    </notice>

    Side boxes

    These are fairly minimal to begin with, but would either be <details> or <aside> in HTML5. Since <details> is not widely supported, <aside> it is.

    <box theme="" theme-source="" collapsible="expanded(|collapsed|off)" layout="right(|left)">
       <navigation />
       <image layout="left" source="image"><default /></image>
       <data source="" />
     
       <template-name priority="primary" lang="en">Template:AdditionalInfo</template-name>
    </box>

    Navboxes and Sidebars

    Navboxes and Sidebars are virtually the same thing, layed out either horizontally or vertically. Either way, they'd be <nav> in HTML5. This method uses <group> as a much better way of nesting Navboxes. Note that there's also additional attributes to "format" and the addition of collapsibility.

    <navbox theme="" theme-source="" layout="wide(|left|right)" collapsible="collapsed(|expanded|off)" navbar="off(|show|plain)">
       <title />
       <header />
       <navigation />
       <image layout="right" />
       <group collapsible="collapsed(|expanded|off)" evenodd="off(|swap|even|odd)" class="">
          <header>...</header>
          <group collapsible="collapsed(|expanded|off)" evenodd="swap(|even|off|off)" class="">
             <header>...</header>
             <data>
                <!- There should be a way to pull this from a Lua or JSON table in "source" ->
                <default>Item 1; Item 2; Item 3</default>
                <format list="horizontal" separator";" />
             </data>
          </group>
       </group>
     
       <template-name priority="primary" lang="en">Template:Navbox_genericexample</template-name>
    </navbox>
      Loading editor
      1. Isn't the notice template covered by the flags concept?
      2. I think that a lot of the ground work for navboxes has already been created. At this point it is mostly a matter of styling it correctly.
      3. What is the purpose of <template-name>, is it to allow things like (v.d.e)?
      4. What the hint is for, hovering over text?

      I'm not sure why you need template-category and category. But in any case, it would be much better to merge those two, and have a type attribute to indicate their purpose.

      I also see that you have the notion of localizing messages. It could be interesting to store them in a separate template, and automatically display them based on the user's browser language.

        Loading editor
      1. I think you may misunderstand the Flags concept. Flags are a way to manage and apply notices. Flags are not a method of constructing or designing notices. They're still Templates that are being invoked. The syntax above complements and augments templates to hint to the Flags management system what the templates are doing. It's the difference between sheet music and a CD player.
      2. Some groundwork for Navboxes has been laid; as you know, the results are inconsistent and suffer from all the same problems that Infobox has in terms of Portability. The wikitext template syntax for nesting Navboxes is tricky and hard on the eyes. Nesting them in Lua is nearly impossible. Styling needs to take a backseat to cohesive structure.
      3. Exactly. And categorization and redirects.
      4. Hint is for the benefit of Flags and the VisualEditor. Think of it as a viable alternative to TemplateData.

      Template Category you'll be hearing more about soon; but if it helps, think of it this way: All infobox templates could be in Category:Infobox, but the articles that contain those infoboxes surely won't. Category is analogous to the cat functions in Message boxes.

      And given how closely some templates are shared among sister language communities, i18n just makes sense.

        Loading editor
      1. Interesting, maybe we'll have an noticebox builder too. Should be easy to develop even without official Wikia support as long as we have the appropriate markup.
      2. Yes, I meant that they can mainly use the code created for portable infoboxes and inherent most of its functionality for this purpose.
      3. I think that's possibly something they can obtain automatically without being specified, or they could always backport the getTitle functionality([1]).
      4. Sounds like a good idea, it seems to be inline with some sort of template meta-data extension they are developing according to a recent announcement.

      I think that the best way to support i18n is using dev.wikia. We already have global modules, and it is easy enough to simply have a sort of mw.loadData("Module:MessageBoxLocalization/en"). That will reduce the duplication of effort, and make them more consistent throughout wikias. For those that don't need it or want it, it could just use its default values.

        Loading editor
      1.  "Should be easy to develop even without official Wikia support as long as we have the appropriate markup." I have no idea what you mean by this. What would be the point of such an endeavor unless you're building a parser extension in PHP that is unlikely to be used by Wikia?
      2. Agreed.
      3. It's not so easy to do, even with an unlikely backport, and better left explicit without the guesswork.
      4. You're catching on.

      I don't see how calling dev for every i18n function rather than a local parse is going to help matters, and I can't think that most admins would consent to drawing all of their localizations from a central repo. Things would slow to an absolute crawl, and Lua doesn't work for every solution.

        Loading editor
      1. I meant that they may build the  <navbox> parser function, and not create any navboxbuilder. Once that's done anyone can create a Gui builder for it using Javascript.

      How exactly will they share code if each wikia maintains its own library of i18n strings? 

      If I find an error in a i18n string will I go through every single wikia and fix the problem?

      There's currently no way for sister wikias to share code or templates. The only thing they can currently share is media files. Unless wikia is planning to introduce something to facilitate that, I don't see how it will work.

      Depending on the markup, they could add a way to parse the whole module once. But the best alternative would be some sort of Json file.

        Loading editor
    • Much simpler. Copy/pasting Templates. Portably. :-) These are templates only likely to be shared among 10, at most, wikias. No template is likely to be shared from a central repo like that.

        Loading editor
    • I think it is a chicken or egg problem. People don't use such templates because they aren't prevalent or they don't know it exists.

      If you look at community central, you'll note two patterns. Most people want a similar solution and most copy paste it from one wikia to another taking with them all the bugs that already exist. You'll also note that user templates are probably transcluded in hundreds if not thousands of wikis.

      Another example is the starter.wikia, in which there are a lot of templates that get pushed to new wikias (along with their dependencies) simply because there was no other way of doing so efficiently. I doubt that there are many people willing to reinvent the wheel when it works so well already.

      Wikipedians have been begging for this functionality for possibly a decade. We have it here, but it is underused because staff hasn't led an effort to make this more efficient.

        Loading editor
    • Now that we've got a couple more eyes on this and it's had some time to brew, any other thoughts or suggestions?

        Loading editor
    • 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.

        Loading editor
    • Dessamator wrote:
      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.

      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.

      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. 

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

      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.

      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

      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.

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

        Loading editor
    • 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.

        Loading editor
    • Dessamator wrote:
      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.
        Loading editor
    • 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.

        Loading editor
    • Cqm

      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.

        Loading editor
    • Cqm wrote:
      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. 

       

        Loading editor
    • Cqm

      Dessamator wrote: 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.

      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.

        Loading editor
    • 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 :

      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.

        Loading editor
    • A Fandom user
        Loading editor
Give Kudos to this message
You've given this message Kudos!
See who gave Kudos to this message

Ad blocker interference detected!


Wikia is a free-to-use site that makes money from advertising. We have a modified experience for viewers using ad blockers

Wikia is not accessible if you’ve made further modifications. Remove the custom ad blocker rule(s) and the page will load as expected.