I would assume that the reason it doesn't work, is because you are using
a method called parseint. JavaScript is case-sensitive... The method
is actually parseInt. But changing that makes IE hang, as someone
pointed out earlier... This I think is caused by the fact that you are
applying the
Hi all,
I've noticed a problem on our website when rendering pages with Firefox 1.5
(and possibly lower).
If you have Firefox 1.5 installed could you please take a look at the
following page:
http://www.intrepidtravel.com/africatrees
And let me know if the main content area renders
Return Receipt
Your RE: [WSG] equal height columns [No Protective Marking]
document:
Quintin Stoltz wrote:
I would assume that the reason it doesn't work, is because you are
using a method called parseint. JavaScript is case-sensitive... The
method is actually parseInt. But changing that makes IE hang, as
someone pointed out earlier... This I think is caused by the fact
Hi Samuel
Just for interest, I checked it in both Firefox 1.5.0.6 and Opera
9.01 on Mac OS X 10.4.9.
In both cases, the page background is a red tile pattern with orange
highlights. The text area appears as a very very pale red (or deep
pink) surrounding a white background for the form.
Yes, I actually only read the replies after my reply. It makes sense.. I
tested it also, and noticed that it worked fine.
Quintin Stoltz wrote:
I would assume that the reason it doesn't work, is because you are
using a method called parseint. JavaScript is case-sensitive... The
method
Hi,
I've not used these expressions much, but is the use parseInt necessary?
I had the impression that offsetHeight returns an integer value of px. Am
I missing something?
Stuart
On Tue, April 17, 2007 7:06 am, Quintin Stoltz wrote:
I would assume that the reason it doesn't work, is
No, it does return an integer value... But I have come across times
where it returned nothing, and then I normally test with isNaN and
parseInt to make sure it returns an integer. I don't think it's
neccesary in this case.
-Original Message-
From: [EMAIL PROTECTED] [mailto:[EMAIL
[EMAIL PROTECTED]:
Can I just substitute ID for NAME and still adhere to web standards
or is NAME really required?
'name' **is** required on inputs. It's confusing, but the name
attribute is required on **form controls** (input etc) so that your
from can be processed on your server -
Stuart Foulstone wrote:
I've not used these expressions much, but is the use parseInt
necessary?
I had the impression that offsetHeight returns an integer value of
px. Am I missing something?
The method has the purpose of keeping the calculations alive in IE/win.
Compare this _with_
Gunlaug Sørtun wrote:
http://www.rhh.myzen.co.uk/gam/sandbox/elc.html
Correction:
The em to px part of the calculation - needed for correct subtraction
of that padding, can be extracted here...
http://www.gunlaug.no/contents/wd_additions_14.html
...where I use it to simulate 'em-based
Return Receipt
Your RE: [WSG] equal height columns
document:
Return Receipt
Your RE: [WSG] equal height columns
document:
This one just came in via the W3C newsfeed:
Internationalization Best Practices: Specifying Language in XHTML
HTML Content
http://www.w3.org/TR/2007/NOTE-i18n-html-tech-lang-20070412/
A well done human readable note on where, how and why embed langauge
information in documents.
djn
--
I have FF 2.0 and it renders fine on first and second glance.
Fix up those strict validation issues and see how you go again.
Rgds',
Ben
On 4/17/07, Jonathan O'Donnell [EMAIL PROTECTED] wrote:
Hi Samuel
Just for interest, I checked it in both Firefox 1.5.0.6 and Opera
9.01 on Mac OS X
Return Receipt
Your RE: [WSG] equal height columns [No Protective Marking]
document:
Return Receipt
Your RE: [WSG] equal height columns [No Protective Marking]
document:
Return Receipt
Your RE: [WSG] equal height columns
document:
Return Receipt
Your RE: [WSG] equal height columns
document:
Return Receipt
Your RE: [WSG] equal height columns
document:
I'm looking at a design involving image thumbnails and the instruction
to click images for larger version -- I have the idea that saying
click is wrong, or rather the assumption that everyone is using a
mouse is wrong.
So, how would you word this instruction, or otherwise inform users that
a
John Horner wrote:
I'm looking at a design involving image thumbnails and the instruction
to click images for larger version -- I have the idea that saying
click is wrong, or rather the assumption that everyone is using a
mouse is wrong.
Depends on the design, of course, but how about simply
John wrote:
I'm looking at a design involving image thumbnails and the instruction
to click images for larger version -- I have the idea that saying
click is wrong, or rather the assumption that everyone is using a
mouse is wrong.
So, how would you word this instruction, or otherwise
John Horner wrote:
Images are linked to larger versions seems to passive-voice to me, and
I can't think of any generic term for using a link.
Joe Clark suggests using something like,
alt=Sunrise at Darling Harbour (link to larger image)
-
Terrence Wood wrote:
[EMAIL PROTECTED]:
Can I just substitute ID for NAME and still adhere to web standards
or is NAME really required?
'name' **is** required on inputs. It's confusing, but the name
attribute is required on **form controls** (input etc) so that your
from can be processed
This is definitely an issue and I second it. But if we as professionals are
going to deal with this issue on an ongoing basis then a solution will be
handy and left for the administrator to pass to the offending party
involved.
My suggestion only.
So that being said is there a solution that
Benedict Wyss wrote:
People need to have auto responders for business reasons, does this
mean we say people on the list have to send and receive from a web
mail address not a work address?
I don't think View - Options - Uncheck 'request read receipt' box
is too much to ask before clicking on
27 matches
Mail list logo
