|
Just be very, very, very, very careful of: jackpot posted:
|
#
?
Jul 23, 2014 16:44
|
|
|
|
| # ? May 9, 2024 20:43 |
|
|
Yeah, why is it helpful to have made-up em equivalents for lengths measured in pixels? That just sounds like cargo-culting.
|
|
#
?
Jul 23, 2014 17:29
|
|
|
pokeyman posted:Yeah, why is it helpful to have made-up em equivalents for lengths measured in pixels? That just sounds like cargo-culting. Device fragmentation.
|
|
#
?
Jul 23, 2014 17:54
|
|
|
Sunspots.
|
|
#
?
Jul 23, 2014 17:58
|
|
|
What shopping cart doesn't suck? We need to choose one for a couple of projects. We could roll our own but the deadlines were made taking into account a ready-made solution with mostly templating work left.
|
|
#
?
Jul 24, 2014 02:39
|
|
|
POST question: When I try making a POST request to a certain service using jQuery.post or jQuery.ajax, it fails, as seen here. When I place a request, using the same data, through a REST debugger extension, it works just fine, as seen in this incomplete screenshot. They're both (allegedly) POSTing the same data to the same endpoint, and yet one works and the other doesn't. WTF am I doing wrong?
darthbob88 fucked around with this message at 03:03 on Jul 24, 2014 |
|
#
?
Jul 24, 2014 02:59
|
|
|
gmq posted:What shopping cart doesn't suck? We need to choose one for a couple of projects. We could roll our own but the deadlines were made taking into account a ready-made solution with mostly templating work left. Shopify?
|
|
#
?
Jul 24, 2014 03:03
|
|
|
darthbob88 posted:POST question: When I try making a POST request to a certain service using jQuery.post or jQuery.ajax, it fails, as seen here. When I place a request, using the same data, through a REST debugger extension, it works just fine, as seen in this incomplete screenshot. They're both (allegedly) POSTing the same data to the same endpoint, and yet one works and the other doesn't. WTF am I doing wrong? Well the one difference maybe is the Content-Type header but that's not likely to be an issue unless your service is checking for it, but, have you tried grabbing the error from the xhr and seeing what the gently caress it says? You know you can also telnet and write the HTTP request out yourself just to convince yourself it works, you can also bring up dev tools in Chrome or FF and see exactly what your XHR is trying to say. Probably some subtle bug in your request. Unless service *really* cares about Content-Type, you should be OK, if everything else is good. I mean it's not like something is lying to you...
|
|
#
?
Jul 24, 2014 03:06
|
|
|
Oh, loving duh. Cross-origin buddy. Can't hit a domain you're not on, includes that fiddle page.
Pivo fucked around with this message at 03:33 on Jul 24, 2014 |
|
#
?
Jul 24, 2014 03:20
|
|
|
Subjunctive posted:Shopify? It sadly needs to be self hosted because we're probably going to need to add some custom functions and also to be able to integrate our local online payment system.
|
|
#
?
Jul 24, 2014 04:06
|
|
|
I've got a CSS problem I'm not sure how to even google. I want to make this (or something like it - I can change the markup):code: instead of HUGE Normal
|
|
#
?
Jul 24, 2014 17:57
|
|
|
Oh hey, the actual intended use for vertical-align: middle. http://jsfiddle.net/3thK7/3/
|
|
#
?
Jul 24, 2014 18:09
|
|
|
So where do I get started in webdev these days, if I want to make a career change? Back in 1999 through 2004 or so, I learned HTML, PHP, Javascript, CSS, MySQL, Perl/CGI, and some Flash. But the web has changed massively since then. There are so many giant libraries and frameworks, CMS's, new languages in popular use, different coding styles (PHP trying to do away with procedural coding in favor of OO), cloud technologies/services, Flash and Perl aren't in wide-use. I feel pretty overwhelmed. I have a good understanding of the underlying fundamentals, but almost no knowledge of how web sites are practically created these days. Are there any good resources for re-learning web-development, but assume you had some knowledge of how web sites were made 15 years ago?
|
|
#
?
Jul 24, 2014 19:43
|
|
|
Meta Ridley posted:So where do I get started in webdev these days, if I want to make a career change? I'm in a similar boat and this podcast has been really informative: http://javascriptjabber.com/episode-guide/ The hosts are pretty goony, but they cover a lot and often argue over a topic so you get a broad perspective.
|
|
#
?
Jul 24, 2014 19:47
|
|
|
Kanpachi posted:Oh hey, the actual intended use for vertical-align: middle. Why the gently caress does putting it on the first one change the other... oh never mind. loving CSS.
|
|
#
?
Jul 24, 2014 19:58
|
|
|
Munkeymon posted:Why the gently caress does putting it on the first one change the other... oh never mind. loving CSS. Because the baseline is still defined by the 'normal' text, not the huge text.
|
|
#
?
Jul 24, 2014 20:02
|
|
|
Meta Ridley posted:So where do I get started in webdev these days, if I want to make a career change? I'm going through a similar updating of early 2000s knowledge. Here are some big things that have changed for me. How I did it 10 years ago: mix html, php and mysql all together in a single file, so that the layout of pages is sprinkled with various "SELECT * FROM..." statements. How I do it now: distinguish between the model (database stuff), controller (php (or equivalent) stuff) and view (html/css stuff). Treat the "front end" as distinct from the "back end". How I did it 10 years ago: do everything on the server with PHP from scratch. How I do it now: Pick a language and use a framework (java script: Node, Python: Django, Ruby: Ruby on Rails, etc.). How I did it 10 years ago: Write all my own html and css from scratch, and produce websites that look like poo poo. How I do it now: use Zurb Foundation for layouts and use SASS to make global changes to styles, and produce websites that look like poo poo. How I did it 10 years ago: write code in notepad, upload files via ftp to a live webserver, accidentally delete important code and spend hours searching for missing semicolons. How I do it now: write code in whatever (vim), use grunt to check for errors every time I save, use git to keep backups of all changes and to push files to a webserver. How I did it 10 years ago: host websites on lovely shared hosting How I do it now: host websites on Amazon AWS instances that scale up and down depending on demand and replace each other when one goes down etc.
|
|
#
?
Jul 24, 2014 20:19
|
|
|
vOv posted:Because the baseline is still defined by the 'normal' text, not the huge text. Not really? http://jsfiddle.net/3thK7/9/ I don't pretend to understand CSS.
|
|
#
?
Jul 24, 2014 21:17
|
|
|
Suspicious Dish posted:Not really? It looks to me like the tallest thing in a line sets the baseline, because if you add another, even bigger bit of text at any point in the line, everything goes back to being bottom-aligned again. I think if I had a time machine, I'd kill everyone on the CSS committee and leave a note reading "Consider using a constraint system instead!" before I got around to Hitler and whatnot. E: wait, no, the vertical-align: middle'd thing looks like a sub WRT to the bigger text and the normal text is on the baseline  Time machine murder fantasy still holds.
Munkeymon fucked around with this message at 22:17 on Jul 24, 2014 |
|
#
?
Jul 24, 2014 21:48
|
|
|
Munkeymon posted:I've got a CSS problem I'm not sure how to even google. I want to make this (or something like it - I can change the markup): Use flexbox and say screw you to IE!!! Or use flexbox with inline-block fallover: http://jsfiddle.net/qzk5Q/1/ (take out the flexbox stuff to see what IE < 11 sees) Just think, in like 4 or 5 years, we'll actually be able to use flexbox..... (edited to make the text in the fiddle HUGER!)
|
|
#
?
Jul 24, 2014 23:02
|
|
|
Next week I have an interview for a job which as far as I know only involves working with HTML and CSS (mainly CSS?). I only really know that it involves creating and or manipulating templates that are used for formatting Word/InDesign documents. The templates aren't graphic heavy so I'm dealing with more of the structural side of CSS than the presentation side so what are some areas I should brush up on? Like the different display types for example.
|
|
#
?
Jul 25, 2014 06:55
|
|
|
Your ability to weather somewhat insane decisions like using HTML and CSS as a mode of interacting with Word and InDesign documents. 
|
|
#
?
Jul 25, 2014 13:07
|
|
|
gmq posted:It sadly needs to be self hosted because we're probably going to need to add some custom functions and also to be able to integrate our local online payment system. Shopify's API is super easy to use and their support for it is very, very good. It is very easy to extend it.
|
|
#
?
Jul 25, 2014 18:38
|
|
|
This is probably a dumb question, but why use <section>s in html5 over divs?
|
|
#
?
Jul 27, 2014 20:07
|
|
|
zfleeman posted:This is probably a dumb question, but why use <section>s in html5 over divs? section is a semantic tag used to indicate that the included content is related to each other. div has no semantic meaning at all. As far as the why goes...well, I guess it's because it makes more sense. I assume it will help search engines either now or in the future.
|
|
#
?
Jul 27, 2014 20:35
|
|
zfleeman posted:This is probably a dumb question, but why use <section>s in html5 over divs? http://diveintohtml5.info/semantics.html#new-elements is a decent overview of the new semantic html5 elements
|
|
|
#
?
Jul 27, 2014 21:09
|
|
|
What are everyone's thoughts on responsive design? As of a few years ago, numerous articles came out saying your website needs to be responsive. It seems once enough websites did that, now a trend in articles is about how you should not make your site responsive. What gives?
|
|
#
?
Jul 28, 2014 12:52
|
|
|
Ummm can you post some of these articles saying not to make a responsive site? Are they offering a different solution for mobile?
|
|
#
?
Jul 28, 2014 13:02
|
|
|
He might be talking about the rejection of certain responsive features that have been abused, e.g. the hamburger menu http://techcrunch.com/2014/05/24/before-the-hamburger-button-kills-you/ And annoying modals etc. I don't think anybody is silly enough to say not to make a responsive website, just that these developments have no value in themselves but that they can be used to better tailor websites to the end-user experience. For e.g. we could have e-books with scrolling marquees and flashing headings and awooga sirens or whatever, but they don't necessarily add to the core desired experience - reading the text within the book. Unless I'm mistaken and there is actually a trend to not make websites responsive to the viewing medium? I haven't seen anything like that, though. There's one website that comes to mind which is just 90s-era black text on a white background and it goes on about how it's perfectly formed and a perfect website etc etc, but even all that was just meant to highlight how websites should be tailored around what the desired end result is. Snazzy flash intros and slideshow sitenav images just get in the way of what your user came to your website to do or discover. So, in short, we can do a lot more cool things with websites that aid interaction or make them look fancy, but they don't necessarily actually make your website any better. Is that what you meant?
|
|
|
#
?
Jul 28, 2014 13:15
|
|
|
The Dave posted:Ummm can you post some of these articles saying not to make a responsive site? Are they offering a different solution for mobile? Sorry, here is one I was sent last month and here is one I saw this morning.
|
|
#
?
Jul 28, 2014 13:40
|
|
|
Ah okay. So the first article is basically that a lot of retailers are making poo poo responsive solutions that are bloating page load. The second is the responsive vs. dedicated mobile site debate which is usually (IMO) a YMMV thing depending on what you're serving.
|
|
#
?
Jul 28, 2014 13:54
|
|
|
The Merkinman, I think you're misinterpreting those articles. The first one boils down to "we tested 12 major retail websites and discovered that their optimisation sucks". The second one is also a question of website design that also reinforces that website design has to be tailored to website purpose and user interaction -- which is achieved by proper responsive design anyway. You can shuffle around order, hide unnecessary elements, load different images, change links and navigation and content etc according to the user interface/medium. None of which is really a rejection of responsive design, just of lovely design. It's like saying "we spoke to several motorists and discovered that sometimes on long drives in the country they worry about not finding a petrol station in time to refill their car. If they had been riding horses instead, they could have just eaten some grass!". It all comes down to what you want to do with your website and what your clients need/want. Equally you could post some articles asking "is MySQL dead?" that are aimed at big data companies like facebook or whatever, but MySQL is "not good, but good enough" for the vast majority of the web, and the vast majority of people will never ever have to worry about accessing millions of records every second. Sulla Faex fucked around with this message at 14:02 on Jul 28, 2014 |
|
|
#
?
Jul 28, 2014 13:58
|
|
|
Sulla-Marius 88 posted:Equally you could post some articles asking "is MySQL dead?" that are aimed at big data companies like facebook (We actually use MySQL heavily.) Responsive design is a particular optimization challenge because it basically guarantees that you're going to send a bunch of content that the mobile user isn't going to see. Worse, there are likely to be whole assets that fall into that category (scripts for UI elements that don't appear on the phone, etc), adding hated round trips. Doing things responsively on the server instead (or as a hybrid) could work better, maybe? Would have to figure out where to slice things to get the right info to the server without losing all that important parallelism and readahead.
|
|
#
?
Jul 28, 2014 14:10
|
|
|
Fair enough re: MySQL, although from memory I think I've read things about you modifying innodb etc extensively, although maybe not to the extent that you've wrapped PHP etc. But yeah, my point was more to avoid the classic beginner programmer mistake of spending hours and hours optimising a piece of code whose performance gains aren't going to break even on the time you've invested in getting them. If you have a couple dozen visitors a day, bringing your page load from 0.05 seconds down to 0.04999 seconds isn't going to be worth two weeks restructuring. For facebook, yes, but there's a real danger in beginners reading all these clickbait articles on ycombinator about the inefficiency of certain languages/databases or the 'death' of responsive websites and getting caught up in the hype. If it's something you need to worry about, chances are it'll be prompted by something, not just idle "ooh what happens if I become bigger than facebook and my responsive website is 5% slower than it could be?". Worry about it when it becomes a distinct possibility. Same reason you wouldn't knock down and rebuild your house as a fifteen-storey stadium just in case 2,000 more people come for your nephew's fifth birthday party than you have invited. I view these low-content clickbait articles on "is [popular thing x] inefficient and dying??" as a symptom of the same unnecessary over-engineering. It can be a trap for newbies who are much better off just building what they can, learning, and going from there. Hipster programmers love jumping ship to 'the best new next-gen language' that magically solves some esoteric unicorn-usecase problem and only takes four months to learn. It's a dangerous addiction. I'm not saying people shouldn't read these articles or anything, just that they should be kept in their proper context. For websites, a far better question than "should I use responsive content?" is "what am i trying to make, how are my users going to interact with that, and what's the best way to do that?" e: That's actually 3 questions cleverly disguised as 1. If you want to hire me as a question-maker consultant, find me on twitter @TheQuestionWizard
|
|
|
#
?
Jul 28, 2014 14:22
|
|
|
Yeah, the issue isn't that responsive isn't a good thing, but that doing it is hard and requires a lot of attention to detail. I see some old school government CMS shops round here try their hand at responsive and it ends up being a 32mb loving disaster. When a lack of experience with front end optimisation and strict deadlines collide, 'responsive' design becomes anything but. Connections struggle to pull it down and then iPads cark it due to limited memory for the images.
|
|
#
?
Jul 28, 2014 14:25
|
|
|
Another thing that's a real problem is scaling high-bandwidth content to the base infrastructure and plans of the end-user. Developed countries still vary incredibly in their telecommunications offers. You could have users in south korea or japan or north-west europe who have unlimited data and 4G phones and expect a lot of high-quality image content and who have no problem downloading high def videos. You also have the slave-plebs in australia and america who struggle to open their emails on 50mb/week and crumbling 3g networks, for whom an image and some css files constitute an insurmountable hurdle. I've never really heard of anybody making the effort to sculpt content (not just content displayed, but content sent to the end-user) based on connection quality or bandwidth caps. How do you handle that? What if someone has a 4g phone but they're capped at 300mb/week? Are you going to send them 15mb of logos and ads per website? And that's something 10x as difficult to overcome but probably almost as prevalent as the IE6 problem. We'll bend over backwards to support 15-year old browsers, but what about 35-year old infrastructure? Sulla Faex fucked around with this message at 14:33 on Jul 28, 2014 |
|
|
#
?
Jul 28, 2014 14:31
|
|
|
Maybe part of the problem is the focus on responsive interactive/visual design, without attention to responsive system/software design.
|
|
#
?
Jul 28, 2014 14:32
|
|
|
I don't have any links to back this up (am trying to analyze my own company's analytics), but I'm beginning to think that responsive design might be bad approach from a design perspective as well, especially for properties that have standalone, native apps. My hypothesis is that people use desktop web and mobile web so differently that responsive design presents hidden dangers in that it encourages least common denominator design. For example, I further hypothesize that native apps, for all intents and purposes, replace the mobile homepage. That is, next to no one will manually type in your domain name into their mobile browser. Extrapolating from that -- does your app's start screen look like mobile homepage? My guess is no, it has been designed around a different set of priorities. So, when starting off I would consider what your native app is trying to do, in terms of startup priorities and supported use cases. I would then consider what you are trying to accomplish with your mobile home page and various other parts of your mobile website (category pages, leaf pages, etc), and how that compares to desktop, bracketed with current analytics data, if possible. For some sites, I'm sure there's enough overlap that desktop and mobile could be covered by a single, responsive design. For others, such as my employer's, I am beginning to think that the patterns of usage are so different that it does not make sense to think of them as the functionally identical.
|
|
#
?
Jul 28, 2014 15:01
|
|
|
I'm most likely an edge case but in the post-Snowden world people like me are probably growing. I still use Facebook and do so a bit on my phone as well, but not the app. I went to install it on a new phone a few years ago and took a quick look at the "This app requires access to the following:" list. When I realised it was demanding full access to a whole bunch of poo poo that it has no right knowing (why would my local librarian need a key to my house and a detailed daily schedule??), I decided not to install it. Facebook on the phone browser can't do everything it could do on a desktop, but there's no way I'm installing an app that arbitrarily trawls through my whole life. Same for those 'flashlight' apps. Its entire purpose is just to turn on the phone flash, and it wants access to everything my phone could possibly about me for data mining? No thanks. I think people are about to start getting a lot more critical about what they give apps access to on their phones, and to my mind that's one potential argument against creating websites for desktops and apps for mobile devices. Mobiles are getting more and more like computers, not less, and if you create your services in a way that blocks interaction and restricts accessibility, you'll not only lose customers, you won't have any points of reference for how you're losing them. There's a whole hidden population of users who realised you need to install an app to go to a website on their phone and then just decided that maybe they didn't really need to go there after all.
|
|
|
#
?
Jul 28, 2014 15:30
|
|
|
|
| # ? May 9, 2024 20:43 |
|
|
You could've just said "Android's permission system is hosed", it's much shorter.
|
|
#
?
Jul 28, 2014 16:03
|
|