Thanks T.J.
Now everything became clear.

On 20 окт, 16:15, "T.J. Crowder" <t...@crowdersoftware.com> 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 <www...@pochta.ru> 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" <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 
prototype-scriptaculous+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/prototype-scriptaculous?hl=en.

Reply via email to