Thanks T.J. Now everything became clear. On 20 окт, 16:15, "T.J. Crowder" <[email protected]> wrote: > Hi, > > > But, as I understud, expando properties == custom attributes > > No, properties and attributes are very different things, as I said. > You have to be cautious when using expandos, and if you're using > Prototype there's not much reason to (use the storage stuff instead), > but they're not "bad" per se. > > > ...but I see expando on extended elements in prototype! > > Prototype's use of expandos is mostly reasonably cautious. (Could be > more so, but...) For instance, all non-API expandos start with an > underscore, which means they are very unlikely to conflict with > official properties in the future. (For example, when you use > `makePositioned` on an element, there's an expando set on the element > instance called `_madePositioned`. It's very unlikely that there will > be an official or browser-specific property called `_madePositioned` > in the future that will conflict with Prototype's expando.) And I'm > reasonably certain they never use an expando to refer to another DOM > element or to a JavaScript object that, in turn, refers to another DOM > object. > > I said "non-API expandos" because, of course, all of the stuff > Prototype adds to element instances (`addClassName`, `up`, `down`, > `select`, etc.) are expandos. On browsers that allow it, they're added > to the element prototype, but on IE (and theoretically other browsers > that don't allow it), they're straight expandos added when the element > instance is extended. And sure enough, that's been a problem at times > in the past, when there was some browser-specific extension that > conflicted with a name that Prototype was trying to use for something > else. (I don't have a specific example, seem to recall some problem > using `Element#select` on certain elements in Safari or something.) I > understand a future version of Prototype will switch to using element > wrappers rather than directly extending the elements (I'm guessing > it'll be 2.0, that's a big enough change to justify bumping the major > rev.) > > In your question you said you wanted to be able to use the things > you're setting on the element in a selector: > > $$('p[myAttr=foo]') > > ...and so in your case, you'll need to use a custom attribute. The > best way to use a custom attribute is to use the "data-" prefix: > > <p data-myAttr="foo">...</p> > > $$('p[data-myAttr=foo]') > > If you also have cases where you don't need it as an attribute, either > use an expando *cautiously* or -- and this is probably better -- use > the storage system (`Element#getStroage`) that Prototype provides. > > HTH, > > -- T.J. > > > Will this to migrate to storage functionality or its not so bad > > practice? > > On Oct 20, 1:48špm, buda <[email protected]> wrote: > > > > > > > > > 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.
