Tijnema ! wrote:
[snip]
Should you create a header that is 1600 width, and resize it down
until 800 when a user with 800x600 visits? and all images used at
borders and corners? That's the biggest problem in dynamic layouts.
Atm, i repeat small images around the borders, but that's a real pain
in
Tijnema ! wrote:
I guess the same can be done with ... But the main problem is
that there's no real standard for resolution. I see people having
resolution set at 800x600, and 1600x200, how is it ever possible to
make a page look good at both? Resizing it to 1600x1200 would give you
an enormous p
Edward Vermillion wrote:
So you're saying that if I "maximize" my browser window, all the
sites that you made with tables will "actually look good", at 1680 x
1050, because they are stretchy-pages?
Honestly, I have no clue as to why some folks think that a "stretchy"/
liquid/dynamic layout
tedd wrote:
At 5:06 PM +0200 4/26/07, Tijnema ! wrote:
It's not XHTML 1.0 Strict valid .. :P
You're page is HTML 4.01 valid, i think you should make it XHTML 1.0
Strict.
Ar. Then I would have to add all those "/" to my ">" in all my
code in all my sites. Literally millions of new "/"
Richard Lynch wrote:
[snip]
Relying on Sprint, however, to honor any kind of oral agreement, is a
big fat *NOT*
"I'm sorry, but we just don't have any reocrd of that conversation.
You're now 2 weeks overdue, because that extension you claim we gave
you doesn't exist."
It was like a parody of
tedd wrote:
However, I did run my audio captcha by a couple dozen _visually
impaired_ testers...
..snip...
...it's interesting to see what _they see_.
nothing?
;-)
--
PHP General Mailing List (http://www.php.net/)
To unsubscribe, visit: http://www.php.net/unsub.php
Richard Lynch wrote:
If you can compile (or find it compiled) on the exact same OS, you can
probably upload the binary and then use 'exec' on your own program.
I've had some success doing this on a shared host.
You might also be able to convince the webhost to just install
Festival for you. I
Dotan Cohen wrote:
I currently an using htmlencode, so < and > show as expected. I do
expect the math faculty to use those symbols :).
Then you're already protected from XSS attacks, no HTML filters
necessary. Easy as pi. ;-)
(ok, that one was lame)
--
PHP General Mailing List (http://
Have you considered using something other than Outlook?
Beauford wrote:
Does anyone else have this problem with the list. It seems that every time I
check my email there is one or more messages from the list that royally
screws up Outlook. I usually have to delete all list messages from the
ac
Dotan Cohen wrote:
On 25/04/07, Justin Frim <[EMAIL PROTECTED]> wrote:
I'm assuming then you want the data to be able to contain _some_ mark-up
considered to be safe?
Not at this stage, no. Maybe if the users ask for it, but not now in
the beginning. The universe's best
Dotan Cohen wrote:
On 24/04/07, Justin Frim <[EMAIL PROTECTED]> wrote:
if (get_magic_quotes_gpc()) {
/*
(unfortunately in PHP these are enabled by default. AHH! Which idiot
thought this was a good idea to turn them on by default? Good
programming
practise is to manually encod
Eric Butera wrote:
One thing you might want to keep in mind is that this little "fix" is
going to get executed on each request if you just throw it in an
include.
...big snip...
That means lots function calls happened before you could even say
hello world. You might want to add wrapper fun
Just my two cents worth...
Magic quotes are the work of the devil. It's a shame that so many PHP
installations have them enabled, and a huge disappointment that PHP is
actually distributed with this stuff enabled! The mere fact that a
script can't change this setting creates a real hassle an
I'll jump in on this one, because I've dealt with the div/object/iframe
frustration before.
And I would not be very happy if the W3C decided to deprecate iFrames
right now, at least with the current state of the world's browsers.
I found that with I didn't have very much control over the
bord
Myron Turner wrote:
I'm not sure I follow here, because the Perl script would be saving
the posted file to disk. It would then send back a redirect with the
name of the file in the query string of the url, which would point to
a php script that would then read the file from the disk. So the f
Edward Vermillion wrote:
On Apr 21, 2007, at 6:35 PM, Justin Frim wrote:
I've always gone by the rule that if you're making software that
other people will see or use, make it clean.
Sometimes I'll "cheat" and stick a @ symbol in front of a line to
shut up err
You are correct, I'm not very familiar with Perl.
If I do go the route of using something else to accept the form data and
then executing the PHP script, I'd be leaning more toward somehow
executing the PHP script directly rather then sending back a redirect to
the user-agent to re-send the re
I've always gone by the rule that if you're making software that other
people will see or use, make it clean.
Sometimes I'll "cheat" and stick a @ symbol in front of a line to shut
up errors and warnings for that particular line, but usually I only do
that for speed optimization. (ie. if it's i
Richard Lynch wrote:
On Thu, April 19, 2007 10:28 pm, Myron Turner wrote:
that should be necessary at this time. For instance, if it's
necessary
to pass in CGI parameters at the same time as sending out a file,
the
parameters can be tacked onto a query string and they will be packed
into b
Regarding some discussion a while back about putting in a feature
request for obtaining the POST body...
I can see the advantage of streaming the POST body directly to disk,
because then you don't have to allocate a huge amount of memory for
keeping a copy of the POST body in a variable. So m
Interesting...
But how will the user-agent know how to pack the data?
AFAIK, if you don't specify enctype in the tag, the user-agent
will assume application/x-www-form-urlencoded. I'm assuming that if you
put in something that's not recognized (like
multipart/x-non-parsed-form-data), the use
can
properly implement a file upload on a web form.
Myron Turner wrote:
Tijnema ! wrote:
On 4/19/07, Myron Turner <[EMAIL PROTECTED]> wrote:
André Medeiros wrote:
> php://stdin perhaps?
>
> On 4/18/07, Justin Frim <[EMAIL PROTECTED]> wrote:
>> André Medeiros wr
This is starting to get super ugly indeed...
I was hoping I wouldn't have to essentially write an HTTP daemon from
scratch, so I'll keep the sockets in mind as a *last* resort.
As much as it would simplify things if $HTTP_RAW_POST_DATA (and friends)
was fixed to always contain the data regardles
I tried that one too.
For any POST requests (regardless of Content-Type), it's always blank.
For GET requests, it contains the PHP script source code.
André Medeiros wrote:
php://stdin perhaps?
On 4/18/07, Justin Frim <[EMAIL PROTECTED]> wrote:
André Medeiros wrote:
> Re
André Medeiros wrote:
Reading from php://input on a webserver will retrieve the Body of the
HTTP Request.
Not for me it doesn't.
That only seems to work when the form is submitted as
application/x-www-form-urlencoded. When the form is submitted as
multipart/form-data, php://input is blank.
Chris Shiflett wrote:
Justin Frim wrote:
Is there any way to retrieve the POST message body when a form is
submitted to a PHP script using multipart/form-data?
There's the always_populate_raw_post_data configuration directive and
the $HTTP_RAW_POST_DATA. Have you tried that?
Yes, th
Greetings,
Is there any way to retrieve the POST message body when a form is
submitted to a PHP script using multipart/form-data?
I can't use just the $_POST[] and $_FILES[] arrays because I need to
calculate the hash of an exact bit-accurate copy of the original POST
body for data verificat
27 matches
Mail list logo
