|
I'm trying to make the viewport size (within the 3rd meta tag) the width of a mobile device, preferably mobile phones in portrait. Instead, it's zooming in a bit too far, which makes the canvas go outside the width of the screen and a horizontal scrollbar is added. Anyone know how to fix this? I'd paste the code here, but I get an error, so it's pastebin instead: https://pastebin.com/JD90G27t
|
# ? Mar 1, 2021 02:37 |
|
|
# ? Jun 3, 2024 23:50 |
|
I'm developing locally on a mac with Catalina and MAMP Pro. Lately it's been driving me nuts how slow my locally-hosted site is compared to a remote site running exactly the same site. Here's an example of me refreshing a single page in the CMS Local site Remote site Exactly the same page on exactly the same site takes longer to load locally than it does remotely! Is this just a fact that my machine is crap at serving sites locally, or should it be significantly better than this? Typically I find pages take 5-7 seconds to load. I don't think browser caching is helping at all because pages don't load any faster after I refresh them, in some cases it gets worse.
|
# ? Mar 4, 2021 17:28 |
|
It's been a bit since I developed on a mac, but my first step would be checking your resource manager while a page loads, to see if you're bottlenecking on CPU, memory, or disk IO. if none of the above are hitting 100% there's likely a configuration limiting one of the above creating the bottleneck. If MAMP is anything like XAMPP the default profiles allocate very few resources.
|
# ? Mar 4, 2021 17:36 |
|
Good Sphere posted:I'm trying to make the viewport size (within the 3rd meta tag) the width of a mobile device, preferably mobile phones in portrait. Instead, it's zooming in a bit too far, which makes the canvas go outside the width of the screen and a horizontal scrollbar is added. Anyone know how to fix this? I'm pretty sure the viewport tag is fine. But the size of the canvas will (I believe) be taken from the width/height if you don't specify them on the element's style: code:
code:
|
# ? Mar 4, 2021 20:57 |
|
nexus6 posted:I'm developing locally on a mac with Catalina and MAMP Pro. Lately it's been driving me nuts how slow my locally-hosted site is compared to a remote site running exactly the same site. Here's an example of me refreshing a single page in the CMS Following up my own post here, it seems MAMP had OPcache off by default. Enabling it and restarting servers has made a significant improvement. If anyone else has similar issues, here's the setting
|
# ? Mar 5, 2021 11:19 |
|
you can also configure httpd with brew -- following a step by step tutorial is not even complicate... and may even work. If you are a horrible person, and are testing static files, you can even run this on the folder of the website $ python -m SimpleHTTPServer 80
|
# ? Mar 5, 2021 13:05 |
|
HappyHippo posted:I'm pretty sure the viewport tag is fine. But the size of the canvas will (I believe) be taken from the width/height if you don't specify them on the element's style: I decided to let it from to the page with, if the page width is equal or below 500px. Works great now with the viewport.
|
# ? Mar 5, 2021 20:28 |
|
nexus6 posted:Following up my own post here, it seems MAMP had OPcache off by default. Enabling it and restarting servers has made a significant improvement. But wouldn't you want locally to not have cache enabled? For the times when you make a change to a file and for some reason doesn't get picked up by the engine?
|
# ? Mar 5, 2021 20:43 |
|
Does em vs px units actually matter in 2021? A lot of the old advice is about how it matters if you make your font bigger, but then all modern browsers just scale everything up including px when you zoom in because no one used em anyway. Maybe it matters if you use a custom browser stylesheet but that’s like 0.001% of the user base?
|
# ? Mar 6, 2021 00:18 |
|
Volguus posted:But wouldn't you want locally to not have cache enabled? For the times when you make a change to a file and for some reason doesn't get picked up by the engine? I don't know how is implemented, but I guess it check timestamps and regenerate the cache if the source file is updated since X.
|
# ? Mar 6, 2021 20:44 |
|
Tei posted:I don't know how is implemented, but I guess it check timestamps and regenerate the cache if the source file is updated since X. That's true, and it usually works just fine. Except when it doesn't. Since performance doesn't (or shouldn't) matter locally why worry about it? It's good that you found the culprit to why is locally the system slower than in production, but I don't really see a reason to not revert back that option.
|
# ? Mar 6, 2021 21:39 |
|
are there any good, human-readable resources on accessibility? i'm fairly sure our front-end is not exactly compliant
|
# ? Mar 7, 2021 01:15 |
|
marumaru posted:are there any good, human-readable resources on accessibility? i'm fairly sure our front-end is not exactly compliant I don't have any good articles or whatnot for you, but Chrome's dev tools comes with an accessibility audit tool built in. It won't catch everything as some of it is hard to check programmatically, but it's good at helping you pluck all the low hanging fruit.
|
# ? Mar 7, 2021 02:21 |
|
marumaru posted:are there any good, human-readable resources on accessibility? This right here is the absolute perfect sentence about accessibility.
|
# ? Mar 7, 2021 04:28 |
|
The #1 thing you can do for accessibility is to build well structured, semantic HTML in the first place. Seriously the number of dumbshit issues I've had to fix because the only way of interacting with an element was an onclick handler on a div, or because they used an h3 tag for an input "label", or because they used an anchor tag instead of a button for a non-navigation page action (STOP DOING ALL THESE), or some other non-semantic issue is too damned high. Aside from that, just spend some hands-on time with accessibility tools like Mac VoiceOver, iOS rotor, or JAWS. It will really help you fix existing issues in your app, get a better sense of what it's like to use those tools and why they exist, boost your empathy for users, and better inform your development process because those principles will be higher in your mind instead of an afterthought. Even just 5 minutes set aside to accessibly interact with whatever new feature you're building as part of the QA process is like gold.
|
# ? Mar 7, 2021 23:29 |
|
A game I like to play whenever I work for a new company is turn on voiceover, close your eyes, and start trying to navigate your site with just the keyboard. Seriously, you'll find a lot of problems just like that. some easy wins: 1. Focus on modal content when a modal pops 2. Focus on changed content when routing in SPAs 3. Give buttons that are just SVGs aria labels describing what they do 4. Fix divs/spans that should be buttons and links 5. add skipto buttons so users can skip navigation/menu poo poo and get straight to the main content without having to tab a million times teen phone cutie fucked around with this message at 23:57 on Mar 7, 2021 |
# ? Mar 7, 2021 23:54 |
|
Anony Mouse posted:The #1 thing you can do for accessibility is to build well structured, semantic HTML in the first place. problem is this is a highly dynamic SPA and poo poo like dropdowns and lists may or may not be present, and i have no idea what that'll look like to a screen reader
|
# ? Mar 7, 2021 23:54 |
|
marumaru posted:problem is this is a highly dynamic SPA and poo poo like dropdowns and lists may or may not be present, and i have no idea what that'll look like to a screen reader I usually take advantage of https://developer.mozilla.org/en-US/docs/Web/Accessibility/ARIA/ARIA_Live_Regions to tell the screen reader something is loading and when it's finished loading
|
# ? Mar 7, 2021 23:56 |
|
Anony Mouse posted:Aside from that, just spend some hands-on time with accessibility tools like Mac VoiceOver, iOS rotor, or JAWS. I had to do some accessibility testing recently and couldn’t believe how much a JAWS license cost. Their demo was pretty limited too. I hope they adopt a better licensing model, or people move to something open source like NDVA as the industry standard.
|
# ? Mar 8, 2021 01:15 |
|
I want to say that 85%+ of the sites I work with as a contractor look like this:code:
|
# ? Mar 8, 2021 11:20 |
|
I've run into some kind of bizarre scaling issue on a website I'm helping to debug. This is what the front page is supposed to look like (this is at 1080P using Firefox's dev tools to scale the viewport): This is what it looks like on my Macbook Pro, and apparently many other laptops, even those with 1080P displays: It's obviously some kind of scaling issue, but everything seems to be using percentages, the meta tags look to be set up correctly etc. For some reason some laptops are just scaling everything the gently caress up and it's loving up the entire layout to a point where the website is unusable on those systems.
|
# ? Mar 8, 2021 11:24 |
|
Sergeant Rock posted:I want to say that 85%+ of the sites I work with as a contractor look like this: What should be used instead, span?
|
# ? Mar 8, 2021 13:03 |
|
I don’t think container divs make sites less accessible (at least as far as I’m aware), but I agree some devs go overboard with them. I’ve had to do that on some sites with particularly complex designs and I hate doing it.
|
# ? Mar 8, 2021 15:08 |
|
Empress Brosephine posted:What should be used instead, span? It should be using semantic elements (e.g., <main>, <article>, <section>, <aside>, even <h1> and <p>). There are appropriate use cases for <div>s, but you should really use them as more of a last resort. And past that, a single piece of content nested in five layers of <div>s is almost definitely a bad practice, heh. Something like this is better for screen readers, web crawlers, etc: pre:<main> <article> <h1>Title</h1> <p>Lorem ipsum</p> <p>Lorem ipsum</p> </article> <aside> <p>Whatever</p> </aside> </main>
|
# ? Mar 8, 2021 15:44 |
|
Shaman Tank Spec posted:I've run into some kind of bizarre scaling issue on a website I'm helping to debug. Remove all the viewport meta tags and see what happens. And what do you mean by "1080P" ? That is a Television term, and I'm not sure the context you are using in here. Are you targeting a TV as the display?
|
# ? Mar 8, 2021 15:48 |
fsif posted:It should be using semantic elements (e.g., <main>, <article>, <section>, <aside>, even <h1> and <p>). There are appropriate use cases for <div>s, but you should really use them as more of a last resort. And past that, a single piece of content nested in five layers of <div>s is almost definitely a bad practice, heh. I was looking into this recently and semantic elements are a lie that almost no client uses. They definitely do make things clearer when developing (and parsing if scraping the site) but they are more of a "nice to have" thing. For a basic webpage, as long as you have a hierarchy (h1-h6) and you're following the rules (interactive elements, what elements can be nested inside other) you're good to go. For a webapp it's time to dust off ARIA and pray.
|
|
# ? Mar 8, 2021 16:55 |
|
Semantic elements have some value in various clients, but I recall reading some article awhile ago that found most developers used them inappropriately (for example, using an <aside> for a sidebar as opposed to an actual aside within an <article>), so most common browsers ignore them and treat a lot of them like divs.
|
# ? Mar 8, 2021 17:08 |
|
As long as we're talking Semantics vs the Real World, how about 'cards'? Where it's multiple elements all wrapped in a single link? Super terrible from an accessibility standpoint, but so many places do it anyway.
|
# ? Mar 8, 2021 17:28 |
|
lunar detritus posted:I was looking into this recently and semantic elements are a lie that almost no client uses. They definitely do make things clearer when developing (and parsing if scraping the site) but they are more of a "nice to have" thing. For a basic webpage, as long as you have a hierarchy (h1-h6) and you're following the rules (interactive elements, what elements can be nested inside other) you're good to go. For a webapp it's time to dust off ARIA and pray. That says there's no official spec there, but my sense is that people with screen readers still find semantic tags helpful. Most accessibility-focused developers really pound the table for them, anyway. The reasons not to bother with them feel a bit chicken/egg to me. Like, right, if developers are using them too inconsistently to build much in the way of client features designed around them, discouraging their usage or marking them as a "nice to have" isn't going to help. There will probably always be a fair number of <div>s in any semi-complex website or web app, but I don't think there's much technical overhead in using at least <main>, <nav>, <article>, and <section> tags.
|
# ? Mar 8, 2021 18:22 |
|
Volguus posted:That's true, and it usually works just fine. Except when it doesn't. Since performance doesn't (or shouldn't) matter locally why worry about it? It's good that you found the culprit to why is locally the system slower than in production, but I don't really see a reason to not revert back that option. Mainly because if my local server is slow as hell I can't get as much work done.
|
# ? Mar 9, 2021 13:52 |
|
I dunno if this is the right thread for this but I couldn’t find a better one: Does anyone have recommendations on spotting users that you’ve previously banned from a service who are trying to sign up under a different account? I just came on as CTO to a 6 person non-profit and the practice I’ve inherited is banning by IP address which is catching way too many false positives. This must be a solved (or at least solved better than us) problem with how pervasive it is, but I have no expertise in this area so just putting out feelers for what others have done.
|
# ? Mar 9, 2021 20:03 |
|
Riven posted:I dunno if this is the right thread for this but I couldn’t find a better one: That's basically impossible to do reliably technically without extremely sophisticated fingerprinting technologies. There's things like permacookies that help but it's a never-ending war with browsers patching vulnérabilities that allow these cookies to work. Comedy option: just set a cookie on the guy's browser. If that cookie is set, simply return an empty page or error message. Unless the guy thinks to clear his cookies or start a Private browsing window (hint: most people won't) there's a good chance that'll stop him for a good while. go play outside Skyler fucked around with this message at 21:00 on Mar 9, 2021 |
# ? Mar 9, 2021 20:53 |
|
If you have a ludicrous amount of money, and I mean ludicrous, "contact us for enterprise pricing", look into something like iesnare or forter. Both effectively work by fingerprinting via browser exploits and abusively exploiting browsers for money. Should be illegal.
|
# ? Mar 9, 2021 20:56 |
|
Yeah I was trying to figure something out that didn’t user evercookie type stuff. I think we’re going with text verifications. It will add a little more friction to a specific user type that we’re trying to minimize friction on but I think worth it in the end in terms of staff sanity. I have the opposite of enterprise ludicrous budget lol.
|
# ? Mar 9, 2021 21:10 |
|
What kind of category are you if you are comfortable sharing? Are people signing up for referral stuff, new user promo abuse, or is this a troll/harassment thing?
|
# ? Mar 9, 2021 21:16 |
|
We provide free, 1:1, 24/7 tutoring for low income high school students via a web app that puts them in a whiteboard/chat interface with a volunteer tutor. Volunteers have to jump through hoops to get an account since we’re putting them in contact with minors, but we want student sign up to be as frictionless as possible so a kid who needs help with homework right this instant can just get into a session. They basically just have to confirm they are in a Title I high school by picking the name. But some teens are trolls, and some are persistent trolls, as I think we’re all aware. So we have a few who know a winning high school/zip code combo (usually because their first sign up was authentic) who now just sign up over and over with fake emails to draw dicks on the whiteboard and cuss out our volunteers.
|
# ? Mar 9, 2021 21:47 |
|
Ask the schools for the format their school Ids are in and then make a ID number required to sign up?
|
# ? Mar 9, 2021 22:59 |
|
how hard is requiring a school email to sign up?
|
# ? Mar 9, 2021 23:19 |
|
Biowarfare posted:how hard is requiring a school email to sign up? isn't it illegal (?) for kids under a certain age to have emails
|
# ? Mar 9, 2021 23:39 |
|
|
# ? Jun 3, 2024 23:50 |
|
marumaru posted:isn't it illegal (?) for kids under a certain age to have emails My daughter has a .edu email address given to her and managed by the school. I looked up the Children's Online Privacy Protection Act out of curiosity, and on a quick glance I see things like "child's email address". So I don't think it's illegal for them to have an email, but it might be illegal to collect those email addresses for identifying purposes? Obviously if you can't legally identify a person by their user account creation details, IP address, etc. because they're a minor, it's going to be hard to block them from signing up. Wasn't there talk of a Dick Identifier* that used machine learning could determine if a drawing was a dick and block/censor it? Maybe there's some censorship things worth looking into. * don't tell me to turn off my monitor
|
# ? Mar 9, 2021 23:50 |