Blakeyrat pointing out NodeBB problems
-
@Onyx said:
It seems that it does save drafts, even though there's no indication of it.
Not in mobile mode. The X button gives you two choices: stay where you are, or throw away your post.
-
@blakeyrat I meant it saves it in case you have to reload the page, which should let you try and hit the post button again. The close button won't let you keep it, yeah. Phrased it badly, sorry.
-
@Onyx said:
I meant it saves it in case you have to reload the page,
The browser does that. Not NodeBB.
-
@blakeyrat said:
gaming PC with 1000-pixel-wide window
Still can't figure out why you choose 1000px.... I also prefer my window is not fullscreen, but I generally stick to ~1024 wide since like 95% of websites specify 1024px as a minimum DESKTOP resolution.....
Using exactly a 1,000px resolution just sounds like asking for CSS to render as mobile shit, or to give you the guaranteed piss poor 800x600 desktop view if there is one defined.
-
@blakeyrat Possibly. With all the JS fuckery going around I honestly forgot how vanilla forms work by this point. In any case, it's a shitty workaround of some kind at least if it gets stuck.
-
@darkmatter said:
Still can't figure out why you choose 1000px....
I just drag it until it looks right. FUCK PEOPLE. I'm not Rain Man.
LOOK, no matter how wide the window is this is not a mobile device and should never, ever, ever under any circumstances be put in "mobile mode". It's a bug. Period.
-
@blakeyrat that's just what has happened due to the near impossibility of reliably telling what IS a mobile device thanks to 8 billion standards and user agents and browser reportings and javascript functionality implementations. The easiest way to make things work reasonably well for everyone (who doesn't decide to run a mobile-sized browser on a desktop computer that is) is to style by size rather than by device lookup.
I will agree with you in a sideways manner though -in my opinion, the 1000px cutoff is retarded and they should have picked 960px instead if they wanted to work for most cases of determining mobile vs desktop UI being applicable.
-
@Onyx Browsers do that so if you flub Back, then hit Forward again you won't have deleted your work. It's surprisingly easy to do if you have a mouse with lots of buttons, some of which are mapped to browser navigation features, that are easy to accidentally hit.
NodeBB does seem to defeat the browser feature pretty often. I've submitted a couple screenshots here where if you accidentally flub Back, then hit Forward you end up in some weird broken limbo-site with no widgets or anything.
-
@darkmatter said:
@blakeyrat that's just what has happened due to the near impossibility of reliably telling what IS a mobile device thanks to 8 billion standards and user agents and browser reportings and javascript functionality implementations.
Waaah! I'm a little baby infant and software development's hard! Let's do it the wrong buggy broken way because doing it right is too hard! Waaah!
-
@darkmatter The cutoff is actually 992px; the whole site is built with Bootstrap, and that's the switching point between what Bootstrap calls 'small' devices (tablets) and 'medium' devices (desktops). @blakeyrat's window is 1000px, but he uses 1.25x browser zoom, giving an effective width of 800px (or thereabouts), so he gets the tablet layout.
-
@darkmatter said:
the 1000px cutoff is retarded
Correct.
@darkmatter said:
they should have picked 960px instead
No; that is equally retarded.
The other point you and several other people seem to be missing is that it measures incorrectly if you have browser zoom turned on. So at 125% zoom, it's not 990 pixels (or whatever the specific value is), it's 1237 pixels. Which I think we ALL can agree is ridiculously wide.
-
@blakeyrat work different in a smaller screen makes more sense than working diffetent just because its mobile. still its incorrect, dunno what would be the correct
-
@fbmac Step 1 would be to not implement it in CSS, so it's impossible to over-ride or turn-off the broken idiot behavior. But alas, the morons who created this forum did not pass the first hurdle there.
-
@blakeyrat said:
Waaah! I'm a little baby infant and software development's hard! Let's do it the wrong buggy broken way because doing it right is too hard! Waaah!
Serious question, since I'm new to web dev: is it possible to do it right? What is a good way to detect whether you need to switch to a more finger friendly layout because the user is likely on a 5 inch screen?
-
@blakeyrat said:
it measures incorrectly if you have browser zoom turned on
blakey, if you hold your phone closer to your face, it doesn't magically become bigger. It's just closer to you.
-
@Jaloopa Not really... I looked into it briefly this morning... handheld devices don't use css media type
handheld, butscreen, much like regular browsers. If that were fully supported this would be a non-issue.So yeah, as @darkmatter says, it's most realiable (read: not really all that reliable, but more reliable than other options) to just use viewport size.
Yeah, it flops over when you're zoomed in/out. Yeah, it flops over when you don't use a maximized-ish window. I wish there were better detection options.
Oh, and re: 960 and such... guess what pixel count the ipad uses in landscape? 1024! Now I get bugs from users who expect the composer to behave similarly on both portrait and landscape, but 1024 is a typical cutoff point for mobile/desktop.
-
@julianlam I guess the other options are browser sniffing and allowing the user to explicitly choose? Both pose their own problems.
I'm really not too keen on web technology. It all seems a naty, hacked-together, ill-thought-out mess. And it's going to be my bread and butter for the forseeable future!
-
So I'm not a web guy at all. But there are other ways desktop vs mobile could work. Could somebody explain why we don't use these?
- Have a site's main URL go to the desktop version. Have a m.foo.bar version for mobile. If you're on your mobile device just go to the m. URL. Don't try to magic the user to the right URL.
- Related, you could use the resolution/client size to make a guess and prompt the user on initial site load which version they'd like and store that preference as a cookie or whatever.
- Many sites have a "use desktop version" or "use mobile version" links. That seems to work well from what I've seen. Especially since many mobile sites suck and Android is more than capable of showing the desktop version well in my experience.
- I was aware CSS had the different media queries built in. From what I've read in this thread, it sounds like many mobile browsers don't understand that properly. Anybody have any ideas why that is?
- CSS could instead use named configs and have a handful with standard names that different types of browsers could try to use by default. This could also allow users to pick configs per site or domain or allow changing it on the fly with some sort of menu or picker box.
- Instead of using CSS, why not have a HTTP header that says "isMobile"? I guess if the mobile browsers don't do the CSS right why would we expect them to do the header right?
-
@Jaloopa said:
Serious question, since I'm new to web dev: is it possible to do it right?
The CSS media query specification does specify a correct way of doing it; unfortunately, browser vendors don't implement that bit right, as
@julianlam said:
handheld devices don't use css media type
handheld, butscreenWhy? No fudging idea.
@Jaloopa said:
I'm really not too keen on web technology. It all seems a naty, hacked-together, ill-thought-out mess.
Pretty much, yeah.
@blakeyrat said:
it measures incorrectly if you have browser zoom turned on
This is a fault of how CSS is implemented in browsers; the layout engine only sees the CSS pixel count, not the true window pixel count. And you're not the first to notice the issue: http://blog.55minutes.com/2012/04/media-queries-and-browser-zoom/
Ultimately, it comes down to the fact that NodeBB is built on Bootstrap 3, which uses pixels in its media queries because it supports IE8 (Bootstrap 4 is dropping IE8 support, and will use
ems exclusively, avoiding this issue entirely). What's more, you only see it in WebKit-based browsers, because they have a bug in the layout engine where enabling browser zoom basically fucks everything up. Firefox, IE, and Edge on the other hand get it right; zooming in won't break the layout.
-
@blakeyrat said:
The other point you and several other people seem to be missing is that it measures incorrectly if you have browser zoom turned on. So at 125% zoom,
Zoom I believe is detectable, so they should have been able to determine that and use the actual window size of 960px as the cutoff rather than screwing it up.
@Jaloopa said:
is it possible to do it right?
Not really. Depends on your definition of "right." And if you're trying to satisfy @blakeyrat, then never.
-
-
@Jaloopa said:
allowing the user to explicitly choose
@mikehurley said:
Have a site's main URL go to the desktop version. Have a m.foo.bar version for mobile. If you're on your mobile device just go to the m. URL. Don't try to magic the user to the right URL
This is the way I prefer sites that I visit do it. But the rest of the world seems to be moving away from that methodology.
@mikehurley said:
CSS could instead use named configs and have a handful with standard names that different types of browsers could try to use by default. This could also allow users to pick configs per site or domain or allow changing it on the fly with some sort of menu or picker box.
The thing is, then you have to change your theme/config every time you visit the site on a different device. You'd have to store it in a cookie as well to make it device specific, and then load from cookie first or saved preference as a backup. Doable, but kind of clunky for supporting multi-device users.
-
@darkmatter said:
The thing is, then you have to change your theme/config every time you visit the site on a different device. You'd have to store it in a cookie as well to make it device specific, and then load from cookie first or saved preference as a backup. Doable, but kind of clunky for supporting multi-device users.
How is that different than needing to log in to your different accounts on the different devices?
-
@mikehurley got me there I guess? it's still adding an extra step to the process, which I'm sure will cause blakeyrat to piss and moan just as much as not being able to use 125% zoom.
Surely you saw how irritated he was about the whole extra click necessary to go to his profile to get the list of topics he's created?
if the site didn't do the CSS switching then he'd complain about something else anyway. Like how maybe at 125+% zoom, some things wouldn't fit on the screen properly because there isn't enough element floating or expanding/contracting on div sizes to perfectly fit his effectively tiny screen size choice.
-
@blakeyrat would a button to force it into desktop or mobile view be good enough?
can we have it, @julianlam ?
-
@fbmac said:
@blakeyrat would a button to force it into desktop or mobile view be good enough?
can we have it, @julianlam ?
Why not this:
default.css has all the default css layouts for desktop
mobile.css has all the media queries.
A checkbox on the profile says "no, fucking really, don't give me the goddamn mobile shit". Maybe this is a cookie instead of a profile setting.
On page render, if that option is present, don't serve up the mobile.css link.
-
@fbmac There isn't separate desktop and mobile 'modes'; it's one responsive webpage that reflows its content based on media queries, and you can't override those with a button.
-
@Jaloopa said:
Serious question, since I'm new to web dev: is it possible to do it right?
Depends on what you consider "right". In my opinion a website should be like www.motherfuckingwebsite.com
Obviously, I wouldn't be able to be paid to develop things like that.
-
@RaceProUK @Lorne-Kates post just above yours have a good suggestion on how to do it.
-
@fbmac Do you have any idea how much work that would take? To separate all the media queries into a separate CSS would mean literally ripping Bootstrap in two, Bootstrap being what this forum is built with.
There is only one real solution to this issue: the bug in WebKit needs to be fixed; for more details, I refer you to this I already posted:
http://blog.55minutes.com/2012/04/media-queries-and-browser-zoom/
-
@RaceProUK said:
Do you have any idea how much work that would take? To separate all the media queries into a separate CSS would mean literally ripping Bootstrap in two, Bootstrap being what this forum is built with.
You mean all NodeBB themes are built on bootstrap and use it extensively? I dunno how much work it takes to write a new NodeBB theme, but I expect it to be much less than rewriting NodeBB or bootstrap.
-
@fbmac said:
You mean all NodeBB themes are built on bootstrap and use it extensively?
The entire site is built on Bootstrap!
-
@RaceProUK there is some interesting constants in bootstrap's less source code at the file variables.less (github link)
If it didn't look so much like work I could try compiling it configured to "anything bigger than 10px is a desktop", and test it on node bb. Then our setting would just need to choose a different compilation of bootstrap. Probably not the cleanest way possible, but is should work.
If not, one last resort would be doing lots of search and replace.
-
Why do I get shown "Mark this answer as correct" if selecting it does nothing? Didn't we all learn "grey-out of hide irrelevant UI widgets" back in 1985?
Seriously, this forum is made by Martians who have never used a computer before.
-
@ben_lubar said:
blakey, if you hold your phone closer to your face, it doesn't magically become bigger. It's just closer to you.
What are you talking about.
I'm just saying that when you tell us it's 992 pixels, you're a liar. The actual value is 992 * your browser zoom level pixels, which is ridiculously wide on my home PC.
-
@Jaloopa said:
Serious question, since I'm new to web dev: is it possible to do it right?
Let's hypothetically argue that it's not:
It's still no excuse to do it wrong. If it's not possible to do it right, just ask the user what type of device he's using. (I mean, not like in-your-face, but a subtle little link or button somewhere to switch modes.)
-
@julianlam said:
So yeah, as @darkmatter says, it's most realiable (read: not really all that reliable, but more reliable than other options) to just use viewport size.
If I didn't want to use windows on my desktop PC, I would have loaded it up with an OS named "Maximized". Seriously.
I don't care if you think that's the best option, just let me turn it the hell off. Because right now, your site is unusable on my desktop at home.
@julianlam said:
I wish there were better detection options.
Stop trying to "detect" it and just ask the user. That's a better option than broken wrong behavior.
EDIT: to be a little more constructive, Fark.com does this PERFECTLY right. It has a GREAT mobile site that kicks ass, it has a fine desktop site, and it never shows you the wrong fucking one. So do whatever the hell Fark.com is doing.
-
@RaceProUK said:
Why? No fudging idea.
... because they have screens? I mean, why wouldn't they choose "screen" on a device with a screen?
It's not the device maker's fault that the W3C is 100% incompetent morons.
-
@RaceProUK said:
This is a fault of how CSS is implemented in browsers; the layout engine only sees the CSS pixel count, not the true window pixel count. And you're not the first to notice the issue:
I don't care why it's wrong; I just care that it's wrong.
-
@darkmatter said:
Surely you saw how irritated he was about the whole extra click necessary to go to his profile to get the list of topics he's created?
I'm not pissed that it takes an extra click, jesus people, stop making up shit and attributing it to me.
I'm pissed that the UI element you click gives NO CLUES WHATSOEVER what it does. And what the average user would assume it does? It doesn't do that, or anything even remotely related to that.
-
@fbmac said:
@blakeyrat would a button to force it into desktop or mobile view be good enough?
can we have it, @julianlam ?
Yeah I love software that fixes bugs by just having a button that says, "stop being buggy".
Seriously, though, that would be better than nothing. It's not a fix, but it's a workaround I can live with.
-
@blakeyrat said:
FUCK PEOPLE. I'm not Rain Man.
I told all you other morons! FROSTY WAS RIGHT AGAIN.
-
@blakeyrat said:
I mean, why wouldn't they choose "screen" on a device with a screen?
Why wouldn't they choose 'handheld' for a device you hold in your hand?
-
@RaceProUK said:
@fbmac Do you have any idea how much work that would take?
They picked the broken framework. They made their bed, now they have to lie in it.
Look, I'm sorry, whiny little crybabies, that sometimes software development is difficult. This solution to that isn't to just GIVE UP and ship broken shit, it's to get your crying fit over with, get to work, then cope with the reality of the situation.
A better lesson here would be, "hey, don't pick broken frameworks that are shitty and have obvious bugs you didn't bother checking for in the first place", but I suppose it's too late to learn that one, huh?
@RaceProUK said:
There is only one real solution to this issue: the bug in WebKit needs to be fixed; for more details, I refer you to this I already posted:
That's not a fix.
THE WIDTH OF THE BROWSER WINDOW IS IRRELEVANT.
Once more:
THE WIDTH OF THE BROWSER WINDOW IS IRRELEVANT.
On a desktop computer, I NEVER want to see mobile mode. Ever. I never want to see it. Stop showing it to me, I do not want it, I never asked for it, showing it to me is wrong, stop doing it.
That is the bug. Don't get sidetracked by some specific number of pixels.
-
@RaceProUK said:
Why wouldn't they choose 'handheld' for a device you hold in your hand?
"handheld" and "screen" aren't mutually-exclusive, is my point. Either selection for, say, an iPhone is perfectly 100% correct. So why would anybody be surprised that a iPhone browser maker would "get it wrong"? How would he even know it's wrong? It's a handheld device that has a screen. BOTH WORK. EQUALLY WELL.
Whoever at the W3C who named this thing, that's the moron who created this bug. That's the idiot.
-
You do know that you can have multiple
@mediaqueries succeed, right? The problem is that mobile devices don't say they're handhelds.
-
@blakeyrat said:
On a desktop computer, I NEVER want to see mobile mode. Ever. I never want to see it. Stop showing it to me, I do not want it, I never asked for it, showing it to me is wrong, stop doing it.
And if there was a reliable way to tell the difference between desktop and mobile, then people would use it. But there isn't, because mobile browsers don't support
handheldproperly.@blakeyrat said:
It's a handheld device that has a screen. BOTH WORK. EQUALLY WELL.
So they should report both, yet they don't; they only report
screen.
-
@ben_lubar said:
You do know that you can have multiple @media queries succeed, right?
Nope!
@ben_lubar said:
The problem is that mobile devices don't say they're handhelds.
Well then that's a different issue.
Question: is a Surface Pro 3 a "handheld"? What about a 14" convertible tablet? Is it defined somewhere?
-
@blakeyrat any device that you hold in your hand is a handheld. Any device that you hold on your lap or a table is not a handheld.
Edit: Let's make this more precise: any device that has a touchscreen as its main input method is a handheld.
-
@ben_lubar said:
any device that you hold in your hand is a handheld. Any device that you hold on your lap or a table is not a handheld.
The Surface Pro 3 is both
Responsive web design - Wikipedia
