T.J., thanks for an exhaustive explanation! But, as I understud, expando properties == custom attributes and its not good, but I see expando on extended elements in prototype! Will this to migrate to storage functionality or its not so bad practice?
On 20 окт, 12:51, "T.J. Crowder" <[email protected]> wrote: > 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 <[email protected]> wrote: > > > > > > > > > maybe I'm confusing javascript properties to the attributes? how do > > they compare? > > > On 20 окт, 02:03, buda <[email protected]> wrote: > > > > Or should I use .storage object? > > > But in this case I couldnt do search like $$('p[myAttr=foo]') > > > > On 20 окт, 01:59, buda <[email protected]> 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 [email protected]. To unsubscribe from this group, send email to [email protected]. For more options, visit this group at http://groups.google.com/group/prototype-scriptaculous?hl=en.
