Skateside

I wonder if that's a carriage return ... You see, when typewriters existed, "new line" and "carriage return" were two commands. When hitting the "enter" key, some operating systems sent both commands to properly emulate the experience. This is why the symbol on the "Return" key is ... ... oh, yeah, solutions ... Dude, this is Prepros. It compiles files such as LESS, SASS, JavaScript, Coffeescript ... more useful is the fact that it can compress CSS files and watch your folder (so saving in Dreamweaver will automatically compress your file). The minified file wouldn't have that weird character in it (would load faster too because it's a smaller file). To top it all off, Prepros is free. Might be worth a shot.

Try removing that "scripts/smooth.pack.js" script. I think it's trying to do the job and possibly causing issues. You can find plugins that do the same job and probably work better, if you need the animation at all.

Sorry, I should have made my answer more specific (ironically enough). .foo { color: red !important; } The food element can be overridden by a selector like: div.foo { color: green !important; } Adding "!important" to the rules is not enough to guarantee that the styles will never be overridden

Only thing to add to what rbrtsmith said is that the padding should be 56.25% for 16:9 videos (9 / 16 = 0.5625, x 100 = 56.25) and 75% for 4:3 videos (3 / 4 = 0.75, x 100 = 75) although 16:9 is the most common aspect ratio online.

Ah - I get it now. I've always called them "surgical" classes and always put them at the end. Just for the record, !important styles can be overridden. The !important will increase the specificity massively but a large specificity will still override them. I believe my point still stands, careful planning can avoid !important all together. Still, thanks for pointing Harry Roberts out to me. There's a lot of good stuff on his site (I love the idea of grouping classes).

Hmm ... I actually find myself disagreeing with this statement as well. I'd need some time to hunt down an example, but I had to build a menu in the header recently. This menu was supposed to show the top-level categories initially. Clicking on a category would slide down the next level. Upon clicking certain entries in that level (denoted by an arrow) the level would slide to the left, out of the way, revealing another level. These sliding levels were supposed to be infinitely nestable (although common sense dictates that only three or four levels should exist). In order to keep the menu maintainable, I broke it up into 3 distinct modules: the accordion (opening and closing based on the top-level category being clicked), a slider (for the sub-levels) and, of course, the header for the main styling. This means that the top-level category link actually had 6 classes on it ("header_tab_link header_tab_link-builder accordion_trigger accordion_trigger-mobile js-accordion-trigger is-active") and the sub level with the slider had 4 ("header_tab_sub_link slidelist_trigger slidelist_trigger-mobile js-slidelist-down") but each of the classes have their own "semantics" meaning they're easy to understand, modifidy and maintain once they've been explained (the leading letters, if 3 or more, describe a module so "header" would be in "header.less", the underscore describes a part of the module, a hyphen describes a modification which would override some styles or add others; the "is-" is a state and will change a couple of the styles by may be dynamically toggled, the "js-" prefix is a JavaScript hook - has no styles, but JavaScript will add functionality to it). To me, this separation of modules makes the CSS vastly more usable (I wouldn't have to re-write the accordion styles if I wanted an accordion somewhere else on the page) and more maintainable (the accordion styles will be in "accordion.less"). However, it does blow the specificity graph to hell as the accordion styles would have the rule .accordion_trigger.is-active {} inside it with selectors only a single class strong above and below it.

I disagree. The problem with !important is that it's toxic. Using !important again is the only way to override it. If you separate content and container, your styles won't be conflicting and !important isn't necessary.

One of the best ways I've ever found to keep specificity down is to add a class to every element you wish to style. This allows you to limit your specificity to a single class strong with very few exceptions, specifically: states, :nth-child() (but use that remarkably sparingly) and pseudo-elements. You end up with a graph that looks somewhat like the one that Harry described (or at least, it would if the styles were ordered by specificity instead of grouped by module). Here's an example of the type of style sheet I mean.

setInterval expects a function. Try re-writing part of your code to this: timer=setInterval(function () { fade($('.pics:first')); }, 500);

Like any other design pattern, the IIFE has its pro's and con's. There's no reason they can't be nested, but frequently it's unnecessary. In terms of working with multiple devs, the issue that the pattern you displayed (other than the SyntaxError - I'll get to that) is that many people will be trying to modify the same code. That will cause headaches at best and merge collisions at worst. A better solution would be to collate multiple files all referencing a common namespace. Each developer would work in his or her own file, and an IIFE for each part of the code would keep scope contained. It would look something like this: // Base file var MYAPP = {}; // Dev 1's file MYAPP.module1 = (function () { return { }; }()); // Dev 2's file MYAPP.module2 = (function () { return { }; }()); Modules would either be started manually or using some kind of autoloader. This pattern gained popularity when it got the name The Yahoo Module Pattern and it's still widely used today. Now - that SyntaxError I mentioned. Your first line looks like this: var App = (function($, d, w, 'undefined'){ The string 'undefined' should be an argument name. The first line should look like this: var App = (function($, d, w, undefined){ It's worth pointing out that in 5 or 6 years of professional JavaScript writing, I have never seen anyone write var undefined = true;

Definitely going to need to see some code. There are 3 main styles of writing object oriented code in JavaScript so it's tricky to advise without knowing your choice; although, at a guess, you're using the prototypal style. We don't really need a full object oriented architecture to add elements to a page, simple functions will do the same job and nodes can be cloned. As for something else that you can do ... you can do as much in OO JavaScript as you can in any other aspect of JavaScript, likewise many other languages. If you're looking for basic inspiration, I'd recommend looking at JavaScript Pro Design Patterns although JavaScript Patterns covers many similar topics and is a lighter read.

I think you're after something like Isotope.

At the risk of giving you a whole bunch of extra work, I think the idea of passing the element's ID in as a string is a bad one; I think the library being flexible enough for a CSS selector or even an element itself would be much better. As an example, quite often in my websites I add a class to an element to identify it for JavaScript interaction, something like "do-show" or "do-refresh." This allows me to bind the same functionality to multiple elements or delegate the event to anything with that class. It's also worth thinking of the DOM as a toll road: if I can travel it once (and store the reference to the other side) then I don't need to pay the toll again. By the looks of things, if I wanted to bind 2 events to an element using your library, I'd have to find the element by ID twice. It would be nicer and more efficient if I could find it ones then bind the events to the reference. It also looks like I can only bind a single event to each element. Your library's a good start and I like the idea of something small and simple to use rather than some of the more monstrously larger libraries, but I think it needs more work before it's ready.

Start understanding the concepts of object-oriented programming (assuming you don't already). I'm sure backbone has it's uses, never really figured out what they are but then I've never tried building a large application purely in JavaScript. I guess looking into things like RequireJS, read up on the works of Nicholas Zakas and the people he mentions and unit test everything.

Before anyone answers this, can I just check: is this homework?

Have you tried putting position: relative; on #masthead nav? I'll try reading your post fully first ... Your problem is your clear fix, .container:after, .row:after, this has visibility:hidden on it, causing the :after on #masthead nav to be invisible. Try creating another element around your nav and putting the container class on that.

The only thing I like about the !important rule is that it has a higher specificity than an inline style. That's useful when you have to modify a page, don't control the markup and someone has used inline styles. I feel that at all other times it shouldn't be used.

Just to provide a difference of opinion here, I almost never use IDs any more (even for JavaScript). I prefer using classes because it makes the CSS more modular and easier to work with owing to the smaller specificity. Having read up on SMACSS, I live the idea of sub-classing my modules and that's much harder with IDs. I'm not saying that IDs are bad things, just that there are those of us out there who chose not to use them.

I know this may seem petty, but we have a convention in JavaScript when it comes to using constructor functions like the one in your example - we always write them with a leading capital letter and train ourselves to see a leading capital and instinctively write new. This helps us get around issues that are caused with implied globals and a default context. The following piece of code is perfectly valid JavaScript and will run without errors (unless you've got "Strict mode" enabled): // Forgot to write "new" var poster = forumMember('Nillervision', 'learning', 'confused');In this situation, this will refer to window, our global scope, rather than an instance. Therefore, your properties and methods become global variables. Calling that function again will update those global variables and cause huge amounts of confusion when poster.name and poster1.name are both "Skateside". Other than that, everything you're saying is correct. You can also set methods and properties using the prototype property of a function, so instead of constantly re-making your revealProperties method, you can simply create it once using the style below: function ForumMember (name, intention, mood) { this.name = name; this.intention = intention; this.mood = mood; } ForumMember.prototype.revealProperties = function () { return this.name + ' ' + this.intention + ' ' + this.mood; };I you have a lot of methods to create, you can also set prototype to be an object literal with all your methods defined therein. This next snippit does exactly the same as the one just above:function ForumMember (name, intention, mood) { this.name = name; this.intention = intention; this.mood = mood; } ForumMember.prototype = { revealProperties: function () { return this.name + ' ' + this.intention + ' ' + this.mood; } };

I'm still learning this myself so my description may be a little ropy but hopefully it should help. Object Oriented Programming is the process of creating objects that handle specific tasks in your application. It's generally seen as the way forward for a couple of important reasons. It separates the interface (the method names) from the implementation (what the methods actually do) - for example, a method called "hide" will clearly make something invisible, but whether that's done by setting "display:none;", "clip:rect(1px, 1px, 1px, 1px);position:absolute;" or even removing the element entirely is up to the programmer. The other key point is code re-use. When you have two elements that do essentially the same thing, but one has a couple of differences, an object-orientated style will allow you to create an object for the first, sub-class and expand it for the second. Instead of re-writing code you've already figured out, or passing in booleans all the time, you've got an easy-to-follow chunk of code. This also helps with any debugging as solving a bug in the parent object usually fixes it in the children too. The book that got me thinking along these lines in JavaScript was Pro JavaScript Design Patterns - it's full of examples of object orientated JavaScript with the added bonus of describing a few of the design patterns that OOP lends itself to and examples of when to use them.

if (Array.isArray(data.files)) { data.files.forEach(function (file) { console.log(file); }); } Essentially, that's how you want to do it.

Hmmm, I'd have approached that one slightly differently: http://jsfiddle.net/Skateside/7RspB/

The other main advantage of learning HTML and CSS rather than simply using DreamWeaver is that your skills are transferable. You can pick up any HTML editor and know how to use it because you've learned the code rather than the program. Or, to answer the main question more directly: no it's not essential as such, but a very good use of time.

What you essentially need to do is put together a string with that combination of values, check it's length and if it's too long, populate a second string with the extra bit before reducing the size of the first string. I've put together an example showing how to do this, feel free to use it: Skateside's example

Always been a problem I'm afraid. Doesn't look like it'll be standardised for a while.