User:Billw58/Prefs Options

Peter 3Jun12: I *really* don't like the numbers. They add nothing for me, they don't refer or relate to a numbered reference section for Preferences. And as Bill pointed out in the email thread the current front page doesn't have numbering anywhere.

Gale 03Jun12: Thanks for the work Bill. The new front page has numbers for the other list it has (the major sections) and this is a list too. Numbers reinforce the importance of Prefs and show the order (which is ambiguous otherwise.
If we have numbers I am +1 on across first, -1 on down first. I like bullets (when aligned properly) +0.75. I'm -0.75 on having neither bullets or numbers. I agree it is not really right in the context of the whole page. If most want neither bullets or numbers, then maybe a subtle border around the Prefs block?
Bill 03Jun12: The PrefBull template aligns the bullets properly, but screen readers will say the link to the graphic every time encountered whether a template is used or not. I thought the bullet graphics were out because of this?
By the 'prefs block' do you mean the table of 16 sections? I've added that to the No Numbers section.
I could make a case for prefs sections to be listed alphabetically. After all, until you see an image of the prefs dialog what does the order matter? Perhaps users could find what they're looking for faster in a alphabetical list? My point is that numbering to show the order of the prefs sections as presented in the dialog is not that important.
Gale 03Jun12: I had not seen your discovery before now that screen readers say the link to the graphic. I understand with "real" Wiki bullet points (asterisk) they say "text"? Can you remind me why we cannot make this a proper list, given we are still using this in "More Details" - is that fixed now for browsers like Chrome?
I agree ordering Prefs alphabetically might help user sometimes but it would be more confusing to then see a different order when you got there. I would not do it unless we actually say that the list is alphabetical.
I can live with no bullets or numbers if needs be with the enclosed box (that is what I meant) but still -0.25. This is primarily about visuals (not giving users an undifferentiated mass of links in amongst already dense text) and consistency. Perhaps we should wait for Ed as he started this.
Bill 03Jun12: The horizontal list items are not fixed in Chrome and Safari. Look at this page in Safari. AFAICT the floating horizontal list items appear work properly on the current front page because they are at the bottom of the cell. But look at the current front page in Safari - there is a blank line below the "importing - exporting - metadata editor" line. Since the vast majority of Mac users will be using Safari or Chrome (Camino is very marginal and I believe Firefox is too), we should get this right for those two browsers. If this means using fake lists or some other form of presentation then I think that should be seriously considered.
VoiceOver behaves differently in Chrome and Safari - Safari says "text" when it encounters a real bullet, Chrome says nothing and skips it (I think). With your change to the PrefBull template, Voiceover in Safari says "wiki bullet dot P N G image".
My point about alphabetizing was that order is not really that important and thus I don't see the point of needing the numbers.
I've never been that concerned about the "wall of links", nor about slavish consistency in using lists versus tables on the front page. If we feel that the table of prefs sections must appear to be a list then I vote for the numbers - at least screen readers will then say e.g. "one. link, devices preferences. two. link, playback preferences...".
Gale 03Jun12: I am sure David B would prefer a list for Prefs as it "is" a list, but if he accepts major sections as not a list then he should accept Prefs like that. Again, my beef against the prefs table with no numbers or bullets is first, ease of reading and second, consistency (not for lists vs headers in the code, but that this list and the major sections list should look similar with some text or graphic before the items).
Midori is identical to Safari in how it displays this page. "More details" using tables is needlessly expanded IMO, but I think it will be unacceptable for both sighted and VI users and for consistency to solve that by removing the list style. Is the webkit issue having extra space when closing a list with </ul> AND using "clear:both" somewhere? See http://gaclrecords.org.uk/samples.html which displays identically on Safari and Firefox both there and on this page. The first pair of channels is one list and the second pair is two lists. I also tried (within your existing code below) adding a "clear:both" div and immediate end div (so we did not clear the li or ul at all) but it did not prevent extra space. Basically we could I suppose put some conditional in the CSS for webkit browsers that styled the second order lists with negative margin-bottoms?
If we use a real unordered list for the Prefs, do we have any "clear:both" webkit issues with that? I'm coming round to accepting that an unordered list is at least as good as a list with numbers. But if a real unordered list is hard to implement and you don't want to spend a lot of time on it then it pretty much looks like numbers or the current headings in that box...
Bill 03Jun12:
- I agree that the two table options are not good: the first because of the spacing and the second due to readability.
- My third option (still in progress as I write: I've got an unbalanced div in there somewhere) is no better than the second version.
- Yes, the webkit issue appears to be with using "clear:both" touching </ul>. Note that I am learning CSS as I go and am rapidly delving into advanced CSS without a proper grounding. I try things out until they work. I do not know at the moment how to use conditional CSS to do something different for webkit browsers.
- I believe that if we use a real unordered list for the prefs we'll have to use "clear:both" and will encounter the same problem. As I recall that is why I'm doing what I'm doing in the prefs section.
- Could you try your list examples, but creating rows of floating list items using "clear:both" to force a new row on your HTML (non-wiki) page? That might tell us something, if only that wiki has defeated us.
  - Later: Never mind. I looked at the page source and wiki is not doing anything strange with that list construct. All the HTML is there exactly as specified on the page, except for the links which should not affect the formatting.
- Yes, am I rapidly reaching the end of my rope on this. I would accept numbers in the prefs list, but I would really like to see the webkit issue solved for the More Details section.
- On a whim I've added numbers to the lists in my third go at the More Details section (the no lists, no tables version). Perhaps that is a reasonable compromise (once I get the last niggle worked out in the formatting).
Peter 4Jun12: The fundamental question that we have to ask ourselves is: "Is what Bill has worked on here and on his new front page better than what we already have, do we prefer it?" If the answer to that question is "yes", then we should implement it - if the answer is "no" then we should abandon it and let Bill get on with his life <smiles>.
Implementing it now will not, of course, preclude us from tweaking it in the future.
Like Bill the "wall of links" large or small is not a matter of concern to me - it has a certain aesthetic cleanliness which is visually pleasing - unlike the clutter of numbering.
Bill 04Jun12:
- I've trimmed this page down to what I believe are the three remaining contenders.
- As noted, the first two examples render the same with webkit and gecko based browsers, so are my preference. We can tweak how the horizontal "list" items float (specifically the width percent or pixels) if we think that would help the appearance.
- I think the bullet lists are out since the More Details section renders improperly in Safari and screen readers will say "wiki bullet dot P N G image" for each bullet encountered in the Prefs section.
- I have a mild preferences for "No numbers", but will accept the numbers if that's what it takes to resolve this.
Gale 05Jun12: There is little doubt of the three you leave up, that "Bullets (using the PrefBull template)" looks best if it looked like that on Safari/Chrome. I think the numbers in "More Details" look like what they are - a patch for a display issue. And we could still have un-numbered "More Details" (further tweaked) with numbered Prefs - the issues are separate.
The "conditional" CSS I have in mind is to add it to skins/monobook/KHTMLFixes.css for Safari, Chrome and Konqueror (see http://en.wikipedia.org/wiki/KHTML). Chrome/Safari used to read this fixed css. As an experiment I made H2's green in KHTMLfixes.css but according to the page source only IE fixes are now being declared, so the green H2's don't show up. If there is no coding solution, I'm sure KHTMLFixes.css is the way to approach the issue, but first we have to find out how to make Chrome and Safari find this stylesheet. I'd rather look into this route than make a second-best solution for all browsers.
Bill 05June12:
- Yes, a proper general cross-browser solution is preferred. I leave it to you to see if it can be done.
- AFAICT the front page is the only place we write <li style="float:left"> and <div style="clear:both">. I don't know if this affects how we implement a solution.
- Un-numbered More Details (with further tweaks) with numbered Prefs could be easily implemented if the KHTML CSS fix can't be done.
- Later: Tweaked the More Details in No Numbers so it doesn't look like a broken up table.
Gale 05Jun12: I'm not sure what the best tweaks might be in More Details if we can't customise for KHTML. I am not sure larger font for the sections helps as it detracts from what should be the bullet items. Maybe spread the links out more horizontally? Anyway, let's see if I can get anywhere with KHTML.
Gale 07June12: I can't do this by adding *Fixes.css files because it doesn't work in MW 1.15 or later without making further changes which are unknown to me (I've asked in a couple of MW support forums without response). But we can do it by putting the code we want inside a webkit conditional inserted in the main.css file. For example this will change the visited link colour in webkit browsers from #5a3696 to green (I tested in Safari and Rekonq):

a:visited {
	color: #5a3696;
}

@media screen and (-webkit-min-device-pixel-ratio:0) {
a:visited {
	color: green;
}
}

So can you make code for More Details using the PrefBull template that closes up the unwanted gaps, then apply it just for webkit as above? If that works and you have the willpower I would like the Preferences as a bulleted list which seems to have more support than numbers (assuming you can similarly close up the resulting gaps for webkit). Prefs is less important than "More Details". I still like the numbers if we need to use those and can live with no numbers or bullets (if inside that box).

Bill 06Jun12: I'll be away until June 11. I'll give this some thought when I get back. Could you point me to the source of this? Does it work if I put in common.css? Do I have access to main.css? The fix appears to be complicated because everything renders properly except in the special case where we write <li style="float:left"> and <div style="clear:both">. <div style="clear:both"> does not appear to cause a problem in Safari unless it immediately follows a list.
Gale 07June12: Yes it will work in common.css (just tried and reverted a test) so you can experiment there as you wish. The changes will only get into the dumped Manual if I add it to main.css (you need to ask me or Buanzo). I would guess you would make a special span olass or similar but only call it in the webkit conditional. The source I found it from was http://www.erisgraphics.com/article/CSS-Fix-for-Chrome-and-Safari.html . Note this is not Javascript so relies on the User Agent sniffing working. It would have been better to use Javascript as well, but I am more hazy on this at the moment.
Bill 10Jun12: Got back early - it's now Sunday evening. See detailed comments in the Bullets section below. I'm going to sleep on this, but I am not hopeful of coming to a resolution of the webkit-floating-list-items issue. My preference at this point would be put "No Numbers" on the front page, but continue to try to reach a resolution of the webkit issue.
Bill 11Jun12: No new inspiration has come my way today. I am officially at an impasse. See additional comment regarding display issues created in Camino/Firefox when attempting to fix Safari/Chrome. If we are going to move forward with this I think we need to abandon bullets for the time being.
Gale: 12Jun12: I think I have found a reasonable solution for the webkit issue. We can always position an element relative to what it should be ( http://www.w3schools.com/cssref/pr_class_position.asp ). So:

 
<li style="clear:both; position:relative; top:-1.5em">

works as does (more ridiculously):

<li style="float:left; position:relative; left:-13.5em">

BTW the code that is giving is so much trouble in webkit here looks very like the side-by-side bullets on the Wiki front page; I can't see what the obvious difference is except the containers.

Bill 12Jun12: I've created another css class to deal with getting "How to arrange Toolbars" to be positioned correctly. I think it works in gecko and webkit. The problem remains of floating list items in gecko "running into each other" - the "margin-left" seems to be ignored. I've made an example in "Details for importing and exporting" that seems to show that floating list items work as long as they are not the first item in the list! After I save this page I will get screenshots of how this is rendered in Camino/Firefox and Safari/Chrome.
- Later: Well, the only major problem remaining is with Camino. This is such a niche browser on Mac that it may not be worth worrying about. Apple web browser stats Strange that Camino renders differently from Firefox as both are gecko browsers. Here's the comparison screen shots as of noon EDT 12June12. Note that the webkit browsers still show some uneven line spacing with no apparent rhyme or reason. Even the gecko browsers show less space after the "On-Demand Loading" line than with other lines in that list.
- Also: I've tweaked the "No numbers" sections with additional indents and a border. I quite like it. It renders identically on all browsers. If webkit is ever "fixed" to deal with the floating list items issue we'd have to adjust our code. Using the "No Numbers" style means we wouldn't have the worry.
- Given that we've been fighting this gecko versus webkit battle for a week now and everything we try breaks in some minor or major way in both gecko and webkit and given that "No Numbers" looks good, I'd like to go with some combination of "Numbers" and "No Numbers" on the front page. We can still, if we have the time and inclination, continue to attempt to get floating bullets to work and implement it when we succeed.

Gale 12Jun12: It looks to me like browser font-size and screen width plays a part here. I can barely see the lesser line-height in list rows after-the-first unless I reduce the font-size considerably, as long as the list row stays on one line which it does in Firefox. But on my screens the row starting with "LAME MP3..." wraps in webkit, thus Chrome (Win), Safari (Mac) and Rekonq (Linux) look really bad:

My only remaining issue with "No Bullets" is the larger font for "How to Arrange Toolbars". I agree perhaps it does not look quite right now without larger font, but is that a vertical spacing issue? I also agree to aid consensus that we can drop back to "No Numbers" (with both "More Details and "Prefs" boxed) if we can't fix the bullets.

A few minutes later: Even if the row starting with "LAME MP3..." wraps in Firefox, I still get acceptable spacing below the wrap.

Bill 12Jun12
- Multiple lists appear to make no difference. New section added to demonstrate.
- "How to arrange Toolbars" in the "No Numbers" section in larger font was an oversight - fixed now.
- Camino is apparently about 0.05% of browser usage, but that's still potentially 1 in 2000 Audacity users will see a broken main page if we can't fix the floating bullets.
- "No Numbers" looks so clean with the consistent line spacing. Maybe I'm just starting to hate those bullets <grin>.
- Yes, I get the line wrap on the "LAME MP3 ..." line if I resize, and I see the squished line spacing in Chrome and Safari. Bad. Could we lose "for more formats" ? I miss the hanging indent you get when using lists, but there doesn't seem to be any way to get it otherwise. I tried a negative text-indent but that seems to be ignored.

In the following two sections the "More Details" part renders the same in Safari and Camino (webkit vs gecko).

Numbers across first

More Details for the Project Window

Additional Menus on Mac:

Audacity Menu

Window Menu

Additional Track types:

Label Tracks

Time Tracks

Note Tracks

Details for importing and exporting:

1. LAME MP3 export and FFmpeg import/export libraries for more formats

2. On-Demand Loading of uncompressed files

Importing Audio

File Export Dialog

Metadata Editor

Toolbars Overview - including how to arrange Toolbars

Preferences - changing your settings

Preferences are at the bottom of the Edit menu (or in the Audacity menu on Mac).

Many settings can be changed including keyboard shortcuts and the interface language.

1.

Devices

2.

Playback

3.

Recording

4.

Quality

5.

Interface

6.

Tracks

7.

Import/Export

8.

Extended Import

9.

Projects

10.

Libraries

11.

Spectrograms

12.

Directories

13.

Warnings

14.

Effects

15.

Keyboard

16.

Mouse

Preferences settings can be reset to default at any time.

No numbers

More Details for the Project Window

Additional Menus on Mac:

Audacity

Window

Additional Track types:

Label Tracks

Time Tracks

Note Tracks

Details for importing and exporting:

LAME MP3 export and FFmpeg import/export libraries for more formats

On-Demand Loading of uncompressed files

Importing

Exporting

Metadata Editor

How to arrange Toolbars

Preferences - changing your settings

Preferences are at the bottom of the Edit menu (or in the Audacity menu on Mac).

Many settings can be changed including keyboard shortcuts and the interface language.

[[ |Devices Preferences]]

[[ |Playback Preferences]]

[[ |Recording Preferences]]

[[ |Quality Preferences]]

[[ |Interface Preferences]]

[[ |Tracks Preferences]]

[[ |Import - Export Preferences]]

[[ |Extended Import Preferences]]

[[ |Projects Preferences]]

[[ |Libraries Preferences]]

[[ |Spectrograms Preferences]]

[[ |Directories Preferences]]

[[ |Warnings Preferences]]

[[ |Effects Preferences]]

[[ |Keyboard Preferences]]

[[ |Mouse Preferences]]

Preferences settings can be reset to default at any time.

Bullets

The "More Details" section:

10Jun12:
- Be sure to look at this page in a webkit browser to see the remaining problems.
- This now displays properly in Chrome and Safari except for "How to arrange Toolbars" which still has an extra line above it.
- My provisional fix is to set the line-height of floating list items to 6px for webkit browsers only. See MediaWiki:Common.css and the .fixwebkit style
- I'm not sure why it appears to work for three sections and not the fourth. Perhaps I am taking the wrong a approach.
- If anyone has the time, skill and motivation, please review what I've done and suggest improvements. Try adding another "line" of floating list elements to either the "Additional menus" or "Details for ..." sections and see what happens.
- Aside: I took the html for this section (the lists within a list, and without the fixwebkit spans), wrapped it in minimal html to create a stand-alone page, saved that page on my HD and opened the page in Camino and in Safari. Safari did not render extra blank lines above first-level list items. However Safari failed to render the second-level bullets on the floating list items. It would appear that Wiki is doing something to us here. If anyone would like to see this I'll put the code and screenshots on the talk page.
11June12:
- Looking at this tonight in Camino (gecko) the "Additional Menus" and "Additional Track Types" are not displaying properly despite having identical code to the "Details for importing..." section. "Additional Menus" and "Additional Track Types" render properly in Chrome.

The Preferences section

10Jun12:
- This still uses the "PrefBull" template
- Note that screen readers will say "wiki bullet dot P N G image" for each bullet in the Preferences section.
- Given the difficulties of getting floating list items to work properly in webkit browsers I can't see any way forward to use real bullets in the Prefs section. Even if we could get floating list items to work in webkit browsers there's the further issue of getting them to line up table-like. As we've seen, putting list items in table cells expands the horizontal spacing unacceptably. This could be got around, I suppose, by setting a custom line-height, but we'd still be using a table which is non-optimum for screen readers - "row one, column one, list, one item. Enter list, devices preferences."