First, Causality is awesome. I use it exclusively to build content and structure. It’s the best tool out there. But… once I’m at first draft, I’ve got to export into other formats for review, etc.
When exporting to HTML, the output could really benefit from style sheets (CSS). Much cleaner, and it allows us to easily change styles and format. (And, this change is easy to code on your side.)
When exporting to Final Draft, it would be excellent if beat titles could carry across to FD scene titles. It’s a hassle to cut and paste all those over to FD. And, if it could bring the beat color over to the scene, that would be handy also.
About the HTML export, if I remember, the goal was for this to be able to become an email, for which using CSS is typically on thin ice, because email client support is spotty, so all the formatting was put inline. Every formatted email you receive has the formatting inline. And this also allowed it to be imported to Word keeping formatting. I think I would still vote for having the formatting inline, but possibly also tagged well enough for CSS classes that CSS could be done in parallel.
About the Final Draft beat titles, a core concept of Causality is that beats are not scenes, and a scene can contain multiple beats. So while it’s possible for you to use Causality in a way where one beat is exactly on scene, it wouldn’t be good to impose that limitation on all users by coding for it. At best, the beat titles for the beats in the scene could be merged into one combo beat title, which is then exported. My problem with that is that it’s lossy, and irreversible, and is likely to be a surprise for someone.
If this is purely about review, wouldn’t it be better to export a PDF? This has elaborate configuration for how to include all the elements. Beat titles even have their own font formatting, so that they are mixed in with the text in the scene.
On HTML, it would be cool to make CSS an option on save. For now, I can write a script that replaces the inline formatting with CSS.
On Final Draft import, I guessed your answer in advance! Beats != Scenes. But, even if it just used the first beat title, that would be decent. Concatenating the beat titles also works because (in my case) nearly all scenes are single beats. (Yeah, I know, but that’s how I work.)
I ultimately solved my problem by exporting to FD, then exporting from FD into the format I needed. Not optimal, but hey, it got the job done.
If you’re wondering the rationale behind all this, it’s that my review distribution is in HTML to allow immediate viewing across all devices. On many devices, PDF requires a file download. With HTML, that step is eliminated.
I’m glad to see someone using the HTML feature for review, because it was made for it, but we weren’t sure if it was useful to anyone.
I’ll put it on the list to make a CSS export. We’d probably have to make a selector for whether to use CSS or inline formatting, because the inline formatting would override the CSS unless you strip it out. It’s obviously not a difficult feature to do (you could whip up a converter quickly), so the only thing holding it back is that 100 of such features still take significant time away from bigger initiatives.
About your converter, are you simply moving the inline styling over the CSS? Or are you making different styling? Since this feature isn’t for me, it’s better to ask someone who’s going to use it.
We have a strong bias against manual formatting such as forced line breaks, because it doesn’t work when the text is formatted differently. For starters, it doesn’t work for using differently sized margins (Squeezed and Super-Squeezed), where text will start wrapping poorly.
We’re very keen on line breaks coming from text wrapping and nothing else. Other things that depend on that are Kindle output, emailed script snippets, switching A4/Letter paper size, subtitles over animation, and more. Basically, the app becomes handcuffed when it has to expect that text can’t be reformatted. We really want it to work like responsive web design where the text automatically formats to whatever device it’s viewed on.
The way to mostly get what you want is to edit the Action paragraph style and not have space before/after. Then Action becomes single-line, and then every Enter makes a new line on the very next line.