Leave the first line of text empty in your text/csv tiddler and you’ll have a plain table with no stylized header row. Because sometimes the first row is not the header, but the data itself.
(empty line)
data,data,data
data,data,data
type: text/csv
I didn’t know text/csv was even a thing! 
It’s one of those less obvious things of TW, I think because the “type” menu doesn’t include it.
Incidentally, you can also embed text/csv in normal wikitext like so:
$$$text/csv
a,b,c
1,2,3
4,5,6
aye,bee,cee
10,22,42
$$$
(and likewise leave the top line blank to be headerless)
Now, that’s a useful post and it opens up new possibilities.
Typed Blocks in WikiText: https://tiddlywiki.com/#Typed%20Blocks%20in%20WikiText
Thank you Nemo and Justin.
A
reading that now I discover embedded SVG can be $$$.svg, but (after testing) nope for $$$.csv.
Why is text/csv a second class citizen?
It isn’t. It is a wooden soldier …
Because a tiddler with a type: text/csv can not handle any eg: wikitext links. Because it needs to be type: text/vnd.tiddlywiki to render eg: links
PS
I did create a PR Add a CSV Table as Example to Typed Blocks in Wikitext by pmario · Pull Request #9318 · TiddlyWiki/TiddlyWiki5 · GitHub which adds the CSV table example to the docs and improves the docs wikitext a bit.
huh? Granted the background to my question was spread over a couple of comments so wasn’t entirely clear, but I never brought up wikitext interpreting as a concern.
So to bring it all together. My question is about why text/csv isn’t included in the “type” menu, and secondarily, why there is no .csv shortcut for text/csv typed blocks (analagous to .svg being a shortcut to image/svg+xml)
Items listed in the “type” field editor are tiddlers with the $:/language/Docs/Types/ prefix.
It’s possible to add new predefined types, by cloning https://tiddlywiki.com/#%24%3A%2Flanguage%2FDocs%2FTypes%2Fimage%2Fsvg%2Bxml tiddler for example, and adapting its fields values.
I couldn’t find how the extension shortcut works for typed blocks though.
Fred
Only the basic elements are part of the core type-dropdown.
As I can remember. There have been more. We removed them because they where confusing for many users.
The CSV parsing utilities have been extended 3 years ago. They have not be registered in boot.js in the right way. I think we can consider this an oversight / bug. (I’ll create a GH issue)
Lets us confront the fact that the type field, mime types, handling new and altertnative ones and hackability are all a dark art in TiddlyWiki and sadley neglected.
I have come up against this wall a number of times and wastyed many hours trying to extend the functionality for a number of specific use cases.
that seems a shame! It feels to me it could be quite powerful for TW to understand many more types.
The loss of CSV from the menu for “avoid confusion” makes sense, however it means it’s completely undiscoverable through using TW, which seems a step too hidden.
A toggle to switch between a basic UI and an advanced UI (that would reveal this, and presumably other things could be worth making the basic/advanced distinction) would be neat to solve that, but adds to the coding overhead 
I can delve back into this subject and provide more details and methods. tiddlywiki is extensible but this aspect is not well documented so it’s like pulling teeth sometimes.
I mentioned offline to look at the JSONMangler plugin, it introduces some additional CSV support.
some types appear after importing files of a particular type.
I will have a look again, a research effort and share what I re-find.
I just spent some time, and once again find it anoying. There are inconsistencies and gaps arrising.
Dont expect a responce too soon, sorry. Maybe someone else with recent expierence.
