Skip to content

[css-page-floats] Snap to nearest edge #1233

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

Open
frivoal opened this issue Apr 18, 2017 · 3 comments
Open

[css-page-floats] Snap to nearest edge #1233

frivoal opened this issue Apr 18, 2017 · 3 comments
Assignees

Comments

@frivoal
Copy link
Collaborator

frivoal commented Apr 18, 2017

There is a common requirements for page (or column) floats that cannot be achieved with the current spec, but could be with a minor tweak.

Authors often want a figure to be floated either to the top or the bottom of the page, whichever is nearest.

This could be achieved by amending the definition of snap-block() as follow:

If near is in effect and the element is within the specified distance both from the start and the end, endthe nearest edge wins. In case the distance to the start and end edges is equal, the end edge wins.

Also, for convenience, and to prevent authors from needing to write snap-block(9999px, near) or other arbitrarily large values just to make sure both edges are within the specified distance, we suggest that the definition of snap-block (without parentheses) is changed to mean snap-block( infinity, near) instead of snap-block(2em, near)

The same changes should be done to snap-inline.


Note: regardless of whether we fix that or not, we need a precise definition of how to measure that distance. I'll file a separate issue for that.

@frivoal frivoal self-assigned this Apr 18, 2017
@frivoal
Copy link
Collaborator Author

frivoal commented Apr 18, 2017

I'll file a separate issue for that.

#1234

@MurakamiShinyu
Copy link
Collaborator

I think float: top bottom or float: block-start block-end might be better than float: snap-block.

I wrote a new float syntax proposal #1251.

@johanneswilm
Copy link
Contributor

@frivoal @MurakamiShinyu Both proposals make sense to me. I don't have much of a preference.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

4 participants