php-general Digest 17 May 2009 01:18:35 -0000 Issue 6125
Topics (messages 292679 through 292692):
Re: CSS & tables
292679 by: Daniele Grillenzoni
292688 by: Stephen
292689 by: Robert Cummings
292690 by: Ashley Sheridan
292691 by: Robert Cummings
292692 by: Stephen
Parsing of forms
292680 by: Daniele Grillenzoni
292681 by: Daniele Grillenzoni
292682 by: Daniele Grillenzoni
292683 by: Daniele Grillenzoni
Fileinfo and MSWord bug
292684 by: b
Re: read the last line in a file?
292685 by: Tom Worster
Re: Shopping Cart
292686 by: Daniel Brown
292687 by: Shawn McKenzie
Administrivia:
To subscribe to the digest, e-mail:
php-general-digest-subscr...@lists.php.net
To unsubscribe from the digest, e-mail:
php-general-digest-unsubscr...@lists.php.net
To post to the list, e-mail:
php-gene...@lists.php.net
----------------------------------------------------------------------
--- Begin Message ---
On 15/05/2009 19.25, PJ wrote:
I know of no better place to ask. This may not be strictly a PHP issue,
but...
I am busting my hump trying to format rather large input pages with CSS
and trying to avoid tables; but it looks to me like I am wasting my time
as positioning with CSS seems an impossibly tortuous exercise. I've
managed to do some pages with CSS, but I feel like I am shooting myself
in the foot or somewhere...
Perhaps I am too demanding. I know that with tables, the formatting is
ridiculously fast.
Any thoughts, observations or recommendations?
A table, meaning ONE table for tough layouts could solve many problems,
specially for newbies, but tbh there are enough resources to do pretty
much whatever you need to do with css if the layout doesn't have absurd
constraints.
Most of the IE bugs are due to floating and clearing, once you have
learned to master overflow: auto and display: inline, you're good to go.
Just don't get insane about trying to achieve pixel perfect in netscape4.
--- End Message ---
--- Begin Message ---
PJ wrote:
I know of no better place to ask. This may not be strictly a PHP issue,
but...
I am busting my hump trying to format rather large input pages with CSS
and trying to avoid tables; but it looks to me like I am wasting my time
as positioning with CSS seems an impossibly tortuous exercise.
CSS 2.1 makes layout easy ans IE8 passes ACID2.
I have some javascript that detects the browser and warns users of IE <8
that they need to upgrade.
Maybe bleeding edge for commercial sites, but helping the user upgrade
is going them a favour.
Stephen
--- End Message ---
--- Begin Message ---
On Sat, 2009-05-16 at 19:48 -0400, Stephen wrote:
> PJ wrote:
> > I know of no better place to ask. This may not be strictly a PHP issue,
> > but...
> > I am busting my hump trying to format rather large input pages with CSS
> > and trying to avoid tables; but it looks to me like I am wasting my time
> > as positioning with CSS seems an impossibly tortuous exercise.
> CSS 2.1 makes layout easy ans IE8 passes ACID2.
>
> I have some javascript that detects the browser and warns users of IE <8
> that they need to upgrade.
>
> Maybe bleeding edge for commercial sites, but helping the user upgrade
> is going them a favour.
>
> Stephen
Tell that to government... many, and in some departments most, are still
using IE6. I'm quite sure they won't appreciate me telling them it's
time to upgrade. On the plus side though, MediaWiki is breaking
ground :)
Cheers,
Rob.
--
http://www.interjinn.com
Application and Templating Framework for PHP
--- End Message ---
--- Begin Message ---
On Sat, 2009-05-16 at 09:15 -0400, Robert Cummings wrote:
> On Sat, 2009-05-16 at 10:48 +0100, Ashley Sheridan wrote:
> > On Sat, 2009-05-16 at 02:25 -0400, Paul M Foster wrote:
> > > On Fri, May 15, 2009 at 01:25:42PM -0400, PJ wrote:
> > >
> > > > I know of no better place to ask. This may not be strictly a PHP issue,
> > > > but...
> > > > I am busting my hump trying to format rather large input pages with CSS
> > > > and trying to avoid tables; but it looks to me like I am wasting my time
> > > > as positioning with CSS seems an impossibly tortuous exercise. I've
> > > > managed to do some pages with CSS, but I feel like I am shooting myself
> > > > in the foot or somewhere...
> > > > Perhaps I am too demanding. I know that with tables, the formatting is
> > > > ridiculously fast.
> > > > Any thoughts, observations or recommendations?
> > >
> > > I think it's pretty telling that on a list of professionals who create
> > > websites constantly, the overwhelming concensus is that for forms,
> > > tables are the preferred solution.
> > >
> > > I liken this sort of discussion to the dichotomy between movie critics
> > > and people who actually go and see movies. The critics inevitably have
> > > all sorts of snobby things to say about the movies which are best
> > > attended. I'm not sure why anyone listens to any critic on any subject.
> > >
> > > Paul
> > >
> > > --
> > > Paul M. Foster
> > >
> > I think the argument of tables vs css can go a little deeper too. These
> > days, sites should not only be developed with good clean code that
> > validates, but semantic markup. If your client doesn't like/know what
> > this is, just give it to them in terms of seo!
>
> FWIW, everything I've read indicates that tables don't affect SEO.
>
> Cheers,
> Rob.
> --
> http://www.interjinn.com
> Application and Templating Framework for PHP
>
>
SEO is not the be and end all. Accessibility is a legal thing in many
countries; UK and Australia especially (they are the two most prominent
I know) so there's no excuse for shoddy coding. I'm not saying that
using tables inevitably leads to that, but more often than not, tables
are used in such a way that the reading of a page is wrong because the
elements appear in the code in the wrong order, even though they
visually appear correct. It's not the responsibility of the
speech/Braille browsers to interpret code designed for a seeing user.
They should only have to interpret semantics.
Rob; sorry, this isn't a pop at you, I just wanted to explain to anyone
who got hooked too much onto the SEO line you mentioned. I agree with
you in that respect though, I've never seen any evidence for tables
having any impact on SEO, and I've done a lot of SEO research!
Ash
www.ashleysheridan.co.uk
--- End Message ---
--- Begin Message ---
On Sun, 2009-05-17 at 01:52 +0100, Ashley Sheridan wrote:
> On Sat, 2009-05-16 at 09:15 -0400, Robert Cummings wrote:
> > On Sat, 2009-05-16 at 10:48 +0100, Ashley Sheridan wrote:
> > > On Sat, 2009-05-16 at 02:25 -0400, Paul M Foster wrote:
> > > > On Fri, May 15, 2009 at 01:25:42PM -0400, PJ wrote:
> > > >
> > > > > I know of no better place to ask. This may not be strictly a PHP
> > > > > issue,
> > > > > but...
> > > > > I am busting my hump trying to format rather large input pages with
> > > > > CSS
> > > > > and trying to avoid tables; but it looks to me like I am wasting my
> > > > > time
> > > > > as positioning with CSS seems an impossibly tortuous exercise. I've
> > > > > managed to do some pages with CSS, but I feel like I am shooting
> > > > > myself
> > > > > in the foot or somewhere...
> > > > > Perhaps I am too demanding. I know that with tables, the formatting is
> > > > > ridiculously fast.
> > > > > Any thoughts, observations or recommendations?
> > > >
> > > > I think it's pretty telling that on a list of professionals who create
> > > > websites constantly, the overwhelming concensus is that for forms,
> > > > tables are the preferred solution.
> > > >
> > > > I liken this sort of discussion to the dichotomy between movie critics
> > > > and people who actually go and see movies. The critics inevitably have
> > > > all sorts of snobby things to say about the movies which are best
> > > > attended. I'm not sure why anyone listens to any critic on any subject.
> > > >
> > > > Paul
> > > >
> > > > --
> > > > Paul M. Foster
> > > >
> > > I think the argument of tables vs css can go a little deeper too. These
> > > days, sites should not only be developed with good clean code that
> > > validates, but semantic markup. If your client doesn't like/know what
> > > this is, just give it to them in terms of seo!
> >
> > FWIW, everything I've read indicates that tables don't affect SEO.
> >
> > Cheers,
> > Rob.
> > --
> > http://www.interjinn.com
> > Application and Templating Framework for PHP
> >
> >
> SEO is not the be and end all. Accessibility is a legal thing in many
> countries; UK and Australia especially (they are the two most prominent
> I know) so there's no excuse for shoddy coding. I'm not saying that
> using tables inevitably leads to that, but more often than not, tables
> are used in such a way that the reading of a page is wrong because the
> elements appear in the code in the wrong order, even though they
> visually appear correct. It's not the responsibility of the
> speech/Braille browsers to interpret code designed for a seeing user.
> They should only have to interpret semantics.
>
> Rob; sorry, this isn't a pop at you, I just wanted to explain to anyone
> who got hooked too much onto the SEO line you mentioned. I agree with
> you in that respect though, I've never seen any evidence for tables
> having any impact on SEO, and I've done a lot of SEO research!
You know, I'm not advocating tables in general, I'm just saying there
are edge cases, that I certainly don't have the resources to flesh out
into pure table-less designs. In general I advocate clean validating
markup, with proper use of semantic tagging. I am very aware of
accessibility guidelines, and have had to follow the Canadian
Government's CLF2 guidelines often enough. However, the W3C guidelines
say not to use tables when appropriate CSS exist, unfortunately the
appropriate CSS is not widespread enough in some environments due to a
certain monopolostic company dragging it's feet. As such, the W3C makes
allowances for tables but tempers that with the expectation that they
linearize properly so that accessibility is still retained. In my use of
tables for the occasional layout, actually my MUD website was the first
time in a long time, I did ensure that linearization was maintained.
This being a hobby site, I'm sure many wouldn't even care :)
Cheers,
Rob.
--
http://www.interjinn.com
Application and Templating Framework for PHP
--- End Message ---
--- Begin Message ---
Robert Cummings wrote:
On Sat, 2009-05-16 at 19:48 -0400, Stephen wrote:
PJ wrote:
I know of no better place to ask. This may not be strictly a PHP issue,
but...
I am busting my hump trying to format rather large input pages with CSS
and trying to avoid tables; but it looks to me like I am wasting my time
as positioning with CSS seems an impossibly tortuous exercise.
CSS 2.1 makes layout easy ans IE8 passes ACID2.
I have some javascript that detects the browser and warns users of IE <8
that they need to upgrade.
Maybe bleeding edge for commercial sites, but helping the user upgrade
is going them a favour.
Stephen
Tell that to government... many, and in some departments most, are still
using IE6. I'm quite sure they won't appreciate me telling them it's
time to upgrade. On the plus side though, MediaWiki is breaking
ground :)
Cheers,
Rob.
My sites are still viewable, and can be navigated. They just look strange.
Government workers are used to strange :)
Stephen
--- End Message ---
--- Begin Message ---
I noticed that php's way to fill $_GET and $_POST is particularly
inefficient when it comes to handling multiple inputs with the same name.
This basically mean that every <select multiple> in order to function
properly needs to have a name ending in '[]'.
Wouldn't it be easier to also make it so that any element that has more
than one value gets added to the GET/POST array as an array of strings
instead of a string with the last value?
I can see the comfort of having the brackets system to create groups of
inputs easily recognizable as such, while I can overlook the
impossibility of having an input literally named 'foobar[]', having to
add [] everytime there is a slight chance of two inputs with the same name.
This sounds flawed to me, as I could easily append '[]' to every input
name and have a huge range of possibilities unlocked by that.
This can't be right. Or can it?
--- End Message ---
--- Begin Message ---
I noticed that php's way to fill $_GET and $_POST is particularly
inefficient when it comes to handling multiple inputs with the same name.
This basically mean that every <select multiple> in order to function
properly needs to have a name ending in '[]'.
Wouldn't it be easier to also make it so that any element that has more
than one value gets added to the GET/POST array as an array of strings
instead of a string with the last value?
I can see the comfort of having the brackets system to create groups of
inputs easily recognizable as such, while I can overlook the
impossibility of having an input literally named 'foobar[]', having to
add [] everytime there is a slight chance of two inputs with the same name.
This sounds flawed to me, as I could easily append '[]' to every input
name and have a huge range of possibilities unlocked by that.
This can't be right. Or can it?
--- End Message ---
--- Begin Message ---
I noticed that php's way to fill $_GET and $_POST is particularly
inefficient when it comes to handling multiple inputs with the same name.
This basically mean that every <select multiple> in order to function
properly needs to have a name ending in '[]'.
Wouldn't it be easier to also make it so that any element that has more
than one value gets added to the GET/POST array as an array of strings
instead of a string with the last value?
I can see the comfort of having the brackets system to create groups of
inputs easily recognizable as such, while I can overlook the
impossibility of having an input literally named 'foobar[]', having to
add [] everytime there is a slight chance of two inputs with the same name.
This sounds flawed to me, as I could easily append '[]' to every input
name and have a huge range of possibilities unlocked by that.
This can't be right. Or can it?
--- End Message ---
--- Begin Message ---
I noticed that php's way to fill $_GET and $_POST is particularly
inefficient when it comes to handling multiple inputs with the same name.
This basically mean that every <select multiple> in order to function
properly needs to have a name ending in '[]'.
Wouldn't it be easier to also make it so that any element that has more
than one value gets added to the GET/POST array as an array of strings
instead of a string with the last value?
I can see the comfort of having the brackets system to create groups of
inputs easily recognizable as such, while I can overlook the
impossibility of having an input literally named 'foobar[]', having to
add [] everytime there is a slight chance of two inputs with the same name.
This sounds flawed to me, as I could easily append '[]' to every input
name and have a huge range of possibilities unlocked by that.
This can't be right. Or can it?
--- End Message ---
--- Begin Message ---
PHP 5.2.6
file-4.17-15.el5_3.1
Fileinfo installed through PECL
Checking certain MSWord files, I'm getting back (sans quotes)
"application/msword application/msword". Someone reported (in the manual
comments) this same thing back in 2007:
http://ca2.php.net/manual/en/ref.fileinfo.php#79063
Can anyone shed any light on how/why this is happening? Specifically, is
this a bug in Fileinfo, file (the app), the Word doc, or the magic file
itself? I'd love to investigate this further but am having some trouble
searching online. Narrowing it down to a specific target would be most
helpful. I don't see anything about it at bugs.php.net and I'd rather
try to figure out if the problem is PHP-related before filing a bug.
For now, I'm doing the following:
$fi = new finfo(FILEINFO_MIME, FINFO_PATH);
$type = $fi->file($file['tmp_name']);
$split = explode(' ', $type);
$type = $split[0];
Pretty hackish. If anyone has a better solution in the meantime, I'd be
most appreciative.
--- End Message ---
--- Begin Message ---
On 5/16/09 3:55 AM, "Per Jessen" <p...@computer.org> wrote:
> Tom Worster wrote:
>
>> imagine writing a script to run as a daemon reading data off the
>> bottom of a log file that gets updated every few minutes and
>> processing each new log line as they arrive.
>>
>> i could exec("tail $logfile", $lines, $status) every now and then. or
>> poll the file mtime and run exec("tail $logfile", $lines, $status)
>> when it changes. there will be some lag due to the polling interval.
>>
>> but it would be nice to not have to poll the file and somehow trigger
>> the processing of the new line when the log file is written. but i'm
>> not sure how to do that.
>>
>> any ideas?
>
> 1) the inotify interface will alert you when a file or directory
> changes.
do you mean the pecl inotify extension? that would eliminate the polling and
the associated lag. but the php manual says it requires linux. if that's the
case then it's not going to work for me. the app i'm working with runs on os
x.
os x 10.5 has FSEvents but i'm not sure that's much improvement on polling
the log file.
> 2) run tail -f logfile | <yourscript> and read from stdin. (not tested).
i thought of this but i couldn't see much difference between reading from
stdin and opening the log file itself and reading from that (reading and
tesing for eof periodically in both cases i suppose). but i may be missing
something in your suggestion.
> 3) if you can change the logfile to a fifo, you're all set.
i don't have any control over the app that writes the log file. if there
were a utility like tail -f that opens a fifo for output rather than
outputting to sdtout...
thanks for the suggestions, per!
--- End Message ---
--- Begin Message ---
On Sat, May 16, 2009 at 05:37, Vernon St Croix <vstcr...@hotmail.com> wrote:
> Hi,
>
> I am pretty new to PHP and I am trying to create a shopping cart.
Just as a side note: in the future, please do not cross-post on
multiple lists. For general questions, this is the right place. The
PHP-DB list is just for database-centric code.
--
</Daniel P. Brown>
daniel.br...@parasane.net || danbr...@php.net
http://www.parasane.net/ || http://www.pilotpig.net/
50% Off All Shared Hosting Plans at PilotPig: Use Coupon DOW10000
--- End Message ---
--- Begin Message ---
Darrel St Croix wrote:
> Thanks for that.
>
> I have changed the code as you suggested, but there is an error on the while
> loop.
>
> *Warning*: mysql_fetch_array(): supplied argument is not a valid MySQL
> result resource in *C:\wamp\www\draft\basket.php* on line *46*
>
That's because $result is not valid because the query failed. You'd see
this if you turned on error reporting. BY is not valid in your query,
maybe ORDER BY?
--
Thanks!
-Shawn
http://www.spidean.com
--- End Message ---
