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" <[EMAIL PROTECTED]> 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
>
> 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
-~----------~----~----~----~------~----~------~--~---
