W3C home > Mailing lists > Public > public-webplatform@w3.org > June 2014

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

From: Doug Schepers <schepers@w3.org>
Date: Tue, 03 Jun 2014 09:24:26 -0400
Message-ID: <538DCC8A.3090008@w3.org>
To: Amelia Bellamy-Royds <amelia.bellamy.royds@gmail.com>
CC: Jen Simmons <jen@jensimmons.com>, List WebPlatform public <public-webplatform@w3.org>
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.
>
Received on Tuesday, 3 June 2014 13:24:37 UTC

This archive was generated by hypermail 2.3.1 : Tuesday, 6 January 2015 21:21:02 UTC