-
Notifications
You must be signed in to change notification settings - Fork 17
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
What should constraining the block-progression direction do? #43
Comments
Intuitively, I don't think clipping makes much sense (and default for CSS is overflow: visible anyhow). If we format the runs and expose line metrics, we'd have to lay everything out anyways. So maybe we apply that principle, and leave clipping up to the canvas renderer if necessary? |
Yes, that makes sense to me. It could also be interesting to expose a boolean line metric flag that would be true when the particular line intersects with or is beyond the provided bounding box of the provided constraints. |
You might want to have it lay out as many lines as will fit, and then stop, and allow the caller to continue formatting the paragraph in another function call (or not format it, similar to using line-clamp). |
But also, if you're not sure what you want to do, maybe you don't offer this parameter. :) |
The explainer's data model allows height and width to be specified. Depending on the writing-mode specified on the context object, either of these dimensions could become the block-progression direction. We know that we want the inline direction to wrap content. But what should happen when the limit specified in the block direction is reached?
This was brought up in review of PR 39
The text was updated successfully, but these errors were encountered: