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 <[email protected]> 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 > >> 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) > > > -- > This is the BBEdit Talk public discussion group. If you have a > feature request or need technical support, please email > "[email protected]" 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 [email protected]. > To view this discussion on the web visit > https://groups.google.com/d/msgid/bbedit/9657472D-1DF8-4EEA-8579-FEE322E283E6%40c18.org. -- This is the BBEdit Talk public discussion group. If you have a feature request or need technical support, please email "[email protected]" 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 [email protected]. To view this discussion on the web visit https://groups.google.com/d/msgid/bbedit/E0A0E2C5-6FD2-4B92-B920-404FC1148093%40gmail.com.
