Td width

[Andrew Brown]

We have a few hundred files to put up on our sites, many of which contain tables, all different, currently coded in html.

Now that one is obliged to use css to fix column widths — a curious development — I am looking for a way of inserting all the relevant instructions in or immediately after the table tag. Can anyone offer an improvement on

<table>
<colgroup>
<col span="1" style="width: 30%;">
<col span="1" style="width: 70%;">
</colgroup>
...

AB

[Harvey Pikelberger]

Is there a logic pattern to how you want your columns sized, or is every column width a customized decision?


<table class="Type1">

<colgroup>
<col span="1" style="width: 30%;">
<col span="1" style="width: 70%;">
</colgroup>

> On Nov 26, 2019, at 06:12, Andrew Brown <li...@c18.org> wrote:
>
> We have a few hundred files to put up on our sites, many of which contain tables, all different, currently coded in html.

> --
> This is the BBEdit Talk public discussion group. If you have a
> feature request or need technical support, please email
> "sup...@barebones.com" rather than posting to the group.
> Follow @bbedit on Twitter: <https://twitter.com/bbedit>
> ---
> You received this message because you are subscribed to the Google Groups "BBEdit Talk" group.
> To unsubscribe from this group and stop receiving emails from it, send an email to bbedit+un...@googlegroups.com.
> To view this discussion on the web visit https://groups.google.com/d/msgid/bbedit/745C117C-BD58-410C-9950-454BFC913D57%40c18.org.

[Andrew Brown]

All custom, Harvey. — A.

[Harvey Pikelberger]

Some thoughts:

Consider a data-and-code solution as opposed to one that involves custom-editing each and every table.

In approx. the same time it takes you to mark up each table you could instead be logging each table (say giving each table an id (or probably better, a class), it’s column count, and preferred column sizing)

There are a number of ways to go about doing this. ( I prefer a JS-coded approach, but at very least you could create a central .css file that effectively lists all your table classes and their customized td widths. )

A number of interesting things come from this approach:
a) You get a centralized overview of all your tables.
b) When you want to make changes you don’t have to again edit all your tables, just the centralized file.
c) You typically discover patterns in your datasets and even your website you weren’t previously aware of, and you can start to think about how to leverage those discoveries in efficient, innovative ways.
d) You open up the possibility — if it makes a difference — of extracting the data out of all the html files into more data-friendly contexts (databases, JSON, etc)


> On Nov 26, 2019, at 07:25, Andrew Brown <li...@c18.org> wrote:
>
> All custom, Harvey. — A.

> --
> This is the BBEdit Talk public discussion group. If you have a
> feature request or need technical support, please email
> "sup...@barebones.com" rather than posting to the group.
> Follow @bbedit on Twitter: <https://twitter.com/bbedit>
> ---
> You received this message because you are subscribed to the Google Groups "BBEdit Talk" group.
> To unsubscribe from this group and stop receiving emails from it, send an email to bbedit+un...@googlegroups.com.

> To view this discussion on the web visit https://groups.google.com/d/msgid/bbedit/2FE6510B-23C9-4F53-AA1C-23BF5D7FD63E%40c18.org.

[Andrew Brown]

This all makes good sense, thanks Harvey, and indeed some patterns could emerge, particularly for the simple tables — but I would end up with almost as many css specifications as tables given that I can rarely use automatic column width. For the moment I am making do the colgroup approach. — AB

[Harvey Pikelberger]

Right, your worst case is a css file with as many specs as tables, BUT in the process you’ve id’d (and/or classified) all your tables, only minimally changed your html files, while simultaneously opening up options for more efficient oversight and control going forward.

Assuming (from your other post) a fluency with FMP and SQL, you open up the option of taking advantage of integrating them into your workflow — An FMP table, perhaps, holding a list of your HTML tables, the column counts and widths, which in turn generates the css specs. Just one of many options that open up.


> On Nov 27, 2019, at 05:42, Andrew Brown <li...@c18.org> wrote:
>
> This all makes good sense, thanks Harvey, and indeed some patterns could emerge, particularly for the simple tables — but I would end up with almost as many css specifications as tables given that I can rarely use automatic column width. For the moment I am making do the colgroup approach. — AB

> --
> This is the BBEdit Talk public discussion group. If you have a
> feature request or need technical support, please email
> "sup...@barebones.com" rather than posting to the group.
> Follow @bbedit on Twitter: <https://twitter.com/bbedit>
> ---
> You received this message because you are subscribed to the Google Groups "BBEdit Talk" group.
> To unsubscribe from this group and stop receiving emails from it, send an email to bbedit+un...@googlegroups.com.

> To view this discussion on the web visit https://groups.google.com/d/msgid/bbedit/9657472D-1DF8-4EEA-8579-FEE322E283E6%40c18.org.