Wiki restyling

[Christian Boos]

Like what happened for Trac 1.2 and the ticket sub-system (#11835), this time I'd like to propose a few enhancements mostly targeting the TracWiki.

The initial goal was to enhance readability, by constraining the width of the page to not exceed a reasonable limit. Other tweaks followed. See cboos.git@wiki-restyling (visible on demo-1.3, CTRL+SHIFT+R is still your friend until we fix #9936).

As usual, tastes and colors… But also, while doing these changes, I started to annotate the recurring CSS values so that we can think about generating the stylesheets from some higher-level format, online during development, offline at install and deploy time. I'm leaning towards using Jinja2 templates for that.

[Ryan J Ollos]

Looks interesting. I'm reviewing and will get you detailed feedback soon.

When the cursor is placed over the wiki expander/collapser, a text input icon is showed (like when hovering over a textarea). Would it make sense to use a finger?

[Ryan J Ollos]

Most of the changes look good to me. The following things stood out:

• The styling of the select elements. The square corners and inset don't seem to fit with the rest of the styling. Most other elements have rounded corners.
• The fonts are generally larger everywhere, which I think is good. The font of the preference forms, such as form#prefs on the Timeline page, looks too small now. Or maybe a different font needs to be used?
• Possibly out-of-scope for the changes here, but it might be better to have a larger mainnav (​example).

[Christian Boos]

Replying to Ryan J Ollos:

Most of the changes look good to me. The following things stood out:

• The styling of the select elements. The square corners and inset don't seem to fit with the rest of the styling. Most other elements have rounded corners.

Ok, I'll improve that.

• The fonts are generally larger everywhere, which I think is good. The font of the preference forms, such as form#prefs on the Timeline page, looks too small now. Or maybe a different font needs to be used?

You're right. With 10pt it looks better. Anyway, the font-size thing will probably be overhauled as I tackle #633. Currently I'm using "pt" as the unit, but I think I'll switch to "em", which will also make it possible to juggle with "rem" if needed.

• Possibly out-of-scope for the changes here, but it might be better to have a larger mainnav (​example).

Could do, yes.

As for the expander, yes, I also planned to add cursor: pointer. Next thing I wanted to add is the possibility to save as a UI preference the initial state of the wiki page, expanded or constrained.

[figaro]

The TOC items could do with a little more top-padding: demo-1.3/wiki/TracGuide

[anonymous]

Also here is an example of a coloration inconsistency: demo-1.3/wiki/TracIni

The heading has color #600, but the stanza heading has color #000. Making it #600 is more consistent. This is already implemented on ​TracHacks.

[anonymous]

There's a new batch of changes. It's not yet "final" but we're getting very close to what I wanted to have, at least for the Wiki. Also, #633 is in there as well.

Note that demo-1.3 is again raw trunk.

From now on, I'll use testing for showing off stuff, (usually the +testing ref).

This makes it easy to compare the feature(s) against the baseline. For example, see testing/wiki/TracUpgrade vs. demo-1.3/wiki/TracUpgrade.

[Christian Boos]

Now working on a branch rebased on trunk after the Jinja2 merge cboos.git@wiki-restyling.2.

Next, I'll fix the glitch with h2,h3 wiki styling being used on more h2,h3 elements than just the Wiki headings, by adding the "section" class to the generated Wiki headings.

+testing has been updated as well, and testing reflects the current status (compare with demo-1.3 which is trunk without wiki-styling.2).

[Christian Boos]

I've rebased the branch once more, this time compacted to just 2 changesets to facilitate reviewing (and it was a lot of back and forth changes anyway):

• [3504843b/cboos.git] (#12640, #633) TracWiki restyling: enhance readability and visual impact. (all the changes previously on wiki-restyling.2)
• [b3526214/cboos.git] (#12640) add a preference for the default wiki presentation (fixed- or full-width) (a new feature from this evening)

I'd like to commit this stage already, as it's quite polished at this point.

The two other big changes I have in mind will be proposed in separate tickets:

• use Jinja2 templates to generate the .css (statically)
• "action" menu for wiki pages, tickets and ticket comments (#12671)

[Ryan J Ollos]

Changes look good to me. Two very minor things.

We could add a small amount of spacing between the text box and checkbox:

When there's no View changes below the table in the change history, there should be more spacing between the table and footer:

---

Fixed in r15526.

[Christian Boos]

Branch merged in trunk in r15523 and r15524.

Soon visible in a Trac near you ;-)

Feel free to continue to report CSS glitches related to these changes, either here or in new tickets.

[Ryan J Ollos]

The choose file input could be made a bit larger on the Add Attachment page.

[Ryan J Ollos]

Link to missing revision now has ? appended: r1000000. Was that intentional?

[Christian Boos]

Yes, after I moved the trailing "?" corresponding to missing Wiki pages from the rendered HTML to the CSS, I noticed "?" got appended to other "missing" resources (changesets, milestones, whatever). (changeset:abcdef, milestone:abc, ticket:1234567). I pondered if I should make the CSS more precise but thought that the semantic being the same, the rendering could be the same as well.

[Ryan J Ollos]

I was thinking the trailing ? should not be copyable, which it seems can be ​done with CSS:

trac/htdocs/css/trac.css

@@ -625 +625 @@
 
 a.missing:link, a.missing:visited, a.missing, span.missing,
 a.forbidden, span.forbidden { color: #666 }
-a.missing::after { content: "?" }
+a.missing::after {
+ content: "?";
+ -webkit-user-select: none;
+ -moz-user-select: none;
+ -ms-user-select: none;
+ user-select: none;
+}
 a.missing:hover { color: #000 }
 a.closed:link, a.closed:visited, span.closed { text-decoration: line-through }

[Christian Boos]

Replying to Ryan J Ollos:

I was thinking the trailing ? should not be copyable

It's currently not copyable for me… at least in Chrome, FF, Edge, Opera (on Windows). For which browser is it a problem?

[Ryan J Ollos]

You are right, it's not copyable. I had mixed up testing between my 1.2-stable and trunk environments. Sorry about that.

[anton]

Hi,

I have a little question. Where is it documented howto configure the wiki that it will showup as not-narrow in default mode.

Actually when I open the wiki it's narrow by default, and I have to click the expand button every time. I prefer the old style and I would like to configure it somewhere. Thanks

[Ryan J Ollos]

Replying to anton:

Actually when I open the wiki it's narrow by default, and I have to click the expand button every time. I prefer the old style and I would like to configure it somewhere. Thanks

Please use the MailingList for queries like this.

The behavior is not configurable. We probably want to make it sticky rather than configurable: #13232.

In the meantime, you could use some custom JS in TracInterfaceCustomization to expand by default.

[boris.horner@…]

I upgraded from trac 1.2 to 1.4. In trac 1.4 it's possible to toggle between wide and narrow view. In general, I like this feature, but I'd rather have the wide view as default. Is there a way to configure this? I checked the style sheets but couldn't find a way to do this…

Is there a way to configure the setting?

Thanks!!

[boris.horner@…]

Findings so far

I found out that users can set the default appearance in their settings. This is fine, but still I want anonymous site visitors to see fullwidth as a default (and likewise, newly created users). Where does trac get the info from that narrow is the default?

[Jun Omae]

Replying to boris.horner@…:

Is there a way to configure the setting?

No. See comment:21 and #13232.

[boris.horner@…]

NOTE: I worked around the issue by putting some JavaScript code in site_head.html that removes the narrow class from the #content on page load. This, however, overrides any settings in authenticated accounts. For the time being, it solves my problem, but a solution that would allow admins to set the default appearance for authenticated and anonymous users would make sense.

Here's my site_head.html:

<script>
  jQuery(function($) {
        var $content = $("#content");
        if ($content.hasClass('narrow')) $content.toggleClass('narrow');
  });
</script>

[Ryan J Ollos]

Replying to Jun Omae:

Replying to boris.horner@…:

Is there a way to configure the setting?

No. See comment:21 and #13232.

See comment:2:ticket:13232.