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

Child doesn't get clipped if width/height is 100% #650

Closed
Paril opened this issue Aug 11, 2024 · 4 comments
Closed

Child doesn't get clipped if width/height is 100% #650

Paril opened this issue Aug 11, 2024 · 4 comments
Labels

Comments

@Paril
Copy link
Contributor

Paril commented Aug 11, 2024

This is an an oddly specific situation, but when a transformation is applied that causes an elements' bounds to overflow, it will erroneously not pick up that it needs a clipping context.

A minimal reproduction is available with this file loaded into load_document.exe in Rml 5.0 and 6.0 (note that I'd love for there to be a generic player that we could use just to drag .rml files into and preview them instantly. Would make making bug reports so much easier!)

<rml>
	<head>
		<title>Demo</title>
		<link type="text/rcss" href="rml.rcss"/>
		<style>
			body
			{
				width: 100%;
				height: 100%;

				font-family: LatoLatin;
				font-weight: normal;
				font-style: normal;
				font-size: 15dp;
				color: white;
			}

			#inner
			{
				position: relative;
				left: 100px;
				top: 100px;
				width: 64px;
				height: 256px;
				overflow: hidden;
			}

			#transform
			{
				transform: rotate(-45deg);
				decorator: image(rmlui.tga contain);
				background: white;
				width: 100%;
				height: 100%;
			}
		</style>
	</head>
	<body>
	<div id="inner">
		<div id="transform" />
	</div>
	</body>
</rml>

Note that even though the objects' real bounds expand outside of the parent, it doesn't pick up that it has overflowed. In HTML, the behavior is to clip it; https://codepen.io/Paril/pen/qBzPpZW

I can work around this with clip: always but it seems like it's just using the inner objects' pre-transformed width/height rather than post-transformed box for checking if overflow needs to happen.

@mikke89
Copy link
Owner

mikke89 commented Aug 11, 2024

Thanks for reporting. This one is a known limitation actually, and the reasoning is the same as with absolutely positioned elements which has been reported previously: #235. This situation is also exactly why we introduced clip: always. In my view, that is a reasonable solution to such situations.

If we instead made it so that transforms could affect layout, performance would suffer a great deal, particularly when combined with animations. I'm sure there are some ways we could potentially work around it, without the performance degradation in all situations. But it's not something I can prioritize right now.

note that I'd love for there to be a generic player that we could use just to drag .rml files into and preview them instantly.

That's a cool idea, I like it.

@Paril
Copy link
Contributor Author

Paril commented Aug 12, 2024

Ah, okay, that makes sense! I tried to search for this issue but my keywords weren't finding it. If it's intentional, I would just close this issue then; could we add a note on either https://mikke89.github.io/RmlUiDoc/pages/cpp_manual/animations_transforms.html or https://mikke89.github.io/RmlUiDoc/pages/rcss/animations_transitions_transforms.html ? These are the two pages I referred to to see if I was missing some sort of limitation about transform, I imagine most people will look there first too.

A player executable would be super useful, yeah. I've gotten mileage out of loaddocument but it's still pretty limited. Would be neat to be able to just make a zip containing .rml/.rcss/.tga files and be able to drag it into the player, and just posting that zip on github when reproducing bugs (or just a single .rml file if the player supports base64 URIs for embedding images)

@mikke89
Copy link
Owner

mikke89 commented Aug 12, 2024

Good idea, this should be better documented indeed. I've made some notes in the above commit.

Thanks for the suggestion, that would be quite neat, I've made a note of it for now.

@mikke89 mikke89 added support Usage questions documentation labels Aug 15, 2024
@mikke89
Copy link
Owner

mikke89 commented Aug 15, 2024

Closing this one, as I believe it has been resolved with the updated documentation.

@mikke89 mikke89 closed this as completed Aug 15, 2024
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Projects
None yet
Development

No branches or pull requests

2 participants