Allow for "bleeds" on wide content?

[iherman]

This may be related to issue #24, but I am not entirely sure that one fully cover it.

The new design has restricted the default width of the text significantly. This creates issues with documents that were prepared under the old style; their transition to the new style may become fairly difficult and time consuming. The difficulty comes with content like large tables or diagrams that try to make use of the full width of a window and which cannot simply be shrunk without loosing readability. Just two examples, both from an upcoming Rec related to CSV on the Web (typically on data table, thus...):

• large diagram
• large table (please push the button down in the section labelled as "show detailed table annotations" to see them all)

I have made some local experimentation with these by simply exchanging the style file reference, and the result are fairly bad. The way I see it the only viable approach today would require a significant editorial re-engineering to make the examples and/or the diagrams usable. (This is a real drag at this stage of the process.) I am not sure whether there is a way to alleviate this. (E.g., is it possible to allow some 'bleed' of these content into the wide margin on the right? Not nice, but may be necessary... Or switch "off" the large margins for the document through a specific class.)

Cc: @plehegar @r12a @gkellogg @JeniT @6a6d74

[r12a]

Issue #24 would indeed help with this situation, by preventing wastage of potential expansion space on the left of the main text block.

However, I didn't mention in issue #24 that large diagrams and tables should be allowed to move past the main text column and expand as the width of the window expands, because I thought that was already agreed, but we should check that that is actually the case. My expectation was that any figure or table would be free to grow past the edge of the main text block to the right. Whether or not the item needs to be in a container with a special class name, i'm not sure (since some examples, especially rtl text, may look neater if constrained to the width of the main text block).

Here is also a case where it would be good to allow the user to switch off/on the display of the TOC on the left of the page since, given that at a certain width the expansion space is suddenly swallowed up again by the TOC, you really have to make the window much wider to see large tables and diagrams.

(I'm a little concerned that we only have one demo document for the styling and that it is limited in the range of features it includes (eg. no wide diagrams and tables). I'll raise a separate issue about that.)

By the way, Ivan, it may help (even in the current style) to set the width of the large diagram to something more than 75%.

(It may also help to reduce the font-size slightly for the large table in the new style.)

[iherman]

On 11 Nov 2015, at 07:52, r12a notifications@github.com wrote:

Issue #24 #24 would indeed help with this situation, by preventing wastage of potential expansion space on the left of the main text block.

However, I didn't mention in issue #24 #24 that large diagrams and tables should be allowed to move past the main text column and expand as the width of the window expands, because I thought that was already agreed, but we should check that that is actually the case. My expectation was that any figure or table would be free to grow past the edge of the main text block to the right. Whether or not the item needs to be in a container with a special class name, i'm not sure (since some examples, especially rtl text, may look neater if constrained to the width of the main text block).

Here is also a case where it would be good to allow the user to switch off/on the display of the TOC on the left of the page since, given that at a certain width the expansion space is suddenly swallowed up again by the TOC, you really have to make the window much wider to see large tables and diagrams.

(I'm a little concerned that we only have one demo document for the styling and that it is limited in the range of features it includes (eg. no wide diagrams and tables). I'll raise a separate issue about that.)

+1
By the way, Ivan, it may help (even in the current style) to set the width of the large diagram to something more than 75%.

(It may also help to reduce the font-size slightly for the large table in the new style.)

Both of these statements are true, but that I believe the larger issue is still relevant. Those changes would not radically improve the situation.

[fantasai]

There's not much I can do in CSS atm that will allow content to make use of space outside max-width unless it genuinely can't fit inside. If it doesn't fit, it will of course spill out. Note however, this means it is unlikely to fit on an A4 sheet when printed, either!!!!

Printing aside (which I can't help), I can add a class that will size an element to the width of the viewport. This can be used to make the element that size (which may be too big, e.g. for a table that's only needs half the size of the viewport, it will still be stretched to the size of the viewport). Or it can be used to create a container for such overlarge content, in which case the content will just see that it has a viewport-sized space available to it and use as much of that space as it needs. However in this case you won't be able to do very sensible centering, since it'll center in that viewport-sized container and not align to the rest of the text column, even if it could. (Either way it's kindof awkward.)

Btw, since content can spill out if it doesn't fit, then you can prevent a table from squashing by adding "@media not print { table { white-space: nowrap; } }".

There's a wide table in the index section, fwiw. :) But I'm happy to add more content to the sample document. In fact, if you want to add a PR to add more chapters similar to "Sample CSS Section", please go ahead. I only haven't done it because I haven't gotten around copying bits of other specs in myself.

[iherman]

@fantasai, I have tried the @media based approach and it indeed helps in many cases. In the specific case of the documents that I referred to it does not solve all the problems (there is also a large left margin which is not used, so the real estate for print, with equivalent sized windows, is still significantly smaller than in the old TR style), but it eases things.

For the use case I had in mind we will probably bypass the issue because we will try to publish the Rec this year. For documents which have more leeway for editorial changes (which is not the case for a Proposed Rec transition to Rec) they can be adapted indeed.

Two minor comments:

• It may be worth adding a general class (something like large) for tables and maybe figures that is styled with the @media rule above, so that authors could selectively choose to bleed the content or not
• Yes, it would be great to have an example in the sample document. I will see if I can do something myself, but maybe it is worth doing only if and when a generic class is added (if you agree having that)

[r12a]

[bring this up here, because there's no indication that https://github.com//issues/24 has been noticed]

During TPAC we agreed that there would be a fixed distance margin on the right of the main text block, and that if the window size was increased horizontally the max-width would therefore produce a variable and potentially much larger margin to the right, so as to better accommodate wide tables, diagrams, etc.

Please implement this. Thanks.

[fantasai]

Okay, I've adjusted the default max-width on figures to be the viewport size rather than 100% of the body text block, and added a .overlarge class for when you want to assign the viewport width to a particular element. Let me know if that seems good, or if you have other ideas for this problem.

[iherman]

On 8 Dec 2015, at 06:39, fantasai notifications@github.com wrote:

Okay, I've adjusted the default max-width on figures to be the viewport size rather than 100% of the body text block, and added a .overlarge class for when you want to assign the viewport width to a particular element. Let me know if that seems good, or if you have other ideas for this problem.

That sounds good; will you add an example into the doc on how that should be used? I would prefer you did it rather than I (or anybody else) trying to reproduce what is necessary…

Thanks

[fantasai]

Ah, I checked that in, but forgot to upload it to my website. http://fantasai.inkedblade.net/style/design/w3c-restyle/2016/sample#overlarge

[iherman]

Thank you!

On 8 Dec 2015, at 14:51, fantasai notifications@github.com wrote:

Ah, I checked that in, but forgot to upload it to my website. http://fantasai.inkedblade.net/style/design/w3c-restyle/2016/sample#overlarge http://fantasai.inkedblade.net/style/design/w3c-restyle/2016/sample#overlarge

[r12a]

Let me know if that seems good, or if you have other ideas for this problem.

i'm inclined to think, after some playing around, that it would be nicer if figures with .overlarge set had text-align: start, especially for items that are only a small amount larger than 50em. A problem you then get with figures however is the positioning of the caption. Any ideas? @iherman what do you think?

[iherman]

On 9 Dec 2015, at 18:51, r12a notifications@github.com wrote:

Let me know if that seems good, or if you have other ideas for this problem.

i'm inclined to think, after some playing around, that it would be nicer if figures with .overlarge set had text-align: start, especially for items that are only a small amount larger than 50em. A problem you then get with figures however is the positioning of the caption. Any ideas? @iherman what do you think?

I think this is indeed a bit better; I guess people will try to avoid the usage of .overlarge, except for larger items, and in those cases every inch (well, every px:-) counts. Ie, to push the image to the left for latin based texts (I guess that is what 'start' means) is indeed sensible.

For the positioning of the caption: the only issue is that it should be consistent with all other figures. Ie, if it is centralized elsewhere, it should be the same for this case. Is that a major issue?

Ivan

[r12a]

here's the problem with captions. Imagine you have a figure containing an image and a caption. Imagine also that your window is 100em wide (about twice the width of the main text column), and that the image is 75em wide. If the caption is centred on the figure width, it will be too far to the right to look correctly positioned relative to the image. I don't know how to position it within the space actually taken by the image (ie. within the 75em width).

[iherman]

On 10 Dec 2015, at 10:53, r12a notifications@github.com wrote:

here's the problem with captions. Imagine you have a figure containing an image and a caption. Imagine also that your window is 100em wide (about twice the width of the main text column), and that the image is 75em wide. If the caption is centred on the figure width, it will be too far to the right to look correctly positioned relative to the image. I don't know how to position it within the space actually taken by the image (ie. within the 75em width)

Ah! Yep, indeed, this is a problem:-( Unless we decide to align the caption by 'start' in general, but that may be ugly. Sigh:-(, I do not have a solution...

[r12a]

Actually, what seems to work better for a figure containing a wide graphic and a caption is to not use .overlarge. The image takes the space it needs and the caption is centred within that space. (If there are multiple images on one line, set the container of the images to white-space: nowrap, or set the figure to nowrap and the caption to normal.)

Perhaps .overlarge is best used just for very wide tables, without captions. But i still suspect that .overlarge should include text-align:start.