[Proto-Scripty] Re: Expando or "data-" like attributes?
Thanks T.J.
Now everything became clear.
On 20 окт, 16:15, "T.J. Crowder" 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]')
>
> 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 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" 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`
[Proto-Scripty] Re: Expando or "data-" like attributes?
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]')
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 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" 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 t
[Proto-Scripty] Re: Expando or "data-" like attributes?
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" 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
> w
[Proto-Scripty] Re: Expando or "data-" like attributes?
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 wrote:
> maybe I'm confusing javascript properties to the attributes? how do
> they compare?
>
> On 20 окт, 02:03, buda wrote:
>
>
>
> > Or should I use .storage object?
> > But in this case I couldnt do search like $$('p[myAttr=foo]')
>
> > On 20 окт, 01:59, buda wrote:
>
> > > I'm confused at all.
> > > On the one hand HTML declares the existence of the elements expando-
> > > attributes.
> > > On the ot
[Proto-Scripty] Re: Expando or "data-" like attributes?
maybe I'm confusing javascript properties to the attributes? how do
they compare?
On 20 окт, 02:03, buda wrote:
> Or should I use .storage object?
> But in this case I couldnt do search like $$('p[myAttr=foo]')
>
> On 20 окт, 01:59, buda 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.
[Proto-Scripty] Re: Expando or "data-" like attributes?
Or should I use .storage object?
But in this case I couldnt do search like $$('p[myAttr=foo]')
On 20 окт, 01:59, buda 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.
