Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

[css-multicol] Improve column-fill example 26 and example 27 #3700

Closed
TalbotG opened this issue Mar 1, 2019 · 20 comments
Closed

[css-multicol] Improve column-fill example 26 and example 27 #3700

TalbotG opened this issue Mar 1, 2019 · 20 comments
Labels
css-multicol-1 Current Work

Comments

@TalbotG
Copy link
Collaborator

TalbotG commented Mar 1, 2019

@rachelandrew

After carefully examining the column-fill: balance Example 26 from the spec and the column-fill: auto Example 27 from the spec, I created these 2 pages:

column-fill: balance Example 26 GT

column-fill: auto Example-27 GT

I propose the following changes to examples 26 and 27 from the spec:

  • a width of 41em (and not 60em) if+since+because the font-size of text is 18px. That way, SVG image of rendered layout will better match the actual CSS code
  • since "Column rules are only drawn between two columns that both have content", then both SVG images (expected rendered layout) should be corrected
  • more text content so that the examples would not require to style 'widows' and 'orphans' and to set them to 1. The initial value of 'widows' and 'orphans' is 2. So, example 26 needs just more text content so that there are at least 2 line boxes in each column boxes. Otherwise, add 'orphans: 1' and 'widows: 1' to the code of both examples. Without 'orphans: 1' and 'widows: 1' or without more text content, the examples are not perfectly reliable or trustworthy
  • Linux users do not necessarly have installed (or preinstalled) Arial or Arial MT typefaces. So, in the SVG code, adding "Liberation Sans" is a tiny bit better+preferable.
@rachelandrew
Copy link
Contributor

Thanks for the notes however, in the ED the rules have been already corrected (you are referring to a now quite out of date WD, I'm going to request republication of the WD after doing the edits for the recent resolutions). In general you should look to the ED of any spec you want to comment on as that is our working document.

I'l have a look at the other things when I next look at diagrams.

@TalbotG
Copy link
Collaborator Author

TalbotG commented Mar 2, 2019

in the ED the rules have been already corrected

At first, I did not understand what you meant. But now I do. You must have meant to say the column-rules.

you should look to the ED of any spec you want to comment on as that is our working document.

I indeed looked at the Editor's Draft, section 7.1 column-fill before posting this. And there is no SVG images for example 26 and 27 in the Editor's Draft.

The main purpose or motivation of this (issue) post is to see code examples that are as realistical and reliable and trustworthy as possible.

@rachelandrew
Copy link
Contributor

The images in the ED currently aren't loading, there seems to be a server error. However as I mentioned they have been corrected already.

@plinss
Copy link
Member

plinss commented Mar 2, 2019

server error should be fixed

@TalbotG
Copy link
Collaborator Author

TalbotG commented Mar 2, 2019

Peter, Rachel,
There are 4 SVG images in section 7.1 that are still not loading in the Editor's Draft.
Example 26, section 7.1 in Editor's Draft.
images/column-balancing-one-paragraph.svg is not loaded.

There is also rather odd code in the examples. Eg
<pre class="highlight"><c- f="">article </c-><c- p="">{</c-> <c- k="">width</c-><c- p="">:</c-> <c- m="">60</c-><c- l="">em</c-><c- p="">;</c-> <c- k="">height</c-><c- p="">:</c-> auto<c- p="">;</c-> <c- k="">columns</c-><c- p="">:</c-> <c- m="">4</c-><c- p="">;</c-> <c- k="">column-fill</c-><c- p="">:</c-> balance<c- p="">;</c-> <c- p="">}</c-> </pre>

@rachelandrew
Copy link
Contributor

That is code from the syntax highlighter, you don't need to view source to use the example. Unless you mean it is visible on the page, I can't see that.

@plinss
Copy link
Member

plinss commented Mar 2, 2019

It seems like you're running into problems with the server's DoS filter blocking some requests (the large number of images in that spec push the limits). I've made some adjustments and it should be better.

@TalbotG
Copy link
Collaborator Author

TalbotG commented Mar 2, 2019

Rachel,
No, the code from the syntax highlighter is not visible on the page.

(Now that I can see the newer SGV images) The font size definitely seems smaller now (by comparison with the font size of images in Latest published version) while the typeface is most likely the same as before. It's possible to approximate the code needed to generate such renderings. The SVG code of images was easier to understand before; now the SVG code is unfortunately a very long <path> and 2 data:image/png;base64
In order to be fully interoperable, reliable and trustworthy, Example 26's code would need either orphans: 1 and widows: 1 or more text content to achieve 2 line boxes. This issue is admittedly not critical or very important.

Peter,
I can see the SVG images now. Thank you!
I probably should just copy the code of images instead of direct-linking to those in my 2 test pages.

@rachelandrew rachelandrew added this to Needs action in css-multicol-1 Mar 9, 2019
@fantasai fantasai added the css-multicol-1 Current Work label Apr 18, 2019
@rachelandrew
Copy link
Contributor

Hi @TalbotG - I'm trying to understand if you think there should be any changes from your comment.

If yes, can you clarify? If not please let me know so I can close the issue - thanks!

@TalbotG
Copy link
Collaborator Author

TalbotG commented May 30, 2019

Rachel,
The only issue I see relates to Example 26 in the Editor's Draft which I believe should have either orphans: 1 and widows: 1 or more text content to achieve 2 line boxes.

To understand why, please load
Example 26 without orphans: 1
and
Example 26 without widows: 1
in Chromium 73+. Chromium 73+ renders both files accurately, precisely and as expected.

@TalbotG
Copy link
Collaborator Author

TalbotG commented May 30, 2019

Also
Example 26 without orphans: 1 and without widows: 1
Again, Chromium 73+ handles that file accurately.
Firefox has no support for orphans and widows (bug 137367)
(I expect to be very busy in the next 5 days and might be slow responding).

@rachelandrew
Copy link
Contributor

I think we may be thinking of two different things here, but the property column-fill is only consulted if the height is other than auto in continuous contexts. Chrome renders correctly without an orphans or widows property, if the container has a height (for example 25px). The spec says that the behavior should be balance if the container is not restricted in the block dimension, so I think that is the Chrome bug. I'm not therefore sure where orphans and widows comes into it.

I think Firefox Nightly has the correct behavior, and again doesn't need orphans or widows to achieve the content split across the first three boxes.

https://codepen.io/rachelandrew/pen/c1bb5629cf4a431054c188b9ca3d8190

I don't understand what you mean about two line boxes hence me wondering if we are talking about two different things.

@TalbotG
Copy link
Collaborator Author

TalbotG commented May 30, 2019

The default orphans value is 2. The default widows value is 2. If in those tests, the orphans: 1 and/or widows: 1 declarations are removed, then the defaults prevail. That is why I say that one option is to add more text content in Example 26 so that 2 line boxes are generated.
What I wrote in my initial comment (1 Mar; 3rd bullet) still applies.

@rachelandrew
Copy link
Contributor

I'm afraid I still don't understand your statement about the example not being trustworthy. As I don't think we need to set orphans and widows to 1. Happy to change the example if I can understand a compelling reason why.

@TalbotG
Copy link
Collaborator Author

TalbotG commented May 30, 2019

If columns are balanced, user agents should try to minimize variations in column height, while honoring forced breaks, widows and orphans, and other properties that may affect column heights.

coming from §7. Filling columns

Column-fill: balance Example 26 with 2 line boxes

Your codepen example uses height: 25px while I use height: auto.

In your codepen example, as soon as content height of multicolumn container is set to 42px (or greater) instead of 25px, then the effect of orphans: 2 occurs (you must use Chromium 73+ or even Opera 12.16 to see such effect). 42px means there is enough vertical space for the 2 line boxes: in which case orphans: 2 can have an effect in such situation.

the property column-fill is only consulted if the height is other than auto in continuous contexts.

Is this the case? Where does the spec state this?

@rachelandrew
Copy link
Contributor

"In continuous contexts, this property will only be consulted if the length of columns has been constrained in the block dimension, including min and max constraints (e.g., height, min-height, max-height). Otherwise, columns will automatically be balanced."

added fairly recently, the changelog details why the example is as it is. https://drafts.csswg.org/css-multicol/#changes-from-20180528

I think the example is correct in terms of the result it is demonstrating. You seem to be basing your suggestion on one browser implementation, and there are many examples in the spec that wouldn't work if we did that.

@TalbotG
Copy link
Collaborator Author

TalbotG commented May 31, 2019

Okay. I read the change... but I do not think this makes significant difference with regards to how orphans and widows can have an effect on line boxes and content distribution among columns.

I have replaced height: auto with height: 3.42em in these 4 tests:

Example 26 without orphans: 1
Example 26 without widows: 1
Example 26 without orphans: 1 and without widows: 1
Column-fill: balance Example 26 with 2 line boxes

and I still believe Chromium 73+ (and presumably Opera 12.16) handle the first 3 tests correctly, precisely and as expected.


Right now, this statement

If columns are balanced, user agents should try to minimize variations in column height, while honoring forced breaks, widows and orphans, and other properties that may affect column heights.

has no examples and no tests.

@rachelandrew
Copy link
Contributor

please raise a new issue for each different thing - it is very hard to deal with more than one thing in an issue without things being missed. Thank you!

@rachelandrew
Copy link
Contributor

rachelandrew commented Oct 13, 2019

Just wanted to add a note here to say this isn't being ignored. The CSSWG have resolved to revert the change which impacts these examples, pending discussion to resolve the issue. As this is going to change these examples, I'll take a look at them again once we have a resolution on the issues around column-fill are resolved, as whatever happens they are going to need further changes.

@rachelandrew
Copy link
Contributor

The part of the spec this all referred to has been changed, and examples removed and renumbered.

If you think there are still issues with examples in the updated spec please raise a new issue - thanks!

@rachelandrew rachelandrew moved this from Needs action to Done in css-multicol-1 Feb 8, 2021
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
css-multicol-1 Current Work
Projects
Development

No branches or pull requests

4 participants