php-general Digest 18 May 2009 15:38:45 -0000 Issue 6128
Topics (messages 292722 through 292731):
Re: CSS & tables
292722 by: Jim Lucas
292723 by: Benjamin Hawkes-Lewis
292724 by: Sancar Saran
292728 by: Al
292729 by: tedd
292730 by: Nathan Rixham
Re: Parsing of forms
292725 by: Peter Ford
Re: SQL help?
292726 by: Marcus Gnaß
292727 by: O. Lavell
Variables not initialized. Is it possible to...
292731 by: Cesco
Administrivia:
To subscribe to the digest, e-mail:
[email protected]
To unsubscribe from the digest, e-mail:
[email protected]
To post to the list, e-mail:
[email protected]
----------------------------------------------------------------------
--- Begin Message ---
Robert Cummings wrote:
CSS3 will make our lives easier once it's fully supported by all major
browser vendors...
Rob, sorry to have to point this out to you, but all major browser vendors don't even support CSS1 or CSS2
completely/correctly yet. Plus, parts of what they do have implemented of CSS1 and CSS2 act differently between the
different browsers that it is a PITA to work with them.
SARCASM: They will be on to CSS5 or CSS6 before they get most of CSS3 features implemented. I guess I'm saying, don't
hold your breath...
Jim
--- End Message ---
--- Begin Message ---
On 18/5/09 08:03, Jim Lucas wrote:
all major browser vendors don't even support CSS1 or CSS2 completely/correctly
yet.
I don't think any browser vendor intends to implement the original CSS2
Recommendation; instead they are aiming for compliance with the CSS 2.1
revision.
We do have /very/ nearly complete implementations of CSS 2.1 from all
major browser vendors.
This was the state of play /before/ IE8 - already pretty good:
http://www.webdevout.net/browser-support-css
Now:
Opera: http://www.opera.com/docs/specs/presto211/#css
IE: http://msdn.microsoft.com/en-us/library/cc351024(VS.85).aspx
Safari:
http://developer.apple.com/documentation/AppleApplications/Reference/SafariCSSRef/Articles/StandardCSSProperties.html
Firefox: https://developer.mozilla.org/en/CSS_Reference
There a couple missing pieces - for example, in the upcoming Firefox
3.5, "The :before and :after pseudo-elements have been updated to full
CSS 2.1 support, adding support for the position, float, list-style-*,
and some display properties."
https://developer.mozilla.org/en/Firefox_3.5_for_developers
But all in all, vendor support for CSS 2.1 is arguably now as good as or
better than for HTML 4.01.
Also, the fact that CSS2.1 implementation is not complete has not
dissuaded browser vendors from experimenting with implementations of
CSS3 drafts (e.g. "border-radius", "text-overflow").
--
Benjamin Hawkes-Lewis
--- End Message ---
--- Begin Message ---
Well.
If you really really want to go Table less css.
You have to you one of those CSS frameworks.
I suggest YAML
And even with YAML.
You have to fix your design to IE6.
My point of view positioning with DIV was time consuming process and very
frustrating experience (especially with IE6).
And to those pesky Table Nay sayers.
Damn get over it. Did you still believe those TABLES ARE SLOW marketing
buzz ?
Hello we are in 2009. We got wordwide broadband access and guess what.
Images and flash contend much bigger than any html and css data. And
your JS generate more load than html parsing to client cpu.
Yes CSS was most elegant solution and most time consuming.
Regards
Sancar
--- 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. 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?
It appears this thread has neglected to mention the "display" property values
that emulate table elements, e.g., table-row, table-cell, etc. As in:
<div class="cell"> where *.cell{display:table-cell}. Thus, one can make a
complete table without once ever using table tags <table>, <td> etc.
Personally, using the display table properties to avoid using table tags has
left me a bit puzzled. But, I just figured I was overlooking something.
Can some one educate me on this point.
Al.........
--- End Message ---
--- Begin Message ---
At 4:05 AM +0100 5/18/09, Nathan Rixham wrote:
Paul M Foster wrote:
And by the way, this attitude of "My code is fine; your browser sucks;
upgrade" can be the worst kind of arrogance, and people react to it
exactly as though it were arrogance. There used to be the same kind of
attitude with regard to screen resolution. 640x480 was just so "80s",
and *all* the latest monitors supported 1280x1024 or whatever. So we
design for 1280x1024 and screw those Luddite users. I would agree if
someone's using Netscape 4; you'd have to kindly break it to them that
they really should upgrade. But beyond that, it gets gray.
-snip-
yeah - major difference being that upgrading your web browser if
free, and as we well know you can have multiple browsers installed
with no problems.
I understand what you are saying, but if 50%+ of the worlds web
developers simply cut support for x, y & z browser (or displayed a
limited site with a notice) then I think the old browsers may just
go away (90%). eg if google, facebook, msn, ebay, yahoo all cut
support for them..
Nathan:
In most technical things you are right, but here I have to agree with
Paul. The user is king -- you must to design for them regardless of
their browser of choice -- even if their choice is a bad one.
There are places/companies where they do not want to upgrade because
of the problems and cost of upgrading. There are managers who believe
"Everything works. There's no reason to upgrade". I know a lot of
people who are frozen in time with their computer system because it
has reached it's technological end. Also, many don't have the money
to upgrade and to some, our discarded systems are the only things
they can afford. What do we do with them -- discard them as well?
According to my stats, IE 6 has a popularity of around 15 percent and
that is dropping at around one percent per month. At some point, IE6
will fall to IE5 levels (< 1%) and we won't have to consider it any
longer regardless. But until then, any responsible web developer
should accommodate IE 6 regardless of it's shortcomings.
Cheers,
tedd
--
-------
http://sperling.com http://ancientstones.com http://earthstones.com
--- End Message ---
--- Begin Message ---
tedd wrote:
At 4:05 AM +0100 5/18/09, Nathan Rixham wrote:
Paul M Foster wrote:
And by the way, this attitude of "My code is fine; your browser sucks;
upgrade" can be the worst kind of arrogance, and people react to it
exactly as though it were arrogance. There used to be the same kind of
attitude with regard to screen resolution. 640x480 was just so "80s",
and *all* the latest monitors supported 1280x1024 or whatever. So we
design for 1280x1024 and screw those Luddite users. I would agree if
someone's using Netscape 4; you'd have to kindly break it to them that
they really should upgrade. But beyond that, it gets gray.
-snip-
yeah - major difference being that upgrading your web browser if free,
and as we well know you can have multiple browsers installed with no
problems.
I understand what you are saying, but if 50%+ of the worlds web
developers simply cut support for x, y & z browser (or displayed a
limited site with a notice) then I think the old browsers may just go
away (90%). eg if google, facebook, msn, ebay, yahoo all cut support
for them..
Nathan:
In most technical things you are right, but here I have to agree with
Paul. The user is king -- you must to design for them regardless of
their browser of choice -- even if their choice is a bad one.
There are places/companies where they do not want to upgrade because of
the problems and cost of upgrading. There are managers who believe
"Everything works. There's no reason to upgrade". I know a lot of people
who are frozen in time with their computer system because it has reached
it's technological end. Also, many don't have the money to upgrade and
to some, our discarded systems are the only things they can afford. What
do we do with them -- discard them as well?
According to my stats, IE 6 has a popularity of around 15 percent and
that is dropping at around one percent per month. At some point, IE6
will fall to IE5 levels (< 1%) and we won't have to consider it any
longer regardless. But until then, any responsible web developer should
accommodate IE 6 regardless of it's shortcomings.
Cheers,
tedd
sadly I agree - and that's what I do as well, because I have to - but I
don't want to and loathe every minute of it :p
there's nothing that makes me cringe as much as a client mailing me
saying "my wifes cousin was just on the site and she said the sites
doesn't look right", then after 2 days of communication I find its
because they're on ie5.5 or something worse; and one feels compelled to
do it gratis.
I'm not going to rant - but yup you're right ted we have to - just part
of me wanted fifteen thousand developers to reply going "I agree, I am
hither too not supporting anything before ie7" - we can dream!
regards!
--- End Message ---
--- Begin Message ---
Daniele Grillenzoni wrote:
> 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?
Isn't it ironic that a post about multiple form inputs is posted four times?
That's not a good way to make friends here, Daniele...
I really don't understand your complaint - in general if your form has multiple
inputs with the same name, then you either meant to do that, (like a multiple
select, in which case there's not really a big deal to add the []),
or it's wrong and wouldn't work as expected anyway.
You could append [] to every input - that would be lovely, but it would hide the
possibility that you mistakenly gave two inputs the same name.
It's true that every so often I can't work out why something is not posting an
array to PHP when I expected it to, and a look back to the form to find I'd
missed a [] on the name is the answer.
As I like to say in other areas of life (especially to my children), "stop
whining and get on with it!" ( sorry :) )
--
Peter Ford phone: 01580 893333
Developer fax: 01580 893399
Justcroft International Ltd., Staplehurst, Kent
--- End Message ---
--- Begin Message ---
Skip Evans wrote:
> Hey all,
>
> I have a SQL requirement I'm not quite sure how to compose.
>
> I have two tables, shows, and shows_dates. It's a one to many
> relationship where there is a single entry in shows and multiple entries
> in shows_dates that list each date and time for a play production for a
> run of entries in shows, like
>
> I need a query that will read each record in shows, but I only want the
> first record from shows_dates, the first one sorted by date, so I can
> display all shows in order of their opening date.
>
> Not sure how to grab just the first record from shows_dates though.
>
> Hint, anyone?
>
> Thanks,
> Skip
>
Join the two tables like you normally would do and aggregate the opening
date column with your dbms-specific max function and finally group the
result by a distinct value from shows.
It would have bee easier if you stated which rdbms you use ...
--- End Message ---
--- Begin Message ---
Skip Evans wrote:
> Hey all,
>
> I have a SQL requirement I'm not quite sure how to compose.
>
> I have two tables, shows, and shows_dates. It's a one to many
> relationship where there is a single entry in shows and multiple entries
> in shows_dates that list each date and time for a play production for a
> run of entries in shows, like
>
> I need a query that will read each record in shows, but I only want the
> first record from shows_dates, the first one sorted by date, so I can
> display all shows in order of their opening date.
>
> Not sure how to grab just the first record from shows_dates though.
>
> Hint, anyone?
I guess this should work in most databases, it does in MySQL:
select q.name, min(q.date) as firstdate from
(select s.id, s.name, d.date
from shows s, shows_dates d
where d.shows_id = s.id)
as q
group by q.id
order by firstdate;
A left join in the sub query will also grab the shows for which no
shows_dates row exist:
select q.name, min(q.date) as firstdate from
(select s.id, s.name, d.date
from shows s left join shows_dates d
on d.shows_id = s.id)
as q
group by q.id
order by firstdate
--- End Message ---
--- Begin Message ---
Is it possible to set a parameter in PHP 5 to ask the interpreter to
raise an error every time I try to use a variable that wasn't
initialized before ?
For example, I've write this piece of code in Python:
print(DonaldDuck)
I get this error:
Traceback (most recent call last):
File "/Users/Cesco/Desktop/prova.py", line 3, in <module>
print(DonaldDuck);
NameError: name 'DonaldDuck' is not defined
Until now I've seen that when I write this PHP equivalent:
echo($DonaldDuck);
When I try to run it, the PHP writes a blank string, because the
variable is not yet initialized and PHP assumes that its value is an
empty string (I guess)
I'd like to have the same behaviour of Python in PHP, do you think
that it is possible?
--- End Message ---
