Re: Status of the status bar
Mike Beltzner
cheers,
mike
Alex Faaborg <faa...@mozilla.com> wrote:
I want to start a quick thread with everyone cc'd so that we can make sure
everyone is on the same page with the status bar. My impression from Myk
and Dietrich is that the status bar is being replaced with an extension bar
(which jetpacks add themselves to), and the extension bar is an entirely new
piece of UI (different id, doesn't contain any Firefox specific UI, possibly
different styling to account for an option of having larger icons). So
while the extension bar, containing jetpacks, can be enabled and disabled by
the user, the status bar as it exists today would no longer be available in
Firefox 4. We've been working on integrating existing status bar
functionality into other parts of the UI to accommodate this change.
Myk and Dietrich: please let us know if that is incorrect, since this will
effect which changes are mandatory or not (like providing the ability for
the user to see a link target on hover).
-Alex
Ron Hunter
> I want to start a quick thread with everyone cc'd so that we can make sure
> everyone is on the same page with the status bar. My impression from Myk
> and Dietrich is that the status bar is being replaced with an extension bar
> (which jetpacks add themselves to), and the extension bar is an entirely new
> piece of UI (different id, doesn't contain any Firefox specific UI, possibly
> different styling to account for an option of having larger icons). So
> while the extension bar, containing jetpacks, can be enabled and disabled by
> the user, the status bar as it exists today would no longer be available in
> Firefox 4. We've been working on integrating existing status bar
> functionality into other parts of the UI to accommodate this change.
>
> Myk and Dietrich: please let us know if that is incorrect, since this will
> effect which changes are mandatory or not (like providing the ability for
> the user to see a link target on hover).
>
> -Alex
Not happy with this decision. Will break many of my current extensions.
Alex Faaborg
> Will break many of my current extensions.
>
In the sort term, but in the long term we believe people will really like
this change. Giving each Jetpack a panel to contain its UI drastically
increases the number of extensions you can have easy access to. There are a
lot of current toolbars that I would consider running if it didn't mean
giving up 1/3 or 1/2 of my screen space because they currently each mandate
persistent primary UI. Obviously making significant changes like this means
some things need to be updated, but it will also position us to have a much
better interface going forward. Jetpacks, the extension bar, and
arrowpanels will create a glorious future of simplistic access to complex
functionality :)
-Alex
> _______________________________________________
> dev-apps-firefox mailing list
> dev-apps...@lists.mozilla.org
> https://lists.mozilla.org/listinfo/dev-apps-firefox
>
Michael Lefevre
> I want to start a quick thread with everyone cc'd so that we can make sure
> everyone is on the same page with the status bar. My impression from Myk
> and Dietrich is that the status bar is being replaced with an extension bar
> (which jetpacks add themselves to), and the extension bar is an entirely new
> piece of UI (different id, doesn't contain any Firefox specific UI, possibly
> different styling to account for an option of having larger icons). So
> while the extension bar, containing jetpacks, can be enabled and disabled by
> the user, the status bar as it exists today would no longer be available in
> Firefox 4. We've been working on integrating existing status bar
> functionality into other parts of the UI to accommodate this change.
Bit of a side issue, which I tried to point out in a bug comment
somewhere, is the sync UI. The docs about sync seem to assert that the
sync icon will continue to appear in the lower right corner (on some
kind of bar). Prior to this thread, someone from Mozilla asserted that
the sync icon wouldn't be in the main UI (I'm afraid I don't have the
bug comment link to hand).
Clearly it can't be on the status bar if it's going away (by default?).
Will it be built-in UI on the "extension" bar? Move somewhere else? Not
be in the main UI? Maybe it's happened somewhere that I didn't see, but
if different people are asserting different things about the same
feature, it seems to me there should be some discussion...
Michael
Ron Hunter
>>
>> Will break many of my current extensions.
>>
>
> In the sort term, but in the long term we believe people will really like
> this change. Giving each Jetpack a panel to contain its UI drastically
> increases the number of extensions you can have easy access to. There are a
> lot of current toolbars that I would consider running if it didn't mean
> giving up 1/3 or 1/2 of my screen space because they currently each mandate
> persistent primary UI. Obviously making significant changes like this means
> some things need to be updated, but it will also position us to have a much
> better interface going forward. Jetpacks, the extension bar, and
> arrowpanels will create a glorious future of simplistic access to complex
> functionality :)
>
> -Alex
>
I will wait and see, particularly how the mouse-over link thing is done.
It is, in my opinion, a critical security issue.
So much is going into Firefox 4 that it boggles the mind thinking how it
will all go together.
Alexander Limi
> I will wait and see, particularly how the mouse-over link thing is done.
> It is, in my opinion, a critical security issue.
>
Here's what the UX team has proposed:
https://bugzilla.mozilla.org/attachment.cgi?id=466903
(relevant bug: https://bugzilla.mozilla.org/show_bug.cgi?id=587908 )
--
Alexander Limi · Firefox User Experience Team · http://limi.net
Alex Faaborg
> is the sync UI.
>
Here's the bug with discussion of a potential primary UI indicator for sync:
https://bugzilla.mozilla.org/show_bug.cgi?id=589981
The sync team is working on that this week, although it likely won't appear
super polished at first. (we're also likely going to make some changes so
that it ultimately looks better than that proposal, things are a bit rough
on XP at the moment).
We've gone back and forth a few times on how much we really want to have
this in primary UI. There are really two totally different issues being
considered:
1) Providing a control for the user to manually initiate a sync since we
won't have real time sync set up at first, and you may be about to switch to
a mobile device
2) providing a visual cue that everything you do with this computer
(history, create an account at a web site, remember a password) is not just
being remembered, but is being uploaded and saved across multiple machines,
kind of the total opposite of private browsing. This becomes increasingly
problematic when account manager lands, since it will allow people to easily
create new accounts at web sites (complete with randomly generated
passwords). If you use a friend's computer, you may accidentally give them
exclusive access to the account you just created. sync+account manager is
pretty fertile ground for mode errors (but is also really powerful and
useful when used correctly).
When we were just considering point 1 I was in favor of doing everything we
could to increase the sync interval, and otherwise moving the ability to do
a manual sync to secondary UI. However, now that we have point 2 to
consider as well, I've switched back to now advocating that we can provide a
strong visual cue that you are using another person's sync account.
In the future we may want to go even farther than the proposal in that bug,
and have selecting a persona (or on windows 7 alternately a favorite color)
part of the sync account creation process. This way we could set the
Firefox button to the user's favorite color (or apply the persona), and
provide a very strong ambient cue that you are logged into Firefox as a
specific user. (you expect the Firefox button to be blue and have your name
next to it, but on this computer it is hot pink and says "Leela", so you are
less likely to create an account at the latest social network until you
switch to a guest account). That of course is well beyond Firefox 4, and is
based on some new platform capabilities to be able to modify color values
(to get the gradient right, etc.)
-Alex
Barry van Oudtshoorn
> Here's what the UX team has proposed:
> https://bugzilla.mozilla.org/attachment.cgi?id=466903
>
> (relevant bug: https://bugzilla.mozilla.org/show_bug.cgi?id=587908 )
URL as a pop-in status bar à la Chrome), it's pointed out that showing
the URL in the address bar is infeasible when in full-screen mode.
What's going to happen when the user's in this mode, or when they're
using a dynamically-created window that doesn't have the address bar? (I
seem to recall, though, that one of the papercut bugs was about
preventing these sorts of windows, so maybe that's not relevant.)
--
Barry van Oudtshoorn
www.barryvan.com.au
Not sent from my Apple πPhone.
broccauley
http://groups.google.com/group/mozilla.dev.usability/msg/1df62b4e2c301d69?
Now, after reading here and looking at the proposals on where you're
proposing to put sync I just think that the idea of removing the status bar
just keeps getting worse and worse. That large sync icon is just cluttering
prime *non-peripheral* space that should be used for extra tabs. Sync is
also a *status* that is better suited to an area of *peripheral* vision like
the status bar.
This *is* FASHION over logical design. It's merely an attempt to get a
one-up over Google in the current game to see who can be the most minimal,
and to attempt to make-up for the fact that Mozilla were late to the game.
Comments like the following from A. Limi on Bugzilla
(https://bugzilla.mozilla.org/show_bug.cgi?id=572160) only re-enforce my
opinion on this:
"... our UI is actually *more* space-efficient than Chrome on Windows. In
itself, that's not a goal, but it does send the right message, that we do
care about browsing screen real estate."
I think you'll already have sent that message that you care about
space-efficiency by rightfully putting the tabs in the title bar (as A. Limi
rightfully suggests) - removing the status bar by default, however, is a
step too far. There comes a saturation point where minimization becomes
inversely proportional to functionality - Opera 10.6 gets the balance just
right. Both Chrome, and now Firefox, look to be passing that point; Firefox
even more so than Chrome! All for the sake of a mere 20 *peripheral*
vertical pixels?!
Paul
johnjbarton
>>
>> Will break many of my current extensions.
>>
>
> In the sort term, but in the long term we believe people will really like
> this change. Giving each Jetpack a panel to contain its UI drastically
> increases the number of extensions you can have easy access to. There are a
I suppose the previous post meant by "my current extensions", "my
not-jetpack-extensions". Consequently any number of fabulous features
for jetpacks will not help them.
> lot of current toolbars that I would consider running if it didn't mean
> giving up 1/3 or 1/2 of my screen space because they currently each mandate
> persistent primary UI. Obviously making significant changes like this means
Alex, could explain this a bit more? Why does the statusbar take up 1/3
of your screen?
> some things need to be updated, but it will also position us to have a much
> better interface going forward. Jetpacks, the extension bar, and
> arrowpanels will create a glorious future of simplistic access to complex
> functionality :)
Wouldn't removing the Firefox features from the status bar, making it's
visibility user-controllable, it's width flexible, and embedding it in
the extension bar or vice-versa accomplish the same goals? (Not a big
deal for us FWIW).
jjb
Alex Faaborg
> could explain this a bit more? Why does the statusbar take up 1/3 of your
> screen?
>
Current extension toolbars could end up taking 1/3 of my screen, this is a
problem that we are hoping to solve with the extension bar (which is being
worked on as part of Jetpack).
Right now we have two common ways for extensions to modify the UI, a
persistent toolbar (yahoo toolbar, etc.) and small controls placed across
the status bar (weather forecast, audio player controls, etc.) The new
Jetpack model is to use an icon in the extension bar that when clicked
displays an arrowpanel containing the extension's controls. So for
instance, if I wanted to use the functionality of the following current
toolbars:
-amazon wishlist
-stumbleupon
-google
-facebook
I would be looking at about 1/3 of my screen covered in persistent
toolbars. However, if these were implemented using Jetpack with
arrowpanels, I would have 4 icons in my extension bar, each with their full
functionality one click away. (and subsequently I could actually use all of
them instead of being forced to choose, since the limits of available screen
space currently force me to use just one or two). Jetpacks that do things
like display the weather could still do so, just by making their part of the
extension bar a bit wider.
The extension bar also helps set user expectations for where there Jetpacks
are going to appear in the interface after install, and would (I believe) be
a fully customizable toolbar, similar to the navigation toolbar.
-Alex
Dao
> However, if these were implemented using Jetpack with
> arrowpanels, I would have 4 icons in my extension bar, each with their full
> functionality one click away.
So, with only four icons present, why couldn't the rest of the bar
function as a status bar?
Dietrich Ayala
This bug is for removing the status bar, and replacing it with a
proper toolbar: https://bugzilla.mozilla.org/show_bug.cgi?id=574688.
The above bug contains all the dependencies. The wiki page above has
those dependencies in list of the current UI pieces in the status bar,
and UX's proposed solution (each linked to back to the bugs). The bugs
for implementing the different parts of the new theme that replace
used-to-be-on-the-status-bar features do not have owners. I signed up
to do the add-on UI integration work, which lead to removing the
status bar in favor of the add-on bar, after Boriss' design work
concluded that way. It's my fault for not calling out sooner that in
order to remove the status bar, each of those dependent bugs probably
needs to block, and therefore needs an owner.
WRT to the design, it was my understanding after repeated talks with
UX that the status bar would be hidden *and* that the user-facing UI
for un-hiding it would be *removed* - replaced instead by the add-on
bar. Boriss addressed the shortcomings of the status bar in her series
of posts about add-on UI on her blog (http://jboriss.wordpress.com/).
The driving reason behind the actual replacement of the elements in
the implementation of that design, is that *the status bar is not
customizable*. You cannot customize it the way that you can the other
parts of primary UI. Customizing the status bar involves enabling/
disabling or install/uninstalling add-ons. Also, add-ons add to the
statusbar via the DOM directly, or via overlays, and can put anything
there. And because a discrete API is not used, we can't do magical
things like wrapping existing items in elements that would make them
properly customizable.
Instead the approach proposed in the bug is:
* Hide the status bar element, but leave it in the document. This
prevents extensions from completely breaking, or breaking Firefox by
not handling exceptions thrown by not checking to ensure they actually
got an element for the status bar.
* Remove the option in the View menu to make it visible. Otherwise add-
ons wouldn't need to update to the new functionality that allows user-
control over what's visible in the bar at the bottom of the screen.
Every story and blog post and tweet would say "Go to the View menu and
re-enable it to get your add-ons back.", and users would be stuck
forever with a status bar that *they cannot customize*. If you decide
you don't want your music widget down there for today, too bad, you
have to uninstall or disable the add-on. Replacing the statusbar with
a toolbar means that they can add/remove at runtime. If add-ons want
to be in the add-on bar, and don't want to use the widget API in
Jetpack, they can use the same toolbar infrastructure they're familiar
with.
* Provide the add-on bar in it's place, a new element that is a
properly customizable toolbar. Much of the conversation is about the
status bar being *gone*, where really the plan is to *replace* it with
a similar bar that is far more friendly to users, and provides far
more functionality and ease-of-use to add-on developers, whether the
add-on is Jetpack-based or not.
On Aug 25, 5:53 am, Mike Beltzner <beltz...@mozilla.com> wrote:
> Indeed. Elucidation on the plan of record would help. Also, knowing what pieces are underway and which are OMGWHAT? underresourced would help a ton a ton.
>
> cheers,
> mike
>
Jesper Kristensen
> I would be looking at about 1/3 of my screen covered in persistent
> toolbars. However, if these were implemented using Jetpack with
> arrowpanels, I would have 4 icons in my extension bar, each with their full
> functionality one click away. (and subsequently I could actually use all of
> them instead of being forced to choose, since the limits of available screen
> space currently force me to use just one or two). Jetpacks that do things
> like display the weather could still do so, just by making their part of the
> extension bar a bit wider.
Have you talked to the developers of those toolbars, and have they
promiced they would change their UI to a single button if Firefox
renamed the status bar to extension bar, or is it just something you
hope? I very much doubt they would do so.
Dietrich Ayala
To repeat: Developers can still create UI-hogging toolbars if they want, and users can still install them.
Dao
> If you decide
> you don't want your music widget down there for today, too bad, you
> have to uninstall or disable the add-on. Replacing the statusbar with
> a toolbar means that they can add/remove at runtime. If add-ons want
> to be in the add-on bar, and don't want to use the widget API in
> Jetpack, they can use the same toolbar infrastructure they're familiar
> with.
The toolbar infrastructure is broken. Add-ons providing items for
toolbars need to either manually inject them (which isn't
straightforward at all, e.g. Adblock Plus gets it wrong) or tell users
to look for the items in the customization UI, which isn't really the
post-install experience you want. I'd argue that the current experience
with the status bar is actually better.
Dietrich Ayala
Can you file bugs on how the toolbar customization infrastructure could be improved? Or throw your thoughts on an etherpad and I'll file the bugs?
Either way, we need to ensure our UI is customizable in a way that allows add-on developers control over their add-ons default appearance, but gives the user maximum ease and control over presence/absence and location.
johnjbarton
...>
> * Provide the add-on bar in it's place, a new element that is a
> properly customizable toolbar. Much of the conversation is about the
> status bar being *gone*, where really the plan is to *replace* it with
> a similar bar that is far more friendly to users, and provides far
> more functionality and ease-of-use to add-on developers, whether the
> add-on is Jetpack-based or not.
Would you please outline how your plan provides more functionality and
ease-of-use for non-Jetpack addons? I'm not disputing your claim, I just
don't see any thing about this in the previous posts.
Well actually I am skeptical. I don't care about more functionality and
ease of use for the statusbar is 100% now because I don't have to do
anything. But overall the UI plan sounds good, so helps us out here:
outline a migration plan from statusbars.
jjb
johnjbarton
>>
>> could explain this a bit more? Why does the statusbar take up 1/3 of your
>> screen?
>>
>
> Current extension toolbars could end up taking 1/3 of my screen, this is a
> problem that we are hoping to solve with the extension bar (which is being
> worked on as part of Jetpack).
But we aren't talking about toolbars or jetpacks here. I want to know
about statusbar icon buttons in non-jetpack extensions. All the rest of
the story sounds great.
jjb
Dao
> The current experience with the status bar is that the user cannot change anything at all. I can't see how that's better.
It works, predictably. A robust and fully customizable UI may be better
but isn't currently available.
I also don't think the desire to move status bar items around is strong
enough to make this a priority.
> Can you file bugs on how the toolbar customization infrastructure could be improved? Or throw your thoughts on an etherpad and I'll file the bugs?
For Firefox 4?
I was just throwing around issues I saw -- I don't have solutions at hand.
Dietrich Ayala
Philip Chee
> On 25.08.2010 16:33, Dietrich Ayala wrote:
>> The current experience with the status bar is that the user cannot change anything at all. I can't see how that's better.
>
> It works, predictably. A robust and fully customizable UI may be better
> but isn't currently available.
It's pretty hacky (extends the toolbar bindings) but it essentially
turns the status bar into a customizable toolbar.
> I also don't think the desire to move status bar items around is strong
> enough to make this a priority.
Besides there is at least one extension (Statusable) that allows you to
move statusbar items around, or at least reorder them.
>> Can you file bugs on how the toolbar customization infrastructure could be improved? Or throw your thoughts on an etherpad and I'll file the bugs?
>
> For Firefox 4?
>
> I was just throwing around issues I saw -- I don't have solutions at hand.
Phil
--
Philip Chee <phi...@aleytys.pc.my>, <phili...@gmail.com>
http://flashblock.mozdev.org/ http://xsidebar.mozdev.org
Guard us from the she-wolf and the wolf, and guard us from the thief,
oh Night, and so be good for us to pass.
johnjbarton
> I want to start a quick thread with everyone cc'd so that we can make sure
> everyone is on the same page with the status bar. My impression from Myk
> and Dietrich is that the status bar is being replaced with an extension bar
(Since I've already posted to this thread 4 more times than I'd wish, I
don't want you to think that this statusbar change is all that alarming
to me. These are just suggestions, don't blow a fuse.)
Because Firebug caught lots of grief in the past for waiting until late
beta releases to update our users, we already released 1.6b1. We are
done making changes; we plan to push our update along with your last
beta. With 5 days left before your feature freeze, coming up with a
surprise addon-breaking change like this makes our work more difficult.
I am sure if I read everything about mozilla I would know about this
change, but then again Alex's post starts out from the assumption that
in fact this is a surprise.
So again I will make my suggestion that the special character of this
so-called beta phase be made explicit. You are changing your development
practice (good!) for important reasons (good!) but you are naming new
things with old names. This confuses people who work with you (not so
good). We should have waited for Firebug 1.6b1 until after your feature
freeze. I just did not notice that is was between b4 and b5 because
based on past experience the difference between those numbers did not
seem significant until I looked at your new beta procedure in detail.
jjb
Boriss
not said anything about it since. Maybe I can sum up what's been
going on, and Dietrich can chime in if I'm missing anything.
We have indeed been aiming to remove the status bar for Firefox 4.0
(reasons are here:
http://jboriss.wordpress.com/2010/04/29/removing-firefoxs-status-bar-and-rehousing-add-on-icons-part-1-of-2/
) and replace it with an add-on bar (see bug 574688). The elements of
the status bar we'd like to surface are being moved somewhere else in
Firefox. The items are in the wiki ( https://wiki.mozilla.org/Firefox/Projects/AddonUI
), but in summary:
Progress bar/page status -> Tab status bar (see bug 578028)
Link destination indicator -> URL bar (see bug 587908)
Add-ons -> Add-on bar (bug bug 574688)
Download progress -> unknown. Previously redesigned in bug 564934,
but now looking unlikely for Firefox 4.0)
Sync UI -> Top of toolbar (see bug 589981)
The plan for the add-on bar is that it will span the entire width of
the page. It would be summoned and dismissed via a small button,
similar to this (imagine the add-ons bar spans the entire page).
Add-on authors who currently have an icon in the status bar would have
to update their code in order to appear in this add-ons bar.
Apparently this is trivial for add-ons not using Jetpack, and Dietrich
offered to put up a blog post on how to achieve this. Dietrich says
that it's fairly easy for add-ons that wish to use jetpack, but it
requires more code changes for existing add-ons because they're likely
using raw DOM.
The add-on bar will eventually allow for customizability, in which
elements of the addons bar can be moved to different areas of Firefox
that support customization (navigation bar, toolbar, addon bar,
possibly more). Implementing this, Dietrich has says, would just use
the current customization sheet which would then need to support
customization of stuff below it: not just in the nav toolbox area.
This is a big change to be starting now, and thus is considered a goal
for Firefox 4.1, not Firefox 4.0.
WHAT'S LEFT TO BE DONE:
1. Implementing the actual add-on bar. Dietrich is working on this
2. Communicating to add-on authors with add-ons currently using the
status bar how to utilize the add-on bar instead
3. Figuring out where to put the download indication that's currently
in the status bar and implementing this. For instance, tabs may be
prime candidates as downloads are linked to tabs and we currently show
a status indicator here for page content already.
4. Finishing link preview. Shorlander is working on the design
5. Finishing Sync button shift, which will likely occur after feature
freeze
Ron Hunter
> No one is banning toolbars! The add-on bar, along with the widget API in Jetpack, is offering new UI options that give those developers the ability to be less obtrusive. Also, widgets on the add-on bar can be as wide as they'd like.
>
> To repeat: Developers can still create UI-hogging toolbars if they want, and users can still install them.
>
>
toolbar writers want to be inconspicuous, or frugal with user's screen
space.
Alex Faaborg
> Have you talked to the developers of those toolbars, and have they promiced
> they would change their UI to a single button if Firefox renamed the status
> bar to extension bar, or is it just something you hope? I very much doubt
> they would do so.
>
After jetpacks and the extension bar have been available for awhile, we
could potentially run a test pilot study to show that users are considerably
more likely to use your extension if you don't force them to have a
persistent toolbar. But yeah, even then they might not see reason. Either
way, we feel that jetpack is providing a better model for users. (and to
reiterate Dietrich's comment, these are simply new options that we are
providing, we definitely aren't banning anything with Firefox 4)
-Alex
Philip Chee
> On Wed, 25 Aug 2010 17:00:21 +0200, Dao wrote:
>> On 25.08.2010 16:33, Dietrich Ayala wrote:
>>> The current experience with the status bar is that the user cannot change anything at all. I can't see how that's better.
>>
>> It works, predictably. A robust and fully customizable UI may be better
>> but isn't currently available.
>
> It's pretty hacky (extends the toolbar bindings) but it essentially
> turns the status bar into a customizable toolbar.
Eeep. I was referring to the Total Toolbars extension. Sorry.
![alta88[nntp]'s profile photo](http://lh3.googleusercontent.com/a-/ALV-UjUA6LqwHL3TKsLebE5-SwXQqtAZJOkobIl_A9x06nUxOiTLww=s40-c)
alta88[nntp]
---On 2010.Aug.25 9:09 AM, Philip Chee wrote:
> On Wed, 25 Aug 2010 17:00:21 +0200, Dao wrote:
>> On 25.08.2010 16:33, Dietrich Ayala wrote:
>>> The current experience with the status bar is that the user cannot change anything at all. I can't see how that's better.
>>
>> It works, predictably. A robust and fully customizable UI may be better
>> but isn't currently available.
>
> It's pretty hacky (extends the toolbar bindings) but it essentially
> turns the status bar into a customizable toolbar.
cmon phil, xml is hacky?? ;)
>
>> I also don't think the desire to move status bar items around is strong
>> enough to make this a priority.
>
i should think the desire by any user to add/remove/reorder statusbar
items is precisely as strong for statusbar as for any other toolbar. it
is a long overdue correction that statusbar will finally receive toolbar
functionality, even if it means replacing it with addon-bar.
> Besides there is at least one extension (Statusable) that allows you to
> move statusbar items around, or at least reorder them.
TotalToolbar
http://totaltoolbar.mozdev.org/
to accomplish Bug 590543, with the highest amount of reuse of existing
customization arch, you will need to use the same methods as the
extension. if the addon toolbar is a true toolbar (<toolbar> within
<toolbox>), 80% of the work will be done by merely passing gToolbox as
an array of toolboxes anywhere in the DOM rather than just the navigator
toolbox, and having an outer loop on the toolboxes.
Robert Kaiser
> cmon phil, xml is hacky?? ;)
Any language can deploy techniques that are hacky, and that's not even
confined to programming languages, but also applies to markup languages.
That does not mean that the language is hacky, it means the technique
used is hacky, and I think that's what Philip meant to say.
Robert Kaiser
alta88[nntp]
yeah, it was a throwaway comment and a good natured poke back. using a
binding on statusbar to effect customization is precisely as hacky as
using a binding on toolbar, which, as you know, we do.
so whether using the technique is hacky on toolbar may be (barely)
debatable, a claim that it is hacky on statusbar and not toolbar is
nonsensical.