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

Title link shifted in Chrome #4

Open
fn-ix opened this issue Sep 27, 2018 · 5 comments
Open

Title link shifted in Chrome #4

fn-ix opened this issue Sep 27, 2018 · 5 comments
Labels

Comments

@fn-ix
Copy link

fn-ix commented Sep 27, 2018

Hi!

When hovering the main title in Chrome, the link area, which turns the title to a link when hovered, seems to be shifted a few pixels above the text:
ed-1
ed-2

Curiously, I don't experience this behaviour in Firefox, and the masthead CSS seems fine to me.

@karlstolley
Copy link
Member

I'm not seeing this in Chrome Version 71.0.3578.98 (Official Build) (64-bit) on MacOS. @HFel -- are you still seeing this? And if so, can you give build/OS details? Thanks!

@fn-ix
Copy link
Author

fn-ix commented Jan 20, 2019

Yeah. It seems the inactive area has shifted downwards, but there is still some space:
edms

On Firefox:
edmsff

Using Chromium Version 71.0.3578.98 on Manjaro KDE 18.0.2.

@karlstolley
Copy link
Member

Okay--I think I see what you mean now. Looks to be a Chrome issue for how it draws clickable areas on text. But I'm keeping this issue open to see how this can be improved in future versions of ed (likely by increasing the clickable area to the entire masthead, or at the very least displaying the <a> tag as a block or inline block.

@fn-ix
Copy link
Author

fn-ix commented Jan 20, 2019

I tried the suggested display properties but they didn't have any effect for me, however I was tinkering around and setting the position as anything other than static seems to have fixed it, or at least it behaves the same way now in Chrome as in Firefox. I'm not sure why exactly though.

@karlstolley
Copy link
Member

Yeah, that's really odd. I need to study other positioning things that might be in play, because the implicit position: static should produce just a vanilla block-formatting context on its own. Setting something like position: relative does, as you say, seem to improve matters—but I'd rather avoid doing hacky little things like that and instead rebuild this to behave properly.

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