Hadien

You're right. It is unnecessary.Since I'm using an && operator it's redundant, but in general a !! is a quick way to see if a property was defined. Though not as accurate as a typeof, especially when the variable can already be a boolean.

I wrote a similar thing when I was learning HTML5 canvas. I was making the illusion of two eyeballs following the cursor while in the dark grey div. Slightly more advanced since I didn't want the "pupils" to follow cursor off of the eyeballs, so I added a little trigonometry(arctangent) that slows down the pupils to a point were they stop following cursor when it reaches a certain distance.Canvas EyeballsSimply add a onmouseover event on the controlling div. While the mouse is over the div, it will continually call the function that will move the image. Once the mouse leaves the div's boundaries, it will stop making the call and thus stop moving the image. The onmouseover event can pass an object which will have the mouse's coordinates. You can then use something like absolute positioning and tie the mouse coordinates to the image's top and left styles.

I started off with notepad long time ago. Then moved to ConTEXT for the longest time. Loved context, but since it's no longer being kept up (was programmed in Delphi). I recently moved to sublime, which basically expands on what context gave. I pretty much use a portable version on a flash drive since there's numerous workstations I move to. The only thing I dislike like about sublime is that it loves trying to close my parens/brackets/quotes automatically at the wrong times. Other than that love it.

No it definitely not working on iPadI played with src in w3schools tryit pages and was able to get it to work fine, so it's not a support issue.Try alerting sel.src immediately after setting it. See if safari is messing with it behind your back. Still doesn't explain why the image isn't breaking on my end though. I mean if the URL is invalid safari should show the broken img icon. Other possibilities could be a caching problem ( safari might think it hasn't actually changed even if src did. add on a ?rand=rand() at the end or something similar) or lack of preventDefault ( unsure if that would matter here). It might even be that (mainimg) you have stuck in the attributes and safari could fail to parse it.

I'm currently posting from an iPad, so I can't look directly at the code right now. But I didn't say to change to "display:inline", but "display:inline-block". Those are very distinct display modes. Float was designed to be used on inline elements. However many sites today use it as it wasn't intended as a hack. As a result browsers get confused as they don't know the precise dimensions of these block elements. To the browser these blocks have no height. The p and hr tags themselves think they are actually rendering below the floated divs (and technically they are as the browser is saying their client height is 0). However the space below these divs are being used by "something" and thus the p/hr tags have no room to go there. But there's room to the right, so they go there.The reason astroviewer has no problem with this (and what most sites do) is that they likely used another "hack" to hide the fact that these block elements were actually getting demolished. The next element on the new line prolly had a clear:both... The floating divs were prolly all contained in another tag which had 100%width so any siblings had no room to the right.... Or the floating divs had display:inline-block which let the browser know their dimensions and thus following "block" elements were able to know how far down they have to go. With inline-block, these elements will have the properties of inline elements and text (affected by text-align, float, trim surrounding whitespace to single-space instead of removing it), yet it will still have the properties of a block element (has a definable width/height, can have other block elements inside it). With inline-block you can basically visualize each of those navigation tabs as a single word. The following block elements (p and hr tags in your case) will see them as if they are text and will properly place themselves under it, even if there was room to the right. The only downside to inline-block is it's lack of support in pre-IE8 (and the fact that you might not want an element to always be affected by both text and block properties). Other than that it has a lot more control in a webpages layout. You don't need to add extra elements to preserve the look. And if you happen to use any JavaScript that depends on these elements dimensions, the DOM will return accurate measurements .

from what I read you want to run a simple state where the link in your nav that points to the current page "lights up". $(document).ready(function (){ $("a[href='"+window.location.pathname+"']").addClass("active);}); you don't even need the onclick event you've used in the other thread. Every time the page loads jQuery will do the check as to which link needs to be active. no <a> tag should have the "active" class nor the onclick="return false". and it should work. the only time the "current" link wouldn't light up is in that period of time between when the <a> tag is rendered and when the document is finished loading. theres numerous other more robust ways you can do this (PHP, cookie/session/localstorage) if what you want is more complicated than this. but if all you need is a simple link to change color based on the current page thats loaded, then this will suffice.

don't follow that first answer, follow the one right below it. like he said the 1st one forces you to create an element to test and that is both slow and unnecessary (but does the trick). var canCanvas = (!!window.HTMLCanvasElement && !!window.CanvasRenderingContext2D); I'm also using memoization here. the inital code I was gonna show you was a lot slower so I memoized it (redefined the function inside itself as a computing optimization). then after several, sevral iterations of simplifying the code I got to this basically it makes the check and assigns automatically when the page loads and thus you just need to make a call like: if(!canCanvas){ //do this stuff since the canvas isn't supported } I haven't tested this myself, but should hold across all browsers and most platforms (mobile devices is out of my territory though) Edit: don't even need to run it as a function, just simplified it further.

in general cross-browser javascript works via feature detection, not browser detection. Having javascript depend on a per-browser basis leads to very inflexible, weak code. if a new browser comes out or a current one has an update, you'd have to come back to this code and make it even more excessively complex. an example of definening a cross-browser addEvent. var addEvent = function (el, ev, fn) { //for nearly every browser (W3C) if (el.addEventListener) el.addEventListener(ev, fn, false); //for IE 8 else if (el.attachEvent) el.attachEvent('on' + ev, fn); //fallback else el['on' + ev] = fn; }; the code itself has no context as to what browser is running the code, it just runs what it knows it can support. there are much better ways to write that code, but this is the most straightforward. like Ingolme alluded to, unless you need to know the browser for some other reason than affect javascript code, you should probably not even try to find out.

3 out of the 4 posts I made today (including this one) explain that they all had the same problem and gave them the same solution. since I just went into detail about this on two other threads, I'll simply link to my posts because I just don't want to type it all out a 3rd time. Need Help? div width

not only text, but any inline element will ignore the width/height you give them (style:width/height that is, things like img are different), and they set their dimensions to what it think it needs. if you want an inline element to have a say in what it's width is, you switch their display to inline-block. inline-block will act in almost every way a character in a group of text will, but will also have access to properties like width/height.

I reread my post, and realise I was saying one thing while thinking of another. the performance hit is not at definition, but at execution. where its defined has an impact on how it's executed. I was specifically talking about event bubbling. for example: say that you add a onmouseover event to the body tag on a page which has it simulate a "tooltip" div which has a counter showing how many times the event fired. every time you move the mouse over the body it would have to update the counter and move the div to follow the cursor. now if the was on a busy webpage with a ton of elements, the hover event would run alot slower the more nested elements it needs to bubble out of. now if every element in the webpage had the onmouseover event added to it, it would run slightly faster since it doesn't have to bubble all the way up to the body to run the function, the body tag and most other tags have onevent attribute simply because how the internet started out. think back in the old days before chrome/safari/firefox. Back to when there was only netscape and IE. There was no real standard and netscape came up with the ability to run special scripting on certain tags. onload (and other simlar html attributes) came first. attachevent, addevent listener, $.on()... all came later. inline event calling is still a valid part of the current DTD because people still use it and use it as intended. but it shouldn't be, I wonder why it hasn't become depreciated. inline scripting has numerous disadvantages and violates XHTML with the fact that markup, and behavior should be separate from each other.

Let's focus on the footer elements in question first off you're using position:relative, which is essentially not needed. you're not offsetting where the footer is placed (with the parent element acting like it never moved). secondly, and the real problem is the use of float and clear. float and clear were intended for inline elements so that they can wrap appropriately. when you use it on block elements the parent element has trouble knowing the dimensions of the wrapping blocks. notice how the 'allo' is shown inside the footer's border but the other two are not. because the browser can't figure out their height and thus treats them as if they weren't there. your aside and section also suffer the same problem, the div#main doesn't know their dimensions. the only reason it appears to work is because the problem is disguised by the last element in the div#main (the footer) having the clear:both. with clear:both, the footer has the contextual information to know where it should put itself after the aside and section. and since footer is inside div#main, the div knows that it needs to have at least "this" height. if you remove the clear:both from the footer and you'll suddenly notice the border for the entire page gets demolished. floating and clear only properly works on elements that behave like inline elements, Now if you still want to use floating you can instead use display:inline-block on any block elements that would be affected by float/clear. With inline-block the elements will behave like inlines in that they'll lack a carriage return after the element and respect wrapping, yet they'll also behave like block element in that they'll support block elements inside of them and let you set their dimensions (you can set an inline dimensions, but browsers usually ignore them). with, their dimensions clearly defined for the parent element, the parent will know how big it needs to be and thus it's children will reside inside it's borders like you want. footer {clear:both;background:url(img/footer.png) no-repeat scroll center top;border:1px solid #000;width:810;height:270;margin:auto;}#colonne1 {display:inline-block;width:39%;}#colonne2 {display:inline-block;width:59%;} notice float is not needed now in these examples since you can you width percentages to control wrapping. now the 'allo' textnode is also an inline and thus will will be on the same line as column1. if you intend to keep 'allo' in there or put something else in that place and want to format the rest of the div, then either wrap that allo in a span and give it a float, insert a br in-between, or wrap in a block element, that should solve the problem with the footer. you "should" fix the same problem you have with aside and section, but its not that important since footer is hiding that. One more thing. inline-block is sensitive to the whitespace you type around it. since inline-blocks are treated like inlines the browser will treat them like text. and any chunk of whitespace around it will get trimed down to a single space. <span> this sentenceiscompletelycontiguous.</span> a browser and trim out all the extra whitespace between the words when its rendered. and to the browser, an inline-block is basically a "word" in the same sense. this is something you should be aware of if you start to scratch your head as to why 3 elements with 33% width wouldn't fit onto one line.

I wanted the error for the URL to be on a separate line from the other errors and a concise way to do that was to put each error in a block level element like <p> tags. Since it's a very bad idea to put block-level elements inside inline elements, like span, I changed the span (which is usually used to collectively format a some words in a paragraph, like bold or background colors) to a div (which is mainly used to hold a collection of elements, not text).I also try to avoid using the br tag when I can. Only time I would use it is if you want more than one new line after a group of text, like between this and the previous paragraph (depending on the forum, some put each paragraph in p tags and trim all whitespace, others just use br tags for newline, many others vary in-between). Block level elements always add a carriage return after themselves, removing the need to use br tags. Margins can further reduce it's need.jQuery has alot of power in playing with elements, and placing the errors inside tags allows more control if you want to add specific behavior or styling to each element you made. For example, since the first group of errors is required, you can give them specific styling to show that it's important. Using .text wouldn't give you the opportunity to add separate styling and events.The use of remove instead of just recalling .text or .html to overwrite stuff you put in adrserror is just habit I'd get into. Remove() also looks for and deletes event handlers that were attached to the deleted elements. Though you didn't add any events in the current example, it a good habit to get into since events linking to elements that no longer exist can cause serious memory leaks.

I couldn't get Ajax to work in JS fiddle so I merely faked the ajax call in my testing but I got the code to work just fine. my code "was" jquery friendly, just buggy, I forgot to make the success callback show that it passes a value and that checkData needs to return "this" not the function... anywho here is what I have in success callback: success:function(data){ data = {"address":false,"city":true,"municipality":false,"url":false}; var missing = []; var validurl = false; //validator constructor var checkData = function checkData(name,check){ if(false === this instanceof checkData) return new checkData(name,check); this.name = name; this.value = data[name]; this.validate = (typeof check=="function")?check:function(){}; return this; }; //validators var requiredcheck = function (){ if(this.value == false) missing.push(this.name); }; var emailcheck = function(){ validurl = (this.value ===false); }; //map data to validators var fields = [checkData('address', requiredcheck), checkData('city', requiredcheck), checkData('municipality', requiredcheck), checkData('url', emailcheck)]; //running checks for( var inp in fields) fields[inp].validate(); //clear previous error messages. $('#adrserror>').remove() //outputting results if (missing.length > 0) $('#adrserror').append('<p>You have to fill: ' + missing.join(', ')+"</p>"); if (validurl) $('#adrserror').append("<p>You have submitted an invalid url</p>");} I'm using .append() instead of .text() so that I could display the messages separately and in tags (I also changed adrserror from span to div, and removed the following br tag).

I don't see how that article is suggesting that its the preferred method, however... performance-wise: events in general have better performance the closer it is defined to the element it's attaching to. when an event is defined the browser needs to traverse the DOM from where it currently is to get to the element that it affects. so in this respect if the event is defined inside the element, the DOM has the least distance to traverse to assign the event. but as far as onload is concerned thats not as such a big deal since onloads are usually only called once in a pages lifetime that traversal speed is a drop in the ocean. onload via html has more use in graceful-degradation. say that an img tag has an onload to attach another hover event to the image when it loads. the hover event does some special things like affect opactiy. but if the image never loads (bad reference or corruption) then the hover event never needs to get attached. thats not to say its better to write onload events directly into the html tags, just that its another way of doing things. writing all your event handlers like onload into a script tag is fine, and its usually easier for the developer since all that code is consolidated in one place. but its perfectly valid to write directly into tags too, just not as flexible.

a lot of duplicated code....Try this: $.ajax({ type: "POST", dataType:"json", url: "adrsajax.php", data: {"address":address,"city":city,"municipality":municipality,"url":url}, success:function(){ var missing = []; //validator constructor var checkData = function checkData(name,check){ if(false === this instanceof checkData) return new checkData(name,check); this.name = name; this.value = data[value]; return (typeof check=="function")?check:function(){}; }; //validators var requiredcheck = function (){ if(this.value == false) missing.push(this.value); }; var emailcheck = function(){ if(this.value === false) missing.push(this.value); }; //map data to validators var fields = [checkData('address', requiredcheck), checkData('city', requiredcheck), checkData('municipality', requiredcheck), checkData('url', emailcheck)]; //running checks for( var inp in fields) fields[inp](); //outputting results if (missing.length > 0) $('#adrserror').text('You have to fill: ' + missing.join(', ')); }}); I didn't test it, but it should work. its roughly the same as my 1st code snippet, but alot of it has been minimized and this way can really cut down on your code duplication (notice that you can both define a function and run it inside a function.) EDIT: needed to add a "this.name" property since the wrong thing would be pushed into missing. also I'm looking more at your code and the checks you're making for uri are more or less redundant. I mean if(this.value === false) is equivalent to everything you're going out of your way to do for the uri check. you're mixing === and !== with == and !=. and they are NOT the same thing. with this in mind I changed requiredCheck and emailCheak to reflect what I THINK you want (look closely at their code, they AREN'T identical). could you clarify what type of check you want on uri 1.what values do you expect data.uri to have? 2.what do you want done if a specific thing is set to data.uri?)

my code is just as good other suggestions. but each suggestion has their tradeoffs. whenever I code, I usually try to put some degree of decoupling into them. its simply in my nature since I'm a software engineer. decoupling, encapsulation, composition, inheritance, etc. are all just coding principals that provide ways to make certain code more flexible and easier to add to. no code can be 100% decoupled,encapsulated, etc because at some point one variable must be able to interact with another. on the other hand it can't be 0% because its no use that all your strings will always be "Hello world" and nothing else. its like getting a new computer. 1)other suggestions are akin simply buying a new computer: the process is simple, quick, and straightforward. but you don't have full control of what your computer starts with. 2)my suggestion was more akin to building a custom computer yourself: you have a lot more control in what goes into your new computer. But the process is slightly more complex and you have to do more to get the job done. either option has their pros and cons,but both get the job done. if you have no plans to expand/change on this ajax checking (if there's only one place that will make this specific ajax call) then the suggestions most others have provided is more than sufficient (and quicker). my suggestion provides a sort of blueprint if you plan to expand on this later, making it easier to add logic.

the most robust way to do this is to use tables. HTML is incapable of having elements to float onto BOTH sides of a larger element to fit. Using tables is by far the simplest approach, which for the diamond cell you simply use rowspan="2". but you can use HTML+CSS to "fake" both-floating too: <div class="container"> <div class="donor_diamond_container"><div class="donor_diamond"></div></div> <div class="donor_stone"></div> <div class="donor_iron"></div> <div class="donor_iron"></div> <div class="donor_gold"></div> <div class="donor_empty"></div> <div class="donor_stone"></div> <div class="donor_stone"></div> <div class="donor_iron"></div> <div class="donor_iron"></div> <div class="donor_iron"></div> <div class="donor_gold"></div> <div class="donor_diamond_container"><div class="donor_diamond"></div></div> <div class="donor_gold"></div> <div class="donor_stone"></div> <div class="donor_gold"></div> <div class="donor_stone"></div> <div class="donor_empty"></div> <div class="donor_iron"></div></div> I simply removed the unordered list in my example and just used a group of divs (also switched out your div container class for mine even though I didn't need to). since div.diamond is meant to span to the next row I built a container for it. the diamond_container has the same dimensions as the normal boxes, but the div.diamond inside has the dimensions to span to the next row (put your content inside THESE divs) then I inserted a div.empty where the div.diamond would span into the next line. the .empty divs are merely placeholders so that the elements around them render as you want them to. the diamond_containers are like the .empty divs, they are merely placeholders to help properly format other elements .container { display: block; width: 700px; } .container>div { display: inline-block; float:left; vertical-align: top; margin: 0 0 5px 5px; width:128px; height:58px; font-weight:bold; border-radius: 5px; border-right: #000000 solid 2px; border-bottom: #000000 solid 2px; text-shadow: #FFFFFF 0.0em 0.1em 0.5em; }.donor_stone { background: #555555 center; border-left: #C0C0C0 solid 2px; border-top: #C0C0C0 solid 2px; } .donor_iron { background: #889 center; border-left: #C0C0C0 solid 2px; border-top: #C0C0C0 solid 2px; } .donor_gold { background: #AAAA35 center; border-left: #FFEE00 solid 2px; border-top: #FFEE00 solid 2px; } .donor_diamond_container { padding: 0px; } .donor_diamond { background: #AAAADD center; margin:0; height:125px; width:128px; font-weight:bold; border-radius: 5px; border-left: #E0E0FF solid 2px; border-right: #000088 solid 2px; border-top: #E0E0FF solid 2px; border-bottom: #000088 solid 2px; text-shadow: #FFFFFF 0.0em 0.0em 0.2em; } .container>div.donor_empty { z-index: -1; border:0px solid black; width:128px; opacity:0; height:58px; margin:2px 1px 7px 7px; } in this example I used display:inline-block and set the width of the container so that I didn't have to worry about line returning. you can also use display:table, table-row, and table-cell to allow other elements to behave like a table (do be aware that CSS Tables don't support row/colspan)

what you could do is write up an inputvalidator object and just run something like input.validate() command per input element. var missing = []; function input(id_name,check){ //this check is just so you don't have to say "new input()" everytime you // want to make a new input class. if (this instanceof input){ this.id =id_name; this.field = $("input#"+this.id); //if a validating function was passed, set it to validate, otherwise // use a default validate function that does nothing this.validate = (typeof check=="function") ?check :function(){ //default validate does nothing and returns self return this }; return this; }else{ return new input(id_name,check); } }; var requiredcheck = function (){ if(data[this.id] === false) missing.push(this.id); return this; }; var emailcheck = function(){ //Add code to validate the url }; var fields = [input('address', requiredcheck), input('city', requiredcheck), input('municipality', requiredcheck), input('url', emailcheck)]; for( var inp in fields){ fields[inp].validate(); } if (missing.length > 0) { $('#adrserror').text('You have to fill: ' + missing.join(', ')); } this way the validate() function worries about all what to do to which elements and you don't have to put in any fancy, inflexible logic like make sure to only require the first 3 elements. (what if later on you add 20 more inputs and they aren't all grouped together by how you want to work on them?). properly encapsulating the logic lets you avoid tons of if/swtich statements (your example was comparatively simple so its nowhere near as bad and it can get.

the img tag is an inline element. As far as inline elements are concerned in respect to horizontal alignment, the browser will treat them as text. so as was previously said, simply add the css (text-align: center) to the parent element to center the images horizontally. in your specific case you need to go to your css file and change this: .galleryphoto { width: 400px; padding-bottom: 20px; margin-bottom: 10px;} to this: .galleryphoto { width: 400px; padding-bottom: 20px; margin-bottom: 10px; text-align: center;} after thinking it over a little I guess I should clarify that this will center the image (and all text and other inline elements) relative to the parent element (elements with the .galleryphoto class). some other things can effect alignment like floating the image or if the parent element is using a display other than block (an old example of aligning inside an display:'inline-block' element in pre-IE8 browsers). however those exceptions shouldn't apply in your case. I guess its possible (though highly unlikely) that you wanted to center the image relative to the window or viewport. in which case, your original use of absolute or fixed positioning would be correct. in this case I'm not sure you can center the images without using something like javascript, and its easily doable with javascript. of course elements using non-static positioning always messes with surrounding elements using static and thus could be a chore to fix. Anywho, I doubt that you really should be messing with the position field in this case,

another beautiful usage of Canvas. I wasn't fully sure exactly what each line in the code does as I haven't seen full documentation on all the functions. (for example I didn't know why Context.save()/Context.restore() was called so many times, as the W3 canvas reference has no link to describe that). now I think its so that when each item is drawn it wouldn't "demolish" other items that are on other layers, specifically the save/restore were used to simulate layers. at least that's what I think.

First off, I like to say that I just joined the forums to a site that I have used as a reference for years, so its cool to finally join the community. I just recently started reading up on HTML5, never actually using it before and I started playing around with the canvas element. after playing with the tryit editors long enough, (I quickly found out that the editor limits how many variables you can have in javascript, so I moved to jsfiddle) and I eventually came up with a couple cool and simple things you can do with a Canvas Canvas Spotlight Canvas Eyeballs