Jump to content


  • Content count

  • Joined

  • Last visited

About Skateside

  • Rank
  • Birthday 08/20/1984

Users Experience

  • Experience
  • Area of Expertise

Contact Methods

  • Website URL

Profile Information

  • Gender
  • Location
  1. CSS Issue - Only First Media Query Working

    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.
  2. HTML5 Anchor - Name tag doesn't pass W3C Validator

    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.
  3. CSS specificity graph.

    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
  4. Video slider scaling problems - CSS

    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.
  5. CSS specificity graph.

    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).
  6. CSS specificity graph.

    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.
  7. CSS specificity graph.

    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.
  8. CSS specificity graph.

    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.
  9. clearInterval don't working

    setInterval expects a function. Try re-writing part of your code to this: timer=setInterval(function () { fade($('.pics:first')); }, 500);
  10. JavaScript variable scoping -- keeping the global clean

    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;
  11. Need help: Object oriented comments

    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.
  12. Looking for a paticular name or JS library

    I think you're after something like Isotope.
  13. Simple to Use Javascript Library

    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.
  14. Next step to building apps with JS

    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.
  15. Need some JavaScript definitions

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