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

Presentation for inline link #1799

Merged
merged 2 commits into from
Jul 15, 2016
Merged

Presentation for inline link #1799

merged 2 commits into from
Jul 15, 2016

Conversation

stefanpearson
Copy link

Fixed #1751, PR to matrix-react-sdk to follow

Signed-off-by: Stefan Pearson stefan@ribot.co.uk

@matrixbot
Copy link

Can one of the admins verify this patch?

.mx_EventTile_content {
display: block;
overflow-y: hidden;
overflow-x: hidden;
/*overflow-y: hidden;
Copy link
Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This may become an issue, but it's the only way to hang elements out of the container.

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This was certainly an issue in the past, however, is it possible that overflow-x: visible is the right fix? (Bug #1154 was ugly scrollbar caused by overflow-x defaulting to scroll). We have to keep the overflow-y: hidden (unless you want to hang elements above/below the container for some reason?) in order to trap Zalgos, which are an amusingly common phenomenon in Matrix thanks to the early geeky audience. For instance, right now in #matrix-dev, this is the only thing stopping the top of SkaveRat's nick splurging all over Ralith:

screen shot 2016-07-15 at 11 06 52

.mx_EventTile_content {
display: block;
overflow-y: hidden;
overflow-x: hidden;
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

don't we want overflow: visible; rather than the default auto here to avoid a repeat performance of #1154?

@ara4n
Copy link
Member

ara4n commented Jul 15, 2016

lgtm other than final question. i'll then merge it and unravel the mess with relying on markdown-body to de-zalgo HTML

@ara4n
Copy link
Member

ara4n commented Jul 15, 2016

going to merge this anyway and worry about the potential #1154 regression so I can fix the markdown-body mess

@ara4n ara4n merged commit 6607bee into element-hq:develop Jul 15, 2016
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

3 participants