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.
