Multiverse Feedback: Recent Activity
| Multiverse Feedback: Cardlist | Visual spoiler | Export | Booster | Comments | Search | Recent activity |
| Mechanics | Upcoming releases | Skeleton |
Recent updates to Multiverse Feedback: (Generated at 2025-07-01 12:21:25)
"the bottom part of the card is often out of view"? Uh... just how small is your screen size?
But yes, I agree I could redesign the card view to use something like flex-box or multiple columns.
Fixed elements are bad idea in general and 90% of the time poorly executed and disrupts the flow of the document, including this site. The only things you would fix are backgrounds.
Moreover the bottom part of the card is often out of view and theres no way to see it because fixed position means scrolling has no effect to see the rest.
The other problem with your current setup is why isnt the comment section resized so that the card doesnt overlap the comments. The comments still take the entire width of the screen, but obviously the fixed card obstructs them.
The better solution is to set the card section and comments section as 2 columns next to each other, with certain heights relative to the screen size. Each section can be set in CSS to overflow:auto that adds scrollbars when necessary. This layout works without javascript and any screen size, and insures the card never overlaps the comments. Both sections can be scrolled individually so the whole of it can be read.
Huh; note that for me - the card doesn't stay in a fixed position; it's nailed to the canvas like any other element. On desktop, I mean. It never occured to me it would be any other way. Why would it be any other way?
But; um, if you really want it to not scroll; it's fairly plainly a case for frames; not CSS.
The fixed card position (on desktop) is most noticeably useful on long discussion threads, especially for cards that have been edited several times or that have complex wording people are discussing. It's a pain to have to keep scrolling up to see what people are referring to.
On mobile, something has to give, and condensing horizontal elements to be concatenated vertically is standard practice.
The problem is that there isn't a good way to detect "on mobile", or even really to define what it means. New mobile devices with bigger screens keep coming out all the time - or even ones with more pixels but not bigger screens, which are even more of a pain. Responsive web design is hard; almost everyone agrees with that. And it's the kind of thing some web developers spend their entire day job trying to keep up with industry trends. For a hobbyist like me, it's just not practical. (My day job does touch on HTML/JS/CSS sometimes, but it's not a major focus.) I've tried to code the site so make things degrade gracefully, but it looks like that's not quite working right in this case... so yes, I'm going to tweak my hard-coded sizes, because nobody has a more sensible way of making CSS detect what counts as mobile than that.
I know that Link and I think Vitenka sometimes respond by phone. And those two are, like, 10% of the total audience right there. I presume that paying attention to mobile is just good business.
That said, I got to admit that if the card didn't scroll down with the comments, it wouldn't occur to me that there was something 'wrong' with that. The card image in Gatherer doesn't do that, for example, and that never bothered me. It's a nice feature. I hope the occasions where it causes a problem are minimal, but I wouldn't know.
Fixing the card in place is a pain in general. Your solution is using more guesswork and hard coded sizes? Moreover the other elements are not resized, so the fixed card still blocks them when scrolling down the page.
Hardly bother to visit on mobile devices.
@Vitenka:
:D
(Really, I've been digging the Pro Surface 4. But Chrome is hacky with it... quite possibly by design. And Firefox has been sick for years. I figure there's nothing wrong with learning how to use Edge, in case of apocalyptic conditions.)
@Alex: Oh, cool. At 175%, screen metrics are:
Sizes
JS screen.width : 1563px
JS screen.height : 1042px
@media (device-width) :
@media (device-height) :
Pixel ratio
CSS pixel-ratio :
JS pixel-ratio : 1.7500
Density
Resolution (dpi) : 168.00dpi
Resolution (dppx) : 1.75dppx
Resolution (dpcm) : 66.14dpcm
Misc
Root font size : 16px
Orientation :
Device Aspect-Ratio : 1.50
At 200%, screen metrics are:
Sizes
JS screen.width : 1368px
JS screen.height : 912px
@media (device-width) :
@media (device-height) :
Pixel ratio
CSS pixel-ratio :
JS pixel-ratio : 2.0000
Density
Resolution (dpi) : 192.00dpi
Resolution (dppx) : 2.00dppx
Resolution (dpcm) : 75.59dpcm
Misc
Root font size : 16px
Orientation :
Device Aspect-Ratio : 1.50
The card frame is meant to stay fixed-relative-to-the-screen (i.e. scroll as the page scrolls) on desktop browsers; it's only if the screen is tiny ("on mobile") that it's meant to stay fixed-relative-to-the-page and scroll off the top. I guess it's your tablet's width, combined with its pixel density etc.
I can tweak my mobile-detection CSS to try to catch your 200% case and still count it as mobile. Can you give me the "Screen metrics" section of http://mydevice.io/ (and the px measurement above it), once with your 200% zoom and once with your 175% ?
I found another bug!
There's at least one person in the world admitting to using the Edge browser! :)
Hi Alex! I've been having this problem for a while now. I want to say that it started ever since I got a Pro Surface 4 and switched to Microsoft Edge...
The problem is that the card frame won't stay in one place while scrolling down the page, ultimately covering the comments and the comment response field. Whenever I go to comment on something, such as with this post, I'm pretty much writing blind.
And... I actually solved my own problem while writing this post, oddly. My zoom was on 200%. Once I moved it to 175%, it works fine. That said, I'm going to be resetting the zoom to 200% when done... it's one of the odd quirks of this Pro Surface 4. The screen resolution is incredibly good, but it's just a normal sized tablet surface. If I set the resolution at 100%, it's the rough equivalent of looking at 3 pt. font typed text.
Anyhow, I don't know how unique my problem is. As technology moves forward maybe more people will have my problem, and this should be looked into. If it's just me, though, then I can just adjust to 175% whenever I look at Multiverse. It's a little uncomfortable, but not unreasonable.
Yes, pretty much. I guess I got spoiled by Wikipedia popups that allow a similar function XD
Mmm, yes. This isn't very easy at the moment.
The current simplest way is to use the "Import data" page with a "Formatting line" of just "name%code", and paste in a list of all your card names followed by "%". I'm fairly sure that should blank the code for all the listed cards. So that's the workaround that you can use at the moment.
It would be nice to be able to perform mass operations from the cardlist, along with some tickyboxes and "Select all" / "Select none" / "Select active" / "Select cards in skeleton". The cardlist is a view that wants a lot of reworking anyway though.
I guess I could add some tickyboxes to the skeleton itself.
Hm. It's currently a two-click process - click the name (or more normally ctrl-click the name to open in new tab), then on the new tab click Edit; you're asking for it to be a one-click process instead?
I guess I could do. I've got an edit on the way that'll make some changes to the card preview popup anyway. It's certainly an easy enough change to make.
Also known as "delete all card codes".
Either because you want to mass move cards and avoid conflicting codes, or because, as I found out the hard way, reordering many cards within a skeleton is a complete nightmare.
Finally tracked this down. The tooltips set their font to Arial, while the on-page cards ask for Verdana first, then Arial if Verdana's not available. On my system at least, Verdana takes up more horizontal space than Arial, and so forces the text onto more lines, which makes the auto-sizing JS squish it smaller.
Should be a fairly easy fix.
Or at least a message on the log in screen saying, "lost password? password recovery not implemented yet, but email me at xxxx and I'll take care of it" if there isn't already. It may not be obvious to people who aren't already regulars that you would respond to such emails when you get them.
Safari, Firefox and Chrome on macOS.
Browser window as large as 1280 x 750. Probably happens on some mobile devices true, but I haven't tried.
Yeah, at the moment the "password recovery system" is "email Alex". Which isn't a very sensible system. I agree I should make something better. (The "email Alex" system does work, it just takes a few hours if you're not in my timezone.)
Thanks for fixing. Updated my mechanics, they work great. See Communist Manifesto , Kird Ape . Also cycle Periodic Spider Periodic Bird Periodic Lizard
It's been brought to my attention by a friend who is having difficulty logging in right now that there aren't any good ways of recovering one's account in case of log-out. At the very least, there should be a confirmation email sent when you create an account and a way to recover lost passwords
Mm, I've wanted this as well. It ought to be a nice simple edit to just one file (which is sadly the kind of criterion I'm working by at the moment: big architectural changes are beyond me with the level of energy I have right now). So I'll definitely have a go at this.
What about a simple check box on the card edit or card view page? And the ability to filter searches with that option in the card list and visible spoiler section.
It would also be nice, but not totally necessary, if it could highlight the card name in red on the skeleton page.
Currently, to implement this, I have been creating a different mechanic for each number I plan to use.
Sweet
implemented
fixed