The idea of ignoring all formatting, and applying a standard to all text is inspired, but as soon as the user wants to have some different formatting, this breaks down.
The concept of style sheets, as used by Word, OpenOffice, and other editors, is genius, and you should consider incorporating it. Currently, if I want to change the formatting of, say, block quotes, I need to search through my entire document, find each one, and select the new formatting. If I had a “Block Quote” style, I could change that, and immediately modify the formatting throughout the document.
Also, the pulldown menu for formatting can’t convey all of the formatting information, making it less useful.
You could highlight the desired passages and select “Preserve Formatting,” and then it doesn’t matter what the compile settings are, you would get the text exactly how it shows in Scrivener. Unless I’m misunderstanding what you’re trying to do?
This is definitely on the list for the future. Styles are more complicated to implement in Scrivener because they have to iterate across multiple documents, many not loaded into memory and thus which get changed behind the user’s back, as it were, but they are something that come up a lot and that we are definitely going to implement as part of a major update. They could still play well with Compile, with Compile perhaps offering the ability to override formatting by style, adding a whole new level of flexibility. It is going to take a lot of careful thought and a lot of code to implement them in the exporters, too, but style sheets of some form are a matter of when rather than if.
Also, related to this, it would be good if styles could be customized on a per project basis, which unless I"m missing something isn’t currently possible. (I imagine that represents another level of complexity.)
More immediately, a “style manager” window, so they can be dealt with without needing to repeatedly navigate a menu system would be nice.
EDIT: Ignore next paragraph… I see it is already there!
Likewise, a styles drop down (e.g., for the Formatting tool bar) would be very useful. Hmm… is that by any chance coming as part of the current update cycle? It seems it would/could/should be part of a basic implementation.
Unfortunately that would not be very useful to you, as HTML output (on both platforms) is generated by the text engines we are using. We didn’t actually code full RTF->HTML generators from scratch. We can make minimal adjustments to it, and this is done to provide a few special features here and there as well as to clean up a few known issues with the default output and make the CSS compliant with Amazon standards—but that’s all done with the all of the sophistication of search and replace, basically. That’s true for both HTML and CSS output.
The reason why it wouldn’t be useful to you is that the engine generates class identifiers dynamically as differences in the formatting are encountered during export. There would be no way of knowing that your block quotes or whatever just so happen to be “p21”, and even if you discovered that post-compile using Sigil, so much as rearranging a section in the Binder could cause that to become “p13” in the next compile, breaking your CSS.
My advice would be—if at all possible—to hold off on the meticulous design phase until you are quite done with the project and have compiled for the last time. Of course you will probably put out a revision in the future and have to start over with it, but at least then it is only something you are doing infrequently.
Yup, looked at the output with Sigil and Calibre hence my comment. I was indeed thinking of the final form compile of ePubs from Scrivener. Although I compile to ePub when proofing my documents (iBooks annotate is really useful for that) once the book is finalised I have to strip out all (and I mean) all the junk and replace it with clean and simple styles and one single CSS file that implements the publisher’s house style. If nothing else this junk removal reduces the size of the content dramatically.
Would the styles necessarily have to be live? I would have thought that all that is needed is to mark the text in some way to show which style is applied. The real stuff happens during compilation.
The compiler could then employ different ‘style sets’ depending on the compile target.
What about those who don’t override the formatting during Compile? The styles would need to be live and you would need to be able to override each style individually during Compile.
As Scrivener’s style and preset features are updated, it would be nice if they could have a “Followed by” attribute so that, for ex, hitting enter from inside Heading 2 always put you into Body.
I don’t understand why this would be a big deal. If someone changes the font for “block quote”, then Scrivener throws up a little “please wait” dialogue until it has updated all the documents in the project. If someone’s messing with fonts and indents, then they’re not composing, so it wouldn’t interrupt what they were doing, would it? Alternately, updating each document as it’s loaded into the editor, or even at compile time if it hasn’t been updated to the new block quote style would push those updates off until absolutely necessary.
Or am I lacking an appreciation for how styles would actually work?
That’s true for both HTML and CSS output.