Add usage documentation for Table cell styling and headers

[bobhy]

Edit: this PR is about Table doc, not Tree! Updated title...

Changes under "Components"; clarify Table page, add a new page for Table Styling and another for Table Headers.
The headers page shows rendered output for the sample code, the Styling page does not, but maybe should?

[andydotxyz]

Table headers seems like a good thing to document.
But the styling - isn't that actually styling Labels not Tables?

[bobhy]

This page is about styling the table, which certainly involves styling labels but also involves the table API as well.

I could see adding a page someday about styling forms, too.

[andydotxyz]

Thanks, but I think this is trying to cover a lot too much - each page is very long.
For the headers page the first section is sufficient to demonstrate the functionality.

In the table styling page if you want it to be about styling the table and not about labels then again the first section seems sufficient - alternating styling across odd/even rows is a great example and I'm not sure the additional examples add a lot.

As you say, illustrating the output would be great.
Thanks for working on this, let's see how to focus it down to a main focus for each page.

[andydotxyz]

It's not a great idea to use 1-dimensional data for a demonstration of a 2-dimensional output.

[bobhy]

The sample renders different data in each column and the pattern doesn't repeat till 5 rows later. It doesn't look like 1-dimensional data.
But the point of the sample is the headers, and maybe it would be simpler and less distracting to put the same placeholder text in all the data cells, or even leave them empty?

[andydotxyz]

I agree the data here is not the point - but docs have to consider every single line will be used as best practice - and 1D data is not best practice for a table and could lead to support requests.

[bobhy]

To clarify, are you concerned about line 25, var dataTemplateText = "0123456789012345"? I thought the concern was about the sample data, at lines 26-31 which is indeed a 1-d vector of strings.
If it's about line 25, please clarify what you'd rather have there (my idea was you can tell at a glance that this string is 16 runes long). If it's about the subsequent lines, I could have the sample show blanks in the data cells. That would focus attention on the headers, which is the point of this sample.

[andydotxyz]

I've noticed also you have replaced the tab indentation in code to 4-space, any particular reason? This is not how Go is normally formatted.

Can you also comment on the file removal?

[bobhy]

The hard tabs in the sample render as 8 spaces on the doc site, not the 4 spaces I see in samples on go std lib (e.g: https://pkg.go.dev/strings#CutPrefix) or my IDE. I couldn't figure out how to configure kramdown or rouge to get this effect, so I replaced them with spaces so they'd at least look "right". I can put back the hard returns if you'd prefer.

[bobhy]

Can you also comment on the file removal?

widget.html is shadowed by widget.md, and in any case, redirects to a non-existent page. Agreed, this change is not directly related to the purpose of the PR, so it's your call whether to retract it.