Velocity Reviews - Computer Hardware Reviews

Velocity Reviews > Newsgroups > Programming > Javascript > David Mark's Javascript Tip of the Day - Volume #1 - #Tip 14-C

Reply
Thread Tools

David Mark's Javascript Tip of the Day - Volume #1 - #Tip 14-C

 
 
Matt McDonald
Guest
Posts: n/a
 
      11-09-2011
On 11-11-08 9:13 PM, RobG wrote:
> element.getAttribute('data-foo');
>
> "works" but
>
> element.data-foo;
>
> does not.


Right, but a little bit of research by these hypothetical developers
would reveal that the `dataset` object [0] houses connections to data-*
attributes. Ergo, the `data-bar` attribute in `<div
data-bar="true"></div>` would be accessed via `[Element].dataset.bar`.

[0]:
http://www.whatwg.org/specs/web-apps...ml#dom-dataset

 
Reply With Quote
 
 
 
 
Tim Down
Guest
Posts: n/a
 
      11-09-2011
On Nov 8, 12:17*pm, David Mark <(E-Mail Removed)> wrote:
> David Mark's Javascript Tip of the Day - Volume #1 - #Tip 14-C
>
> In an (X)HTML DOM, don't read/manipulate DOM attributes (e.g.
> "class"). Use the corresponding properties (e.g. "className"). It's
> more intuitive, with less code, less calls and no legacy IE nonsense
> (e.g. broken get/setAttribute, no hasAttribute, etc.) to worry about.
> This has been the rule forever.
>
> In all the time I've worked with DOM elements, there is only one
> exception that comes to mind. Something like this, IIRC:-
>
> var elButton = document.createElement('button');
> //elButton.type = 'button';
> elButton.setAttribute('type', 'button');
>
> ...was required in Webkit-based browsers at the time. From a quick
> console session, it appears this is still the case as the "type" set
> on the BUTTON fails silently, so the default of "submit" remains. Not
> sure if this is a bug or if there is an allowance for such behavior in
> the recommendation for BUTTON elements. Doesn't seem reasonable to
> make the "type" property of a button write-once unless the caller is
> afforded a chance to write it once.
>
> I normally use INPUT of type "button", which has no such ambiguity, so
> don't really care one way or the other. Whether due to a browser bug
> or recommendation shortcoming; it's the one time I can think of where
> I had to resort to using setAttribute in an HTML DOM operation.
> Operative word is "one".
>
> Buttons created with innerHTML will not have this problem as the
> parser will take care of setting the "type" property to "button".


Another exception is getting hold of a property of a <form> element
such as "action" or "method" when a form input with the corresponding
name exists. The input wins.

<form id="test" action="somepage.html">
<input name="action" value="foo">
</form>

var form = document.getElementById("test");

form.action is a reference to the <input> element.
form.getAttribute("action") is "somepage.html", except in older IE
with its broken getAttribute().

Tim
 
Reply With Quote
 
 
 
 
RobG
Guest
Posts: n/a
 
      11-09-2011
On Nov 10, 2:29*am, Matt McDonald <(E-Mail Removed)> wrote:
> On 11-11-08 9:13 PM, RobG wrote:
>
> > * *element.getAttribute('data-foo');

>
> > "works" but

>
> > * *element.data-foo;

>
> > does not.

>
> Right, but a little bit of research by these hypothetical developers
> would reveal that the `dataset` object [0] houses connections to data-*
> attributes. Ergo, the `data-bar` attribute in *`<div
> data-bar="true"></div>` would be accessed via `[Element].dataset.bar`.
>
> [0]:http://www.whatwg.org/specs/web-apps...ipage/elements.....


It will be quite some time before that feature is sufficiently well
supported that it can be used without feature testing and fall-back to
getAttribute, something like:

if (element.dataset) {
alert(element.dataset[dataAtt]);
} else {
alert(element.getAttribute('data-' + dataAtt));
}

Since getAttribute works everyhwere (in regard to data- attributes at
least), it seems a better option to dispense with the feature test and
just use getAttribute.

Host objects have some quirks still, in Chrome 15:

alert(element.dataset)

reports in the console:

Uncaught TypeError: Cannot convert object to primitive value


--
Rob
 
Reply With Quote
 
David Mark
Guest
Posts: n/a
 
      11-10-2011
On Nov 9, 8:51*am, Scott Sauyet <(E-Mail Removed)> wrote:
> Denis McMahon wrote:
> > David Mark wrote:
> >> David Mark's Javascript Tip of the Day - Volume #1 - #Tip 14-C

> > We have a faq server, we have Thomas 'pointed ears' Lahn, we don't needa
> > (nother) self appointed wannabe guru trying to build a rep by spouting
> > twaddle that we're not interested in reading on a daily basis.

>
> I know you've been around long enough to recognize that David Mark is
> not new here. *His posts are often repetitive, self-aggrandizing, and
> bullying, but there is also a lot of useful content in them.


In other words, you have no idea what you are talking about (and are
relatively new around here).

> His
> manner is among the most obnoxious I've seen on USENET, and I've given
> up on responding to him (a fact he celebrated [1].) *But I'm not sorry
> to have him participate here. *When he does respond to requests for
> help (as opposed to his more common messages promoting his library or
> denigrating all others), he often does so with some skill and with
> genuinely helpful responses.


You are just ****ed that your constant advice to use things like Dojo
and jQuery turned out so badly.

>
> If you're interested in discussions where his usual bluster is not
> welcomed, try JSMentors. *The discussion there is much more civilized,
> generally helpful, and often more interesting than what's here.


I'll see you over there. Hope you aren't doing your usual act.

> Some
> of the more interesting and helpful participants from
> comp.lang.javascript also participate there. *But I find there is
> still much to learn here and many fascinating dialogs, if you can
> stomach the nonsense.
>


....And the stalkers. Get a life.
 
Reply With Quote
 
David Mark
Guest
Posts: n/a
 
      11-10-2011
On Nov 9, 5:41*pm, Tim Down <(E-Mail Removed)> wrote:
> On Nov 8, 12:17*pm, David Mark <(E-Mail Removed)> wrote:
>
>
>
>
>
>
>
>
>
> > David Mark's Javascript Tip of the Day - Volume #1 - #Tip 14-C

>
> > In an (X)HTML DOM, don't read/manipulate DOM attributes (e.g.
> > "class"). Use the corresponding properties (e.g. "className"). It's
> > more intuitive, with less code, less calls and no legacy IE nonsense
> > (e.g. broken get/setAttribute, no hasAttribute, etc.) to worry about.
> > This has been the rule forever.

>
> > In all the time I've worked with DOM elements, there is only one
> > exception that comes to mind. Something like this, IIRC:-

>
> > var elButton = document.createElement('button');
> > //elButton.type = 'button';
> > elButton.setAttribute('type', 'button');

>
> > ...was required in Webkit-based browsers at the time. From a quick
> > console session, it appears this is still the case as the "type" set
> > on the BUTTON fails silently, so the default of "submit" remains. Not
> > sure if this is a bug or if there is an allowance for such behavior in
> > the recommendation for BUTTON elements. Doesn't seem reasonable to
> > make the "type" property of a button write-once unless the caller is
> > afforded a chance to write it once.

>
> > I normally use INPUT of type "button", which has no such ambiguity, so
> > don't really care one way or the other. Whether due to a browser bug
> > or recommendation shortcoming; it's the one time I can think of where
> > I had to resort to using setAttribute in an HTML DOM operation.
> > Operative word is "one".

>
> > Buttons created with innerHTML will not have this problem as the
> > parser will take care of setting the "type" property to "button".

>
> Another exception is getting hold of a property of a <form> element
> such as "action" or "method" when a form input with the corresponding
> name exists. The input wins.
>
> <form id="test" action="somepage.html">
> * * <input name="action" value="foo">
> </form>
>
> var form = document.getElementById("test");
>
> form.action is a reference to the <input> element.
> form.getAttribute("action") is "somepage.html", except in older IE
> with its broken getAttribute().


Yes, so the best bet is not to name form controls "action" (or
anything else that clashes with properties of the form object).
 
Reply With Quote
 
David Mark
Guest
Posts: n/a
 
      11-10-2011
On Nov 8, 11:13*pm, RobG <(E-Mail Removed)> wrote:
> On Nov 8, 10:17 pm, David Mark <(E-Mail Removed)> wrote:
>
> > David Mark's Javascript Tip of the Day - Volume #1 - #Tip 14-C

>
> > In an (X)HTML DOM, don't read/manipulate DOM attributes (e.g.
> > "class"). Use the corresponding properties (e.g. "className"). It's
> > more intuitive, with less code, less calls and no legacy IE nonsense
> > (e.g. broken get/setAttribute, no hasAttribute, etc.) to worry about.
> > This has been the rule forever.

>
> Yes, but if you want to use non-standard attributes, get/setAttribute
> is the only way to go.


Absolutely as there are no corresponding properties.

>
> I don't think non-standard attributes should be used, but as soon as
> the design heads down that route, get/setAttribute looms large.


Right. Will create expando properties in IE5-7 (and compatibility
mode), but there's nothing that can be done for that.

>
> Also, there seem to be many programmers from other languages who like
> using a function call like get/setAttribute rather than direct
> property access. It seems to give them comfort and is a difficult
> habit to shake.


Yes and all of the ridiculous library "attr" functions and their bad
documentation aren't helping at all.

>
> [...]
>
>
>
> > It's unfortunate that most of the "major" JS libraries feature an
> > "attr" method that attempts to deal with *both* HTML and XML (though
> > not normally XHTML). Even worse, they seem to have been written with
> > little understanding of the above concepts, IE bugs and shortcomings,
> > etc., ending up as gobbledygook after years of guesswork and patching.

>
> > The documentation for the recently added "prop" function demonstrates
> > just how confused that effort is.

>
> >http://api.jquery.com/prop/

>
> Unfortunately the authors of various W3C specifications haven't made
> life any easier with their muddled handling of the issue. HTML5 only
> makes it worse, particularly as it introduces a heap of new
> attributes. Anyone using them will prefer get/setAttribute to property
> access to deal with older browsers where:
>
> * element.getAttribute('data-foo');
>
> "works" but
>
> * element.data-foo;
>
> does not.


Yes, hyphenated attribute names have traditionally been reflected by
camel-case property names. I assume the data-whatever attributes are
not reflected and should therefore be handled like custom attributes.

And HTML5 really screwed up the naming as well (DOM properties are now
some sort of attributes apparently). Given that for several years,
the most "advanced" JS efforts out there couldn't tell attributes from
properties, what chance will beginners have if both are now called
"attributes"?
 
Reply With Quote
 
Scott Sauyet
Guest
Posts: n/a
 
      11-11-2011
Andrew Poulos wrote:
> On 10/11/2011 12:51 AM, Scott Sauyet wrote:
>> Denis McMahon wrote:
>>> David Mark wrote:
>>>> David Mark's Javascript Tip of the Day - Volume #1 - #Tip 14-C
>>> We have a faq server, we have Thomas 'pointed ears' Lahn, we don't needa
>>> (nother) self appointed wannabe guru trying to build a rep by spouting
>>> twaddle that we're not interested in reading on a daily basis.

>
>> I know you've been around long enough to recognize that David Mark is
>> not new here. *His posts are often repetitive, self-aggrandizing, and
>> bullying, but there is also a lot of useful content in them. [ ... ]

>
> Funny, I read this post of yours in the same manner that you describe
> many of the posts of DM.


I'm curious as to why. (I know that I once accused you of being a
David Mark pseudonym, and I know that some might find that insulting,
but you are clearly a fan, so I can't imagine you're terribly
offended.) I've been reading this group two years and posting two
months less. In that time, there is only one person who has publicly
suggested that my contributions were inappropriate or that my effect
on the group was less than salubrious. That was David Mark, of
course. Now he's accusing me of promoting jQuery, Dojo, etc, which is
not at all what I've posted. But if he stays true to form, he'll keep
saying it, acting as though if he says it enough, it'll be true.

Except when seriously provoked, I'm fairly mild-mannered in my
posting. David Mark, on the other hard, obviously works to draw
attention to himself, and has drawn the ire of many here in the
process. As I said earlier, I wish he was less abrasive and less
abusive. But I do think that he has also made significant positive
contributions in the time I've been watching.

-- Scott
 
Reply With Quote
 
 
 
Reply

Thread Tools

Posting Rules
You may not post new threads
You may not post replies
You may not post attachments
You may not edit your posts

BB code is On
Smilies are On
[IMG] code is On
HTML code is Off
Trackbacks are On
Pingbacks are On
Refbacks are Off


Similar Threads
Thread Thread Starter Forum Replies Last Post
David Mark's Essential Javascript Tips - Volume #8 - Tip #47E -Attaching and Detaching Event Listeners David Mark Javascript 1 12-17-2011 08:07 AM
David Mark's Daily Javascript Tips - Volume #3 - Tip #10 - How toCreate an XHR (Ajax) Object David Mark Javascript 8 12-10-2011 07:56 PM
David Mark's Daily Javascript Tips - Volume #3 - Tip #8 - How toCompute Styles David Mark Javascript 1 12-07-2011 02:34 AM
David Mark's Javascript Tip Du Jour - Volume #1 - Tip #1234 - How toMeasure Element Dimensions David Mark Javascript 58 12-06-2011 10:13 PM
David Mark's Javascript Daily - Volume #3 - Tip #6 - How to Get andSet HTML David Mark Javascript 6 11-16-2011 06:51 PM



Advertisments