-
Notifications
You must be signed in to change notification settings - Fork 9
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
Tune links and hashes #1290
Tune links and hashes #1290
Conversation
Deployed to Cloudflare Pages
|
2238690
to
603bd36
Compare
d5cb70e
to
20fdc32
Compare
Thanks @csillag I was suggesting to keep the truncate for the addresses in a more standardized way ("0x1234...abcdef"), but this works better IMO. We provide more clarity this way. Just to clarify two things:
|
Works with Chrome, but not with FF. Lemme fix that... |
506dc8a
to
9efcad3
Compare
It was not. Now fixed. Firefox: Chrome:
For account address, no, not before we bring in named accounts in another PR. |
9efcad3
to
4d838d1
Compare
With this, we can adaptively truncate text based on the available space. When truncated, we can display the full version in a tooltip.
4d838d1
to
528b5fe
Compare
This branch has too many merge conflicts now. I have rebased the code (on the Pontus-X branch), and extracted the relevant parts again into #1396. Closing this as obsolete. |
@donouwens wrote:
Up to now, on mobile, we were always truncating hashes to a fixed length (the same as in tables).
With this change, we can now display them adaptively, that is, taking up all the space that is available.
A similar change has also been implemented for block hash links and other similar things.