Paragraph columns

[Alex Jordan]

Planning to continue table features, and paragraph-style cells are next. But what should XML look like for these? LaTeX handles paragraph cells as a kind of horizontal alignment option, as many of you know. To me, what "feels" right though is to make a cell be a paragraph cell just by virtue of having a <p> inside it. So that would be a cell-based approach rather than the column-based approach LaTeX uses.

In all cases, an author must specify some kind of width. Either a width for the cell (or column) that has a paragraph, or perhaps give a width for the whole table and then paragraph cell widths are determined by divvying up available space equally. Widths can be absolute (4cm, 20em, ...) or relative (30%, 0.25).

I imagine that these cells will respect vertical alignment for the row. And if it sounds reasonable, they will respect horizontal alignment with left -> right-ragged, right -> left-ragged, and center -> justified.

As a reminder, a table has a tabular child. The tabular can optionally have empty col children with attributes. And the tabular has row children, which have cell children.

So what would good XML source look like for paragraph cells?

[Rob Beezer]

Dear Table Master,

On 06/10/2016 09:34 PM, Alex Jordan wrote:
> Planning to continue table features, and paragraph-style cells are next. But
> what should XML look like for these? LaTeX handles paragraph cells as a kind of
> horizontal alignment option, as many of you know. To me, what "feels" right
> though is to make a cell be a paragraph cell just by virtue of having a <p>
> inside it. So that would be a cell-based approach rather than the column-based
> approach LaTeX uses.

Yes, I really like the presence of a "p" as the indicator of a paragraph cell.

> In all cases, an author must specify some kind of width. Either a width for the
> cell (or column) that has a paragraph, or perhaps give a width for the whole
> table and then paragraph cell widths are determined by divvying up available
> space equally. Widths can be absolute (4cm, 20em, ...) or relative (30%, 0.25).

We have lots of depth, the longtable package in LaTeX if need be (used for lists
of notation already), and infinitely long web pages. We have to be very careful
with width, it is a scarce resource. The hard right margin (600px) in HTML
lines up well with the recommended physical page width. Don't forget mobile.

So we can get pretty good sync of horizontal widths across outputs. The only
thing I am really happy with in terms of authoring - in images, side-by-side and
now videos - is a percentage width. I would like to standardize on 30%, meaning
not having 0.30 as an option. I included a small template for converting 30% to
0.30 so that YouTube videos could maintain their aspect ratio, and you can do
basic arithmetic in XSL.

This is another important decision I have delayed, so further discussion encouraged.

> I imagine that these cells will respect vertical alignment for the row. And if
> it sounds reasonable, they will respect horizontal alignment with left ->
> right-ragged, right -> left-ragged, and center -> justified.

My inclination would be to no-indent the first paragraph, and indent subsequent
paragraphs. Maybe at the low-end of indentation to minimize even worse
hypenation and word-spacing, given the scarcity of width. Bringhurst (recently
dis-credited here) says at least 1 en (2.3.2). Too many columns like this coul
end up looking horrid, so some education could be part of the sample article.
(See Bully Pulpit nearby.)

I don't feel a need for left-ragged/center/right-ragged, especially because some
other more global halign is in play. I suspect as a practical matter you might
spend more time defeating/overriding the row/col/tabular setting on many
paragraph cells? But I haven't even built one practical example. ;-)

Remember that we have side-by-side for some of this.

It feels to me like a width specification belongs on a column or a tabular, but
not on a row or a cell. Orthogonal to your valign project. But coding this
up will likely tell.

Thanks for taking this on.

Rob

[Alex Jordan]

Consider a row with three cells. First two each just contain one word. Last is a paragraph cell with a big paragraph. If 30% is the paragraph width, then on a small screen I think that would look terrible. So how about the default CSS being width:auto, with an appropriate default max table width in place?  In that example on the small screen, the browser would adjust widths to "optimize" according to the browser's algorithm. Use a default width like 30% in LaTeX.

 

> I imagine that these cells will respect vertical alignment for the row. And if
> it sounds reasonable, they will respect horizontal alignment with left ->
> right-ragged, right -> left-ragged, and center -> justified.

My inclination would be to no-indent the first paragraph, and indent subsequent
paragraphs.  Maybe at the low-end of indentation to minimize even worse
hypenation and word-spacing, given the scarcity of width.  Bringhurst (recently
dis-credited here) says at least 1 en  (2.3.2).  Too many columns like this coul
end up looking horrid, so some education could be part of the sample article.
(See Bully Pulpit nearby.)

I don't feel a need for left-ragged/center/right-ragged, especially because some
other more global halign is in play.  I suspect as a practical matter you might
spend more time defeating/overriding the row/col/tabular setting on many
paragraph cells?  But I haven't even built one practical example.  ;-)

What I meant was that in the context of a paragraph cell, what does halign="right" even mean? I'm suggesting that could mean left-ragged. And vice versa for halign="left".

But I realize now that "center" and "justify" are two different things which might both be wanted by authors. Maybe center not so much as right-ragged and justify, but surely more than left-ragged. Do we let authors have center and justify?

Maybe there needs to be a new attribute @justify=right|center|justify|left, separate from @halign.
 

Remember that we have side-by-side for some of this.

It feels to me like a width specification belongs on a column or a tabular, but
not on a row or a cell.  Orthogonal to your  valign  project.  But coding this
up will likely tell.

OK, so one or more <p> in a column indicates a paragraph cell. In LaTeX XSL, this triggers looking up into the <col> to see if there is a @width specified.

• if the <col> does have a @width, how to use it? I think rather than put it into the alignment string at the start of the tabular, all the paragraph cells need to use \multicolumn{1}{}{}. Because the row's @valign will determine if it is a p{}, m{}, or b{} paragraph.
  
  
• If not, look to the <tabular> for an overall <width>, and if there is one... well, I can't see what to do with that if we are not using the tabularx package. Not knowing how wide any "regular" columns might end up, there's no way to calculate a single paragraph's width just from the tabular's width. So I vote to make tabular/@width ignored for this purpose. You have to specify col/@width (or see next bullet)
  
  
• If the author has not specified widths anywhere, use some kind of defaults like auto and/or 30% as described above.

Sound good?

 

[Rob Beezer]

More later. But first - I did not mean 30% literally as a default, I meant nn%
as the *style* of specifying a width. Not 0.nn, nnex, etc.

Does that moot some of this? (I can't tell if I was misunderstood.)

> * if the <col> does have a @width, how to use it? I think rather than put it

> into the alignment string at the start of the tabular, all the paragraph

> cells need to use \multicolumn{1}{}{}. Because the /row/'s @valign will

> determine if it is a p{}, m{}, or b{} paragraph.
>

> * If not, look to the <tabular> for an overall <width>, and if there is one...

> well, I can't see what to do with that if we are not using the tabularx
> package. Not knowing how wide any "regular" columns might end up, there's no
> way to calculate a single paragraph's width just from the tabular's width.
> So I vote to make tabular/@width ignored for this purpose. You have to
> specify col/@width (or see next bullet)
>

> * If the author has not specified widths anywhere, use some kind of defaults

> like auto and/or 30% as described above.
>
> Sound good?
>
> Thanks for taking this on.
>
> Rob
>

> --
> You received this message because you are subscribed to the Google Groups
> "MathBook XML Support" group.
> To unsubscribe from this group and stop receiving emails from it, send an email
> to mathbook-xml-sup...@googlegroups.com
> <mailto:mathbook-xml-sup...@googlegroups.com>.
> For more options, visit https://groups.google.com/d/optout.

[Alex Jordan]

Alright then, here is my proposal, more streamlined. I feel like HTML and WeBWorK will be easy(er) so this is LaTeX-centric:

One or more <p> in a cell indicates it is a paragraph cell. In LaTeX XSL, this triggers looking up into the corresponding <col> to see if there is a @width.

• if the <col> does have a @width, use \multicolumn{1}{p{width}}{<paragraph text>}. Because the row's @valign will determine if it is a p{}, m{}, or b{} paragraph, this is why a local \multicolumn is used instead of something in the tabular's alignment string.
  
  
• @width is always of the form "X%". Educate authors somehow that small relative widths like 20% will be terrible on small screens.
  
  
• If the author has not specified widths anywhere, use some kind of defaults like auto (for CSS) and/or 1/<number of columns> (in percent form) as described above.
  
  
• Implement right-ragged/justified/center/left-ragged via a new @justify attribute for <p>. In the context of a <p> within a table, <col>s can also have @justify to apply to the <p>'s in that column.

[Alex Jordan]

I think now that these justification options are too much presentation, not content. In the spirit of benevolent dictatorship, we should just pick something that looks good. If authors have some special need for other justification (poetry?) then that's a separate element.

For LaTeX with serifed font, I'd like to explore some kind of width-dependent justification. Fully justified until the width reaches a minimal threshold and then left-justification (ragged-right) kicks in. For CSS with sans serif, my thoughts are that left-justification (ragged-right) all the time is OK.

I don't have typesetting guides though. I'll see what the internet tells me, but if you guys and your physical print typesetting guides have input on this, kindly let me know.

[David Farmer]

I'd like to see some real examples where ragged right is
not appropriate for HTML.

For the LaTeX, it is expected that there be cases which have to
be handled by hand, once per year as the annual official edition
is created. This looks like you are heading into that territory.
So I suggest just offer basic options for now.

When it comes time to do the official micromanagement of such
tables, and we have a few real examples, the I think it is likely
a pattern will emerge and we can do an enhancement that handles
those cases.

Regards,

David

On Sun, 12 Jun 2016, Alex Jordan wrote:

> I think now that these justification options are too much presentation, not content.
> In the spirit of benevolent dictatorship, we should just pick something that looks
> good. If authors have some special need for other justification (poetry?) then
> that's a separate element.
>
> For LaTeX with serifed font, I'd like to explore some kind of width-dependent
> justification. Fully justified until the width reaches a minimal threshold and then
> left-justification (ragged-right) kicks in. For CSS with sans serif, my thoughts are
> that left-justification (ragged-right) all the time is OK.
>
> I don't have typesetting guides though. I'll see what the internet tells me, but if
> you guys and your physical print typesetting guides have input on this, kindly let
> me know.
>
>
> On Saturday, June 11, 2016 at 10:49:48 PM UTC-7, Alex Jordan wrote:
> Alright then, here is my proposal, more streamlined. I feel like HTML
> and WeBWorK will be easy(er) so this is LaTeX-centric:
>
> One or more <p> in a cell indicates it is a paragraph cell. In LaTeX
> XSL, this triggers looking up into the corresponding <col> to see if
> there is a @width.

> o if the <col> does have a @width, use

> \multicolumn{1}{p{width}}{<paragraph text>}. Because the row's
> @valign will determine if it is a p{}, m{}, or b{} paragraph, this
> is why a local \multicolumn is used instead of something in the
> tabular's alignment string.
>

> o @width is always of the form "X%". Educate authors somehow that

> small relative widths like 20% will be terrible on small screens.
>

> o If the author has not specified widths anywhere, use some kind of

> defaults like auto (for CSS) and/or 1/<number of columns> (in
> percent form) as described above.
>

> o Implement right-ragged/justified/center/left-ragged via a new

> @justify attribute for <p>. In the context of a <p> within a table,
> <col>s can also have @justify to apply to the <p>'s in that column.
>

> --
> You received this message because you are subscribed to the Google Groups "MathBook
> XML Support" group.
> To unsubscribe from this group and stop receiving emails from it, send an email to

> mathbook-xml-sup...@googlegroups.com.

[Rob Beezer]

Sounds great. Comments interspersed.

On 06/11/2016 10:49 PM, Alex Jordan wrote:
> Alright then, here is my proposal, more streamlined. I feel like HTML and
> WeBWorK will be easy(er) so this is LaTeX-centric:
>
> One or more <p> in a cell indicates it is a paragraph cell. In LaTeX XSL, this
> triggers looking up into the corresponding <col> to see if there is a @width.

Remember that there is a "colspan" to respect, so you may need to add up widths
across several adjacent columns (just to make it interesting, you know).

There is a new modal template "width-percent-to-real" that will save you some
bother. It will semi-error-check the X% and that feature could be improved.
You can use that to add and then do something like 0.30\linewidth (or is
\textwidth better?).

> * if the <col> does have a @width, use \multicolumn{1}{p{width}}{<paragraph
> text>}. Because the /row/'s @valign will determine if it is a p{}, m{}, or

> b{} paragraph, this is why a local \multicolumn is used instead of something
> in the tabular's alignment string.
>

> * @width is always of the form "X%". Educate authors somehow that small

> relative widths like 20% will be terrible on small screens.

Right - that's what I was driving at.

> * If the author has not specified widths anywhere, use some kind of defaults

> like auto (for CSS) and/or 1/<number of columns> (in percent form) as
> described above.

For reciprocals, you'll likely just compute internally and use the real number.

> * Implement right-ragged/justified/center/left-ragged via a new @justify

> attribute for <p>. In the context of a <p> within a table, <col>s can also
> have @justify to apply to the <p>'s in that column.

Subsequent messages on this thread.

[Rob Beezer]

On 06/12/2016 10:13 AM, Alex Jordan wrote:
> I think now that these justification options are too much presentation, not
> content. In the spirit of benevolent dictatorship, we should just pick something
> that looks good. If authors have some special need for other justification
> (poetry?) then that's a separate element.

For poetry, "poem" now has fine-grained control (announcement soon). I'd think
stuffing them into side-by-side (not yet supported explicitly) would make the
most sense.

> For LaTeX with serifed font, I'd like to explore some kind of width-dependent
> justification. Fully justified until the width reaches a minimal threshold and
> then left-justification (ragged-right) kicks in. For CSS with sans serif, my
> thoughts are that left-justification (ragged-right) all the time is OK.

I like this idea, but also agree with David that maybe this could happen later,
as requested. And LaTeX could be tweaked by hand. For now, universal
ragged-right strikes me as best. A browser will not typically do a straight
right margin on flowable text, no? Perhaps make the "ragged-right" explicit in
the produced LaTeX in a way that search/replace can find it easily and
substitute "center" (not sure if that is feasible or not).

> I don't have typesetting guides though. I'll see what the internet tells me, but
> if you guys and your physical print typesetting guides have input on this,
> kindly let me know.

Bringhurst says ragged-right can look bad ("anorexic") at under 30 characters
per line. But can go to 12 or 15 (in English) for "small patches" like marginal
notes. 66 characters is "considered ideal", so I guess 20% is a bare minimum,
and roughly 50% is a practical minimum for longer stuff.

I greatly expanded the range of LaTeX fontsizes (8pt to 20pt?) and want to set
text width at 30 times the font size (in points), or so (Bringhurst again). In
this way, your percentage widths (and recommendations) will all scale reasonably
uniformly.

Rob

[Alex Jordan]

I have paragraph cells working to my satisfaction in LaTeX, but I think I should post a few questions before I move on to HTML and WeBWorK.

Within a p{} cell in LaTeX, \parskip and \parindent have been reset to 0 (just as they are within a minipage or a parbox). One of them can stay 0, but I think not both. Bringhurst says that block paragraphs (parindent=0, parskip>0) "can be useful in short documents....In longer sequences they may seem soulless and uninviting." I find that indenting these narrow paragraphs makes the interword spacing, already awkward, even moreso. And since the content within a cell is unlikely to be a "longer sequence" that block paragraphs are the way to go. To me, \parskip=0.5\baselineskip looks good. Screenshot attached. Will this pass? (All three vertical alignments are demonstrated too.)

Next question. I have it so that an author can declare a width, only up in the col though, not in the cell. Should I make it so that the width can be more locally defined as an attribute of the cell?

If no width is declared by the author, the XSL first looks to count how many cols there are, N. [If cols are missing altogether, the XSL counts the number of cells in the appropriate row, N.] Then it takes some percentage (I'm using 90) and divides by N. So for example, a two-column table with just single words in the first column and paragraphs in the second, that has no author-defined width, will end up using 45% for the paragraph cell width. My question is about the 90%. In theory this should be about the maximum width (of \linewidth) we want tables to be. In practice, unless all columns are paragraph columns, usually the final width of the table will be less than this percentage. I did not immediately find where Bringhurst might discuss table widths, and also I know that we have special MBX width considerations. So does anyone have a recommendation to replace the "90"?
 

[Rob Beezer]

On 06/17/2016 10:21 AM, Alex Jordan wrote:
> I have paragraph cells working to my satisfaction in LaTeX, but I think I should
> post a few questions before I move on to HTML and WeBWorK.

Excellent! Looking good.

> Within a p{} cell in LaTeX, \parskip and \parindent have been reset to 0 (just
> as they are within a minipage or a parbox). One of them can stay 0, but I think
> not both. Bringhurst says that block paragraphs (parindent=0, parskip>0) "can be
> useful in short documents....In longer sequences they may seem soulless and
> uninviting." I find that indenting these narrow paragraphs makes the interword
> spacing, already awkward, even moreso. And since the content within a cell is
> unlikely to be a "longer sequence" that block paragraphs are the way to go. To
> me, \parskip=0.5\baselineskip looks good. Screenshot attached. Will this pass?
> (All three vertical alignments are demonstrated too.)

Definitely change one. We do block paragraphs with vertical gaps by default on
the HTML side. No indent will help with narrow width jumble. So I'd vote for
zero indent and a gap (which we can fine-tune for appearance later, if we like).

> Next question. I have it so that an author can declare a width, only up in the
> col though, not in the cell. Should I make it so that the width can be more
> locally defined as an attribute of the cell?

And then you can react accurately to @halign? Will you stuff text into a div on
the HTML side so you can respect a width override? Does a bigger width on one
cell override the whole column? If I put widths on a subset of cells of a
particular column can you compute the max width for the (absent) column
specification in LaTeX? Now, add some @colspan streaking through your columns?
Starts to sound problematic (with edge-case goofieness?). I'd just see how
the technical work goes and what problems (author, LaTeX, HTML aspects) crop up.

> If no width is declared by the author, the XSL first looks to count how many
> cols there are, N. [If cols are missing altogether, the XSL counts the number of
> cells in the appropriate row, N.] Then it takes some percentage (I'm using 90)
> and divides by N. So for example, a two-column table with just single words in
> the first column and paragraphs in the second, that has no author-defined width,
> will end up using 45% for the paragraph cell width. My question is about the
> 90%. In theory this should be about the maximum width (of \linewidth) we want
> tables to be. In practice, unless all columns are paragraph columns, usually the
> final width of the table will be less than this percentage. I did not
> immediately find where Bringhurst might discuss table widths, and also I know
> that we have special MBX width considerations. So does anyone have a
> recommendation to replace the "90"?

I put lots of 90% widths in various places as a way of getting some balanced
indentation on the sides. That would be better handled by CSS on the HTML side,
especially if done "responsively" so as to make the best use of small screens.
I'll be changing some 90% to 100% based on Jiri's comments about skinny screens,
knowl borders and 90% figures/images making him feel like a medieval archer
spying the enemy through the slit in the castle wall. An author can shrink an
image down anyway if they choose to.

Looking at your screenshot. For the sample article, a cell with three
paragraphs will best help us eyeball the separation, I think. I think doing
these paragraphs ragged-right would be an improvement (isn't that what
Bringhurst says about things like 2-column pages?). No hyphenation, no bad
word-spacing. In your example, there is a hard right margin from the vertical
rule and to my eye that just accentuated the hyphenation and spacing.

"pulque"?

[David Farmer]

If you let me know what selectors to use (or send a live
link and I'll figure it out), then I can add some CSS for
the p cells.

I am guessing that we want less vertical space between paragraphs
in this case. May also need to trim the margins around a paragraph.

> I put lots of 90% widths in various places as a way of getting some balanced
> indentation on the sides. That would be better handled by CSS on the HTML
> side, especially if done "responsively" so as to make the best use of small
> screens. I'll be changing some 90% to 100% based on Jiri's comments about
> skinny screens, knowl borders and 90% figures/images making him feel like a
> medieval archer spying the enemy through the slit in the castle wall. An
> author can shrink an image down anyway if they choose to.

Rob: it may be that MBX and SL2X manage those widths differently.
I recall wanting to use a purely CSS approach (meaning that the
html does not say anything about widths). If we want to responsively
by (proportionally) wider on a narrow screen, then it would be
better to have it all in CSS.

David

[Rob Beezer]

Right. I agree, and won't guarantee that I have it right in MBX output.

I'm refactoring very fundamental aspects of "blocks" and knowls and being more
careful about related CSS. (Some released soon?)

When you and I can coordinate on a good time for us both, we should do a serious
audit of the CSS MBX is using and needs, etc We'd just need a time we could
both respond quickly to each other and choose a sample document to analyze. I
could produce more readable HTML as part of that.

[David Farmer]

The add-on CSS file has grown quite large. I suspect this
work will just add to it, after which we need a major factorizing
of the SCSS.

I think this should be done after we have the umpteen new environments
people want, and after I get a bit further on the MBX conversions.

> --
> You received this message because you are subscribed to the Google Groups
> "MathBook XML Support" group.
> To unsubscribe from this group and stop receiving emails from it, send an

> email to mathbook-xml-sup...@googlegroups.com.

[Rob Beezer]

On 06/17/2016 01:15 PM, David Farmer wrote:
> The add-on CSS file has grown quite large. I suspect this
> work will just add to it, after which we need a major factorizing
> of the SCSS.

Exactly, but maybe soon we can get some help with that job.

> I think this should be done after we have the umpteen new environments
> people want, and after I get a bit further on the MBX conversions.

Sure. Just on my radar for the summer, so it is easy for me to block out a day
or two to knock it out.

Rob

[Alex Jordan]

"pulque"?

It's good if you like sours and you get it fresh. You can find an approximation in a can in some Mexican groceries.

Followed the LaTeX advice here and am moving on. But here's an observation before I actually start HTML. Naked cell content (meaning not wrapped in "p" or "line") already behaves differently in LaTeX than HTML. In LaTeX, no wrapping. In HTML, it's allowed to wrap. Should this be let alone?

Pro to leaving this alone:
Authors of existing content who like the wrapping they see in HTML get to keep it without any action on their part.

Con to leaving it alone:
You might look at your HTML and think your table is in order, and not realize that because your cell has a rather long phrase, that your LaTeX version of this table cell is way too wide.

Pro to making the HTML not wrap:
Addresses con above.

Con to making the HTML not wrap:
HTML will often be viewed on small screens, and without wrapping, tables could turn into wide scrolling beasts.

Pro to making the LaTeX wrap:
Addresses con above.

Con to making the LaTeX wrap:
Somehow, a defined width has to come into play. If it's author-defined, a burden on the author. If it's automated, no good way to automate a good choice. Likely, automated width calculations will generally overshoot by a lot.

[Alex Jordan]

Need some help, probably from David. But anyone with CSS ideas may be able to offer help.

Background: An author wants to make a table where some cells are paragraph cells and some are not. Refer to Tables 13.12 and 13.13 from http://spot.pcc.edu/~ajordan/temp/section-13.html, or the PDF at http://spot.pcc.edu/~ajordan/temp/derivatives.pdf.

Controlling the width of these things is not as easy as I thought it would be in HTML. Authors have two options: let defaults do what they do, or specify a column's width as a percentage. I have a minor question about my solution to the first option, and a major question about the second.

• If the author relies on defaults, then my solutions for HTML and LaTeX can cause a discrepancy in the relative column widths between the output modes. Since the author didn't care to specify a width, I think this is fine. But I am asking here to confirm that this is OK. Compare Table 13.12 in HTML to PDF. This is where default algorithms are being used.
  
• If the author does specify a width, I'm having trouble with CSS. If the author specifies a percentage width, it should be respected across output modes. In Table 13.13, the paragraph columns have been set to be 25% wide. What then happens is that the browser expands the table itself to take the full available width, reserves 25% for each of the paragraph columns, and then the non-paragraph columns get the rest of the space which is far too much space. I can't get the first two columns to shrink down to being just wide enough, like they are in Table 13.12.
  
  The only solutions I have come up with for this are clearly hacks or accessibility violations. Anyone have any ideas?
  

[Alex Jordan]

For anyone interested in paragraph cells within tables, the holdup has to do with the issue I have posted about here:

http://stackoverflow.com/questions/38314212/set-table-cell-width-to-be-percentage-of-ancestor-without-affecting-neighboring/38314390?noredirect=1#comment64047880_38314390

If you are interested in this issue and have CSS and/or jquery tricks up your sleeve, let me know your thoughts.

[Alex Jordan]

Accidentally pasted a link to a comment in that thread. In case that sub-post gets deleted someday, here is the parent:

http://stackoverflow.com/questions/38314212/set-table-cell-width-to-be-percentage-of-ancestor-without-affecting-neighboring

[Rob Beezer]

I've recently discovered "flex boxes"

Not sure if you can use them on the parts of a table, especially columns, or if
they'd solve your problem. But they are easy and powerful.

https://css-tricks.com/snippets/css/a-guide-to-flexbox/

[Alex Jordan]

I'll look into flex boxes next time I am tackling this.

The SO post has produced an answer that seems to me to work but uses jquery. Are there strong feelings about not using scripting for layout?

[David Farmer]

using scripting for layout = asking for trouble

> --
> You received this message because you are subscribed to the Google Groups "MathBook XML Support"
> group.
> To unsubscribe from this group and stop receiving emails from it, send an email to

> mathbook-xml-sup...@googlegroups.com.

[Alex Jordan]

I agree that scripting should not be considered.

I looked into flexboxes, but I have been unable to make them work in the context of a table with tr rows. I think I understand enough to say that they were not designed for this. In theory they *should* work if you could apply them to col elements in a colgroup. But it appears to me that browsers have not evolved far enough along to use them in this way. colgroup and col have always been odd. They certainly don't work applied one row at a time, because they ruin the alignment of cells above/below each other.

A third possibility is to make a table without using the HTML table element. This would be done by using divs and flexboxes with the right css to align everything. An approach like this to HTML tables might be nice in the long term for all MBX tables, because it allows for pretty cool dynamics with changing screen size and other interactivity. But I'd want to get input from accessibility experts on how accessible such tables can be before considering it seriously.

So here is where I'm at. I'd like to get something acceptable, if not perfect, up and running for both my own needs and Bob's, and others I'm sure. So I can continue with imperfect CSS, complete paragraph tables for WeBWorK too, and make a pull request. Right away I could post a GitHub issue to acknowledge the formatting badness. So, kick the can down the road. Any objections?

To review, here is an extreme example of what the not-perfect formatting from this would look like in HTML: https://jsfiddle.net/2y3uwpq4/. In PDF, the paragraph column would still be 50% but the word column would be minimally narrow. So no problems there.

[Alex Jordan]

Alternatively I could implement the HTML/CSS so that any author-specified percentage is ignored, which would look nicer than what you see in the jsfiddle link. But I think it would be bad long term if an author-specified attribute is ignored in one output mode and used in another, when it would be reasonable to expect it to be made use of in both modes. We certainly need to allow authors to specify widths of these paragraph columns, because in the print version having fine control of this is important for making tables not end up too tall.

[Rob Beezer]

On 07/12/2016 06:31 PM, Alex Jordan wrote:
> I agree that scripting should not be considered.

Good. ;-)

> I looked into flexboxes, but I have been unable to make them work in the context
> of a table with tr rows. I think I understand enough to say that they were not
> designed for this. In theory they *should* work if you could apply them to col
> elements in a colgroup. But it appears to me that browsers have not evolved far
> enough along to use them in this way. colgroup and col have always been odd.
> They certainly don't work applied one row at a time, because they ruin the
> alignment of cells above/below each other.

Sort of as I suspected. With side-by-side I basically have just one row, and an
author is obligated to explicitly or implicitly specify widths, so less to
control for. But they are still worth knowing about and so far are working
splendidly for side-by-side.

> A third possibility is to make a table without using the HTML table element.
> This would be done by using divs and flexboxes with the right css to align
> everything. An approach like this to HTML tables might be nice in the long term
> for all MBX tables, because it allows for pretty cool dynamics with changing
> screen size and other interactivity. But I'd want to get input from
> accessibility experts on how accessible such tables can be before considering it
> seriously.
>
> So here is where I'm at. I'd like to get something acceptable, if not perfect,
> up and running for both my own needs and Bob's, and others I'm sure. So I can
> continue with imperfect CSS, complete paragraph tables for WeBWorK too, and make
> a pull request. Right away I could post a GitHub issue to acknowledge the
> formatting badness. So, kick the can down the road. Any objections?

Yes. ;-) Generally, I'm not a fan of making features available with known
problems. Of course, that depends on the severity of the problem.

> To review, here is an extreme example of what the not-perfect formatting from
> this would look like in HTML: https://jsfiddle.net/2y3uwpq4/. In PDF, the
> paragraph column would still be 50% but the word column would be minimally
> narrow. So no problems there.

What if your example was authored with the first column set as a column of
paragraphs with width 20% (say)? How would that look/behave? Close to what
also happens in PDF?

In other words, is there a way to author that avoids the scenario described and
which can be expected to be future-proof?

Rob

[Alex Jordan]

What if your example was authored with the first column set as a column of
paragraphs with width 20% (say)?  How would that look/behave?  Close to what
also happens in PDF?

In other words, is there a way to author that avoids the scenario described and
which can be expected to be future-proof?

If the author-specified percentage is literally used in inline CSS (which I think it would have to be) then this won't work. (Try it by adding style="width:20%;" to the first col in the jsfiddle.)

What happens is, as soon as some element in the table (col, td) has a width specified as a percentage, then the browser says, percentage of what? The behavior is to assume then that the table has width 100% (of the table's container). In the example you propose, one column would be assigned 20% of that width, and the next 50%, but then that leaves 30%, which gets distributed among the two columns (proportionately or 15% and 15% I'm not sure).

Similar issues if the you make the first column have an absolute width. As long as one percentage is in there, it gets ugly.

What you really want is a way to specify the width of a paragraph column to be a percentage of the block which contains the table. But CSS doesn't allow you to use percentages of ancestors. Either you use percentages of the parent, or of the viewport. (And we can't use the viewport percentages either when you consider tables in sidebysides, dynamically moving between wide screen and small screen, and tables appearing in knowls.)

[Rob Beezer]

Suppose you have two columns, 20% and 50%.

Then give your table right and left 15% margins. Then make your columns

(2/7)*100% and (5/7)*100%

of the resulting 70% wide table.

In other words - author gives textwidth percentages, you compute resuting
percentages with yur knowledge of how CSS "thinks".

I can send in-progress XSL for this approach. (I think I just read that
flexboxes let you just give unit-less numbers and it sorts all this out for you.)

Rob

> --
> You received this message because you are subscribed to the Google Groups
> "MathBook XML Support" group.
> To unsubscribe from this group and stop receiving emails from it, send an email
> to mathbook-xml-sup...@googlegroups.com

> <mailto:mathbook-xml-sup...@googlegroups.com>.

[Alex Jordan]

In other words - author gives textwidth percentages, you compute resuting
percentages with yur knowledge of how CSS "thinks".

I don't like it if an author would now have to declare a width on non-paragraph columns once a paragraph column has a specified width. Ideally such columns should just work at their minimal width to contain their content. What happens if they specify a percentage that works out to be smaller than the length of the text (which is assumed to be single-line and not wrap)? Maybe it's only smaller than the length of the text on some screens that the author is not testing on. And will such width specifications on non-paragraph columns be honored in the LaTeX side? Everything just works there right now using the best width algorithmically determined by LaTeX.

I can send in-progress XSL for this approach.  (I think I just read that
flexboxes let you just give unit-less numbers and it sorts all this out for you.)

Flexboxes do allow for weighting each box and then they are extra space is divvied according to normalizing those weights. But I had no success getting components of a table with display:flex to work. (Not saying it can't be done, just that I tried and couldn't get it.)

[Rob Beezer]

OK, I was trying to see if some of the things I've wrestled with on sidebyside
would carry over.

I have a similar problem - tabular end up being a certain width and are not
"horizontally squishy" like paragraphs, lists, images, poems (sort of), etc. I
think setting a "width" on them in current "sidebyside" is a fiction.

I'll think some more about the current problem.

[Alex Jordan]

This my seem out of place in this thread, but can we assume that the main body in HTML will never be more than 600px wide? Can we further assume that it will never be more than 536px wide once you account for margins?

[David Farmer]

Dear Alex,

We put some care into setting a good maximum line width, to mimic
the well-established text width in books. I think it is unlikely
we will decide to make it larger, and it is extremely unlikely that
we will make it easy for users to choose to over-ride that on
their own.

But note that you can have content that extends past the right
margin: long equations, for example.

What if we implemented "biographical asides" as a tall skinny
column that partially extended into the right margin? That is,
the new element is 200 wide, the main text has been decreased by 100,
the the total "page width" is now 100 wider than usual. Would
that conflict with whatever nefarious purpose lurks behind your
question?

It is the length of a line of text that caused us to set the
current margins. This was in the days before side-by-side.
I don't think we were against the "page" being wider,
if it was made up of elements which separately had suitable line
widths. (That would be for wide browsers, with suitable alternate
behavior on a narrow screen.)

There also is the lucrative real estate of the right margin,
where we may try to put links, post-it notes, etc. But those
are separate entities, outside of the main text.

Regards,

David

On Thu, 28 Jul 2016, Alex Jordan wrote:

> This my seem out of place in this thread, but can we assume that the main body in HTML will never be more than
> 600px wide? Can we further assume that it will never be more than 536px wide once you account for margins?
>

> --
> You received this message because you are subscribed to the Google Groups "MathBook XML Support" group.
> To unsubscribe from this group and stop receiving emails from it, send an email to

> mathbook-xml-sup...@googlegroups.com.

[Alex Jordan]

The reason I am asking is that I'm considering factoring in max-width on some of these table columns and making that an absolute value calculated as a percentage of 536px. So some columns would be say 33%, but have max-width at 177px. All part of my experiments.


On Friday, June 10, 2016 at 9:34:04 PM UTC-7, Alex Jordan wrote:

Planning to continue table features, and paragraph-style cells are next. But what should XML look like for these? LaTeX handles paragraph cells as a kind of horizontal alignment option, as many of you know. To me, what "feels" right though is to make a cell be a paragraph cell just by virtue of having a <p> inside it. So that would be a cell-based approach rather than the column-based approach LaTeX uses.

In all cases, an author must specify some kind of width. Either a width for the cell (or column) that has a paragraph, or perhaps give a width for the whole table and then paragraph cell widths are determined by divvying up available space equally. Widths can be absolute (4cm, 20em, ...) or relative (30%, 0.25).

I imagine that these cells will respect vertical alignment for the row. And if it sounds reasonable, they will respect horizontal alignment with left -> right-ragged, right -> left-ragged, and center -> justified.

As a reminder, a table has a tabular child. The tabular can optionally have empty col children with attributes. And the tabular has row children, which have cell children.

So what would good XML source look like for paragraph cells?

[Rob Beezer]

First variable in xsl/mathbook-html.xsl is

$design-width

initialized to 600. Used presently only to maintain aspect-ratio on embedded
YouTube videos.

> --
> You received this message because you are subscribed to the Google Groups
> "MathBook XML Support" group.
> To unsubscribe from this group and stop receiving emails from it, send an email
> to mathbook-xml-sup...@googlegroups.com

> <mailto:mathbook-xml-sup...@googlegroups.com>.

[Alex Jordan]

Here is my proposed solution to the CSS for tables with one or more paragraph columns. (I really want to get this feature off my queue.)

Example: Author makes a table with 5 columns:

• A: not-paragraph
• B: not-paragraph
• C: paragraph, sets width to 15%
• D: paragraph, sets width to 25%
• E: paragraph, doesn't set width, so default of 1/5 = 20% is used, where the 5 is because there are 5 columns

None of the percents literally go into inline styling for cell/column width. (Because, as discussed in this thread, that leads to messed up spacing with columns A and B).

Instead, columns C, D, and E get their max-width set, respectively, to the absolute values of 536px * 0.15 = 80.4px, 536px * 0.25 = 134px, and 536px * 0.20 = 107.2px. (Why 536? See an earlier post in this thread.)

Probably if you are viewing using a big screen, the contents of C, D, and E will expand to these values wide, and leave A and B in their natural widths. (If A or B has a wide natural width or if {C|D|E} has a narrow natural width then C, D, and E may end up narrow than the author specified.)

If you switch to small screen or if the table is appearing in a too-narrow knowl, then these max-widths do not matter and the browser's auto algorithm does its best to display it all.

1. In principle does this sound OK? (FWIW I think this is the best we can do without script for layout. At worst, a future CSS refactor by an expert could inform us making an improvement.)
   
2. For tables inside sbs, I could factor in the panel's width and margin to use different max-widths that are scaled down accordingly. Good idea? The alternative is to let them behave like as described with small screens and within knowls. I'm inclined to scale them down because the author probably did not make these tables wide in the first place if they are in a sbs.
   
3. For consistency with LaTeX, I'd lean toward "not-paragraph" cells not having wrapped text. If I carried this out, then to get multiline text in a cell you would have to either use paragraph cells or use explicit line elements. This may upset an author who likes the text wrapping that they currently have on the HTML side (but who may be unaware of the ugliness that is happening with their tex output). They may need to change source to wrap p around the cell contents.
   

[Alex Jordan]

Try a live version of my example here: https://jsfiddle.net/2y3uwpq4/2/

See what happens if you narrow the screen.

[David Farmer]

Looks reasonable to me.

David

On Sat, 30 Jul 2016, Alex Jordan wrote:

> Try a live version of my example here: https://jsfiddle.net/2y3uwpq4/2/
>
> See what happens if you narrow the screen.
>
>

> --
> You received this message because you are subscribed to the Google Groups "MathBook XML Support" group.
> To unsubscribe from this group and stop receiving emails from it, send an email to

> mathbook-xml-sup...@googlegroups.com.

[Rob Beezer]

Dear Alex,

Hard-coding widths (max-widths) with pixel counts does not bother me when we
have exhausted more semantic or CSS-styling approaches. I know you have worked
very hard on this one. Questions:

1. If I give no specification of table columns holding paragraphs, will all
output be identical to current status quo? If not, what changes? (Perhaps
other than removing current soft-wrapping).

2. Where does 536px come from? I think we have 600px across the screen.
Generally, I don't care if a table/image/side-by-side goes as wide as the entire
physical screen, since real estate is so precious. Or we have itty-bitty
margins (not ~5%). But I also don't want to upset the fidelity of text chunks
between print and screen, which is remarkably good.

So this is a general question and should not delay your work. Just code it with
a variable, so it is a one-line change later. From my recent sidebyside and
image work, I've been trying to figure out if browsers/CSS/MBX is constraining
widths of figures, etc, some. I'd like to squeeze out as much width as we can -
it is precious. ;-)

3. I need this NOW for a table of short text phrases I just built. (My turn to
beg.) ;-)

Thanks for continuing to hammer away at this one.

Rob

On 07/30/2016 10:33 PM, Alex Jordan wrote:
> Here is my proposed solution to the CSS for tables with one or more paragraph
> columns. (I really want to get this feature off my queue.)
>
> Example: Author makes a table with 5 columns:
>

> * A: not-paragraph
> * B: not-paragraph
> * C: paragraph, sets width to 15%
> * D: paragraph, sets width to 25%
> * E: paragraph, doesn't set width, so default of 1/5 = 20% is used, where the

> 5 is because there are 5 columns
>
> None of the percents literally go into inline styling for cell/column width.
> (Because, as discussed in this thread, that leads to messed up spacing with
> columns A and B).
>
> Instead, columns C, D, and E get their max-width set, respectively, to the
> absolute values of 536px * 0.15 = 80.4px, 536px * 0.25 = 134px, and 536px * 0.20
> = 107.2px. (Why 536? See an earlier post in this thread.)
>

> /Probably/ if you are viewing using a big screen, the contents of C, D, and E

> will expand to these values wide, and leave A and B in their natural widths. (If
> A or B has a wide natural width or if {C|D|E} has a narrow natural width then C,
> D, and E may end up narrow than the author specified.)
>
> If you switch to small screen or if the table is appearing in a too-narrow
> knowl, then these max-widths do not matter and the browser's auto algorithm does
> its best to display it all.
>

> 1. In principle does this sound OK? (FWIW I think this is the best we can do

> without script for layout. At worst, a future CSS refactor by an expert
> could inform us making an improvement.)

> 2. For tables inside sbs, I could factor in the panel's width and margin to use

> different max-widths that are scaled down accordingly. Good idea? The
> alternative is to let them behave like as described with small screens and
> within knowls. I'm inclined to scale them down because the author probably
> did not make these tables wide in the first place if they are in a sbs.

> 3. For consistency with LaTeX, I'd lean toward "not-paragraph" cells /not/

> having wrapped text. If I carried this out, then to get multiline text in a

> cell you would /have/ to either use paragraph cells or use explicit line

> elements. This may upset an author who likes the text wrapping that they
> currently have on the HTML side (but who may be unaware of the ugliness that
> is happening with their tex output). They may need to change source to wrap
> p around the cell contents.
>
>

[Alex Jordan]

1.  If I give no specification of table columns holding paragraphs, will all
output be identical to current status quo?  If not, what changes?  (Perhaps
other than removing current soft-wrapping).

You mean no width specification? If such a column has a p in it and there are N columns, then 1/N is the default width.
This doesn't really change anything because currently cells should not have any p's in them.

Or put another way, if the table is written to respect the current DTD, then nothing will change. The moment there is a p
inside a cell, or a col gets a width attribute, or halign="justify" is used somewhere, then one cell at least is going to have new
formatting (and likely the cells in its row or col too).

I have a comprehensive example in the sample article preceded by a full explanation. Review it when the PR comes in and then
send me adjustments.

 

2.  Where does 536px come from?  I think we have 600px across the screen.
Generally, I don't care if a table/image/side-by-side goes as wide as the entire
physical screen, since real estate is so precious.  Or we have itty-bitty
margins (not ~5%).  But I also don't want to upset the fidelity of text chunks
between print and screen, which is remarkably good.

600px is the width of the central panel but the main content has left and right margins
that are hard coded at 32px when viewing in wide-screen mode. So 536=600-32-32.
536 is more accurately the content width.
 

So this is a general question and should not delay your work.  Just code it with
a variable, so it is a one-line change later.  From my recent sidebyside and
image work, I've been trying to figure out if browsers/CSS/MBX is constraining
widths of figures, etc, some.  I'd like to squeeze out as much width as we can -
it is precious. ;-)

Will do. You already have 600 as a variable. I might add the 32px margin as a variable
and let 536 be calculated from these.

3.  I need this NOW for a table of short text phrases I just built.  (My turn to
beg.)  ;-)

I'm in the home stretch as far as LaTeX and HTML. (Although I'll need to send final CSS
adjustments to David.) If it ended there, I could probably PR tonight. But then there is PG
which might take 10 minutes or 10 hours to figure out. Haven't given it a second of thought yet.
Do you need it urgently enough to settle for a first run that doesn't implement in PG?

[Rob Beezer]

On 07/31/2016 02:32 PM, Alex Jordan wrote:
> Do you need it urgently enough to settle for a first run that doesn't implement
> in PG?

Definitely teasing. ;-) No rush at all, but I did author and push something
that will need it (currently has disclaimer).

Thanks for the answers. More later.

[Robert Beezer]

Alex Jordan (aka The Table Master) has just contributed the ability to put paragraphs into table cells.

If you use a "p" in a table cell, then the whole cell must be structured as a sequence of "p" (only), and you need to give a width as a percentage on the relevant "col" element (which may mean you need several empty "col").

This is different that using "line" in a cell, which creates lines that break exactly where you want them to.

As usual, for more careful details, see examples in Section 13 of the sample article.  Notice there the behavior of the side-by-side with two tables, each with paragraph cells, as you skinny-up your browser window or view on a small device.

Thanks, Alex!

(Side note: the pull-request queue is empty for the first time in a long while.  Hint, hint.)