Layout refactor

[Anaminus]

The layout of the website is messy, derived from a poor understanding of CSS. There is a rudimentary application of fluidity, but this conflicts with the dynamic nature of the content.

[Anaminus]

Case: Table of Contents

The Table of Contents (ToC) can display members of a class. Sometimes a member name can be really long. How is the width of the ToC handled?

1. The width expands to the width of its content. (current)
   • All content is displayed correctly consistently.
   • ToC can squeeze sibling content, making that content look worse.
   • The dynamic between deciding which content deserves more screen space.
   • CSS has poor support for moving content around based on its size. Only real support for screen sizes, which does not address the problem.
   • Diminishing returns: there are too few long members to justify the amount of screen space allocated to the ToC.
2. The width is either set or limited. Long members are truncated or wrapped.
   • Less dynamic: depending on how they are handled, long items can look bad, and can even have bad UX.
   • Constant content width is significantly easier for designing layouts.

Consensus: Poor support for "fluid" layout. Refactor should incorporate layout based on constant-sized space allocations. Dynamics are handled by having multiple layouts selected by @media queries.

[Anaminus]

Case: Width analysis

The frequency of the widths of member names can be analyzed to decide on an optimal width for elements for various screen sizes.

For example, a sample was taken of the widths of every member name in the API, using Open Sans font at 10pt*1.5, rendered on Firefox. The following table displays a pixel width, and the percentage of members that are less than that width (coverage), and the width as a percentage of several screen widths.

Width	Member %	1920px	900px	500px
0 px	0.00%	0%	0%	0%
20 px	2.46%	1%	2%	4%
40 px	15.77%	2%	4%	8%
60 px	36.34%	3%	7%	12%
80 px	54.89%	4%	9%	16%
100 px	69.41%	5%	11%	20%
120 px	79.92%	6%	13%	24%
140 px	88.00%	7%	16%	28%
160 px	93.41%	8%	18%	32%
180 px	96.96%	9%	20%	36%
200 px	98.35%	10%	22%	40%
220 px	99.03%	11%	24%	44%
240 px	99.54%	13%	27%	48%
260 px	99.84%	14%	29%	52%
280 px	99.94%	15%	31%	56%
300 px	100.00%	16%	33%	60%

This could be used, for example, to decide the amount of screen width to allocate to a list that displays members, such as a ToC. A smaller width will take up less of the screen, but will truncate more members. Conversely, a larger width will truncate less members, but use up more of the screen.

300px is enough to display every member without truncation. However, for common screen resolutions, a significant portion of the screen will be allocated. On the other hand, at only half the width, 90% of members are still covered.

Using @media queries, widths can be chosen that are optimal for different screens, while also maximizing member coverage. For example, a base layout could allocate up to 20% of the screen for a ToC, and then the layout is changed when member coverage drops below 70%. According to the table, this would occur at screen widths below 500px.