* HTML output for tbl @ 2011-01-12 21:58 Joerg Sonnenberger 2011-01-13 12:36 ` Kristaps Dzonsons 0 siblings, 1 reply; 5+ messages in thread From: Joerg Sonnenberger @ 2011-01-12 21:58 UTC (permalink / raw) To: tech Hi Kristaps et al, looking at the output for queue(3), there is a rather obvious bug in the width output. It repeats the width: xxx for every column, e.g. the third column has three width in order. This magically works due to the overwrite rules, but is far from pretty. I also wonder if we should use min-width and screw IE 6. That and using a single table (not one per row) would be enough to give queue(3) a properly formatted table without having to go extra wide by switching spacing from ex to em. Joerg -- To unsubscribe send an email to tech+unsubscribe@mdocml.bsd.lv ^ permalink raw reply [flat|nested] 5+ messages in thread
* Re: HTML output for tbl 2011-01-12 21:58 HTML output for tbl Joerg Sonnenberger @ 2011-01-13 12:36 ` Kristaps Dzonsons 2011-01-13 12:53 ` Joerg Sonnenberger 0 siblings, 1 reply; 5+ messages in thread From: Kristaps Dzonsons @ 2011-01-13 12:36 UTC (permalink / raw) To: tech > looking at the output for queue(3), there is a rather obvious bug in the > width output. It repeats the width: xxx for every column, e.g. the third > column has three width in order. This magically works due to the > overwrite rules, but is far from pretty. I also wonder if we should use > min-width and screw IE 6. That and using a single table (not one per > row) would be enough to give queue(3) a properly formatted table without > having to go extra wide by switching spacing from ex to em. Joerg, This isn't really a bug: it's because tables can be interspersed with arbitrary macros, so each row should in theory be standalone. However, I agree that this makes for ugly output, and having just tested it with SCALE_EM, I think it's best to keep a few bits of state and just reinitialise the table if broken up by other macros. I'll write this up when I've a few minutes to myself. And no, we can't screw IE6. It just now occurs to me that, since CSS "cascades" atop the HTML, I can set <COL> pixel-widths as a safe default and let CSS, with its precise "em" widths, override these values. This will make browsers without CSS also recognise mandoc -Thtml's tables, whether from tbl(7) or otherwise, which for now require the style-sheet for stipulating widths. Thanks, Kristaps -- To unsubscribe send an email to tech+unsubscribe@mdocml.bsd.lv ^ permalink raw reply [flat|nested] 5+ messages in thread
* Re: HTML output for tbl 2011-01-13 12:36 ` Kristaps Dzonsons @ 2011-01-13 12:53 ` Joerg Sonnenberger 2011-01-13 14:30 ` Kristaps Dzonsons 0 siblings, 1 reply; 5+ messages in thread From: Joerg Sonnenberger @ 2011-01-13 12:53 UTC (permalink / raw) To: tech On Thu, Jan 13, 2011 at 01:36:43PM +0100, Kristaps Dzonsons wrote: > >looking at the output for queue(3), there is a rather obvious bug in the > >width output. It repeats the width: xxx for every column, e.g. the third > >column has three width in order. This magically works due to the > >overwrite rules, but is far from pretty. I also wonder if we should use > >min-width and screw IE 6. That and using a single table (not one per > >row) would be enough to give queue(3) a properly formatted table without > >having to go extra wide by switching spacing from ex to em. > > Joerg, > > This isn't really a bug: it's because tables can be interspersed > with arbitrary macros, so each row should in theory be standalone. > > However, I agree that this makes for ugly output, and having just > tested it with SCALE_EM, I think it's best to keep a few bits of > state and just reinitialise the table if broken up by other macros. > I'll write this up when I've a few minutes to myself. ACK. I do prefer to have SCALE_EX as default, the width can go way too large otherwise. > And no, we can't screw IE6. Well, the other option would be to require a bit JS for IE6. The point is that it is the only larger browser that might still be used that doesn't do min-width and also understands CSS. Worst case is that it doesn't use the size hints -- I consider that acceptable as fallout for getting much better output with useful browsers. > It just now occurs to me that, since CSS "cascades" atop the HTML, I > can set <COL> pixel-widths as a safe default and let CSS, with its > precise "em" widths, override these values. This will make browsers > without CSS also recognise mandoc -Thtml's tables, whether from > tbl(7) or otherwise, which for now require the style-sheet for > stipulating widths. I disagree somewhat. Using col is a good idea as it avoids redundant markup. Trying to second guess the font width is prone to fail. That's why specifying a minimal width is better -- it will still just stretch if needed. Joerg -- To unsubscribe send an email to tech+unsubscribe@mdocml.bsd.lv ^ permalink raw reply [flat|nested] 5+ messages in thread
* Re: HTML output for tbl 2011-01-13 12:53 ` Joerg Sonnenberger @ 2011-01-13 14:30 ` Kristaps Dzonsons 2011-01-13 14:51 ` Joerg Sonnenberger 0 siblings, 1 reply; 5+ messages in thread From: Kristaps Dzonsons @ 2011-01-13 14:30 UTC (permalink / raw) To: tech >> However, I agree that this makes for ugly output, and having just >> tested it with SCALE_EM, I think it's best to keep a few bits of >> state and just reinitialise the table if broken up by other macros. >> I'll write this up when I've a few minutes to myself. > > ACK. I do prefer to have SCALE_EX as default, the width can go way too > large otherwise. Joerg, I just checked in a change to -Thtml for tables that has the following basic logic: when a new table is encountered, it sets column widths using <COL> and the "width" CSS style. These columns are used until a macro is encountered. At this point, the table is closed out and the macro is processed. (This also works with block macros.) Then when the first table-row is again encountered, the table is re-opened in the same way. This allows for arbitrary breaks in the table flow; subsequent table rows, by being in the same TABLE, are all sized intelligently by the browser. >> And no, we can't screw IE6. > > Well, the other option would be to require a bit JS for IE6. The point > is that it is the only larger browser that might still be used that > doesn't do min-width and also understands CSS. Worst case is that it > doesn't use the size hints -- I consider that acceptable as fallout for > getting much better output with useful browsers. > >> It just now occurs to me that, since CSS "cascades" atop the HTML, I >> can set<COL> pixel-widths as a safe default and let CSS, with its >> precise "em" widths, override these values. This will make browsers >> without CSS also recognise mandoc -Thtml's tables, whether from >> tbl(7) or otherwise, which for now require the style-sheet for >> stipulating widths. > > I disagree somewhat. Using col is a good idea as it avoids redundant > markup. Trying to second guess the font width is prone to fail. That's > why specifying a minimal width is better -- it will still just stretch > if needed. Consider this. If I hardcode <COL WIDTH="20" STYLE="min-width: 4ex;">, where "20" is (I'm just making these numbers up) a reasonable guess at the pixel-width of 4 x's, then "real" browsers can use the min-width and IE6, and any other non-CSS, will use the COL sizes for a reasonable spacing. Thoughts? Kristaps -- To unsubscribe send an email to tech+unsubscribe@mdocml.bsd.lv ^ permalink raw reply [flat|nested] 5+ messages in thread
* Re: HTML output for tbl 2011-01-13 14:30 ` Kristaps Dzonsons @ 2011-01-13 14:51 ` Joerg Sonnenberger 0 siblings, 0 replies; 5+ messages in thread From: Joerg Sonnenberger @ 2011-01-13 14:51 UTC (permalink / raw) To: tech On Thu, Jan 13, 2011 at 03:30:42PM +0100, Kristaps Dzonsons wrote: > >>However, I agree that this makes for ugly output, and having just > >>tested it with SCALE_EM, I think it's best to keep a few bits of > >>state and just reinitialise the table if broken up by other macros. > >>I'll write this up when I've a few minutes to myself. > > > >ACK. I do prefer to have SCALE_EX as default, the width can go way too > >large otherwise. > > Joerg, > > I just checked in a change to -Thtml for tables that has the > following basic logic: when a new table is encountered, it sets > column widths using <COL> and the "width" CSS style. This looks good. > These columns are used until a macro is encountered. At this point, > the table is closed out and the macro is processed. > > (This also works with block macros.) > > Then when the first table-row is again encountered, the table is > re-opened in the same way. > > This allows for arbitrary breaks in the table flow; subsequent table > rows, by being in the same TABLE, are all sized intelligently by the > browser. This sounds fine, too. > >>And no, we can't screw IE6. > > > >Well, the other option would be to require a bit JS for IE6. The point > >is that it is the only larger browser that might still be used that > >doesn't do min-width and also understands CSS. Worst case is that it > >doesn't use the size hints -- I consider that acceptable as fallout for > >getting much better output with useful browsers. > > > >>It just now occurs to me that, since CSS "cascades" atop the HTML, I > >>can set<COL> pixel-widths as a safe default and let CSS, with its > >>precise "em" widths, override these values. This will make browsers > >>without CSS also recognise mandoc -Thtml's tables, whether from > >>tbl(7) or otherwise, which for now require the style-sheet for > >>stipulating widths. > > > >I disagree somewhat. Using col is a good idea as it avoids redundant > >markup. Trying to second guess the font width is prone to fail. That's > >why specifying a minimal width is better -- it will still just stretch > >if needed. > > Consider this. If I hardcode <COL WIDTH="20" STYLE="min-width: > 4ex;">, where "20" is (I'm just making these numbers up) a > reasonable guess at the pixel-width of 4 x's, then "real" browsers > can use the min-width and IE6, and any other non-CSS, will use the > COL sizes for a reasonable spacing. > > Thoughts? The question arrives if you have input that is too large to fit, but can be broken apart like multiple words. For queue(3) the changed version works because the "_FOREACH_REVERSE" is a single word. If you replace the second _ with a space, it will be line wrapped. With min-width, modern browser will try to increase the total width of the table to avoid line breaks. Specifying both width and min-width is useless as width overrides any min-width attribute. Joerg -- To unsubscribe send an email to tech+unsubscribe@mdocml.bsd.lv ^ permalink raw reply [flat|nested] 5+ messages in thread
end of thread, other threads:[~2011-01-13 14:51 UTC | newest] Thread overview: 5+ messages (download: mbox.gz / follow: Atom feed) -- links below jump to the message on this page -- 2011-01-12 21:58 HTML output for tbl Joerg Sonnenberger 2011-01-13 12:36 ` Kristaps Dzonsons 2011-01-13 12:53 ` Joerg Sonnenberger 2011-01-13 14:30 ` Kristaps Dzonsons 2011-01-13 14:51 ` Joerg Sonnenberger
This is a public inbox, see mirroring instructions for how to clone and mirror all data and code used for this inbox; as well as URLs for NNTP newsgroup(s).