FANDOM


  • Most of these are transplanted from Community Council, with permission.

    Fandyllic wrote:

    Group styling

    Need group styling like: <group grouptheme="bigfatgroup"> or <group grouptheme-source="whichgroup">

    Non-rendering data

    I also want data that doesn't render anything: <data source="thing" norender="true" /> ...or maybe... <data source="thing" render="false" /> The reason I want a data tag that doesn't render is because the value would only be used to render if another data value is used or for deciding what to render via ifs.

    Here's an example:

    <data source="unique-eq">
      <format>[[Unique-Equipped]]
        {{#if:{{{unique-type|}}}
         | {{colon}} {{{unique-type|}}}}}
         {{#ifexpr: {{{unique-eq}}}-1 |  ({{{unique-eq}}}) }}
        }}</format>
    </data>
    

    In this case, I want structured data to be maintained for unique-type, but only if unique-eq is used. If I create something like: <data source="unique-type"></data> to capture the values for unique-type, it will render a <div> for it, but not where I want it.

    Alternative Layouts

    I'd also like to see possible structures like:

    Title Pusheenreading
    Data
    Data

    ...or this...

    Pusheenreading Title
    Data
    Data
    FishTank wrote:

    Collapsible groups

    <group collapsible="default|collapsed|expanded|off">

    Lists and Separators

    <data separator=";" list="horizontal">

    Microdata and Data Structure (typing and masks)

    <infobox itemtype="http://schema.org/Book">
      <title source="name" itemprop="name">
      <image source="cover" itemprop="image">
        <format type="file" />
      </image>
      <data source="ISBN" itemprop="isbn">
        <format type="number" maxlength="13" mask="###-#-##-######-#" />
      </data>
    </infobox>

    "itemtype" and "itemprop" above in that example are HTML5 properties that can be passed through the Portable syntax into the output. They're called microdata. They're invisible to users most of the time, but they tell a semantic processor (or a search engine) what kind of data is actually being presented (for example, it clearly identifies the example given as a book, and not just random name/value pairs). There's a collaborative project by Google, Microsoft, Yahoo and Yandex called http://schema.org that standardizes quite a bit of it, but there's plenty of room for expansion and custom types. The downside to using it (as it was explained to me), is that syndicating that data to search engines makes the results more accurate and raises their SEO, but also tends to drop PageViews because that data gets recontextualized and turned into widgets in the search results (ultimately meaning less revenue for Wikia if the users don't actually go to the page).

    Wikia is trying to figure out a way around that issue, but it's still not a bad idea to have the syntax baked into Portable for when they do. It also, coincidentally, makes for good CSS selectors for those who want to style only certain elements, and it should give the semantic datastore something concrete to work with when looking for data. Like this.

    (Referring to above) Fandyllic wrote:
    I guess I'm not a huge fan of the naming conventions, but they aren't the worst.

    Maybe:

    <infobox datascheme="Schema:Book">
      <title source="name" datatype="name">
      <image source="cover" datatype="image">
        <format filetype="file" imagevariant="bitmap"></format>
      </image>
      <image source="publisherlogo" datatype="image">
        <format filetype="file" imagevariant="vector"></format>
      </image>
      <data source="ISBN" datatype="isbn">
        <format stringtype="number" maxlength="13" mask="###-#-##-######-#" ></format>
      </data>
      <data source="ebook" datatype="boolean" />
      <data source="hardcover" datatype="boolean" />
      <data source="softcover" datatype="boolean" />
    </infobox>
    Technobliterator wrote:

    Special:Portability/Defaults

    For PortableInfoboxes, and future portable templates, I think a good idea would be to implement a MediaWiki page that allows users to add default child tags/attributes to some of the tags. This just means applying some default options set to some of the tags.

    As an example, for the <group> tag, currently if a wiki always wanted their groups to be collapsible and collapsed by default, they would have to set <group collapsible=collapsed> (although I know that the "collapsible" child tag doesn't exist yet) to every single use of the group tag, aside from the few that don't require it. However, if there were a MediaWiki page, such as "MediaWiki:PortableInfoboxes", where communities could instead add group = collapsible or something, this would save a lot of code added to all these pages.

    I'm suggesting this because as far as I can tell, once PortableInfoboxes are really finalised in their next updates, these defaults will really be the only thing that infobox metatemplates will have over them. I think it would be a good idea if PortableInfoboxes were more customizable and controllable across the site with something like this.

    Peteparker wrote:
    There's so many threads about Portable Infoboxes, I'm not sure this is the right one for this...

    As a preamble, I'm relatively inexperienced with CSS. In most templates I've made, I just include the styling there.

    So in the PI, I'm not able to easily find the default styling the portable-infobox starts with. Most often, I know what I want to change to, but have a hard time finding everything I have to undo to get a clean start.

    My second biggest issue is attempting to make changes to styling midway through the infobox.

    Say I want the first half of the labels to be text-align:left and the last half of the data labels to be text-align:center. Right now, the only way I can figure out how to do that is to set it for either the entire pi structure on the site, or for the entire theme of that infobox, and then add styling to a div or span tag inside the format tag on the every single label I want different.

    Using tags inside a format tag just for styling purposes feels silly. I'd love to simply be able to apply styling to the format tag itself, along with the label and header tags as well, especially if we don't get a way to specify themes for different sections.

    Another way this could be done has been specified here already, allowing groups to have their own themes. I believe groups have some specific functionality to not show the entire group if none of the fields are supplied by the template invocation, so it's probably not a solution for all the time.

    Keep the suggestions coming on this thread!

      Loading editor
    • Interesting suggestions I particularly like the idea of structured data and validation, in addtion to the list syntax. Anyway my suggestion is here Thread:2487.

        Loading editor
    • I would like to be able to add explicit ids and classes to these elements and have them be passed through to the HTML as it is generated. Group theme is fine (and a good thing), but when you want to change individual elements it would be helpful to explicitly say which element(s) you want to change. Being able to add ids and classes would give us pretty much unlimited control over how we want the infoboxes to look, both on desktop and on mobile (assuming we ever get to apply custom CSS to the mobile skin).

      The other suggestion that I have is to allow <default> values to be passed through <format>. I suppose there may be some cases why that wouldn't be a good idea, but generally speaking I would expect most people to want their default values to be formatted similarly to any user-generated input.

        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
      1. Collapsing is already done.
      2. Non-rendering data is already possible exactly as described, unless I misunderstood it.
      3. Alternative layouts are interesting, but not widely used I presume. Those two layouts can possibly be done with a little bit of css magic.
      4. I don't think we need group styling specifically, what we need is custom classes to make styling less painful.
      5. A CSS template (or skeleton) is a good idea, we should create a generic one in this wikia, so we and others have starting point (especially with Mentoring). It could also be available in some GUI, e.g. Infobox Preview.
      6. Special:portability is a good idea, although staff will still have to investigate and decide what it should contain. It could be a tool like the admin dashboard, but one that could also be visible to regular users, with some limitations.
        Loading editor
    • Fix the converter or kill it with fire. ;-)

        Loading editor
    • Fandyllic wrote:
      Fix the converter or kill it with fire. ;-)

      I often find it strange when people claim that the converter doesn't work. I took two random infoboxes and converted them:

      Both were converted just by pressing a button, and although it still requires user intervention to make it look the way people may want, it greatly reduces the work related to adding the markup for each of these.

      I suppose it may be possible to improve by either looking at the HTML dom, and extracting the fields from there rather than wikitext or using a mix of both. There are many ways to improve it, but all of them start with understanding in what exact cases it fails with clear examples, e.g. user expectation vs reality.

      Perhaps I have low or realistic expectations or I simply misunderstand how people want these converted?

        Loading editor
    • Personally, I've never had a problem with the converter, and always found it fairly easy to use. I never personally use the "approve draft" thing, and just copypaste the draft over the original infobox table instead, though.

      As far as improvements for infoboxes at this point go, I think other than horizontal rows within collapsible groups, and possibly the ability for groups to have their own different themes, nothing major is really needed anymore other than the minor stuff. I'd kind of like tabbers outside of infoboxes to work better on the mobile skin, but that's a smaller issue.

        Loading editor
    • Currently trying to target individual fields with css is a nightmare, when it really shouldn't be that hard. It is telling how much is already devoted to this at w:c:dev:Portable infoboxes/Tips and tricks#CSS. But those methods are really hacks and don't work reliable.

      Putting divs insdide format tags is often too late, one can't target the parent div generated by the PI that way.

      All the n-th of type approaches break down easily if some content is optional.

      I wouldn't call this "nothing major" - such things usually lead to non-acceptance (infoboxes look broken after conversion) or abominations (a bit akin to table layout) by misusing certain features to be able to get the desired result.

        Loading editor
    • Can you show me an example of you having this issue? I've had no issue with doing that simply using the right divs, see: Dressphere fields on linked page.

        Loading editor
    • Changing the color in the example isn't a problem, trying to undo padding from the surrounding div is - also I notice in the example that the blue boxes are still partly yellow, not sure if that is intended, but that's the effect of not targeting the surrounding div generated by the PI.

      Examples for issues at w:c:fallout:Kid in a Fridge:

      • The small text over the title should get the title background and not get the general css for data fields (it isn't always there, so targeting the first child doesn't work, sometimes there is small text below the title too). Currently this is solved by using a data field (so it doesn't get the title fontsize css), putting all other data fields into groups and targeting group-less data fields (I call that a hack, and it wasn't me). I really want to distinguish text in the title from general text somewhere else in the box, but are stuck with the few tags PI offers me, not being able to distinguish the surrounding divs further.
      • The footer image resides inside a data fields because footers can be either text or images and the infobox doesn't know which. There is a general inherited 2 pixel padding for data fields in infoboxes, that is unwanted here. I can't target the last div in the infobox, because the footer isn't always there. Currently this is alleviated a bit by adjusting the position of the inner div to the left - but this isn't really clean.

      It can now be argued that some design decisions of the infobox weren't optimal way back then, but this isn't going to help. And it isn't really about finding clever ways to get the result, but having a clean, reliable way. Using <data source="text"><format><div class="foo">{{{text|}}}</div></format> is really a clutch throwing a heap of markup at something that could be just <data source="text" class="foo" />.

        Loading editor
    • Undoing the padding is very easy with CSS, but because it's only 5px in the example I linked, I haven't done it, since it's just a non-issue.

      Looking at the example, I know what you mean, because I've worked with templates from that wiki in the past, so I can identify the problems, though they don't necessarily hurt readability. The issue with the small text over the title could more easily be solved using the navigation tag, and coloring the navigation in with title colors using the CSS. The 2px padding in the footer can very easily be removed with CSS, and if there is always a footer used, even without an additional div.

      Even though I'd love a class parameter for the tags, I don't see how this is a deal-breaker that, as you said, "usually lead[s] to non-acceptance".

        Loading editor
    • Dessamator wrote:

      Fandyllic wrote:
      Fix the converter or kill it with fire. ;-)

      I often find it strange when people claim that the converter doesn't work. I took two random infoboxes and converted them:

      Both were converted just by pressing a button, and although it still requires user intervention to make it look the way people may want, it greatly reduces the work related to adding the markup for each of these.

      I suppose it may be possible to improve by either looking at the HTML dom, and extracting the fields from there rather than wikitext or using a mix of both. There are many ways to improve it, but all of them start with understanding in what exact cases it fails with clear examples, e.g. user expectation vs reality.

      Perhaps I have low or realistic expectations or I simply misunderstand how people want these converted?

      You got lucky.

        Loading editor
    • Fandyllic wrote:

      Dessamator wrote:

      I suppose it may be possible to improve by either looking at the HTML dom, and extracting the fields from there rather than wikitext or using a mix of both. There are many ways to improve it, but all of them start with understanding in what exact cases it fails with clear examples, e.g. user expectation vs reality.

      Perhaps I have low or realistic expectations or I simply misunderstand how people want these converted?

      You got lucky.

      Let's say that not everyone shares that experience with the Migration tool, and it's not always accurate in determining the right elements. Some staff members share each of your experiences, dependent on the types of communities they work with. This is an area where the engineers are constantly trying to improve, but they don't release updates to the Migration tool very often. Better things are always in the works, and you will see better tools for Infobox crafting sooner rather than later.

        Loading editor
    • FishTank wrote:
      Fandyllic wrote:

      Dessamator wrote:


      I suppose it may be possible to improve by either looking at the HTML dom, and extracting the fields from there rather than wikitext or using a mix of both. There are many ways to improve it, but all of them start with understanding in what exact cases it fails with clear examples, e.g. user expectation vs reality.
      Perhaps I have low or realistic expectations or I simply misunderstand how people want these converted?
      You got lucky.
      Let's say that not everyone shares that experience with the Migration tool, and it's not always accurate in determining the right elements. Some staff members share each of your experiences, dependent on the types of communities they work with. This is an area where the engineers are constantly trying to improve, but they don't release updates to the Migration tool very often. Better things are always in the works, and you will see better tools for Infobox crafting sooner rather than later.

      I think the mistake here was automating it too much. It would be quite simple to add an intermediary dialog like the one used for template classifier to ask users what fields belong to certain values. This would be especially useful in cases where it fails with blank results.

      For one thing, most lua based infoboxes will certainly fail miserably because often there is no template metadata to extract from it, or it is incredibly hard to do. Although one option would be to follow the backlinks (whatlinkshere) from those templates and extract their parameters (something they already do for the infobox previewer).  

      Anyway, given that the output is in a structured format. Nothing stops volunteers from developing their own conversion or editing tools. 

        Loading editor
    • Since default is already widely used, I'd like to propose <default_value>. Currently, default isn't subject to <format> which in my eye is a POLA violation, but maybe it makes sense to others. To fix it, I'd like <default_value> which is then used as input for <format> so I don't have to maintain two tags for consistent output.

        Loading editor
    • There's no need to do that. You can just use a <default> tag and have a parameter pipe in it, like {{{value|default}}}.

        Loading editor
    • Lytora wrote:
      Since default is already widely used, I'd like to propose <default_value>. Currently, default isn't subject to <format> which in my eye is a POLA violation, but maybe it makes sense to others. To fix it, I'd like <default_value> which is then used as input for <format> so I don't have to maintain two tags for consistent output.

      I actually mentioned exactly that issue when the <default> tag was introduced. But most other "beta" testers claimed that both default and format were needed. It might be simpler to just introduce an attribute rather than a tag, e.g.:

       <default value="true">Cash kings</default>

      Anyway, the default tag can be used to format content anyway, so currently there may not be any benefits to introducing more complex code. Besides, the infobox GUI builder will  probably reduce (if it is ever launched)  the need to know the markup, so it won't be a major issue.

        Loading editor
    • As an attribute I'd use format="true".

        Loading editor
    • Lytora wrote:
      As an attribute I'd use format="true".

      As I noted previously, that was suggested, and not implemented for whatever reason. See w:c:Thread:841717#282 for the history of that tag.

        Loading editor
    • Great suggestion! I'd say <default format="true" /> (or an equivalent) makes the most sense.

        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.