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.
