Which browser to write for??

T

Toby Inkster

Jose said:
Sometimes you want to keep something (old) while you select something
(new) and do something (else) with it.

The corresponding situation on Windows would be:

you copy section A into the clipboard,
then go and make a minor cut/paste edit with section B,
then go to paste section A and find it gone.

The solution is not to do the above, but rather:

go and make a minor cut/paste edit with section B,
then you copy section A into the clipboard,
then go to paste section A and find it works.

On most platforms there is a limit of one thing that can be held on the
main clipboard at once; and certain activities will cause that thing to be
overwritten. Just don't do those things when you've got something
important in clipboard.
 
T

Toby Inkster

Alan said:
That's a matter of opinion! The slightest blunder with the mouse then
results in the previous clipboard contents (the ones I wanted to use!)
getting destroyed.

Destroyed?!

This is *copy*/paste, not cut we're talking about.
 
N

Neredbojias

To further the education of mankind, "Alan J. Flavell"
That's a matter of opinion! The slightest blunder with the mouse then
results in the previous clipboard contents (the ones I wanted to use!)
getting destroyed.

Mouse blunders have been the bane of mankind for quite some time...
 
J

Jose

The corresponding situation on Windows would be:
you copy section A into the clipboard,
then go and make a minor cut/paste edit with section B,
then go to paste section A and find it gone.

No, the corresponding situation (which doesn't occur) in Windows would be:

You copy section A into the clipboard, intending to paste it later.
Then you select section B and make it bold.
Then you go to paste section A and instead paste a copy of section B.

Bummer. But it doesn't happen in Windows.

Jose
 
I

I V

No, the corresponding situation (which doesn't occur) in Windows would be:

You copy section A into the clipboard, intending to paste it later.
Then you select section B and make it bold.
Then you go to paste section A and instead paste a copy of section B.

Well, yes and no. If you do this in X the way you'ld do it in windows
(select, ctrl-v, select, ctrl-c), it works the same way. X has two
clipboards (well, one is called CLIPBOARD and the other is called
something else, maybe PRIMARY), one of which always contains whatever you
last selected (so is easy to overwrite), the other one is only replaced
when you explicitly copy. So look on the middle-click-paste thing as an
optional extra.
 
J

Jose

X has two
clipboards (well, one is called CLIPBOARD and the other is called
something else, maybe PRIMARY), one of which always contains whatever you
last selected (so is easy to overwrite), the other one is only replaced
when you explicitly copy.

Ok. That's cool. :)

Jose
 
T

Travis Newbury

Beauregard said:
Design for other browsers first, then possibly add some fixes for the IE
bugs. Make sure you are using a DOCTYPE that triggers standard and not
quirks mode.

Why design for the minority and try to put fixes in for the majority?
(Sounds like a liberal thing, but I won't go there right now)

IE is still the most used browser there, so wouldn't it be prudent to
make sure it works correctly in IE FIRST, then make the needed fixes
for everything else?
 
A

Arne

Once said:
Why design for the minority and try to put fixes in for the majority?
(Sounds like a liberal thing, but I won't go there right now)

IE is still the most used browser there, so wouldn't it be prudent to
make sure it works correctly in IE FIRST, then make the needed fixes
for everything else?

Because when it works in other browsers, it's easier to fix the IE bugs.
If you first make it look good in IE you probably added and used som
much rubbish (and IE specific) code, without you even knowing it, so it
will be harder to fix it to work in other browsers.
 
M

Martin Jay

In message said:
Why design for the minority and try to put fixes in for the majority?
(Sounds like a liberal thing, but I won't go there right now)
IE is still the most used browser there, so wouldn't it be prudent to
make sure it works correctly in IE FIRST, then make the needed fixes
for everything else?

LOL. Which version of Internet Explorer do you suggest we design for? :)
 
A

Andy Dingley

Travis said:
Why design for the minority and try to put fixes in for the majority?
IE is still the most used browser there, so wouldn't it be prudent to
make sure it works correctly in IE FIRST, then make the needed fixes
for everything else?

No, for two reasons.

First of all, this is software not a widget factory. Volume doesn't
matter to software - if you have to do it once, you have to do it. Once
you've done it, you've done it for everyone.

The effort of support is the efort of designing this support, not a
volume-weighted sum. While we still have a situation of "at least one
IE user" and "at least one standards user" then we have to support
both, and supporting both is just the same work whether it's for one
user or for nearly all of them.


Secondly, the problem of IE support is now a question of working around
IE's faults. It's no longer the world of 2000 or so where there were
two clear browser camps with equal claim to being "best" (or at least,
"least broken"). It's now easy to design for a standards-based browser
and notably harder to design robustly for IE. In this context, it makes
sense to code to the standard first, then kludge it for IE later.

You should be _aware_ of IE's flaws from the start, but that doesn't
mean compromising the entire design (or at least not until you have to).
 
A

Alan J. Flavell

Why design for the minority and try to put fixes in for the majority?

Indeed. And all except one browser is currently aiming at
implementing the published interworking specifications; so if you
design for the specifications, you're designing for the majority of
browsers.

After that, there's just a minority of one browser-like object (maybe
in more than one of its versions, maybe in several of its fix levels)
to worry about.
IE is still the most used browser there, so wouldn't it be prudent to
make sure it works correctly in IE FIRST

No, it wouldn't, because IE isn't even a fixed target. It keeps
changing the specifications at which it's aiming. The other browsers
are correcting bugs in their implementation of the published
specifications. There's quite a difference there, whether you can see
it or not.

Designing for the web first, and then adjusting as necessary for IE,
still rates to bring the best results - even for IE. And this will
become even more true as IE7 appears, I'd say.
 
R

roomsixproductions

Bill, when I create webpages, I check them in both IE6 and Firefox. I
probably should check them in Opera and Netscape as well, but I dont.

Since stats indicate that IE6 is the most used browser in the world
(even though it's not all that standards-compliant), I'd say to make
your page based on that browser, even though I personally prefer
Firefox.
 
M

Martin Clark

Bill wrote...
Oh, I see... IE has the current market share so I'll just stick my fingers
in my ears and say NANANANANANAN.....
If I were selling something and I knew 80 percent of the population prefered
the item in blue I'd be rather foolish to make it in green wouldn't I.
In an earlier post you said "it is a church site after all shouldn't it
be accessible to everyone who wants to 'view' it".

Everyone except those who don't use IE?

You have had it pointed out to you that if you design for a compliant
browser like Firefox or Opera, it will, in most cases, look fine in IE,
or can be made to do so with small tweaks. IE 6 will be replaced soon by
IE 7, which will be more standards-compliant. Are you going to want to
re-write all your pages then for IE 7?
Wonderful, another net cop.....
Why insult people who are trying to help you?

At some point in the future you may find yourself really stuck on
something and want to come back and ask for advice. Do you think people
will be willing to help you if they think you are going to stick your
fingers in your ears and say "NANANANANA" again?
 
N

Neredbojias

To further the education of mankind, "Travis Newbury"
Why design for the minority and try to put fixes in for the majority?
(Sounds like a liberal thing, but I won't go there right now)

Simply because other browsers respond much more correctly to correct markup
than does IE6.
IE is still the most used browser there, so wouldn't it be prudent to
make sure it works correctly in IE FIRST, then make the needed fixes
for everything else?

No, not prudent at all. Unwise.
 
T

Toby Inkster

Travis said:
Why design for the minority and try to put fixes in for the majority?
(Sounds like a liberal thing, but I won't go there right now)

For several purely practical reasons -- different reasons will apply to
different people:

* (in my experience at least) it's generally *easier* to design
for a standards compliant browser and then tweak for IE than
the other way around;

* IE is not a cross-platform browser, so the developer may not
have a copy on their main development platform;

* IE generally suffers from many security problems: by avoiding
it for the majority of the development process, you're helping
secure your development workstation;

* Many people like to use web developer tools that are available
built-in (or as add-ons) to their non-IE browser;

* IE's caching mechanism can sometimes be a little off-kilter:
sometimes it will continue to use an older version of a style
sheet when a newer one has been uploaded -- this can make
testing a pain.

Take your pick. Choose several if you like.
 
M

Michael Winter

On 25/04/2006 08:20, Toby Inkster wrote:

[snip]
* IE's caching mechanism can sometimes be a little off-
kilter: sometimes it will continue to use an older version
of a style sheet when a newer one has been uploaded -- this
can make testing a pain.

True, but as far as I can see (I've been checking with
dynamically-generated images), this only occurs when no freshness
information (Expires header or Cache-Control: max-age directive) is
available, or when a specified lifetime is too long.

In the former case, the behaviour IE exhibits is generally acceptable as
the estimated lifetime should suffice in the majority of cases on the
Web. For the latter case, one can hardly blame IE for an incorrectly
specified lifetime, however undesirable the consequences. Still, doesn't
Ctrl+F5 (forced refresh) also reload style sheets?


Unfortunately, I don't know how IE makes its lifetime estimate; the
cache lists 'None' rather than the date and time that IE intends to use.
However, it seems clear that if the Last-Modified header is absent, and
as long as IE isn't configured /not/ to reexamine cached entities, IE
will always revalidate a resource.

That said, one must recognise that the caching behaviour isn't entirely
sensible: if the Last-Modified date matches that of the Date header in
the same response, IE still seems keen to reuse it without revalidation.
There also seems to be a minimum lifetime of around two seconds, even
when an explicit zero is given.


Comparing other user agents, it would seem that Op acts similarly to IE,
though without any dependency on the Last-Modified header; the History
preferences will determine when it revalidates a resource that lacks
freshness information. Fx takes a different approach, and always
revalidates whenever the lifetime is unknown (though there an advanced
property, browser.cache.check_doc_frequency, that will that).


Whilst we're (I'm) discussing caching, can I ask for some clarification
(though I'm quite certain of the answer)?

The name of the no-cache Cache-Control directive is misleading in that
it implies that the caching of a response entity should not be permitted
(though no-store is explicit in that regard) and indeed IE and Op both
seem to take that position. However, I agree with Mark Nottingham[1]
that RFC 2616 does permit the caching of such a resource, but requires
end-to-end revalidation before satisfying any subsequent request with
the same entity.

Does anyone care to provide definitive remarks either way, and perhaps
caches (proxy or client) that are known to be problematic? Fx appears to
behave as I would expect as a no-cache resource is listed in the disk
cache (about:cache?device=disk).

Mike


[1] <http://www.mnot.net/cache_docs/#CACHE-CONTROL>
 
N

Neredbojias

To further the education of mankind, Michael Winter
Fx takes a different approach, and always
revalidates whenever the lifetime is unknown (though there an advanced
property, browser.cache.check_doc_frequency, that will that).

I'm only casually familiar with caching mechanisms in general but this
statement surprised me because I've been having a bit of trouble with
Firefox and caching. Whenever I change/update a page on my site and then
open it with FF, I always seem to get the old version. None of my pages
have any explicitly-stated caching directives, meta or otherwise. Sure, I
can manually reload the page and _then_ get the new version, but this
shouldn't be necessary. I've checked in Firefox's "tools" menu and didn't
see anything that might address the issue.

Any thoughts?
 
F

frederick

Neredbojias said:
To further the education of mankind, Michael Winter


I'm only casually familiar with caching mechanisms in general but this
statement surprised me because I've been having a bit of trouble with
Firefox and caching. Whenever I change/update a page on my site and then
open it with FF, I always seem to get the old version. None of my pages
have any explicitly-stated caching directives, meta or otherwise. Sure, I
can manually reload the page and _then_ get the new version, but this
shouldn't be necessary. I've checked in Firefox's "tools" menu and didn't
see anything that might address the issue.

Have you explored the myriad of different options available by typing
in "about:config" in the address bar?

Note that knowing what all the bells and whistles do requires a bit of
Googling, and some options are only detailed after they've been
explicity set by the user.
 

Ask a Question

Want to reply to this thread or ask your own question?

You'll need to choose a username for the site, which only take a couple of moments. After that, you can post your question and our members will help you out.

Ask a Question

Members online

No members online now.

Forum statistics

Threads
473,744
Messages
2,569,483
Members
44,903
Latest member
orderPeak8CBDGummies

Latest Threads

Top