How can I avoid my "hide/show" from being seen when my page first loads?

Head out to and you'll see the page that shows a working model of what I'm currently struggling with.

I've got a recordset that I throw in a temporary table and then break it into two separate recordsets, one being the even numbered ids, the other being the odds in order to facilitate a two column presentation. The page I have referenced above is just the resulting HTML, I didn't recreate the whole database dynamic - I've got that code attached. I tried a couple of different approaches, but the code that I have attached is what gave me what I was looking for.


When I run this from my live server, all of the "hidden" text fields show up briefly and then go away after the page has finished completely loading. What can I do differently that would allow the page to load a little more elegantly? Even if I had a little "loading..." verbiage on the page so it didn't look so clunky as it uploaded.

What do you think?

Here's my code:

	public function term_row_number() {
		global $mysqli;
			$sql=" SELECT * FROM `terms` WHERE term REGEXP CONCAT('^(the |a )?', 'a')";
				$err = 'your search query failed because: '
				.' ERROR:'
				.' and the epic failure we\'re talking about is: '
				trigger_error($err, E_USER_NOTICE);
			$the_letter = $_GET['letter'];
			$sql=" SELECT * FROM `terms` WHERE term REGEXP CONCAT('^(the |a )?', '$the_letter')";
			.'ERRNO: '
			.' QUERY: '
			trigger_error($err, E_USER_WARNING);
		//delete the current term_temp
		$sql_4 = "drop table term_temp";
		$query_4 = $mysqli->query($sql_4);
		$sql_3 = "CREATE TABLE `term_temp` (
		  `id` int(11) NOT NULL AUTO_INCREMENT,
		  `term` varchar(150) NOT NULL,
		  `definition` blob NOT NULL,
		  PRIMARY KEY (`id`)
		$query_3 = $mysqli->query($sql_3);
		//for whatever reason, I had a hard time ensuring that the term_temp table started with an id of 1, so...
		$sql_5="ALTER TABLE term_temp AUTO_INCREMENT=1";
			$sql_1="insert into term_temp (term, definition) values ('$the_term', '$the_definition')";
			echo $mysqli->error;

Open in new window

After I get the temp table loaded up with my recordset, I then create and display two tables, one being the odd ids, the other being the even ids.

We're looking at total of 500 rows, so even if there's a more elegant way of retrieving and displaying the data, my concern is that there still needs to be something that prevents the data from being displayed until it's ready to presented completely intact.

How can I do that?
brucegustPHP DeveloperAsked:
Who is Participating?
I wear a lot of hats...

"The solutions and answers provided on Experts Exchange have been extremely helpful to me over the last few years. I wear a lot of hats - Developer, Database Administrator, Help Desk, etc., so I know a lot of things but not a lot about one thing. Experts Exchange gives me answers from people who do know a lot about one thing, in a easy to use platform." -Todd S.

I'm not sure I understand 100% but if I do, you may consider putting your data into a containing <div> and give it an in-line style of display:none;

In you header or footer place:


    $(".Your Div Class Here").show('slow');      

That way the entire page will need to load before the dive shows up.
(Make sure you include the jQuery library.
The problem can't be solved in PHP.

If you set the style "display:none" on the class slidingDivTerms I thing your problem will be solved.
Because the div will be hidden right on the page load.
You must be hidding those divs in javascript or jquery when the page ends loading i guess.
So a few thoughts:

1. The answer to your question could be simple. If your web server is streaming data instead of buffering it, then you could end up with partial HTML showing up on the page before the page is fully loaded. Buffering can be a good thing, but it basically holds everything in memory until the page is completely finished loading and THEN everything gets sent to the browser. There are a variety of ways to buffer:

1a. If you enable gzip compression on the web server itself (e.g. if you're using Apache, you'd use mod_deflate,, this should automatically handle buffering on web pages without any code changes because in order to effectively compress data, the server needs to know all the data upfront before it can start compressing. So it buffers data, compresses, and sends it. The positive side effect of this approach is that you DRASTICALLY improve bandwidth and transfer speed. A 1-megabyte page of data can be compressed down to less than 100k, which can be transferred much faster. And it's all invisible / automatic to the user.

1b. If you don't have access to the web server configuration, you can still do output buffering in PHP (but you don't get the gzip compression benefits without some more complicated coding). Output buffering is pretty simple - just add one line to the top of your script:

The "ob" stands for "output buffer" - anything you echo or print - ANY output at all, will instead go into this buffer in memory and then once the page finishes, everything goes to the browser at once.

2. If the problem isn't output buffering but rather just an issue with the order of events in client-side processing, then you can put everything into a DIV that is hidden, then use an onload event (jQuery's document.ready is pretty easy to use) to show the DIV.

3. It looks like you're trying to create a temporary table, but you're really creating a regular table that is just NAMED term_temp. It's an on-disk database table. If you need to create a temporary table, you should probably use in-memory temp tables. However...

4. Temporary tables are almost always a bad idea. They should always be the VERY VERY VERY VERY VERY VERY last resort. There's almost always a better way to do things. What happens if two or more people request the web page at the exact same time? Someone will end up with errors, because that table will already exist and have someone else's data in it. Sure, you could create a dynamic name for the temp table, but table creation, population, and deletion is a pretty big performance hit. Imagine if you went on vacation somewhere, and instead of staying in a hotel, you built a brand-new house for 3 days, and then demolished it when you left. That's what you're doing in database terms.

You may want to open up a new question that discusses the overall goal and the best ways to accomplish it.

5. I think I understand what you're trying to achieve with the REGEXP in your query - if someone searches for terms starting with "a", you want to ensure that you're showing "the apple" and "an apple" (although you only have "a" and not "an"). However, this is a pretty heavy query on the database because the database has to look at every row and apply the regex to each one to figure out if it's a match.

A far better way to do it would be to pre-process the data in the terms table and either eliminate any pronouns (the, a, an, my, your, etc...) or create a new, indexed column that contains only the term without the pronoun (plus any other data processing like case sensitivity), and then search on that new column.

You should be able to do a new_column LIKE 'q%" in your WHERE clause, which should show all terms starting with "q". It would be FAR FAR faster to run, especially as the volume of data increases. It may not seem like a big difference on a small database with one developer, but the difference is night and day later on in a real environment.

Experts Exchange Solution brought to you by ConnectWise

Your issues matter to us.

Facing a tech roadblock? Get the help and guidance you need from experienced professionals who care. Ask your question anytime, anywhere, with no hassle.

Start your 7-day free trial
500 rows in two tables with scripting is going to be a problem because table generally need to passes to be rendered, and if there is also scripting that makes the rendering even slower because when script is encountered during parsing, the parsing is suspended  until the script is finished executing because it may have to go back and modify layout.  The problem is that the layout is table based and the rendering engine is completing the layout and flow steps beforee all the styling is complete so it displays the layout and then has to wait for the style mapping to be completed.

The solution of using non-table elements will eliminate the double pass, but you could still have a problem if there is a lot of line scripting and you might then have to go to using defer on the scripts so thst they do not execute until parsing is completed.  That way both layout and painting should not experience enough of a delay to cause a problem.

brucegustPHP DeveloperAuthor Commented:
rgranlund - sweet little approach! Thank you!

Gonzo - thanks for taking the time to elaborate like you did. Your counsel inspired me to revisit what I had done and it was then that I was able to determine that the temp table that was supposedly being deleted with every session, wasn't being deleted at all. So instead of having to process a couple hundred rows, after several rounds, there were thousands upon thousands of rows to be process which is why I was seeing the delay.

Once I remedied that nonsense, we were gold.

Rock on!
Question has a verified solution.

Are you are experiencing a similar issue? Get a personalized answer when you ask a related question.

Have a better answer? Share it in a comment.

All Courses

From novice to tech pro — start learning today.