Hi, > maybe I'm confusing javascript properties to the attributes?
Yes, I think you are. Easy enough to do, but they're really quite distinct things. HTML elements have attributes, which (initially) come from the markup and are accessible via the DOM methods `getAttribute` and `setAttribute` (Prototype provides `readAttribute` and `writeAttribute` that you should use instead, as they fix lots of oddities -- particularly in IE -- related to certain attributes.) Attributes are not properties. JavaScript objects have properties. The objects browsers provide to JavaScript to represent the DOM are sufficiently like JavaScript objects that they also have properties. (This needn't necessarily have been the case, host-provided objects can follow just about any rules they want, but in practice -- fortunately -- even IE made it possible for the objects themselves to have JavaScript-like properties.) Some attributes are _reflected_ as properties. The classic example is the "class" attribute, which is reflected by the `className` property. Setting the attribute changes the property; setting the property changes the attribute. But not *all* attributes are reflected as properties, and not all properties reflect attributes. People sometimes add their own custom properties to DOM objects. That's what we call "expando" properties. These are not attributes. Technically (again) it would be possible that a browser would not allow custom properties on the DOM objects it provides, but fortunately (again) none of the major browsers has a problem with it. And so we can do things like this: var div = $('mydiv'); div.foo = "bar"; ...and later we can refer to `$('mydiv').foo` and get back the string "bar". This is very convenient, but you need to be careful with it, especially on IE. Firstly, you need to be sure you're not using a property name that the browser is already using for something else! Secondly, you need to be sure that you don't create circular references between DOM elements and JavaScript objects when you do that, because that causes memory leaks on IE. That's why libraries like Prototype provide a means of storing metadata on elements via their APIs (I think on Prototype it's `Element#getStorage`), so they can take care to avoid issues for you. People sometimes add their own *attributes* to HTML elements, usually in the markup to associate further information with the element. For instance, recently I ran into someone who put all of the weights on a page into spans so that users could easily toggle between pounds and kilos in the display using JavaScript, but he couldn't figure out how to do it. I suggested using a custom attribute to hold the canonical weight (what they have in their database) and then toggling the content of the span based on what the user prefers. For 15 years, custom attributes on HTML elements in the markup have been *invalid* -- they would not pass the validation suites that people use to check their markup. The HTML5 working group recognized the value of custom attributes, but also the danger in people just defining things willy- nilly, and so they defined the "data-" prefix. You can't have your own "weight" attribute, but you can have your own "data-weight" attribute. I use custom attributes (*always* with the "data-" prefix) for conveying information in the markup that I later want to access from script, like the data-weight attribute above. I also use them if I need to be able to search for elements that have a certain piece of information on them. For instance, in the weights example, it's trivial to find the spans we need to change when the user changes the display from kgs to lbs: $$('span[data-weight]').each(...); If we used an expando property that we added to the elements after page load, we wouldn't be able to use that selector. I use expando properties (or data storage via an API) when I need to associate information with an element that I don't need to convey via markup or search for later with a selector. This is just to cut out the overhead of reading and writing attributes to the underlying DOM, and because properties can be things other than strings. In practice, I find I have virtually no use for expando properties in my applications (I use elements to *represent* application objects, not *as* application objects), but they're frequently useful in library code. Hopefully that rambling was of some use. :-) Happy coding, -- T.J. Crowder Independent Software Engineer tj / crowder software / com www / crowder software / com On Oct 20, 4:34 am, buda <www...@pochta.ru> wrote: > maybe I'm confusing javascript properties to the attributes? how do > they compare? > > On 20 окт, 02:03, buda <www...@pochta.ru> wrote: > > > > > Or should I use .storage object? > > But in this case I couldnt do search like $$('p[myAttr=foo]') > > > On 20 окт, 01:59, buda <www...@pochta.ru> wrote: > > > > I'm confused at all. > > > On the one hand HTML declares the existence of the elements expando- > > > attributes. > > > On the other hand HTML5 says that all illegal attributes must begin > > > with "data-". > > > What should I do? > > > continue to use espando or a new style of naming attributes with the > > > "data-"? > > > Prototype.js uses expando attributes - should I do the same? > > > > Thanks -- 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-scriptacul...@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.