[Proto-Scripty] Re: Generating invalid HTML for purpose of custom attributes
On Mar 27, 11:43 am, Walter Lee Davis wa...@wdstudio.com wrote: On Mar 26, 2011, at 9:37 PM, kstubs wrote: Is it bad, or does it make parsing objects unstable if you append custom attributes to an HTML tag? Lets say I want to keep track of a number, maybe a customers ID, so I do something like: var div = new Element('div', {'customerID':1234}); The issues are inadvertent overwriting of HTML attributes (so you can't just use any attribute name, you have to be careful) and IE's mishandling of DOM element attributes and properties. To get consistency across browsers, you have to read the attributes using getAttribute and set them (using code) with setAttribute. Because IE munges attributes and properties, you should only ever use DOM properties for HTML atributes. So you need to be careful to distinguish between the two and only use the appropriate method, which is why it is usually suggested to not use custom attributes and to use a data object instead, that way you only ever use one method that is consistent for all browsers. which should result in: div customerID=1234/div Should being the operative word. Note that in IE, the div DOM element will have a property of customerID, but it will not in Firefox. That sort of inconsistency is why you should avoid custom attributes and properties. Perhaps that issue is fixed in IE 9, but it will be a very long time before you can ignore all other versions of IE on the web. HTML5 lets you do this, and pretty much anything else you like, by adding a data- prefix to the attribute name. Have at it. HTML5 is not a standard, nor is it widely supported yet. -- Rob -- You received this message because you are subscribed to the Google Groups Prototype script.aculo.us group. To post to this group, send email to prototype-scriptaculous@googlegroups.com. To unsubscribe from this group, send email to prototype-scriptaculous+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/prototype-scriptaculous?hl=en.
[Proto-Scripty] Re: Generating invalid HTML for purpose of custom attributes
Because IE munges attributes and properties, you should only ever use DOM properties for HTML atributes. This is (as I understand it) one part of the rationale for the `data-` prefix: There aren't any DOM element properties with those names, and so IE's broken behavior isn't an issue with them. Yes, it does dump them on the element instance (if you put a data-foo attribute on a div, the element instance for that div will indeed have a property called data-foo on it -- prior to IE9), but it's harmless (though as always, YMMV). For instance, try this: http://jsbin.com/ewade3/2 That works fine on IE6, IE7, (I don't have IE8 handy), IE9, Chrome 10, Safari 5, Firefox 3.6, and Opera 11 under Windows; and Chrome 10, Firefox 3.6, and Opera 11 under Linux (Ubuntu 10.04 LTS). I don't have a Mac handy, but it works in Mobile Safari on my iPhone. :-) The IE checks show that IE6 and IE7 and presumably IE8 (but not IE9, yay) do dump the data- properties on the element, but you wouldn't look for them there anyway since no one else does -- stick to `getAttribute` (or better yet, Prototype's `readAttribute` because of the *other* insane things IE does with attributes) and you're fine. HTML5 lets you do this, and pretty much anything else you like, by adding a data- prefix to the attribute name. Have at it. HTML5 is not a standard, nor is it widely supported yet. True. But there are two very different aspects to HTML5: Codifying and standardizing the things browsers were already doing and had been doing forever, and defining new things for them to do. By its very nature, the first part is widely supported. :-) data- attributes fall into that category (every browser I've ever seen supported custom attributes on elements; HTML5 reins it in a bit). I dare say that that subset of HTML5 is a better specification for HTML in the real world than the HTML4.01 standard from over 11 years ago. Of course, the trick with the HTML5 spec is knowing which bits are which. ;-) -- T.J. On Mar 28, 7:23 am, RobG rg...@iinet.net.au wrote: On Mar 27, 11:43 am, Walter Lee Davis wa...@wdstudio.com wrote: On Mar 26, 2011, at 9:37 PM, kstubs wrote: Is it bad, or does it make parsing objects unstable if you append custom attributes to an HTML tag? Lets say I want to keep track of a number, maybe a customers ID, so I do something like: var div = new Element('div', {'customerID':1234}); The issues are inadvertent overwriting of HTML attributes (so you can't just use any attribute name, you have to be careful) and IE's mishandling of DOM element attributes and properties. To get consistency across browsers, you have to read the attributes using getAttribute and set them (using code) with setAttribute. Because IE munges attributes and properties, you should only ever use DOM properties for HTML atributes. So you need to be careful to distinguish between the two and only use the appropriate method, which is why it is usually suggested to not use custom attributes and to use a data object instead, that way you only ever use one method that is consistent for all browsers. which should result in: div customerID=1234/div Should being the operative word. Note that in IE, the div DOM element will have a property of customerID, but it will not in Firefox. That sort of inconsistency is why you should avoid custom attributes and properties. Perhaps that issue is fixed in IE 9, but it will be a very long time before you can ignore all other versions of IE on the web. HTML5 lets you do this, and pretty much anything else you like, by adding a data- prefix to the attribute name. Have at it. HTML5 is not a standard, nor is it widely supported yet. -- Rob -- You received this message because you are subscribed to the Google Groups Prototype script.aculo.us group. To post to this group, send email to prototype-scriptaculous@googlegroups.com. To unsubscribe from this group, send email to prototype-scriptaculous+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/prototype-scriptaculous?hl=en.
[Proto-Scripty] Re: support vars in the popwindow
I am sorry, causing the mismatch with the direct answering. David, you were right. But I cancelt the whole Problem, by adding another raw with two radio buttons. It is easier for me, saver and simpler. But thanks for your efforts! Best tsunami On 26 Mrz., 20:19, David Behler d.beh...@gmail.com wrote: I guess what he means is this: He opens a popup and wants to access a variable that's declared in the parent window. He could pass the value of the variable in the url (= by get, $_GET in PHP) but he wants to support large texts and might pose a problem when put in the url. Solution: I don't think there is a prototype-way to do this, but it can still be done with standard javascript: opener.document.getElementById(foo).value = 'bar'; David Am 26.03.2011 19:03, schrieb T.J. Crowder: Hi, On Mar 26, 5:42 pm, tsunamio.ei...@googlemail.com wrote: Dear all, is there a possibillity to support vars from the parent window? Yes, of course by get, but I want to support large texts. So get might be a wrong decision. Best tsunami Not following you, can you explain more what you mean? -- T.J. Crowder Independent Software Engineer tj / crowder software / com www / crowder software / com -- You received this message because you are subscribed to the Google Groups Prototype script.aculo.us group. To post to this group, send email to prototype-scriptaculous@googlegroups.com. To unsubscribe from this group, send email to prototype-scriptaculous+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/prototype-scriptaculous?hl=en.
[Proto-Scripty] Re: future of script.aculo.us
What the future will be Prototype and script.aculo.us if my future developers want to choose only one library. Which should we choose for future ? and why ? Predicting the future is a mug's game. Right now, jQuery is huge. It has corporate sponsors, full-time staff, a massive userbase, and a lot of momentum. Prototype doesn't have corporate sponsors or full-time staff, I _think_ the userbase is rather smaller (but I don't have numbers for that and there are a LOT of people using it with Rails), and releases and new features aren't coming as quickly by comparison. Both have passionate individuals extending, contributing to, and using them. But all that could change in, seemingly, seconds. The community could take against a direction jQuery goes. A new library could appear that takes over the world, pushing both Prototype and jQuery to the sidelines. A megasponsor could decide that Prototype is the bee's knees and hire people to work on it full-time. If you review the replies in this thread, there's a clear theme: Teach fundamentals, not libraries. JavaScript is a rich and very powerful language that probably doesn't quite work the way your students think it does. Make sure they understand it. Make sure they understand the DOM -- not necessarily the details of the DOM API beyond a few basics, but the fundamentals of elements and trees and nodes and documents. Teach them how browsers work, and the nature and consequences (and advantages) of asynchronous communication between client and server. Teach them about JSON and basic XML. Teach them to seek, and read, details from primary sources like the ECMAScript specification, the various DOM specs, the CSS spec, the HTML5 spec, etc., rather than relying on meta-sources like w3schools (*shudder*). Do that, they'll have no trouble picking up any library they want to with just a couple of hours' work reading the API docs, kicking around the related tags on StackOverflow or the discussion group for the lib, and tinkering. Best, -- T.J. Crowder Independent Software Engineer tj / crowder software / com www / crowder software / com On Mar 24, 11:09 am, Ali.MD alimihando...@gmail.com wrote: thank you very much my question about future jQuery and prototype and some other javascript library is similar to each other I can not find a significant difference between them. is that right ? a agree jquery is better to teach. and we must to teach other javascript library with jQuery I'm worried about the future What the future will be Prototype and script.aculo.us if my future developers want to choose only one library. Which should we choose for future ? and why ? i dont worry about plugins and extensions because we can use all of them together ;) -- You received this message because you are subscribed to the Google Groups Prototype script.aculo.us group. To post to this group, send email to prototype-scriptaculous@googlegroups.com. To unsubscribe from this group, send email to prototype-scriptaculous+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/prototype-scriptaculous?hl=en.
[Proto-Scripty] Re: Generating invalid HTML for purpose of custom attributes
Hi, I created a little helper for custom data-attributes: http://mstuhlmann.wordpress.com/2011/01/10/working-with-custom-data-attributes/ Greets, mstuhlmann On 28 Mrz., 12:18, T.J. Crowder t...@crowdersoftware.com wrote: Because IE munges attributes and properties, you should only ever use DOM properties for HTML atributes. This is (as I understand it) one part of the rationale for the `data-` prefix: There aren't any DOM element properties with those names, and so IE's broken behavior isn't an issue with them. Yes, it does dump them on the element instance (if you put a data-foo attribute on a div, the element instance for that div will indeed have a property called data-foo on it -- prior to IE9), but it's harmless (though as always, YMMV). For instance, try this:http://jsbin.com/ewade3/2 That works fine on IE6, IE7, (I don't have IE8 handy), IE9, Chrome 10, Safari 5, Firefox 3.6, and Opera 11 under Windows; and Chrome 10, Firefox 3.6, and Opera 11 under Linux (Ubuntu 10.04 LTS). I don't have a Mac handy, but it works in Mobile Safari on my iPhone. :-) The IE checks show that IE6 and IE7 and presumably IE8 (but not IE9, yay) do dump the data- properties on the element, but you wouldn't look for them there anyway since no one else does -- stick to `getAttribute` (or better yet, Prototype's `readAttribute` because of the *other* insane things IE does with attributes) and you're fine. HTML5 lets you do this, and pretty much anything else you like, by adding a data- prefix to the attribute name. Have at it. HTML5 is not a standard, nor is it widely supported yet. True. But there are two very different aspects to HTML5: Codifying and standardizing the things browsers were already doing and had been doing forever, and defining new things for them to do. By its very nature, the first part is widely supported. :-) data- attributes fall into that category (every browser I've ever seen supported custom attributes on elements; HTML5 reins it in a bit). I dare say that that subset of HTML5 is a better specification for HTML in the real world than the HTML4.01 standard from over 11 years ago. Of course, the trick with the HTML5 spec is knowing which bits are which. ;-) -- T.J. On Mar 28, 7:23 am, RobG rg...@iinet.net.au wrote: On Mar 27, 11:43 am, Walter Lee Davis wa...@wdstudio.com wrote: On Mar 26, 2011, at 9:37 PM, kstubs wrote: Is it bad, or does it make parsing objects unstable if you append custom attributes to an HTML tag? Lets say I want to keep track of a number, maybe a customers ID, so I do something like: var div = new Element('div', {'customerID':1234}); The issues are inadvertent overwriting of HTML attributes (so you can't just use any attribute name, you have to be careful) and IE's mishandling of DOM element attributes and properties. To get consistency across browsers, you have to read the attributes using getAttribute and set them (using code) with setAttribute. Because IE munges attributes and properties, you should only ever use DOM properties for HTML atributes. So you need to be careful to distinguish between the two and only use the appropriate method, which is why it is usually suggested to not use custom attributes and to use a data object instead, that way you only ever use one method that is consistent for all browsers. which should result in: div customerID=1234/div Should being the operative word. Note that in IE, the div DOM element will have a property of customerID, but it will not in Firefox. That sort of inconsistency is why you should avoid custom attributes and properties. Perhaps that issue is fixed in IE 9, but it will be a very long time before you can ignore all other versions of IE on the web. HTML5 lets you do this, and pretty much anything else you like, by adding a data- prefix to the attribute name. Have at it. HTML5 is not a standard, nor is it widely supported yet. -- Rob -- You received this message because you are subscribed to the Google Groups Prototype script.aculo.us group. To post to this group, send email to prototype-scriptaculous@googlegroups.com. To unsubscribe from this group, send email to prototype-scriptaculous+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/prototype-scriptaculous?hl=en.
[Proto-Scripty] wired object behavour in IE7
hi there, i know this is generic JS und it is only occuring in IE7, but i hope you can help me though... i have an array/list of objects like [ { name : 'blah blah', mp3 : 'http://server.tld/song.mp3', }, . ] when i do a for-in loop over such an object, i get its keys and values as it should be... but, the next line, when i try to access the objects' properties 'directly' like oTrack.mp3or oTrack['mp3'] all IE(7) outputs is a unsatisfying 'undefined'... (please, see the code below for further details) any ideas anyone, please? YT BB code for ( iTrack in aPlaylist ) { var oTrack = aPlaylist[iTrack]; for ( mData in oTrack ) { document.write('' + iTrack + ', ' + mData + ', ' + oTrack[mData] + 'br /'); // everything seems fine, all keys, all values } document.write('' + iTrack + ', ' + oTrack.mp3 + 'br /');// nothing is fine, outputs 'undefined' for any property document.write('' + iTrack + ', ' + oTrack['mp3'] + 'br /'); // ... } /code -- You received this message because you are subscribed to the Google Groups Prototype script.aculo.us group. To post to this group, send email to prototype-scriptaculous@googlegroups.com. To unsubscribe from this group, send email to prototype-scriptaculous+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/prototype-scriptaculous?hl=en.
[Proto-Scripty] Re: wired object behavour in IE7
Hi, Can you put together a minimalist, self-contained example that demonstrates the problem and post it to jsbin.com or jsfiddle.net or something? (You can't use document.write there, but you can append paragraphs to the page or some such.) BTW, your code to loop through the `aPlaylist` array isn't quite right (but I don't think that's the actual problem). If you use `for..in` to loop through the array's elements, you have to do some checks because arrays can have properties other than array indexes, which will break your code. Details here: http://blog.niftysnippets.org/2010/11/myths-and-realities-of-forin.html Fundamentally, I don't see a problem other than the above with what you've quoted. Seems to work: http://jsbin.com/ulesa4 HTH, -- T.J. Crowder Independent Software Engineer tj / crowder software / com www / crowder software / com On Mar 28, 3:21 pm, Björn Bartels bbd...@googlemail.com wrote: hi there, i know this is generic JS und it is only occuring in IE7, but i hope you can help me though... i have an array/list of objects like [ { name : 'blah blah', mp3 : 'http://server.tld/song.mp3', }, . ] when i do a for-in loop over such an object, i get its keys and values as it should be... but, the next line, when i try to access the objects' properties 'directly' like oTrack.mp3 or oTrack['mp3'] all IE(7) outputs is a unsatisfying 'undefined'... (please, see the code below for further details) any ideas anyone, please? YT BB code for ( iTrack in aPlaylist ) { var oTrack = aPlaylist[iTrack]; for ( mData in oTrack ) { document.write('' + iTrack + ', ' + mData + ', ' + oTrack[mData] + 'br /'); // everything seems fine, all keys, all values } document.write('' + iTrack + ', ' + oTrack.mp3 + 'br /'); // nothing is fine, outputs 'undefined' for any property document.write('' + iTrack + ', ' + oTrack['mp3'] + 'br /'); // ... } /code -- You received this message because you are subscribed to the Google Groups Prototype script.aculo.us group. To post to this group, send email to prototype-scriptaculous@googlegroups.com. To unsubscribe from this group, send email to prototype-scriptaculous+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/prototype-scriptaculous?hl=en.