STL comes in 2 flavors: ascii and binary. Binary uses 32-bit IEEE floats for X,Y,Z coordinates, and presumably any ascii STL file will be read-converted into internal 32-bit IEEE floats, as well. There are 2 problems with using floats for STL: writing & reading. If you've built a "watertight"/"legal" 3D model with _rational_ coordinates, the mere rounding from rational to 32-bit IEEE binary float coordinates could make the "watertight"/"legal" model into a non-watertight/illegal model due to "interference" from one portion of the model intersecting with another portion of the model. However, even if you have a "watertight"/"legal" model whose exact coordinates are specified with 32-bit IEEE binary floats, some (most?) reader(s) used to read STL files may incorrectly determine that the file isn't watertight/legal, due to _imprecision_ in the computations used to check watertightness/legality. I've been considering building an STL "writer" which is capable of "relaxing" the positions of X,Y,Z coordinates just enough to keep watertightness/legality when read by these inferior readers. However, this is a large amount of work, both the write the code and to compute the relaxation. It would be better to have "design rules" which would enable the automatic generation of always-watertight/legal STL models in the first place. I have already built an STL reader which is bit-exact. However, checking watertightness/legality in a bit-exact manner is quite computationally intensive. It is conceivable that such checking is necessarily computationally intensive, because the denominators may multiply into extremely large numbers if they are relatively prime. At 12:37 PM 11/16/2013, Bill Gosper wrote:

...

For 3D stuff, "STL" format is very popular, but I don't know if there are any STL plugins for browsers yet.

STL is perhaps the only pathway from Mathematica 3D polygons to NeilBs 3Dprinterware. Mma's exporter uses an atrociously inefficient and illegal triangulator that sorely tests Neil's patience and skill.