» in my experience...

» home | about | contact | résumé
» archives | donate | rss syndication

»
»
NASA's Ion engine


Communiblog Communiblog expressed as RSS 2.0
Here at IMX
Memes R' Us
freetheaudio2.jpg
SuperNova 1987A from 1994 to 2003
GarageBand

Category Archive » Web Browsers

Old news.
[ March 24, 2004 | Permalink | 0 Comments | 0 TrackBack | TB URL ]

A voice enabled browser? Bah, I was doing that years ago.


OmniWeb is relevant.
[ August 12, 2003 | Permalink | 3 Comments | 0 TrackBack | TB URL ]

For a very long time, I have felt that OmniWeb is an irrelevant annoyance on the web browser landscape. I mean, who are they kidding? another browser to support, that no one uses? I'm having a hard enough time writing compliant code that renders consistently in Mozilla and Internet Explorer. Safari came along and completely marginalized a mostly marginalized browser.

That has changed. OmniWeb 4.5 now "uses the WebCore framework from Apple for greatly improved standards support." That's the engine that runs Safari, so OmniWeb is essentially, just another Safari browser, but with one crucial difference. There's a JavaScript Console now, that shows me errors that might be occurring in the page I am developing. The error messages are a bit cryptic, but are still more useful than the errors that Safari gives you (read: none). I would prefer that the error messages were a bit more like Mozilla's though.

In the environment that I work in, we have more than 15% of our users running Safari. That's a pretty high percentage, and definitely passes the "they can't be ignored" ratio (which is, imho, about 8%). Not only can't they be ignored, but functionality can't just gracefully degrade, it has to be on par with IE and Mozilla support. OmniWeb's JavaScript Console makes that easier. If I were the business/marketing wonk down at The Omni Group, I'd be pushing that behind the registration fee. But I'm not, so I'm glad it's not.


Lack of control is a business risk.
[ July 24, 2003 | Permalink | 7 Comments | 0 TrackBack | TB URL ]

It's been a busy week so far (between baby, work and other events) so the postings have been meagre; sorry about that. I had to post something about this thing though...

Microsoft may have unwittingly started a revolt against its Internet Explorer (IE) browser by discontinuing it as a standalone product and blurring the future of the current version, IE 6.
And here's on example of the fallout...
Say explained that First Direct is due to update the security certificate on its secure servers and unless users had upgraded to the latest version of IE, they would receive "odd messages" questioning the authenticity of their connection. Four weeks after asking Microsoft for advice on the subject, he is still waiting for a response.

"This is a tricky one for us because we have no control or influence that we can exert,"
Notice the lack of control there. If there's one thing a business can't stand it's uncertainty, and a lack of control breeds that feeling rabbits on Carrot Island. Losing control over your application, and the method of making money, to another corporation that is known to be horribly predatory, can only be bad. How do you go about mitigating that risk? Adopt standards, support Mozilla and Safari, and avoid MSFT specific code.


Netscape.
[ July 16, 2003 | Permalink | 0 Comments | 0 TrackBack | TB URL ]

Recently I speculated about the demise of Netscape, and more to the point, that Netscape would not meet an untimely end. Apparently, I was wrong, and it's pretty depressing to see it happen.

The point I made about the MSFT/AOL deal was that AOL would still prefer to NOT place control of its business into the hands of its competitors. That's definitely true, but I carried that into a hope that Netscape wouldn't be scuttled. At least Mozilla will carry on with active funding from the likes of AOL, IBM and Sun.


Wicked Fast.
[ July 02, 2003 | Permalink | 6 Comments | 0 TrackBack | TB URL ]

moz_14_icon.gifI have been working on a reformation of Kalsey's CSS tabs code to NOT use unordered lists and list items in favor of divs and spans. I'm also adding some JavaScript to change the className on mouseover to change the menus without having to click and get a new page (something I am sure Mr. Kalsey has thought of before).

One striking fact that has come out of the work, is that Mozilla 1.4 on Mac OSX is extremely fast (download). It renders the code I have way faster and cleaner than Safari. Perhaps I haven't been paying attention recently, or maybe I'm in a Safari induced haze, but this new release is just awesome and might become my default browser. Oh yeah, and it has a nice new icon.

Anyone else have any thoughts?


I want to Sync, not import.
[ April 09, 2003 | Permalink | 9 Comments | 0 TrackBack | TB URL ]

Is it me, or can you not export your bookmarks from Safari? It's possible to back up your bookmarks file by going to this file path...

/Users/your_user_name/Library/Safari/Bookmarks.plist
...but I'd like to have a mechanism in the broswer to export this to (X)HTML or RDF or even RSS.

Apple's PLIST format is XML, and parseable, and transformable. So ultimately, what I really want is for someone (even Apple) to write something that can transform my Safari bookmarks into the format Mac IE5 reads and into the format that Camino reads (and vide versa).

Some sort of cronable job would be optimal where all of my bookmarks would be sync'd between my browsers, which would require transformations from and to each format. This avoids exporting, and then importing, which is time consuming. I can't even imagine writing the diff code.

Not even the Camino authors have Safari bookmark imports working yet, so maybe I'm asking for a bit much...

Note that, although it initially shows you Internet Explorer's bookmarks, you can import bookmarks from OmniWeb, iCab, Mozilla, Netscape, and Camino itself. Safari bookmarks cannot yet be imported.
One can wish, can't he?


Make it work.
[ March 20, 2003 | Permalink | 3 Comments | 0 TrackBack | TB URL ]

While discussing some 'quirks mode' and 'strict mode' browser behaviors, and regarding the need for more correctly written HTML, Dave Hyatt asks...
If you don't behave strictly when in standards mode, how will people ever write valid HTML?
Sorry dude, that's a false question. "Writing Valid HTML" is like "burning clean coal." It can sort of be done, but there's always something making it dirty, or systems that are so draconian that they sap out the value of the resource (be it coal energy, or perfectly valid XHTML).

Human nature, poor markup rendering engines that are widely spread, and idiotic decisions like making XHTML 2.0 not be backwards compatible, will make "strict" the sigma seven on the curve of diminishing returns.

Should we try to write valid markup, and assume it will be rendered with tender loving care? Of course! And I think Dave's efforts, to make that a reality by following reason and altruistic goals, are good efforts. Unfortunately, browsers can't trust the markup they will have to render, and web developers can't trust browsers not to be quirky (or completely stupid).

Should strict mode be "less quirky" mode or should strict mode be "if it isn't perfect, it's going to be an f'ing mess" mode?


Smart UI comments from Andreesen.
[ February 21, 2003 | Permalink | 4 Comments | 0 TrackBack | TB URL ]

Regarding the original web browser Andreesen says...

Things like the Back and forward button, we never intended that to be a permanent part of the interface. But people get locked into metaphors. You have to be careful with the metaphors you put in front of people because once they click onto one, that's it.
This is pretty much true of web apps, brochure-ware and compiled applications. And this represents the largest risk to the high fidelity prototype. You want to under promise and over deliver on your projects, but you need to draw a fine line between giving away the store and not delivering the goods.

To mitigate this, you have to know what you are talking about, and how to execute on various requirements as they arrive on your doorstep. Pattern languages can help but real experience will better inform your decisions. Andreesen's comments are based on experience, but this next one is off the mark...

I think it's so funny that Apple comes out with a new browser in 2003. Where were you guys six years ago? I wish them the best, but it's not as if you're about to see Safari go from 0 percent market share to 47 percent.
In its (puny) market, Safari owned that market overnight, so in terms of that bit of business strategy, Marc missed the point. Safari is a good move for Apple due to the fact that none of the seven browsers I have installed on my tiBook are fully adequate. But I digress; Andreesen's UI instincts seem to be finely tuned, even if he's supposed to be a business guy.


Beating a dead horse.
[ February 20, 2003 | Permalink | 0 Comments | 0 TrackBack | TB URL ]

One of the great things about Internet Explorer 5 for the Mac (IE5) is that it's pretty tight on the html and css standards, and kind of behaves like it's PC cousin. That made developing sites somewhat easier because you could reasonably guess that JavaScript you wrote would work in both, and IE5 has been dominant on the Mac platform since is was made the standard (which was a few years ago). Enter Safari.

Now, we have the KHTML engine to deal with since that is what Safari is based on, and if you cover Mac news, or software, or Mac-whatever, you need to support it, because on the Mac IE5 use has evaporated overnight. Those same results appear at this site, but I see a larger contingent of PC based browsers than Daring Fireball does.


Here's an epiphany: let's stop reinventing the wheel.
[ February 19, 2003 | Permalink | 2 Comments | 0 TrackBack | TB URL ]

If using Safari is like Voting for Ralph Nader, then using Epiphany (yet another Mozilla based browser) is like voting for Al Sharpton. However, some folks will go their own way and accept the consequences of their choices. Too bad those choices affect others in adverse ways.

This is considerably less stupid then what's happening to the Chimera browser these days. They are considering a name change instead of trimming and improving the code base.


Safari wish list.
[ January 30, 2003 | Permalink | 10 Comments | 0 TrackBack | TB URL ]

I want all of the following in the final rev of Safari...

  1. Right click and select "View Source in [your application of choice]" which of course would be BBEdit. (This is sort of possible already using JavaScript and running that script from BBEdit)
  2. Right click and select "Subscribe to this sites' RSS feed in NetNewsWire"
  3. Tabs.
  4. Select a block of text, right click and 'View Source of Selection'
  5. A massive AppleScript dictionary
  6. Right click an image and "Send to [your application of choice]" which in my case would be ImageReady.
  7. XML support (that's done)
  8. Support the <label> tag (because Fitt's Law owns).
Any more?


Does Safari have inheritance problems?
[ January 14, 2003 | Permalink | 8 Comments | 0 TrackBack | TB URL ]

Here are two examples of what I think are inheritance problems in Safari. I have sent the first one to Apple's WebCore guy, Dave Hyatt, as a bug report. The second one seems to be in the same vein of inheritance problems and locality...
  1. iframe size inheritance
  2. table cell padding inheritance.
Now, I am right about the rules of inheritance and CSS styling, correct? These are bugs in the way Safari (in both revs 54 and 81) is choosing to render the page, right? In any event, many thanks to Dave Hyatt for his efforts and for publically sharing info on the development efforts of Safari.

Ironically, today Hyatt notes fixes to their table rendering code on his blog. I wonder if he's fixed the problem I've noted here.


More than a Safari.
[ January 08, 2003 | Permalink | 7 Comments | 0 TrackBack | TB URL ]

By now everyone has heard about Safari, and if they haven't this blog is probably not a place they will visit. So screw 'em. And screw Apple for not using Gecko. I loath the idea of supporting yet another browser and dealing with it's quirks, half-implementations and unpredictable behaviors. It felt to me just two days ago that it would remain a Mozilla/Gecko vs Internet Explorer Universe, and thus make my job a little easier. What really burns my ass is that Safari is as fast as Stevie Boy Blew says it is, which means people will use it, making it more likely that I will have to support it.

I digress. Bitch session over. Safari owns. One of the guys developing Safari has a weblog and he promises some details in the coming days/weeks about the new browser. I'll be making daily visits to Dave Hyatt's weblog hoping he says good things about hard core standards compliance. In the meantime, go download it, and enjoy goodies like popup blocking, Rendezvous support, better bookmark handling, smart cookie blocking and text selections that actually work. Good stuff.

Also, Apple has it's own X11 package (!).


Fastzilla.
[ September 24, 2002 | Permalink | 0 Comments | 0 TrackBack | TB URL ]

Perhaps the core Mozilla group is taking a cue from the Chimera guy (who now works at Apple by the way), because there is a 'lean browser initiative' tasked to create a browser, called Phoenix, that is based on "Speed, Speed, and Speed." It's about time, but I'm still bullish on the rumor of Apple creating their own version of a Gecko based browser (often name dropped as "iBrowse"). The reasons are many...

  • I prefer OS native widgets, and thus think XUL sucks (even though it's a cool idea)
  • Apple has an interest in making a kickass browser.
  • Apple has the Chimera guy working for them, and Chimera is great, but needs work.
  • Reliance on MSFT to provide browsing technology is silly.
  • Apple would likely make a user centric browser that wouldn't turn off the popup blocking tech that AOL stifled in Netscape 7.0
  • The Mac zealot in me just wants an Apple branded browser.
Be sure to read David Hyatt's weblog to get more perspective and educated opinions on what is going on with all of this.


Browser wars? Browser onslaught.
[ June 13, 2002 | Permalink | 1 Comments | 0 TrackBack | TB URL ]

Sometimes people argue against using MacOS(X) using a lack of software as their corner stone argument. While this may be true (there is, as a side effect, much less crap software for MacOS(X) than their is for Windows) it isn't true when it comes to web browsers. I have seven different browsers installed on my machine...
Chimera...
...is based on Mozilla, but endeavors to be a web browser, not a catch all Internet client that reads email, edits pages, dice onions and walk your dog. It rips out the XUL interface and replaces it with native Aqua widget calls. Version 0.3 was released last week and has been far more stab;e than the 0.2 series (imho). The view-source-in-a-tab thing is awesome.
Mozilla...
...is where the good display engine is coming from. Too bad it wants to do too much and slows way down compared to Chimera. (Anecdotal evidence only, real numbers would be cool).
Internet Explorer...
...starts up in about three seconds, doesn't crash (too much), supports standards pretty well, and often hangs when one window opens another. It's a workhorse browser, but I can't wait to replace it.
Opera...
...is one step behind on MacOSX in terms of the version. Windows users get version 6.0 while we're back in the 5's (and just barely). I rarely use this browser.
Omniweb...
...looks great, and is fat, but doesn't really adhere to the standards. People pay for it though, so it must have something going for it, and the Omni Group is completely dedicated to Mac based development.
Netscape 6.x...
...was a disaster. A commercial product based on Mozilla 0.9.4 (read: beta) code was not a good idea, so I'm not going to provide a link to it in fear that any more people will download it. On the other hand, Netscape 7 will be a good thing, someday soon.
iCab...
...has a following due to it's small size. But I NEVER use it, and never see it in my server logs.
I sincerely believe that integrated solutions are a great thing, and that bloatware is like a shadow in the morning; faint at first, and inevitable as time goes by. Applications need to keep focused on the solutions they present without causing new problems to be solved, which is what Chimera intends to do.

The Web Standards Project has a breakdown of these browsers' compliance with standards. Their conclusions should weigh heavily with users, but they won't, so it's up to us.


Mozilla, (almost) ready to run.
[ May 01, 2002 | Permalink | 0 Comments | 0 TrackBack | TB URL ]

There's an interview with the Cheif Lizard at Mozilla.org which covers the vision behind the project and where they hope to go with it. I think the thing that I like about it is that the Gecko engine is being used in a lot of different places already, and that means cross platform development will be getting just a little bit easier. Chimera for the Mac, Galeon for Linux, Netscape for many platforms, all use Gecko, and makes the browser wars more than just a memory.


Browser Wars, going back to the future.
[ March 26, 2002 | Permalink | 0 Comments | 0 TrackBack | TB URL ]

So, Netscape 6.22 came out last week and it's still betaware. But, Gecko based browsing is in AOL's future and there will be ramifications. Now, I think Lie's quote about AOL going to Gecko is spot on when he says that "If AOL successfully deploys Mozilla...Authors will need to write browser-neutral pages...." But I think it's important to remember that the uptake rate of Gecko (as embedded in AOL 8?) is not going to be lightning fast, and even if it turns out to be fairly aggressive, I think we have a good year before Gecko becomes an entry in a project plan.


Killer apps are not planned.
[ December 28, 2001 | Permalink | 0 Comments ]

OSopinion has an article about 'How Mozilla Could Help Us Take Back the Web' which has nothing more to say than that Mozilla needs a killer feature for the one point oh release. Of course it does! And it already has a killer feature called standards compliance. The latest milestone build (0.9.7) notes the following new features...

The DOM Inspector is a tool that can be used to inspect and edit the live DOM of any web document or XUL application. The DOM hierarchy can be navigated using a two-paned window that allows for a variety of different views on the document and all nodes within. If you're using the Mozilla installer, be sure to switch from typical, to complete or custom install to install the DOM inspector and JS Debugger.
That last bit about the JS Debugger is a killer feature for the web interface developers of the world. But, for the public at large, a killer feature comes in the form of something like Napster which defines a whole new market, which is NOT the mission of Mozilla. The OSopinion author goes on to say "The only way Mozilla will wrest the Web from the iron grip of that overshadowing blue 'E' is by providing its users with a killer feature that has universal appeal." I argue that the universal appeal is compliance with standards as defined by the W3C.

Also, I have yet to see anyone go about creating a 'killer app' and actually succeed on the level of Navigator or Napster. These were accidents like Silly Putty.


I could not have put it better myself.
[ December 09, 2001 | Permalink | 0 Comments ]

The question of developing web sites for Netscape users is getting to sound a lot like the question about developing applications for Mac users. Why do it?

Fortunately for everyone, and especially folks like me, the answers are more compelling (and heartening) every day. A List Apart has taken on the Netscape question, and O'Reilly continues to offer answers to the Mac question.

But, in spite of any argument one way or the other, always keep in mind one crucial question. Who is your target audience?


MovableType AmphetaDesk
NetNewsWire BlogTree Subscribe with Bloglines RSS Feed
Copyright © 2001 - 2003 by Daniel Kapusta