Firstly as far as I am aware, you cannot include HTML elements as part of an address (which is what the mailto protocol forms) due to how it would be interpreted (though you could probably use CDATA characters (& for example) to work around this problem. However as to the issue with the length of mailto, there is a fixed and standardised maximum length an address can be (whatever protocol it origionates from) and you are simply pushing the technology past its intended usage. Simply put, you cannot use mailto in that capacity and quite frankly you should not be using mailto in the first place, you should be using a customised HTML form to send emails with predefined content (or large amounts of data to fill in).
This would be a handy link, but there are two important challenges.
First, you need to encode any reserved characters used in the URL. For example a line break must be encoded as “%0D%0A”.
Second, you don’t know which mail client will be used, so the rendering of HTML is unpredictable.
If implementing the functionality myself, I’d use a link that brings up an editor and/or sends the email from phpmail or a server side technology. You may have additional requirements.
The reason behind doing this was lazyness! The table needs to be either printed or emailed - using maito would allow them to create the email and print it off if required. I’ll have to stop being lazy and do it the proper way I suppose
First thing you’re running into is probably the max allowable length of the query string.
Probably the best way to handle it is on the server end. Have an “email report” link on the page, and when that link is clicked the query that produced it is posted to the server, which takes the results, formats it into an email, and sends it.
You’ll need some security in place to keep other folks from hijacking it, but that’s what I’d start looking at.