I'm going to say something now that may seem to completely contradict
a previous post of mine, in which I basically said that taking a "who
cares" attitude about certain browsers (because of their non-standard
CSS rendering) makes no sense.
Well, you have to draw the line *somewhere*... and contradictory or
not, I've decided that I've suffered with Netscape 4 for long enough.
Coding workarounds for its brain-dead CSS rendering has literally
doubled my development time on some projects. It's the only browser I
can truly say that I *hate*, and now that its market share seems to
have slipped below one percent (I hope!), I'm saying "enough."
So I'm planning to simplify my CSS and JavaScript files by stripping
out most or all of the NS4-specific bloat, and never find out what
gibberish it makes out of my pages by the simple method of not
viewing them myself in NS4.
However, I may leave my JavaScript browser-sniffer in place. My
question is, what's the best way to blow off NS4 users? Here are
some options that I've thought of:
1. Do nothing special (even get rid of the sniffer).
Pros: Simplest thing to do. They're going to see garbage
anyway, and they're probably used to it.
Cons: They don't know that their browser is crap, and they'll
blame me (or my clients).
2. Put up a JavaScript alert box on every page load, saying that my
site doesn't support NS4, and did they know they can get a modern
browser for free?
Pros: -Performs a public service - educates them a little.
-Lets them know I know what's happening (i.e. I'm not
just oblivious/incompetent).
Cons: -Might make pages unusable (too annoying) that might
otherwise be readable even in NS4.
-I'm not sure, but I don't think I can put a link (to
a browser upgrade site) in an ordinary JS alert.
I could certainly generate a special little window
(pseudo-"alert") with a link, but that would be work.
-If my sniffer screws up, I may end up annoying
non-NS4 users.
3. Use JavaScript to write some bold red text on every page with a note
(as in #2 above) and a link to some kind of browser upgrade site.
Pros: A little less harsh than the other options.
Cons: -More work for me. Do I have to check each page in NS4
to see that the warning is actually visible? Even if
it is, will I be able to restrain myself from "fixing"
each page after I see what garbage it looks
like in NS4?
-If my sniffer screws up, I may end up annoying
non-NS4 users.
Opinions? How do you handle this?
16  2181 
On Thu, 15 Jul 2004 23:22:32 GMT, Jonas Smithson wrote: 1. Do nothing special (even get rid of the sniffer).
...but use @import to make your CSS invisible
to the brain-dead NN4. That way you do not
risk your (precious) content being hidden by
some bizarre rendering of style-sheet based
positioning effects.
Any NN4 user now would have to be getting used
to seeing 'Black Times New Roman on a White BG'.
They either know what is happening and do not
need/want formatting on web pages, or put it
down to 'some web design FAD'.
To sum it up, I do not think someone who is
still using NN4 gives a toss what color *we*
want the BG of our pages to be, and if they
are happy with that, so am I.
--
Andrew Thompson http://www.PhySci.org/ Open-source software suite http://www.PhySci.org/codes/ Web & IT Help http://www.1point1C.org/ Science & Technology
Jonas Smithson wrote: I've decided that I've suffered with Netscape 4 for long enough.
Coding workarounds for its brain-dead CSS rendering has literally
doubled my development time on some projects.
That's what many of use have found. Fortunately, NS 4 is capable of
rendering HTML sans CSS in most situations -- it has some trouble with
the character model, IIRC, but that may not affect you -- and it is
trivial to simply hide all CSS from it.
@import "hidefromns4.css";
However, I may leave my JavaScript browser-sniffer in place.
That sounds suspect. What is this "JavaScript browser-sniffer" all
about? Such things are notoriously unreliable and counter-productive
besides.
My question is, what's the best way to blow off NS4 users?
Don't. Server then HTML; don't serve them CSS. You'll be doing NS4
users a big favor by protecting them from CSS that their browser will
choke on.
1. Do nothing special (even get rid of the sniffer).
In *any* case, get rid of the sniffer.
Cons: They don't know that their browser is crap, and they'll
blame me (or my clients).
Chances are that NS4 users are accustomed to the web as it appears.
Your site, by contrast, will be much friendlier for them, since it
will actually function.
2. Put up a JavaScript alert box on every page load, saying that my
site doesn't support NS4, and did they know they can get a modern
browser for free?
In other words: "I know what you need more than you do. You're an
idiot. Do as I say."
The difference between clueful authors and the other kind is as
follows: the clueful think of themselves as guests of those who come
to the site; the clueless think their visitors are guests of their
-Lets them know I know what's happening (i.e. I'm not
just oblivious/incompetent).
3. Use JavaScript to write some bold red text on every page with a note
(as in #2 above) and a link to some kind of browser upgrade site.
If you put an alert in bold red text telling them to upgrade, you'll
appear quite incompetent. You are a www author. You write documents
for the www, and make sure they work in commonly used browsers. That's
the beginning and end of your work. It is simply not your place to
tell users what software they should run to accomodate you.
--
Brian (remove ".invalid" to email me) http://www.tsmchughs.com/
Brian wrote: ....It is simply not your place to tell users what
software they should run to accomodate you.
I agree with you -- it's not my place to "tell" them what they "should"
run. But perhaps it depends on how it's worded? That is, perhaps a
*suggestion* that they *could* upgrade, not a *command* that they do
so? What brought this to mind... I discovered almost by accident that a
couple of non-technical friends of mine were using NS4 and literally
didn't know what browser they were using, didn't know they could
upgrade it, and didn't know that it made any difference. Wouldn't it be
performing a service (to them and to the Web design community) to let
NS4 site visitors know? How else would they find out they could upgrade
to a better browser?
I seem to recall a site called "The Browser Upgrade Project" or
something like that, set up for this purpose (i.e. you provide a
suggestion and a link to that site, or even just redirect your page to
them, and they provide explanations of why modern browsers are better,
and links to many browsers). Of course I'd still need to run a JS
sniffer to know whether to write a "suggestion" note and a special link
to them, and you seem opposed to JS sniffers, although I'm not sure
why. I've used them for years (as many sites do) to serve up somewhat
different CSS to NS4, and not one user has ever reported a problem. I
know browsers sometimes lie about what browser they are, but does any
browser lie specifically about being NS version 4 when it isn't?
it is trivial to simply hide all CSS from it.
@import "hidefromns4.css";
I hadn't thought of that. Do you mean fetch *all* my external styles --
i.e. my main external stylesheets -- via @import rather than via <link
rel... etc. so they'd be invisible to NS4/Opera 3/etc? Is there any
downside to doing it that way... does the CSS stylesheet load just as
reliably/quickly/efficiently in modern browsers via @import as via
<link rel... ?
Jonas Smithson wrote: I agree with you -- it's not my place to "tell" them what they
"should" run. But perhaps it depends on how it's worded? That is,
perhaps a *suggestion* that they *could* upgrade, not a *command*
that they do so?
And this will be on every page? So every page of your site will have a
"suggestion" that they upgrade? This makes sense -- if your site is
about upgrading browsers. If your site is about something else, then
why would you put such a message on every page? Or on the home page of
such a site?
If you are determined to do this, then do it in an out of the way
place. A small link on the home page only, to an "about this site"
page. On that page, you might note that NS 4 users will get an
unstyled page, and that such users can upgrade at
http://getabetterbrowser.loser.com.
The site in my sig sort of takes that approach; every page has a link
to a "help" page. On that page, besides some genuine help, is a link
to a "visual presentation" page. On *that* page is a note about css,
and that older browsers will be shielded from it.
Note: visitors only get there 2 links from the home page; the page in
question is not an "upgrade, loser" page, it's a note about how the
visuals were accomplished; and the message simply explains how and why
things look as they do. I don't patronize viewers by telling them what
they should use, I explain what I did to make it work in the browser
they chose. In other words, I assume they chose their browser -- MSIE,
Firefox, Opera, Netscape 4, Lynx, whatever -- for a reason, and I'm
not going to question that choice.
I did create a site requirements page. There again, I suggest that
they should upgrade, I merely tell them what might improve for them.
One final note: I put some work into these pages, but I doubt that
anyone has ever actually read them. I conducted very informal
usability tests, and the subjects (all 2 of them!) never went anywhere
near the /site/ pages. I regard that a success. If they don't need
help, then my site is reasonably user-friendly.
Of course I'd still need to run a JS sniffer to know whether to
write a "suggestion" note and a special link to them, and you seem
opposed to JS sniffers, although I'm not sure why.
It is the very wrong way to see what the visitor is using. What if js
is disabled? What if the referrer string is suppressed or forged?
I've used them for years (as many sites do) to serve up somewhat
different CSS to NS4, and not one user has ever reported a problem.
They usually don't; they just hit the back key and look for reading
material elsewhere.
@import "hidefromns4.css";
Do you mean fetch *all* my external styles -- i.e. my main external
stylesheets -- via @import rather than via <link rel... etc.
Yes.
so they'd be invisible to NS4/Opera 3/etc?
It will hide all styles from NS4 and IE4. I'm not familiar with old
versions of Opera, so I can't comment on that.
does the CSS stylesheet load just as reliably/quickly/efficiently
in modern browsers via @import as via <link rel... ?
Noone here has ever suggested otherwise.
--
Brian (remove ".invalid" to email me) http://www.tsmchughs.com/
On Thu, 15 Jul 2004 22:08:51 -0400, Brian
<us*****@julietremblay.com.invalid> wrote: If you are determined to do this, then do it in an out of the way
place.
How about something styled display: none? NN4 will see it, as the CSS is
imported. Only other folks to see it will really be Lynx.
Neal wrote: Brian wrote:
If you are determined to do this, then do it in an out of the way
place.
How about something styled display: none?
Why? What is behind this desire to remind users that their browser is,
according to the author, sub-standard?
NN4 will see it, as the CSS is imported. Only other folks to see it
will really be Lynx.
And Links, W3M, Opera or Firefox with styles disabled, etc. Oh, and
Googlebot.
So how will the page be indexed?
Joe Clueless Home Page
Your browser is out of date; time to upgrade
This is my home page, with photos and...
How professional.
--
Brian (remove ".invalid" to email me) http://www.tsmchughs.com/
On Fri, 16 Jul 2004 00:22:06 -0400, Brian
<us*****@julietremblay.com.invalid> wrote: Neal wrote:
Brian wrote:
If you are determined to do this, then do it in an out of the way
place.
How about something styled display: none?
Why? What is behind this desire to remind users that their browser is,
according to the author, sub-standard?
Hey, not MY desire. But if you're looking to send content to no-CSS
viewers, that's it.
Neal wrote: How about something styled display: none? NN4 will see it, as the CSS is
imported. Only other folks to see it will really be Lynx.
That sounds clever; thanks! That would allow me to avoid using a
JavaScript sniffer. (Although, BTW, a *properly written* sniffer is not
as unreliable -- for this purpose, anyway -- as some people seem to
think. It's true that most sniffers are unnecessary even for
JavaScript's own purposes, since object detection usually works better,
but that's not relevant in this case; and many sniffers are badly coded
-- but mine isn't. Nonetheless, I agree that they're a little dicey and
best avoided, and I appreciate your suggestion.)
Moving on... looking back over the previous posts, I'm having a couple
of problems here.
First of all, I just tried the @import idea and immediately saw a
problem: it (naturally) doesn't block inline styles, or styles in the
head. Now I do use external styles whenever possible -- and I'd say
it's practical for about 90% of my styles. But the other 10% -- the
head and inline styles -- make a total mess when the external sheet is
blocked.
There's also a bigger problem (maybe) that I'm thinking of...
Andrew Thompson wrote:
Any NN4 user now would have to be getting used
to seeing 'Black Times New Roman on a White BG'.
True, and if font and background information were all that was
involved, hiding all the CSS from NS4 would be a no-brainer. But I'm
starting to rely on CSS-positioning for entire page layouts (not just
for sections within an outer table), and that opens up a whole other
can of worms if most or all of the CSS is blocked.
Consider the case of various main units of text which each "own" a
small ancillary sidebar, connected with CSS positioning. I'm *not*
talking about sidebars with author pullquotes to pique the reader's
interest, and whose precise adjacency doesn't really matter. I'm
talking about sidebars with ancillary technical material related to
their specific parent paragraphs -- for example, a main paragraph which
discusses xyz and an adjacent small sidebar with links to "Sites with
more information" (i.e., more info about xyz).
The sidebar is an absolutely positioned element whose spatial
relationship to its parent will change without CSS. It may even appear
on an entirely different part of the page if the CSS is missing or
mangled. Worse case, the reader may actually think the ancillary
material refers to a different "parent" paragraph than it actually
does!
I suppose the simple retort to my example is "that's a true tabular
relationship, use a table" -- but I was trying to get away from table
code! Or "don't put that in a sidebar" -- so I have to limit my design
options with CSS, although I didn't when using tables? Rhetorical
question: So are we to conclude that any page that requires specific
positional adjacencies as a clue to meaning can't be safely laid out
with CSS? I doubt many people here would say that. It seems to me that
many, many pages have such positional relationships!
This may get philosophical/contentious pretty quickly... my belief is
that (many comments in this newsgroup notwithstanding) there cannot
always be a clear demarcation between "structure" and "appearance."
Using CSS positioning means you may (in some important cases) be
inevitably affecting meaning, not just "decoration."
I can understand Brian's objections to my suggesting too obtrusively to
readers anything about their browser: whenever I've visited a site that
said "This site best viewed in... [insert browser name]" my reaction
was always that the designer was both arrogant and clueless. So it's a
little strange that I'm contemplating something like that now. (I
emphasize "contemplating"; I haven't decided, that's why I'm posting
here.) But if a Netscape 4 user may actually *misconstrue the meaning
of the content on a page* because the positions have been scrambled,
might it not be the lesser of several evils to warn them or even block
the page to them entirely?
Regardless of whether I...
1. ...block most of the CSS with @import (and have the unstyled HTML
unpredictably blend with the inline styles that I can't block), or
2. Allow all the CSS through and have NS4 create its usual mishmash out
of the styles...
*Either way* I run the risk of users seeing adjacencies that could be
highly misleading. This is a question of *meaning*, not fonts and
backgrounds. That's why it seems like some kind of warning to NS4
visitors -- yes, on every page -- might be the least obnoxious
solution. (?)
Or else it's back to table code. Or back to testing individual page
layouts in NS4, endless convoluted CSS workarounds, etc. :(
Still open to ideas; my mind is *not* made up on all this.
Thanks.
(P.S. Did I mention that I *hate* Netscape 4?)
On Thu, 15 Jul 2004 23:22:32 GMT,
Jonas Smithson <sm************@REMOVETHISboardermail.com> posted: 1. Do nothing special (even get rid of the sniffer).
Pros: Simplest thing to do. They're going to see garbage
anyway, and they're probably used to it.
Cons: They don't know that their browser is crap, and they'll
blame me (or my clients).
I'd go for do nothing. Attempts to be intelligent at guessing what a
browser does, or can do, tend to be wrong a lot of the time. As you say,
people with older browsers are used to them sucking.
If you feel the need to educate people, and you have a page to help people
with using the site, mention it there.
--
If you insist on e-mailing me, use the reply-to address (it's real but
temporary). But please reply to the group, like you're supposed to.
This message was sent without a virus, please delete some files yourself.
Jonas Smithson wrote: So I'm planning to simplify my CSS and JavaScript files by stripping
out most or all of the NS4-specific bloat, and never find out what
gibberish it makes out of my pages by the simple method of not
viewing them myself in NS4.
What the others said. Hide your CSS from NS4 and write decent,
well-structured HTML. See my site for an example:
http://tranchant.plus.com/
If you view it in Firefox, click on the little icon with an "A" on it on
the left edge of the status bar, and select Basic Theme. That's what my
NS4 viewers see.
Implementation hint: Firefox displays this icon if you give the
stylesheet a title in the <link> element.
However, I may leave my JavaScript browser-sniffer in place.
Don't. Javascript is a really poor way to browser-sniff. The least poor
way is server-side testing of the user-agent string, but even that is
notoriously unreliable. I do it only to detect IE to fix a couple of
things for its poor users, like <abbr>.
My
question is, what's the best way to blow off NS4 users? Here are
some options that I've thought of:
1. Do nothing special (even get rid of the sniffer).
Other than make sure the CSS call is hidden from NS4 (via @import, or
using media="screen,projection"), that's the right thing to do.
2. Put up a JavaScript alert box on every page load, saying that my
site doesn't support NS4, and did they know they can get a modern
browser for free?
No. Extremely annoying, and some people may be using public computers
that they can't upgrade. They'll leave your site pretty quickly.
3. Use JavaScript to write some bold red text on every page with a note
(as in #2 above) and a link to some kind of browser upgrade site.
See 2.
Opinions? How do you handle this?
See above. Sounds like you need to rely less on Javascript, too.
--
Mark.
Jonas Smithson <sm************@REMOVETHISboardermail.com> writes: First of all, I just tried the @import idea and immediately saw a
problem: it (naturally) doesn't block inline styles, or styles in the
head. Now I do use external styles whenever possible -- and I'd say
it's practical for about 90% of my styles. But the other 10% -- the
head and inline styles -- make a total mess when the external sheet is
blocked.
Styles in the head you can use a different hiding method for. There's
several that work on NN4, how about:
<style type='text/css'>
/*/*/
body {
break-ns4: yes;
}
/* */
</style>
You might even be able to use the same thing in an inline style <p
style='/*/*/ break-ns4: yes /* */'> but I haven't tested that because
I don't use inline styles myself on live pages.
The sidebar is an absolutely positioned element whose spatial
relationship to its parent will change without CSS. It may even appear
on an entirely different part of the page if the CSS is missing or
mangled.
If you've already checked this, my apologies, but what happens if you
increase your browser font size to somewhat larger than normal - does
the positioning relationship break?
Worse case, the reader may actually think the ancillary material
refers to a different "parent" paragraph than it actually does!
<p>This is a paragraph ... </p>
<div id="sidebar1">This is the paragraph's sidebar</div>
<p>This is another paragraph ... </p>
<div id="sidebar2">This is another paragraph's sidebar</div>
Or similar. That way the sidebars are close to the paragraphs without
CSS, and it's no harder than otherwise to position them close with it.
I suppose the simple retort to my example is "that's a true tabular
relationship, use a table" -- but I was trying to get away from table
code!
If it *is* true tabular relationship then use table code. It seems a
slight stretch in this case, but maybe not - URL for an example?
Or "don't put that in a sidebar" -- so I have to limit my design
options with CSS, although I didn't when using tables? Rhetorical
question: So are we to conclude that any page that requires specific
positional adjacencies as a clue to meaning can't be safely laid out
with CSS? I doubt many people here would say that. It seems to me that
many, many pages have such positional relationships!
Absolutely not, as you've guessed. However, the positional
relationships are *initally* in the HTML, in a good design. CSS
positioning may be used to _reinforce_ the relationship, but not to
initially indicate it.
I can understand Brian's objections to my suggesting too obtrusively to
readers anything about their browser: whenever I've visited a site that
said "This site best viewed in... [insert browser name]" my reaction
was always that the designer was both arrogant and clueless. So it's a
little strange that I'm contemplating something like that now. (I
emphasize "contemplating"; I haven't decided, that's why I'm posting
here.) But if a Netscape 4 user may actually *misconstrue the meaning
of the content on a page* because the positions have been scrambled,
might it not be the lesser of several evils to warn them or even block
the page to them entirely?
There's a concept in web design called 'linearisation'. It means that,
when CSS is disabled, or tables are disabled (since it's important for
both layout methods), or both, the page still makes sense. If your
page doesn't do this then you have your HTML elements in the wrong
order and you need to fix that.
Regardless of whether I...
1. ...block most of the CSS with @import (and have the unstyled HTML
unpredictably blend with the inline styles that I can't block), or
Or move the inline styles into the stylesheet
<p style='...'> becomes <p id='...>
p#... {
...
}
*Either way* I run the risk of users seeing adjacencies that could be
highly misleading. This is a question of *meaning*, not fonts and
CSS should not be used as the sole indicator of meaning in the same
way that colour shouldn't.
backgrounds. That's why it seems like some kind of warning to NS4
visitors -- yes, on every page -- might be the least obnoxious
solution. (?)
No, fixing the HTML code so that it doesn't require CSS to make sense
is the *least* obnoxious solution. Give a URL for a problem case and
we might be able to make suggestions.
(P.S. Did I mention that I *hate* Netscape 4?)
Yes.
--
Chris
"Mark Tranchant" <ma**@tranchant.plus.com> wrote in
comp.infosystems. www.authoring.stylesheets:Jonas Smithson wrote: 2. Put up a JavaScript alert box on every page load, saying that my
site doesn't support NS4, and did they know they can get a modern
browser for free?
No. Extremely annoying, and some people may be using public computers
that they can't upgrade. They'll leave your site pretty quickly.
Agreed -- about as annoying as that voice at the checkout reminding
me after I scan EVERY DAMN ITEM, "Please place the item in the bag."
People who have Netscape 4 on their own computers already know that
later browsers are available, and they know how to find them if they
want them. And I echo Mark's comments about public computers.
--
Stan Brown, Oak Road Systems, Tompkins County, New York, USA http://OakRoadSystems.com/
HTML 4.01 spec: http://www.w3.org/TR/html401/
validator: http://validator.w3.org/
CSS 2 spec: http://www.w3.org/TR/REC-CSS2/
2.1 changes: http://www.w3.org/TR/CSS21/changes.html
validator: http://jigsaw.w3.org/css-validator/
Neal wrote: Brian wrote:
Neal wrote:
How about something styled display: none?
Why? What is behind this desire to remind users that their
browser is, according to the author, sub-standard?
Hey, not MY desire.
Sorry, Neal. I was on a bit of a tirade last night, wasn't I? My
apologies, it was not even your idea. :-/
if you're looking to send content to no-CSS viewers, that's it.
As is so often the case, the question should be "how do I...?" but
"should I...?"
--
Brian (remove ".invalid" to email me) http://www.tsmchughs.com/
Jonas Smithson wrote: Neal wrote:
How about something styled display: none? NN4 will see it, as the
CSS is imported. Only other folks to see it will really be Lynx.
That sounds clever;
You'll look clever, too, the next time the Googlebot indexes your
site. ;-) (See my response to Neal about this.)
(Although, BTW, a *properly written* sniffer is not as unreliable
Oh? Since js is optional, and ua strings can be forged, how can such a
thing be reliable?
It's true that most sniffers are unnecessary even for JavaScript's
own purposes, since object detection usually works better,
Object detection always works better in js.
many sniffers are badly coded -- but mine isn't.
Ok, genius, let's see your brilliant code! I wait with baited breath. :-)
First of all, I just tried the @import idea and immediately saw a
problem: it (naturally) doesn't block inline styles, or styles in
the head.
That's true. I didn't mention it, because I use neither of those
techniques. You may need to ditch any advanced inline css to protect
NS 4 from itself.
I'm starting to rely on CSS-positioning for entire page layouts
(not just for sections within an outer table), and that opens up a
whole other can of worms if most or all of the CSS is blocked.
I do all layout in CSS for my sites. All of it. I write in HTML
4/strict, which offers little presentation markup. NS 4 users get a
plain site, with no floats, no positioning, no styling at all. It was
the right choice for me. Only you can decide whether it's right for
your projects.
Consider the case of various main units of text which each "own" a
small ancillary sidebar, connected with CSS positioning.
Place it in a div after the paragraph, perhaps. We'd need a url to
provide more specific advice.
if a Netscape 4 user may actually *misconstrue the meaning of the
content on a page* because the positions have been scrambled,
Then you need to rethink the page. CSS is optional no matter what the
browser. Your content should be comprehensible without it. If it is
not, then rethink your markup.
--
Brian (remove ".invalid" to email me) http://www.tsmchughs.com/
.oO(Jonas Smithson) Brian wrote:
it is trivial to simply hide all CSS from it.
@import "hidefromns4.css";
I hadn't thought of that. Do you mean fetch *all* my external styles --
i.e. my main external stylesheets -- via @import rather than via <link
rel... etc. [...]
You can also stay with the link-element and an media-attribute. NN4 only
recognizes media='screen'.
From time to time I add a simple stylesheet only for NN4 (could be
written in JSSS for example), but the default stylesheet for all other
browsers is written according to the CSS 2.1 standard without any hacks.
Micha This thread has been closed and replies have been disabled. Please start a new discussion. Similar topics
by: Jeff Johnson |
last post by:
Hi Everybody,
I have a function that works great in IE but fails in NN. Would
someone please give me some insight as to how to correct this:
function init(){
var oFrame = parent.frames;
...
|
by: rez |
last post by:
I find it rather frustrating that Netscape 4.x is "no longer
supported:"
http://help.netscape.com/products/client/communicator/reflib.html
Same seems true with IE.
How am I ever supposed to...
|
by: Laurens |
last post by:
Hi,
Which browser has the best CSS paged media support?
I'm about to write a business plan, which needs to be printed on paper to be
presented to the bank. Now I cringe at doing this in...
|
by: Peter Foti |
last post by:
Simple question... which is better to use for defining font sizes and why?
px and em seem to be the leading candidates. I know what the general answer
is going to be, but I'm hoping to ultimately...
|
by: bulk88 |
last post by:
I know Netscape 4 is Ancient and horrible but I need to make my site
Netscape 4.8 compatible. But how can I rewrite HTML code/do minor DTHML
on my site with Netscape 4/4.8, document.write works,...
|
by: Nariak |
last post by:
Dear friends of programming!
the script below only works with MSI and Opera but not with Netscape 7.x and
Mozilla 1.x!
What is wrong?
Please help me!
Thanks Ralf
|
by: Jason |
last post by:
We have an Extranet with one customer with 20,000 users that has,
unfortunately, standardized on Netscape 4.77 for the entire company. We are
in the process of rewriting this application from Java...
|
by: Zytan |
last post by:
Obviously you can't just use a simple for loop, since you may skip
over elements.
You could modify the loop counter each time an element is deleted.
But, the loop ending condition must be...
|
by: jim |
last post by:
Let's just say that I am foolish enough to code and distribute a free app to
the general public over the web.
What is the best (cheapest, smallest bandwidth, easiest to code) way to
publish...
|
by: Charles Arthur |
last post by:
How do i turn on java script on a villaon, callus and itel keypad mobile phone
|
by: aa123db |
last post by:
Variable and constants
Use var or let for variables and const fror constants.
Var foo ='bar';
Let foo ='bar';const baz ='bar';
Functions
function $name$ ($parameters$) {
}
...
|
by: emmanuelkatto |
last post by:
Hi All, I am Emmanuel katto from Uganda. I want to ask what challenges you've faced while migrating a website to cloud.
Please let me know.
Thanks!
Emmanuel
|
by: BarryA |
last post by:
What are the essential steps and strategies outlined in the Data Structures and Algorithms (DSA) roadmap for aspiring data scientists? How can individuals effectively utilize this roadmap to progress...
|
by: nemocccc |
last post by:
hello, everyone, I want to develop a software for my android phone for daily needs, any suggestions?
|
by: Sonnysonu |
last post by:
This is the data of csv file
1 2 3
1 2 3
1 2 3
1 2 3
2 3
2 3
3
the lengths should be different i have to store the data by column-wise with in the specific length.
suppose the i have to...
|
by: marktang |
last post by:
ONU (Optical Network Unit) is one of the key components for providing high-speed Internet services. Its primary function is to act as an endpoint device located at the user's premises. However,...
|
by: Hystou |
last post by:
Most computers default to English, but sometimes we require a different language, especially when relocating. Forgot to request a specific language before your computer shipped? No problem! You can...
|
by: jinu1996 |
last post by:
In today's digital age, having a compelling online presence is paramount for businesses aiming to thrive in a competitive landscape. At the heart of this digital strategy lies an intricately woven...
| |
