Thing is that the attribute *is* there because IE adds them with a default
(or returns a default by, err, default). Which makes sense for at least some
of the attributes, e.g. width - if it doesn't have a width of something,
then it has a width of nothing, whether the programmer has set it or not. It
makes coding more concise and doesn't break the recommendations because
defaults are allowed.
So it would seem easier to return an empty string/zero for non-IE browsers
when requesting a known style attribute (i.e. emulate IE on other browsers)
and return null for non-existent user-defined attributes. The alternative is
to keep your own list ow what has been explicitly or implicitly set - good
luck with that if you choose that route :-)
You can't just return a blank string for any attribute, even non-existent
ones because it is a) dangerous (because a typo will still give you a valid
return where a null will raise an exception or at least be noticably wrong)
and b) is unexpected/surprising because it's not what *any* browser does.
What I don't understand is why an undocumented breaking change was added in
at the last moment to what was an accepted release candidate. Surely a
release candidate if accepted goes out unchanged or it's not so much a
candidate for release, more of "a candidate for a bit of tweaking before we
send it out untested by the people we release RCs to". If that's the case,
be honest and call it a beta :-P
Ian
2008/9/4 Joel Webber <[EMAIL PROTECTED]>
> The problem with 'returnNullIfNotFound' is that it's a contract we can't
> guarantee will be honored. IE (and possibly others, though I'm not certain)
> will definitely return non-null (and apparently non-string in some
> instances) values for unspecified attributes at times. How could we guard
> against that?
> It might seem a little verbose to have to write
> e.hasAttribute("foo") ? e.getAttribute("foo") || null;
>
> but I can practically guarantee that any code we have to make the return
> value of getAttribute() correctly null will be at least as expensive.
>
> We also have to figure out how to implement hasAttribute() on IE, which is
> not there by default. Ideas on that front welcome (e.g., we need to
> correctly implement Element.hasAttribute("tabIndex"), which on IE simply
> returns "0", even if it was never specified).
>
> Cheers,
> joel.
>
> On Mon, Sep 1, 2008 at 5:12 PM, GeekyCoder <[EMAIL PROTECTED]> wrote:
>
>>
>> Joel,
>> can a overloaded method be added too ?
>>
>> public final native String getAttribute(String name, boolean
>> returnNullIfNotFound)
>>
>> so that getAttribute(String name) return the current behaviour as
>> return by browser so that for those who program browser-specific code
>> can handle it.
>>
>> and For those who want to maintain single code base, setting a flag
>> will force it to return null if attribute is not found.
>>
>> It will be too verbose to do the following check.
>>
>> String _i = (hasAttribute("xxx") ? getAttribute("xxx") : null); //
>> or use a if
>>
>>
>> This will be good.
>> String _i = getAttribute("xxx", true);
>>
>>
>>
>> On Sep 2, 12:46 am, "Joel Webber" <[EMAIL PROTECTED]> wrote:
>> > All,
>> > There is certainly a possibility that this change was a mistake, but it
>> does
>> > *not* appear cut-and-dried from reading the spec. Here is the actual
>> text
>> > from the DOM spec:
>> >
>> > ---
>> > getAttribute
>> > Return Value
>> > DOMString The Attr value as a string, or the empty string if that
>> > attribute does not have a specified or default value.
>> > ---
>> >
>> > Depending upon how you interpret that (especially the definition of the
>> > phrase 'does not have a specified or default value'), you could see it
>> > either way. It certainly doesn't specify that you *can* depend upon a
>> null
>> > return value to determine that an attribute doesn't exist. In fact, it
>> > doesn't even address the definition of a 'non-existent' attribute. You
>> could
>> > make the argument that it enumerates the valid types for the return
>> value as
>> > "a string, or the empty string", specifically excluding 'null'. Or you
>> could
>> > reasonably argue that all browsers *do* return null for undefined
>> > attributes. But the reality is that it's not entirely dependable. Let me
>> > demonstrate by example:
>> >
>> > <div id='foo'>
>> >
>> > var foo = document.getElementById('foo');
>> > getAttribute('id')
>> > IE7: foo
>> > Firefox3: foo
>> > getAttribute('className')
>> > IE7: ""
>> > Firefox3: null
>> > getAttribute('tabIndex')
>> > IE7: 0
>> > Firefox3: null
>> > getAttribute('xxx')
>> > IE7: null
>> > Firefox3: null
>> >
>> > This puts us between a rock and a hard place. If we allow developers to
>> > depend upon the return value being null, it won't always work. Do we
>> then
>> > have to put an explicit test in getAttribute() to force a null return
>> value
>> > in weird corner cases like tabIndex and className?
>> >
>> > The only thing that appears clear to me in the spec is that you should
>> > probably call hasAttribute() if you're not sure whether it's there or
>> not --
>> > which we would need to add to Element (and implement somehow on IE,
>> since
>> > it's not there by default). I would also be willing to consider changing
>> the
>> > type-coercion in getAttribute(), but only with the strong caveat that
>> its
>> > behavior is not specified when the attribute is 'not specified'.
>> >
>> > Cheers,
>> > joel.
>> >
>> >
>> >
>> > On Sun, Aug 31, 2008 at 7:04 PM, Ian Bambury <[EMAIL PROTECTED]>
>> wrote:
>> >
>> > > 2008/8/31 Thomas Broyer [EMAIL PROTECTED]
>> >
>> > >> > Could someone from Google explain why there has been this diversion
>> from
>> > >> the
>> > >> > path of 'least surprise'?
>> >
>> > >> Because that's how the DOM is defined:
>> > >>http://www.w3.org/TR/DOM-Level-2-Core/core.html#ID-745549614
>> >
>> > > No it's not. w3.org's *recommendations" that you link to state that
>> > > getAttribute() returns the string, or an empty string if the attribute
>> is
>> > > empty and there is no default. It doesn't appear here to recommend
>> any
>> > > return value if the attribute does not exist.
>> >
>> > >> > What suddenly became so wrong with returning what
>> > >> > JS gives you?
>> >
>> > >>http://code.google.com/p/google-web-toolkit/source/detail?r=3568
>> > >> Apparently, not all browsers give you nulls.
>> >
>> > > That doesn't explain the sudden change.
>> >
>> > >> On Aug 31, 4:09 pm, "Ian Bambury" <[EMAIL PROTECTED]> wrote:
>> > >> > And now I can't tell the difference between an attribute which is
>> > >> missing,
>> > >> > and an attribute which is there but empty...
>> >
>> > >> Blame Microsoft eventually at first...
>> >
>> > > Why is it Microsoft's fault that Google made the change?
>> >
>> > > I'm quite happy to blame Microsoft for anything and everything that
>> has
>> > > ever or will ever happen (I don't want to look out of place here) but
>> if
>> > > there is a genuine connection, all the better.
>> >
>> > > The bottom line for me is that IE, FF, Opera and Safari all return
>> null in
>> > > raw JavaScript if the attribute doesn't exist - I really don't give a
>> > > monkey's about the other browsers that GWT supports (!?) - and since
>> when
>> > > have Google worried about being officially compliant over getting the
>> job
>> > > done?
>> >
>> > > Ian
>>
>>
>
> >
>
--
Ian
http://examples.roughian.com
=========================================================================================
Internet communications are not secure and therefore I will not accept legal
responsibility for the contents of this message.
Any views or opinions do not necessarily represent what I really think
unless otherwise specifically stated, and even then, I
might still be lying. This message may contain confidential privileged
information, but if it does, I've nicked it from someone
else. If you have received this email in error then tough, hit delete, and
don't bother me about it, I really don't care. Batteries
not included. Contents can go up as well as down. Shares can vary in size.
May cause drowsiness, if affected, go to sleep.
=========================================================================================
--~--~---------~--~----~------------~-------~--~----~
You received this message because you are subscribed to the Google Groups
"Google Web Toolkit" group.
To post to this group, send email to [email protected]
To unsubscribe from this group, send email to [EMAIL PROTECTED]
For more options, visit this group at
http://groups.google.com/group/Google-Web-Toolkit?hl=en
-~----------~----~----~----~------~----~------~--~---
