This has been a big development cycle, and we're really excited about the advancements in GWT over the last year. As always, we're eager to hear your feedback once you've tried this new version.
GWT 1.5 would not have been possible without the immense contributions of code and ideas from the GWT open source community. Thank you, thank you, thank you.
> This has been a big development cycle, and we're really excited about the
> advancements in GWT over the last year. As always, we're eager to hear your
> feedback once you've tried this new version.
> GWT 1.5 would not have been possible without the immense contributions of
> code and ideas from the GWT open source community. Thank you, thank you,
> thank you.
Terrific!!!
Just I get a 404 file not found error when I try to download the Linux
version (hope this is temporary...) but anyway thanks a lot for all
the neat new features :)
Tom
> Terrific!!!
> Just I get a 404 file not found error when I try to download the Linux
> version (hope this is temporary...) but anyway thanks a lot for all
> the neat new features :)
> Tom
> This has been a big development cycle, and we're really excited about the
> advancements in GWT over the last year. As always, we're eager to hear your
> feedback once you've tried this new version.
> GWT 1.5 would not have been possible without the immense contributions of
> code and ideas from the GWT open source community. Thank you, thank you,
> thank you.
Congratulations! Although I've been using 1.5 for some time now, it's
always nice to have a final release. Great work, 1.5 is a huge step
forward. Thanks you for all the hard work!
Regards,
Arthur Kalmenson
On Aug 28, 8:44 pm, "Bruce Johnson" <br...@google.com> wrote:
> This has been a big development cycle, and we're really excited about the
> advancements in GWT over the last year. As always, we're eager to hear your
> feedback once you've tried this new version.
> GWT 1.5 would not have been possible without the immense contributions of
> code and ideas from the GWT open source community. Thank you, thank you,
> thank you.
Sorry for the confusion on the Linux download link. The download page should be updated momentarily. In the meantime the .tar.bz2 link below is correct.
> On Aug 29, 3:21 am, Thomas <thomas.lacr...@jouy.inra.fr> wrote: > > Terrific!!! > > Just I get a 404 file not found error when I try to download the Linux > > version (hope this is temporary...) but anyway thanks a lot for all > > the neat new features :) > > Tom
Hi Bruce,
GWT documentation is great and informative. Is there a plan to access
doc offline instead of keep accessing the web ? It will be good if the
doc comes in download ?
Browsing document offline is very useful in place where internet
access is not available etc in plane, in customer's site where public
internet access is prohibited.
Although I think that the main reason why information is kept online
is to facilitate information update, I'm sure developers will rather
have quick access to offline documentation. When I read through the
doc, I find that the current information is good and current enough
for developer, so I wonder if the current documentation can be made
available for offline browsing.
Another (definitely 'Breaking') change in 1.5.2 from 1.5.1 is that
public final native String getAttribute(String name) /*-{ return this.getAttribute(name); }-*/; in Element has become
public final native String getAttribute(String name) /*-{ return this.getAttribute(name) || '';
}-*/;
i.e. if the attribute does not exist, then for some reason, you don't get the expected null, you get an empty string.
Could someone from Google explain why there has been this diversion from the path of 'least surprise'? What suddenly became so wrong with returning what JS gives you? Could you mention it in the release notes as a breaking change? It breaks any number of my apps, all of which check for null, because that's what you used to get.
As for the other, unfixed problems, surely a release candidate is a candidate for being released. If it passes, it gets released. If it doesn't pass you change it and put out another release candidate. I'm a bit surprised that 1.5.2 is 'official'.
> Could you mention it in the release notes as a breaking
> change? It breaks any number of my apps, all of which check for null,
> because that's what you used to get.
On Aug 31, 4:09 pm, "Ian Bambury" <ianbamb...@gmail.com> 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...
...but having an Element.hasAttribute deferring to
getAttribute()==null in case hasAttribute doesn't exist would probably
be enough to get this "fixed" (or better: deferred binding, which
would also use getAttribute(name, 2) for IE to get the appropriate
behavior)
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?
> On Aug 31, 4:09 pm, "Ian Bambury" <ianbamb...@gmail.com> 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?
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:
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'.
> 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?
>> On Aug 31, 4:09 pm, "Ian Bambury" <ianbamb...@gmail.com> 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?
Who is able to publish this wonderful version on the Maven 2
repository (http://repo1.maven.org/maven2/com/google/gwt/) ?
I can find four old 1.5 versions of GWT, but nor the final 1.5.2
release.
Many thanks
Bernard
> 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:
> 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 <ianbamb...@gmail.com> wrote:
> > 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?
> >> On Aug 31, 4:09 pm, "Ian Bambury" <ianbamb...@gmail.com> 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?
> Who is able to publish this wonderful version on the Maven 2
> repository (http://repo1.maven.org/maven2/com/google/gwt/) ?
> I can find four old 1.5 versions of GWT, but nor the final 1.5.2
> release.
> Many thanks
> Bernard
> This has been a big development cycle, and we're really excited about the
> advancements in GWT over the last year. As always, we're eager to hear your
> feedback once you've tried this new version.
> GWT 1.5 would not have been possible without the immense contributions of
> code and ideas from the GWT open source community. Thank you, thank you,
> thank you.
> Thanks, somebody has published gwt 1.5.2 on maven repo...
> On 1 sep, 11:37, lups <bernard.l...@gmail.com> wrote:
> > Who is able to publish this wonderful version on the Maven 2
> > repository (http://repo1.maven.org/maven2/com/google/gwt/) ?
> > I can find four old 1.5 versions of GWT, but nor the final 1.5.2
> > release.
> > Many thanks
> > Bernard
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).
On Mon, Sep 1, 2008 at 5:12 PM, GeekyCoder <geekyco...@gmail.com> 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" <j...@google.com> 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:
> > 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 <ianbamb...@gmail.com> > wrote:
> > > 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?
> > >> On Aug 31, 4:09 pm, "Ian Bambury" <ianbamb...@gmail.com> 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?
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
> 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 <geekyco...@gmail.com> 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" <j...@google.com> 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:
>> > 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 <ianbamb...@gmail.com> >> wrote:
>> > > 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?
>> > >> On Aug 31, 4:09 pm, "Ian Bambury" <ianbamb...@gmail.com> 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?
=========================================================================== ============== 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. =========================================================================== ==============
I transferred tipit.to over to the new code base, and that's from a
GWT 1.4 that was custom patched with a couple of pretty deep hacky
bits in it. I had scheduled a week for transfer and testing, but it
wasn't nearly as bad. Give it a try, in other words!
On Sep 4, 4:05 pm, "Ian Bambury" <ianbamb...@gmail.com> wrote:
> 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
> > 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 <geekyco...@gmail.com> 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" <j...@google.com> 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:
> >> > 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 <ianbamb...@gmail.com>
> >> wrote:
> >> > > 2008/8/31 Thomas Broyer t.bro...@gmail.com
> >> > >> > Could someone from Google explain why there has been this diversion
> >> from
> >> > >> the
> >> > >> > path of 'least surprise'?
> >> > > 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?
> >> > >> On Aug 31, 4:09 pm, "Ian Bambury" <ianbamb...@gmail.com> 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?
> =========================================================================== ==============
> 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.
> =========================================================================== ==============
