- From: Amelia Bellamy-Royds <amelia.bellamy.royds@gmail.com>
- Date: Mon, 2 Jun 2014 23:42:21 -0600
- To: Jen Simmons <jen@jensimmons.com>, List WebPlatform public <public-webplatform@w3.org>
- Message-ID: <CAFDDJ7zq-L2Q-vpxYvH+oe0MNn0DW0V5dR1e86n=ygxnxS_ZhQ@mail.gmail.com>
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 topicssvg/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> 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> 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 >> >> [image: 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 >> 5by5.tv/webahead >> twitter: jensimmons <http://twitter.com/jensimmons> >> >> >> >> On Fri, May 9, 2014 at 12:15 AM, Doug Schepers <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 >>>> 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/ be the appropriate place to post? >>>> Regards. >>>> >>> >>> >>> >>> >> >
Attachments
- image/png attachment: csspropertylistatmdn.png
Received on Tuesday, 3 June 2014 05:42:51 UTC