Re: Table formatting at http://docs.webplatform.org/wiki/svg

Thanks Renoir,

You'll want to find the php code currently being used by
Special:PrefixIndex to see if you can use their search function but then
(a) group/nest the results based on the file path hierarchy
(b) create list output instead of table
(c1) (maybe) filter out so only the next level down in the hierarchy is
shown
(c2) (even better) create an expandable nested list representing the entire
file path hierarchy

However, you do not have to drop everything and do this, I think we can use
the other solutions for the interim.

To Doug's suggestion:
For some top-level pages manual indexes might be an alternative to
automatic ones, but that brings up the problem of keeping things up to date
when pages get moved or renamed.  And it's just a lot of messy code when
you're listing dozens of subpages.

However, one thing I would like to do manually is to make sure that every
page has the "Path" and "Page Title" properties set even if they don't have
a page template and form.   I'll add it to the QA Sprint checklist: it's
just a matter of inserting the {{Page Title}} template to the top of each
page.  Once that's done, I can work on trying to get semantic mediawiki to
behave, as an alternative to Renoir's approach.

I still think it's worth tweaking the CSS now to tidy things up while we're
working, though.  We can discuss on the telecon today.

Thanks for the feedback,
Amelia





On 3 June 2014 08:40, Renoir Boulanger <renoir@w3.org> wrote:

> Hi Amelia, Doug—
>
> My mother tongue is PHP.  Let me see how we can get to make the required
> markup from PHP directly, there must be a way to do. I might even be
> able to perpare some views that are intensive (e.g. list views) and send
> them to memcache —if they aren’t already.
>
> I’ll spend some time with you guys to address the coding part.
>
> Renoir~
>
>
> On 2014-06-03, 9:24 AM, Doug Schepers wrote:
> > Hi, Amelia–
> >
> > Thanks for doing this!
> >
> > I hate to mention this, but should we perhaps simply make these pages
> > manually, rather than use a Semantic MediaWiki query? That way we
> > could control the output better (e.g., trim the page names).
> >
> > Regards-
> > -Doug
> >
> > On 6/3/14 1:42 AM, Amelia Bellamy-Royds wrote:
> >> I spent some time this evening exploring the options for this issue.
> >>   There's no easy solution, unfortunately. For now, we should make it a
> >> little nicer with CSS.  I haven't got myself set up to edit the CSS on
> >> github yet; if someone else is able to do that please volunteer!
> >>
> >> The horrendous tables that currently exist come from
> >> http://docs.webplatform.org/wiki/Special:PrefixIndex
> >> The content created by that page is then just plunked into the referring
> >> page as-is.
> >>
> >> That's a problem because the formatting of results from special search
> >> pages are not controlled by any templates we can edit, it is part of the
> >> Mediawiki core functionality.  It is apparently possible to create a
> >> custom "special page" by writing the actual PHP code [1].  I might try
> >> that out eventually, but it's not something I'll have time to do any
> >> time soon.  If any PHP experts want to tackle it, you'd be welcome.
> >>
> >> The approach I hoped would work was to use Semantic Mediawiki's search
> >> function [2], which allows various result formats including custom
> >> templates.  The problem with that is that you can only search by
> >> Semantic Mediawiki properties or categories, not by page names/prefixes.
> >>   This issue has been recognized in previous WebPlatform Docs attempts
> >> to create category listing templates [3], and most of the page templates
> >> now explicitly set "Page Name" and "Path" properties for each page so
> >> that the values can be used in a query.  However, not all pages have
> >> these properties set; if they don't, they won't show up in the search
> >> results.  That excludes a lot of imported pages (including tutorials
> >> from MDN and reference docs from MSDN) as well as many custom concept or
> >> category pages that don't use page templates.
> >>
> >> Eventually, all pages should have these properties set and inline
> >> queries might work, but not now.  Even then, it won't allow fancier
> >> layouts like nested hierarchies unless we explicitly set categories or
> >> semantic properties for each level in the hierarchy.
> >>
> >> The final option: use what we've got, but make it less ugly.  The
> >> following CSS would turn the search result tables into a bulleted list:
> >>
> >> table#mw-prefixindex-list-table{
> >>
> >>  1. display: block;
> >>
> >> }
> >> table#mw-prefixindex-list-table td {
> >>
> >>  1. display: list-item;
> >>  2. list-style-position: inside;
> >>  3. background: transparent;
> >>  4. color: inherit;
> >>  5. border: none;
> >>
> >> }
> >> table#mw-prefixindex-list-table tr {
> >>
> >>  1. display: inline;
> >>
> >> }
> >>
> >> Output:
> >>
> >>
> >>     Index of all SVG topics
> >>
> >> svg/attributes <http://docs.webplatform.org/wiki/svg/attributes>
> >> svg/attributes/alignment-baseline
> >> <http://docs.webplatform.org/wiki/svg/attributes/alignment-baseline>
> >> svg/attributes/baseline-shift
> >> <http://docs.webplatform.org/wiki/svg/attributes/baseline-shift>
> >> svg/attributes/clip-rule
> >> <http://docs.webplatform.org/wiki/svg/attributes/clip-rule>
> >> svg/attributes/color-interpolation-filters
> >> <
> http://docs.webplatform.org/wiki/svg/attributes/color-interpolation-filters
> >
> >>
> >>     svg/attributes/dominant-baseline
> >> <http://docs.webplatform.org/wiki/svg/attributes/dominant-baseline>
> >> svg/attributes/enable-background
> >> <http://docs.webplatform.org/wiki/svg/attributes/enable-background>
> >> svg/attributes/fill
> >> <http://docs.webplatform.org/wiki/svg/attributes/fill>     (etc.)
> >>
> >>
> >> I'm sure a CSS expert could even wrap the list into columns in browsers
> >> and screen sizes that support it, but either way it's an improvement
> >> over the current look.
> >>
> >> Amelia
> >>
> >> P.S. to renoirb: Don't blame me for the id-based CSS selectors; that's
> >> the only unique identifier on the content spewed out by MediaWiki!
> >>
> >> [1]: http://www.mediawiki.org/wiki/Manual:Special_pages
> >> [2]: http://semantic-mediawiki.org/wiki/Help:Inline_queries
> >> [3]:
> >>
> http://docs.webplatform.org/wiki/WPD:Implementation_Patterns/Templates#Summaries.2C_Page_Title.2C_and_API_Name
> >>
> >>
> >>
> >>
> >>
> >>
> >>
> >>
> >> On 12 May 2014 10:33, Amelia Bellamy-Royds
> >> <amelia.bellamy.royds@gmail.com <mailto:amelia.bellamy.royds@gmail.com
> >>
> >> wrote:
> >>
> >>         And think about what's possible given the constraints of
> >>         Mediawiki??
> >>
> >>
> >>     One possibility, as opposed to trying to fix everything with CSS, is
> >>     to replace the default mediawiki index with a templated inline query
> >>     [1].
> >>
> >>     With a query we should be able to create a list with just the
> >>     individual page title (instead of the path).  You can also select an
> >>     output format: bulleted list, multi-column list with alphabetical
> >>     groupings like the MDN example above, or a table of page names +
> >>     other information (e.g., summaries).
> >>
> >>     It might even be possible to create nested lists to represent
> >>     sub-categories so that the information from the path structure isn't
> >>     lost, or to filter out sub-categories altogether.
> >>
> >>     However, it won't be trivial to come up with a good template for the
> >>     query that can then be popped into every index page with pleasing
> >>     results.  We'd probably want the template to switch between two or
> >>     three different index styles, depending on how many entries there
> >>     are in the index and whether there are sub-hierarchies.
> >>
> >>     If people have a chance, look at the inline query documentation to
> >>     get an idea of what's possible, then we can discuss what we want to
> >>     achieve.
> >>
> >>     [1]: http://semantic-mediawiki.org/wiki/Help:Inline_queries
> >>
> >>     Amelia
> >>
> >>
> >>
> >>
> >>     On 12 May 2014 10:00, Jen Simmons <jen@jensimmons.com
> >>     <mailto:jen@jensimmons.com>> wrote:
> >>
> >>         Yes, this has been driving me insane, too. The CSS styling of
> >>         the tables makes it worse, and I think we can reskin the tables
> >>         to make all tables easy to understand. Having the first column
> >>         of this table be dark brown while the rest is a light color
> >>         seems to convey that the first column is something special — but
> >>         it's not.
> >>
> >>         In fact, I'm not sure why this is a table at all. It's not a
> >>         data set. It's a long list of links. The HTML should be a list,
> >>         not table. Will mediawiki let us make it a list?
> >>
> >>         And visually, it would be much better as simple columns of
> >>         links. Like at MDN:
> >>         https://developer.mozilla.org/en-US/docs/Web/CSS/Reference
> >>
> >>         Inline image 1
> >>
> >>         I honestly think that designing better doc list landing pages is
> >>         key to making a successful project. If someone clicks on "CSS"
> >>         or "SVG" or "APIs", they should get to a useable landing page.
> >>         When instead, people see things like what Rob pointed to, it
> >>         erodes their confidence in the content on the site.
> >>
> >>         Can we talk about this in a meeting? And think about what's
> >>         possible given the constrains of Mediawiki??
> >>
> >>         Jen
> >>
> >>         Jen Simmons
> >>         designer, consultant and speaker
> >>         host of The Web Ahead
> >>         jensimmons.com <http://jensimmons.com>
> >>         5by5.tv/webahead <http://5by5.tv/webahead>
> >>         twitter: jensimmons <http://twitter.com/jensimmons>
> >>
> >>
> >>
> >>         On Fri, May 9, 2014 at 12:15 AM, Doug Schepers <schepers@w3.org
> >>         <mailto:schepers@w3.org>> wrote:
> >>
> >>             Hi, Rob–
> >>
> >>             Thanks for chiming in.
> >>
> >>             This is a reasonable request, and creating at issue at
> >>             project.* would be great.
> >>
> >>             Sadly, Semantic MediaWiki is not very powerful in these
> >>             sorts of things, so I wonder what we can do to fix it
> >>             (unless we do it manually). This might have to wait until we
> >>             move to a new CMS in the hopefully-not-too-distant future.
> >>
> >>             Regards-
> >>             -Doug
> >>
> >>
> >>             On 5/8/14 11:59 PM, Rob^_^ wrote:
> >>
> >>                 Hi,
> >>                 ref: http://docs.webplatform.org/__wiki/svg
> >>                 <http://docs.webplatform.org/wiki/svg>
> >>                 attached please find a screenshot of the above page
> >>                 showing the table of
> >>                 Index of all SVG topics.... which overflows the text
> >>                 content in all
> >>                 browsers....
> >>                 Can I raise a change request to have this corrected...
> >>                 (the text
> >>                 overflow in the table?)...
> >>                 I tried using the Developer tools to apply a style rule,
> >>                 but it seems to
> >>                 me that the only solution is to abbreviate the text
> >>                 content... eg... use
> >>                 attributes i/o svg/attributes....
> >>                 I am unfamiliar with mediawiki, so please forgive me if
> >>                 this is not the
> >>                 appropriate avenue to make a change requests.
> >>                 Would http://project.webplatform.__org/
> >>                 <http://project.webplatform.org/> be the appropriate
> >>                 place to post?
> >>                 Regards.
> >>
> >
>
> --
> Regards,
>
> Renoir Boulanger  |  Developer operations engineer
> W3C  |  Web Platform Project
>
> http://w3.org/people/#renoirbhttps://renoirboulanger.com/  ✪
>  @renoirb
> ~
>
>
>

Received on Tuesday, 3 June 2014 15:28:05 UTC