Aliasing property values?

[Ray Cromwell]

Imagine that you want to support a new feature in the latest Safari
3.1 or WebKit nightly, but if you simply extend user.agent with
another property value, your new property value won't pick up Safari
bindings, even though in the many of cases, you want only to add
behavior in some small sections.

For example, on Safari3.1, there are functions "querySelector" and
"querySelectorAll" which execute CSS selector queries at native
speeds. Likewise, there is a new getElementsByClassName() function on
the newest versions of Firefox, Opera, and Safari/Webkit. I seem to
have two options:

1) Option 1, add a new single property and provide that does
capability detection for those functions, ugh.
2) extend-property user.agent with Saf3.1/FF3/etc, and then add or
patch bindings in module files for every deferred binding that
references user.agent

Wouldn't it be nicer to have a sort of alias/subclass type
relationship for properties, and let <when-property-is> have a meaning
like 'is assignable", e.g., extend user.agent with properties like
Safari3, Firefox3, iPhone, etc but assert "unless bound otherwise,
Safari3 is the same as Safari, Firefox3 will bind to gecko1.8, iPhone
will bind to Safari, etc" Binding resolution would first look for a
binding to the actual value (like Safari3), if none exists, have it
fallback to Safari2.

I suggest the following simple (rubyish) syntax:

<extend-property name="user.agent"
values="safari3<safari,iphone<safari,firefox3<gecko1_8"/>

"=" could also be used, or ":" (C++)

Property providers would also need the ability to be chained, adding a
provider for "user.agent" in a submodule should result in all
providers being invoked in turn, from the bottom up, until a non-null
value matching the expected values is returned.

In summary, I want to extend browser sniffing, without patching
user.jar or writing additional deferred bindings to map every
reference to user.agent for the new values, when in many cases, the
bindings will be the same for the new values.

-Ray

[Thomas Broyer]

I had the exact same thoughts!

Could be used in user.jar to cleanly separate "safari old" vs. safari
(see FocusImpl).
Could be used too, to have IE7-specific rebindings (e.g. a custom
RoundedPanel using <div>s only as in GMail v1 -or 3x3 tables as in GWT
1.5's DecoratorPanel- vs. using <div>s and images as in GMail v2; or
simply not using the "alpha" filter for PNGs, etc.)

As for your querySelector/getElementsByClassName, option 1 seems good
to me (e.g. IE8 will take advantage of querySelector without the need
to change your module and recompile your applications)

[Andrés Testi]

+1
Since the newest versions of FF,IE,Safari and Opera supports HTML5,
features like cross site RPC are easy to implement without plugins.
For old versions, we can use Flash hacks.
- Andrés

[Joel Webber]

I'm going to leave the discussion of changing module syntax to others, but I would like to take a moment to address the question of new user.agent values.

We've really tried hard to avoid exploding this set, because it does affect compile time (which I recognize is generally slower than it seems it ought to be right now, but that's another question). Right now we have five user agents defined: ie6, gecko, gecko1_8, safari, and opera.

Currently "gecko" is really only used for the Linux hosted-mode browser, and even there it's only used for to hack around its lack of focusable divs, and one bug in absolute position calculation. So as soon as we get OOPHM going, we should be able to retire it safely.

That leaves us with four, essentially one for each browser engine. But soon we'll have IE8 in the mix, which appears to be effectively an entirely new browser lineage. And there are some pretty significant differences between Safari 2 and 3 that we are currently hacking around in an ugly way. I'm not as sure about FF2/3, where the differences seem fewer.

What would everyone say to this proposal for 1.5:

- gecko, gecko1_8 (still need it for Linux), ie6, opera, safari, safari3

Adding safari3 will allow us to unsnarl some of the nastier pieces of code, like RichTextArea, FocusImpl, and History, that have dynamic checks for safari2/3 right now.

Moving towards this for the next release (on the assumption that OOPHM will allow us to ditch the old Linux gecko engine):

- gecko, ie6, ie8, opera, safari, safari3

I realize that the names are a little inconsistent (ie6 for old ie's, but just 'safari' for old safaris, but it's better to avoid breaking anyone than to clean them up).

Thoughts?

joel.

[Thomas Broyer]

On 11 avr, 17:11, "Joel Webber" <j...@google.com> wrote:
> I'm going to leave the discussion of changing module syntax to others, but I
> would like to take a moment to address the question of new user.agent
> values.
> We've really tried hard to avoid exploding this set, because it does affect
> compile time (which I recognize is generally slower than it seems it ought
> to be right now, but that's another question). Right now we have five user
> agents defined: ie6, gecko, gecko1_8, safari, and opera.
>
> Currently "gecko" is really only used for the Linux hosted-mode browser, and
> even there it's only used for to hack around its lack of focusable divs, and
> one bug in absolute position calculation. So as soon as we get OOPHM going,
> we should be able to retire it safely.
>
> That leaves us with four, essentially one for each browser engine. But soon
> we'll have IE8 in the mix, which appears to be effectively an entirely new
> browser lineage. And there are some pretty significant differences between
> Safari 2 and 3 that we are currently hacking around in an ugly way. I'm not
> as sure about FF2/3, where the differences seem fewer.

...but AIR is a new "runtime" (based on WebKit, but...), and so is
Android I guess.
Having ["ie6", "air"], ["ie6", "noair"], etc. permutations seems
really odd to me (yes, AIR apps could be loaded from "the wire", and
still take advantage of some AIR APIs (not all, due to security
restrictions, but some; or am I misleading and misreading?)).

For someone targeting "desktop web" (IE, Safari, Opera, etc.) and
"enhanced-mobile/embedded web" (iPhone/IPod Touch, Opera/Wii, etc.)
with the same app, it seems better to have "mobile-safari" and "opera-
wii" user.agent values than "unreachable" permutations such as ["ie6",
"mobile-safari", "opera-wii"], ["ie6", "not-mobile-safari", "opera-
wii"], ["ie6", "mobile-safari", "not-opera-wii"], etc.

So having the ability to extend the user.agent property (let's talk
just about this one for now) while saying "if there's no specific
rebinding for this value, then rebind based on this value
instead" (com.google.gwt.user.client.ui... does not deal with "opera-
wii", just use "opera" instead) would be a real plus.
Such feature could be based on naming conventions, such as
hierarchical values separated with a dash or underscore (à la locales:
if you can't find "fr_FR", use "fr", or otherwise default to
"default"), which wouldn't require syntax changes in the module. And
this could be scoped to affect the user.agent property only (at least
by default).

The workaround for now is to either:
- have distinct modules served at distinct URLs (or eventually using
some other "selection script" to redirect to the appropriate module)
- "patch" gwt-user.jar (and/or any other third-party library)

> What would everyone say to this proposal for 1.5:
> - gecko, gecko1_8 (still need it for Linux), ie6, opera, safari, safari3

I think you mean "gecko" is still needed for Linux, not "gecko1_8"

> Adding safari3 will allow us to unsnarl some of the nastier pieces of code,
> like RichTextArea, FocusImpl, and History, that have dynamic checks for
> safari2/3 right now.
>
> Moving towards this for the next release (on the assumption that OOPHM will
> allow us to ditch the old Linux gecko engine):
> - gecko, ie6, ie8, opera, safari, safari3

Are your proposing renaming gecko1_8 to gecko, but keeping "safari"
for Safari 2 and adding safari3? Why not renaming safari to safari2
and making safari the "new safari"? What would it break? (given that
"safari" is also taking Safari 3 into account).

Otherwise, great!

[Joel Webber]

I don't think it makes sense for us to have explicit user-agent values for things other than the primary 'platform' -- basically, the broad concept of 'browser engine'. Thus, it makes sense to have cases like safari3 and ie8, but not 'air'. Because 'air' is an additional library, as is (for the most part) 'safari-mobile' -- both are cases where the core browser is WebKit, with some extra api's. I'd say the same thing goes for the opera-wii.

Imagine, for example, a world where we add 'air' as a separate user-agent value. We then add a library that wraps the AIR api's (let's say one of them is AIR.readLocalFile() -- I have no idea if that exists, but you get the idea). There is no sane implementation of that API for any other user-agent value than 'air' -- you'd simply have to generate lots of permutations that would be completely broken.

Now I'm not saying that this 'default value' idea has no merit -- just that I don't think it's appropriate for user-agent.

> What would everyone say to this proposal for 1.5:
> - gecko, gecko1_8 (still need it for Linux), ie6, opera, safari, safari3

I think you mean "gecko" is still needed for Linux, not "gecko1_8"

Whoops, yes.

 

> Adding safari3 will allow us to unsnarl some of the nastier pieces of code,
> like RichTextArea, FocusImpl, and History, that have dynamic checks for
> safari2/3 right now.
>
> Moving towards this for the next release (on the assumption that OOPHM will
> allow us to ditch the old Linux gecko engine):
> - gecko, ie6, ie8, opera, safari, safari3

Are your proposing renaming gecko1_8 to gecko, but keeping "safari"
for Safari 2 and adding safari3? Why not renaming safari to safari2
and making safari the "new safari"? What would it break? (given that
"safari" is also taking Safari 3 into account).

That was a bit of a typo (I can't seem to keep those geckos straight for some reason). What I meant to propose was

- always leave existing names the same (i.e. only add new names for newer versions)

  - specifically add safari3, leaving 'safari' to refer to versions < 3

- eventually (post 1.5) retire gecko, leaving gecko1_8 as the earliest supported version