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

On 20 окт, 12:51, "T.J. Crowder" <t...@crowdersoftware.com> 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 <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 
For more options, visit this group at 

Reply via email to