|
On the topic of Bootstrap, I just started using it and it's been fantastic if not for one hang nail in the form of the navbar active class and how I can't change it with a higher priority css file shy of putting !Important in the rule. That can't be right, can it? Why is the base css file taking priority when it's the first declared?
|
# ? Jun 13, 2014 07:31 |
|
|
# ? May 9, 2024 16:46 |
|
ConanThe3rd posted:On the topic of Bootstrap, I just started using it and it's been fantastic if not for one hang nail in the form of the navbar active class and how I can't change it with a higher priority css file shy of putting !Important in the rule. Is the base CSS selector more specific? Like how nav li .active takes precedence over li .active.
|
# ? Jun 13, 2014 07:34 |
|
pokeyman posted:Is the base CSS selector more specific? Like how nav li .active takes precedence over li .active. Even if I declare it as nav li .active it still don't sit right unless I use !imporant (I'm doing it to not have the active tab change colour when hovered over, so the rule is technically active a:hover but that shouldn't be an issue, surely.
|
# ? Jun 13, 2014 11:43 |
|
nav li .active was just an example - the easiest way to do it is to simply track down what rule it is obeying, then either make your intended behaviour one that is one level higher in specificity or reduce that base rule by a level of specificity; which is best is dependent on what the rest of your rules are doing around it.
|
# ? Jun 13, 2014 14:01 |
|
Yeah are you using developer tools / firebug to check out where the rule is exactly coming from?
|
# ? Jun 13, 2014 15:15 |
|
pokeyman posted:Is the base CSS selector more specific? Like how nav li .active takes precedence over li .active. The specificity in bootstrap sometimes looks like: .nav>li>a.special-name So you pretty much need to specify children sometimes to change parent tags.
|
# ? Jun 13, 2014 15:22 |
Is it a horribly stupid idea to have the same URL go to different things depending on which user you are? i.e. if I'm logged in then http://mycoolsite.com/employee/joe_blow/ goes to the Joe Blow that works at my company. But if somebody at another company is logged in then the same URL goes to the Joe Blow at their company. (If you aren't logged in then you don't get to see anything.)
|
|
# ? Jun 13, 2014 23:16 |
|
That's a very common thing. Consider that http://www.facebook.com shows different content for every person who loads it.
|
# ? Jun 13, 2014 23:27 |
|
fletcher posted:Is it a horribly stupid idea to have the same URL go to different things depending on which user you are? I would say have canonical URLs like http://mycoolsite.com/company1/employee/joe_blow and http://mycoolsite.com/company2/employee/joe_blow, then make http://mycoolsite.com/employee/joe_blow redirect to the appropriate one if you really want the slightly shorter URL.] edit: Subjunctive posted:That's a very common thing. Consider that http://www.facebook.com shows different content for every person who loads it. But isn't facebook.com/joe_blow the same Joe Blow no matter who's logged in?
|
# ? Jun 13, 2014 23:28 |
|
I think its pretty bad because it doesn't account for any cases where a user may have associations with more than one company within your system. Not knowing anything about your system, of course, but I think it would be wise to have a top level classifier, a slug of the company, either in the directory structure or as a sub domain to make context clear. Even if you're not intending to, what about admins who may be managing multiple client companies, if it was a service. A URL should be able to get you to support points reliably, and making it dependant on user state is probably a bad idea.
|
# ? Jun 13, 2014 23:31 |
|
Subjunctive posted:That's a very common thing. Consider that http://www.facebook.com shows different content for every person who loads it. I think it depends on the resource being presented. facebook.com is a dashboard. facebook.com/joe_blow is a specific resource, presented differently depending on who you are certainly, but always the same resource.
|
# ? Jun 13, 2014 23:34 |
|
pokeyman posted:But isn't facebook.com/joe_blow the same Joe Blow no matter who's logged in? Sure, but /friends/ or whatever isn't. There's nothing magic about a person's name (versus a page name) that means it has to be globally scoped, if a person using the site will necessarily be dealing with a subset of the entries. (And /joe_blow will show different content depending on who is logged in and their relationship to Mr Blow.) It will be diagnostics harder, because you have no good way of specifying which joe_blow you want if you're investigating a bug, and your error logs will have to be more complicated.
|
# ? Jun 13, 2014 23:55 |
pokeyman posted:I would say have canonical URLs like http://mycoolsite.com/company1/employee/joe_blow and http://mycoolsite.com/company2/employee/joe_blow, then make http://mycoolsite.com/employee/joe_blow redirect to the appropriate one if you really want the slightly shorter URL.] ick try http://company.site.com/employee/<name>
|
|
# ? Jun 14, 2014 00:13 |
|
To be clear, I would probably design with scoped/unique URLs, but I don't think it's incorrect to do otherwise. Using names is a PITA in a few ways, so unless you think people are putting these URLs on business cards or typing them in otherwise, just using unique IDs could be a lot simpler. If you use names, prepare for people to change them, to have annoying characters in them, and otherwise grumble a fair bit to yourself.
|
# ? Jun 14, 2014 00:26 |
|
down with slavery posted:ick Sure. The point was to recommend having a unique URL for each person, not to bikeshed. Subjunctive posted:To be clear, I would probably design with scoped/unique URLs, but I don't think it's incorrect to do otherwise. Using names is a PITA in a few ways, so unless you think people are putting these URLs on business cards or typing them in otherwise, just using unique IDs could be a lot simpler. If you use names, prepare for people to change them, to have annoying characters in them, and otherwise grumble a fair bit to yourself. But don't you want cool URIs? They don't change!
|
# ? Jun 14, 2014 01:03 |
|
Hey guys, I've been playing around with HTML and CSS and I've encountered a problem that I don't entirely understand. When I started using <div> to layout a page I've discovered there seems to be a border. I made a tiny example to show off what I mean and I'll post the code. The border of white outside the colour is what I mean. code:
code:
It is the same in FF and Safari, although the border is slightly different sizes in both.
|
# ? Jun 14, 2014 03:51 |
|
Add this to your css:code:
Cawd Rud fucked around with this message at 03:57 on Jun 14, 2014 |
# ? Jun 14, 2014 03:54 |
|
It worked perfectly for Safari, but Firefox is still has this. code:
|
# ? Jun 14, 2014 03:59 |
h1 { margin: 0 } Using something like http://necolas.github.io/normalize.css/ can help with these sorts of things
|
|
# ? Jun 14, 2014 04:02 |
|
Ah wonderful! Thanks guys, I'm glad it was something stupidly easy like that.
|
# ? Jun 14, 2014 04:05 |
|
Right, I'm sorry to be bothering you guys so much but I've got another really stupid question. I was doing a Certificate to bring my grades up to help getting into Uni, and part of it was a couple of lessons on HTML. I learnt how to do layouts using Tables but I've been told that Divs are now the preferred way of doing it. But I'm having trouble working out how to do it. The purple and teal area work just fine. But the other 3 areas I've coloured aren't. Basically I want the yellow (menu) section to travel down to the bottom of the screen, same with the green (frame) section and have the blue bar (copyright) sit right at the bottom even if the page doesn't go all the way down to the bottom. code:
code:
|
# ? Jun 14, 2014 08:57 |
|
Just use tables or flexbox. (This is Bad Advice but it is practical and has no downsides.)
|
# ? Jun 14, 2014 09:09 |
|
pokeyman posted:Just use flexbox. FTFY. E: You could also use "display: table-cell" tbh.
|
# ? Jun 14, 2014 09:15 |
|
Flexbox looks exactly like what I am looking for. Is there anything special I need to know about it? According to the exactly the first thing I read about it, it suggests that Safari, iOS and Android all use the old syntax (whatever that means). Is Flexbox something that is only partially supported?
|
# ? Jun 14, 2014 09:26 |
Edit: Sorry if this is more appropriate for the critique thread, but that thread seems awfully dead. It's been years since I did any serious design. As a consequence, I am now totally poo poo at design and layout. I recently soft-launched Pick a Prez, and I want to get a few opinions on whether the layout conveys information in a reasonably attractive way, and whether the new design is an improvement over the old version. I know it's rear end, I know it probably makes you want to puke, but I want to know if it makes you want to puke less than the original. You have to click a few candidates to see how the layout changes. There's a chick with a really long name who fucks up the thumbnail layout. I am aware of that problem. Also, take a look at the stats page, if you have the time. I know it's clashy and simplistic, but, again, is the information laid out fairly intuitively? Thanks Centripetal Horse fucked around with this message at 09:47 on Jun 14, 2014 |
|
# ? Jun 14, 2014 09:45 |
|
Lord Windy posted:Flexbox looks exactly like what I am looking for. It's fairly widely supported but since WebKit (the code behind (Mobile)Safari and Android Browser) jumped in early it has slightly different syntax than what everyone else settled on. It all works the same way, and browsers ignore CSS they don't understand, so it's not too bad as far as these things go. It's worth looking up which browsers it works on, just to double-check, but by now it's pretty widespread.
|
# ? Jun 14, 2014 10:12 |
|
Really dumb quick question: is it best to use em in lieu of px? I remember em being a proportion of font size, so hypothetically you could make a layout that wasn't horribly disproportionate on mobile devices or older computers by using it, correct?
|
# ? Jun 14, 2014 10:33 |
|
Literally Elvis posted:Really dumb quick question: is it best to use em in lieu of px? I remember em being a proportion of font size, so hypothetically you could make a layout that wasn't horribly disproportionate on mobile devices or older computers by using it, correct? em for some things, px for others. Actually, rem, but that's not 100% supported yet! I think. The problem with setting type size in em is that it inherits. So if I have my LI type size at 0.85, and I nest lists, then the inner list will be .85 x .85 in size. What I do is: px for type sizes, and a mix of percentages, px, and em for widths, margins and padding. Of course, this will vary based on your design. tl:dr; there is no "rule", use what makes sense, but type in px is usually the right thing.
|
# ? Jun 14, 2014 13:48 |
|
We just had that conversation at work, and the one front end guy's opinion was that with the way modern browsers handle thing, it's perfectly fine to just stick with PXs. Centripetal Horse posted:I know it's clashy and simplistic, but, again, is the information laid out fairly intuitively I'm not sure it is, moving those stats to the sidebar decouples it mentally (to me) from the main area. The old design also lets me know that I did something with the whole "You selected..." part and stats. With the new design I just have a hard time figuring out what's going on. And yes, you definitely do not have an eye for design. It's okay though! Modern design is all about decluttering and getting down to the basics as much as possible, while still providing personality. So your site is actually over-designed. The colors you are picking are really harsh, and then on top of that you're using them as background colors, which really punch you in the face. There are tons of websites where you can pick out color pallets if you're not a designer. Your sight could look a lot better though by just stripping things away and giving things room to breathe. I can tell you're used to designing for small resolutions, but you can safely design at ridiculous sizes now, the most common resolution is actually 1366x768. However you should also design to what you analytics tells you about your userbase. So just going with removing background colors and being super simple, you can do this with your site, which while plain, isn't visually offensive:
|
# ? Jun 14, 2014 15:38 |
|
Centripetal Horse posted:Edit: Sorry if this is more appropriate for the critique thread, but that thread seems awfully dead. Very blunt critique: The incredibly saturated colors make my eyes hurt and makes me immediately not want to look at it, and not "trust" the site because of the terribleness of the colors. The info is not laid out well, as the things I would care about "What is this page?" "What am I supposed to do?" are small relative to the rest of the content. The white space between bits of grouped content is poor, as it makes me think related things are not related. Many, many missed opportunities to convey information in a meaningful way... why are the bars next to the percentages all the same size, despite being different percentages? This will sound mean, but this is an example of a page I would use to show "how to do everything wrong in Web UI / Graphic Design". Hire somebody. Again, this may sound mean, but I'm just being honest.
|
# ? Jun 14, 2014 16:53 |
|
Regarding the color scheme, you can pick something nice here: https://kuler.adobe.com/explore/most-used/?time=all
|
# ? Jun 14, 2014 17:39 |
|
So I'm learning with a end goal project in mind, and as I research the available frameworks, I find myself more and more confused. There's so many options out there, and picturing how they all fit together and what is most appropriate to invest the time in learning is difficult. What would be an appropriate set of frameworks for the following project: A web app focusing on food service tools, initially inventory management and recipes, then expanding to encompass other aspects of small business: scheduling, event planning, reservations, etc. I'll start very very basic, but would like to use a set of frameworks which can hold my hand a bit, but won't lead me into a dead end. The end goal would be something with mobile support, including gestures, fluid data updates, and a modern interface. Lots of forms, lots of tables and graphs. I've done light coding in the past, mainly VBA, MEL, some PERL, and dabbled in Java, but I'm basically a newbie. I've worked my way through a basic HTML/CSS book, and a Web app dev book, and am currently working on a Javascript/Jquery book. Node.js, Ember.js, and Semantic-ui look like attractive options. But so does KendoUI, Meteor (except for it being mondoDB locked), and just about everything else. What would your recommendations be for a set of frameworks that have broad support, a bright future, aren't too imposing to learn as a newbie, and work well together?
|
# ? Jun 16, 2014 08:23 |
|
Goon posted:What would your recommendations be for a set of frameworks that have broad support, a bright future, aren't too imposing to learn as a newbie, and work well together? I'm only like one stage ahead of you in terms of experience but I've been really enjoying using MEAN (Mongodb, Express, Angular and Node) for the last few months. It all works pretty nicely. There's a premade stack here http://mean.io/#!/ But I recommend following the tutorials on scotch.io and building from scratch http://scotch.io/tutorials/javascript/creating-a-single-page-todo-app-with-node-and-angular One day I am gonna ask about using Node in production in this thread, and whether it can replace apache and nginx, but I'm not quite there yet.
|
# ? Jun 16, 2014 11:29 |
|
Just use MVC5 with SSMS. Throw in Angular or Knockout if you want some dynamic stuff. The MEAN stack sounds pretty miserable.
|
# ? Jun 16, 2014 15:07 |
|
Goon posted:So I'm learning with a end goal project in mind, and as I research the available frameworks, I find myself more and more confused. There's so many options out there, and picturing how they all fit together and what is most appropriate to invest the time in learning is difficult. "It depends." You are going to need a server-side no matter what, so the question becomes how heavy is your client. If you want a single page "app", then your client is heavy, and you pick Angular, Ember, Backbone + React or Flux + React as your front end (I suggest React + Flux / Backbone, but run through the 'Hello World' of all and see what makes sense to you) and just about anything to make a "dumb-ish" backend, remember that you should NEVER TRUST THE CLENT. Your backend will still need to have business rules on it because people are mean and or stupid and send bad data. This can lead to duplication of effort, as your front end "app" may need to validate to the client and then validate again on the server. Some folks use Node to share code between back and front end, others recoil in horror at using JS on the server. I have no opinion on the matter. The other option is to make just a normal old website like the good-old days, in which case you don't need a fancy front-end framework, and can use whatever you'd like on the back end that handles full site related stuff. I personally use Django for that, but you may want to look into Flask as well. Both use python, which I find to be a wonderful language to code in. Flash is more like a base toolkit you use to build what you need, whereas Django is very much a "we did everything for you" solution. This is not to say that there are not other options: PHP has a bad rep, generally deservedly so, but it's ubiquity, large number of frameworks, and ease of hosting make it something you can't dismiss offhand. The only thing I'd advise against is using MongoDB as your sole data store. I have read / heard enough stories about data going missing that I would be scared to use it for anything other than cache. tl;dr: I'd suggest Django or Flask on the server, React + Flux or React + Backbone on the client.
|
# ? Jun 16, 2014 15:10 |
|
Chill Callahan posted:The MEAN stack sounds pretty miserable. How come? I finally settled on something after trying like a million loving combinations of different frameworks. Please don't make me change again. Lumpy posted:others recoil in horror at using JS on the server. I have no opinion on the matter. What are some reasons people give for this? I don't wanna keep using Node if it's really so terrible, but a JS backend is a pretty big bonus for me because it's the only language I know other than php. Also I really rely on stuff like grunt now.
|
# ? Jun 16, 2014 15:53 |
|
fuf posted:How come? Haters gonna hate.
|
# ? Jun 16, 2014 16:04 |
|
fuf posted:How come? I have no experience on the matter, but MongoDB gets brought up in the Coding Horrors thread semi-frequently. Before you jump in to using it because it's the hot cool thing, I'd investigate why that is. I'd also push you to learn a different language for the backend. Not because I have an opinion on Node, but because learning a new language once you know one isn't that big of a deal...especially if you choose something like Python which is very similar to Javascript...and running a server knowing just JS seems like a bad idea. Heck, you might learn something like Python and still end up using Node, but picking Node because you just know JS doesn't seem too smart when the hurdles to learning another language aren't terribly significant and will open up your options significantly.
|
# ? Jun 16, 2014 16:57 |
|
Yeah that all makes sense. I mean I didn't pick Node just because it's JS, that's just a nice bonus. I like how easy it is to manage projects with NPM, grunt, etc., and also how you have to build everything from scratch so you know what's going on. I've gotten pretty far with django a few times in the past, but managing different versions of python with virtual environments or whatever kind of drove me crazy (can't remember the details). What I really want to know is if Node is actually significantly slower, less reliable, or less secure or something, because that would be a good reason to change. quote:running a server knowing just JS seems like a bad idea. You mean like managing a server? I've been doing that for a while with just bash. What else might I need? (not trying to be defensive or anything, these are genuine questions! )
|
# ? Jun 16, 2014 18:18 |
|
|
# ? May 9, 2024 16:46 |
|
Thanks for all the great responses!Lumpy posted:"It depends." You are going to need a server-side no matter what, so the question becomes how heavy is your client. If you want a single page "app", then your client is heavy, and you pick Angular, Ember, Backbone + React or Flux + React as your front end (I suggest React + Flux / Backbone, but run through the 'Hello World' of all and see what makes sense to you) and just about anything to make a "dumb-ish" backend, remember React definitely seems like an attractive option. The website lists it as being at v0.10.0. Am I reading this wrong, or is it still short of a production ready release? How do the various types of frameworks like bootstrap and semantic-ui, React and Angular, and templating engines work together? Are they supposed to or are they exclusive technologies solving separate issues? I'm looking at making what would end up being a heavy client, but I'd like to start with a basic website and get the back-end database fleshed out first. Does a single page app require sufficiently different architecture that it would be a bad idea to iterate from one to the other?
|
# ? Jun 16, 2014 18:46 |