I’m not totally sure they are separate kinds of structure. A Scrivener project has Chapter, Section, Body, Note sections, to say just a few. Each of them corresponds to a structure’s level in an outline. Not so different than what most wordprocessors call a paragraph style.
Are you kidding? And what about the pleasure of taking the merit of convincing you to add a particular feature? 
Paolo
Ah, but what if the discussion makes me change my mind and not add it after all?
Paolo! Look! A rabbit!! Over there! Quick, let’s go see if we can find it and let Keith get back to his work uninterrupted.
Sorry, but i don’t understand your advice.
Can you explain again to me in a more simple way?
I have a 3000 pages document.
Every 3 lines, style changes.
I have 15 styles in the document.
I know that i can change style to all instances of a text.
But when text comes out from Scrivener, how can i tell to Scrivener to go out with 15 styles? (so to be able to change them later)?
My identity was stolen! Some hacker faked my identity and wrote all the messages above!
Now, excuse me, but I must look after that rabbit…
The Real Paolo
Paolo, I think we are talking about different things. Of course the concept of stylesheets has been around for longer than Word has. Not even early desktop publishing packages can claim to have originated that.
What I was referring to, and how Word changed the way people expect to do “word processing” is the notion that word processing should be done in a desktop publishing (even if only partially conceived) environment where one looks at text using systems designed to produce its final outcome, rather than, to a modest degree, what generates that outcome, like in WordPerfect 5. That’s really where things forked for me and many other writers.
When it comes to stylesheets themselves, you don’t have to convince me of the usefulness of them. You wouldn’t have to convince anyone that prefers to not work in WYSIWYG, because that is all we have: strict separation between content and design. We are not publishing asterisks and [b]\emph{LaTeX codes}[/b], we are turning them into the final form using stylesheets. The debate isn’t over the system as a concept, but how you interface with it while writing.
The notion that the authoring environment should use paper publishing conventions (what I refer to as reader-centric) to display semantics is one that I don’t find creatively useful, and instead a hindrance. Whether your stylesheet literally looks like the book you will buy off the shelf or not is beside the point. The point is I don’t want even the vague premise of fonts and formatting to be used to signify semantics. I find that wildly over-complicated. It’s the million dollar solution to fixing pens in space when grease pencils will do just fine.
I’m not sure why you have a problem with that term. Italics are used for publishing, as is bold, indentation and all of these things. That is the whole point of them. We did not use them for writing until very recently. It’s okay to say you prefer using publishing tools designed to make reading easy, for writing. That’s what Word people like—nothing wrong with it.
Right, but this is relevant to both systems of writing. I don’t see how that helps you any more than me. If we wish to conform to standards, we both have to start and stop semantic ranges in the appropriate place. I would argue, from opinion, that writing in a symbolised environment makes it much easier to proof for mistakes, and much more difficult to make mistakes in the first place, since you can actually see where semantic ranges start and stop. You can’t with rich text because whitespace is not coded.
To come back to my original statement: this isn’t a right or wrong debate. This is a matter of author’s preference. Some prefer to use a stylesheet that looks like what their agent wants, some prefer to use an emphasised stylesheet in a word processor that is intentionally not accurate like my red text = italic example, some prefer Scrivener type systems which are a bit of a hybrid between desktop publishing and structured writing, some prefer to write using plain text and symbols, and among them there are many dozens of different schools of thought on which plain-text system as best, too. Troff, XML, LaTeX, DocBook and abstracted formats like Markdown or Textile that can produce these other more technical formats—there are all of these different systems because at the end of the day when each of us sits down to write, we do so in an environment we have created to best suit our habits and desires. When we’re done, we all produce something using familiar reader conventions like italics for emphasis, or big bold letters for titles.
There is no room in that for a flat declaration, such as: visual is better than symbols.
Ok Amber, i made some trials and i could realize your advice.
First of all, thanks, because it was a clever advice and very useful.
So, my only important thing is to have different presets in Scrivener.
It doesn’t matter how they look, because i can change in an instant in Scrivener.
The only important thing is that they should be the same for every future style i have in mind inside Word.
So came my next question: would it be nice to have in Scrivener the same option you advised me in Word?
I mean: being able in Scrivener to search for same instances of text (i mean font, size, intend etc) and change all of them in Scrivener too?
This would be useful when i import in Scrivener a work form Word, so when i start to work on it in Scrivener i’m sure to make all the same instances with the same preset.
KB, just a question: can you reveal (even in little part) the way SN will handle styles (in the next versions and when will it happen, more or less)?
Just to know how to move and direct our work for the future.
Tks for all,
Raf
(Sorry if I get too geeky here, I’m a web developer by trade…)
TL/DR; Rather than using RTF and word processor like formatting toolbars, Scrivener should use HTML, limited to a subset of HTML elements and user-named classes, and then use user-controlled CSS to style them. This would allow users to focus on the writing rather than manually adjusting the formatting in each text file as their preferences or needs change, and would neatly solve a whole slew of export issues related to formatting.
I’d love to see Scrivener use HTML internally rather than RTF.
The problem with styles in word processors (including Word) is that they offer both arbitrary styling and named styles simultaneously. This undisciplined approach results in an unmanageable plethora of auto-generated styles.
I’d actually love to not have menu options for directly selecting the typeface, font size, line spacing, etc. Instead, for any given block of text (at a paragraph level and at a phrase/character level) I would just select the general meaning of the text (heading level 1, heading level 2, paragraph, etc.) and a more specific meaning that relates to my document (e.g., heading 2: slugline or paragraph: dialogue).
Then, the user would have a separate interface to map each general/specific meaning (aka HTML element and class) to its formatting, and ideally be able to load and save those settings at will. As a user, I could, say, have one stylesheet for editing on my large desktop monitor, another (with a larger font) for my Macbook Air laptop, and another (with reversed colors) for writing at night.
The hardest piece to implement would be converting RTF-based text in existing Scrivener files, or text pasted into Scrivener (which will come into a WebKit or similar control as nasty style-heavy HTML). For that, I think Scrivener would need a user-controlled “format scrubbing” routine. In other words, let the user choose whether pasting will ignore certain format types (for example I would almost always ignore font name and size) or if it will attempt to match the format to an existing class (and auto-create a new P or SPAN class if there is no match).
Having that level of control would allow a user to either coalesce most of the incoming style down to the few things they care to maintain (such as bold or italic), or if they want something closer to the original, deal with the fact that it may require creating some auto-generated classes with meaningless names.
Geek-out points:
(1) It would be super-awesome if Scrivener’s UI for formatting each element/class combination also had a box to directly type in some CSS. This would allow you to focus the UI on CSS styles that correspond to current formatting options, while allowing advanced users to do fun things like making a character names always appear in uppercase (using text-transform).
(2) HTML like this would be super-easy to convert back and forth to Markdown/BBCode variants.
(3) In many situations where an HTML-based export format is needed (such as EPUB, or posting to a web site with its own style), you expressly don’t want most of your formatting choices in Scrivener to end up in the exported document, but you do want to export the difference between headers and paragraphs, or the fact that a phrase is emphasized (i.e., probably but not necessarily should be italicized).
(4) HTML is much more extensible than RTF for tagging Scrivener-specific stuff like footnotes and comments to particular blocks of text. And using fancy CSS selectors like :after, you could style in some things like icons for footnotes, paragraph symbols before line breaks (like Wordperfect “code view”), etc. without them being actually stored in the text. WebKit does all the hard work.
Oh, one more really cool thing about using a restricted form of HTML plus stylesheets – it would be just as useful as MultiMarkDown for compiling to any workflow, but with WYSIWYG formatting rather than the “I’m-editing-a-Wikipedia-article” look.
And for those who want to still use MMD, translating back and forth would be a breeze.
I will add my two bits here and say that without styles there is very little I can do with the otherwise very powerful Scrivener. I write fiction and drama and although some will accept pdfs for submissions, virtually all of them accept .doc and .docx. And I format and write with styles all the time. A further suggestion is that the import and split function — a real cool feature — would be much more useful to me if it could import based, not on adding has marks, but using styles from Word. I think anyone not using styles in Word, or things based on styles, like navigation pane, is missing very powerful features that I hope are built into Scrivener soon. I’m on 3.2.2 and have yet to seriously use it.
This thread is nearly eight years old, and has been overtaken by events. Scrivener 3 includes true Style support.
Hi,
Import and Split already recognises Word styles — File > Import > Import and Split…, make sure Options is selected, then tick Split using the document’s outline structure. This will create a binder hierarchy based on the Word document’s headings styles.
NB: you have to select a suitable document in the dialogue box (i.e. one with styles, like .docx, .md and so on) before the option will appear.
BTW, Styles were a major enhancement for Version 3, but there are other significant differences from older versions. It sounds like you haven’t yet had a chance to do the Interactive Tutorial (on the Help menu) — it really is highly recommended that you do this ASAP. It won’t take long (about an hour or so to skim through — less if you only look at the ‘What’s new in V3’ collection) and you’ll make much better use of the program much quicker than otherwise.
HTH.
Scrivener styles are real, and they’re more powerful than Word styles.
I think Scrivener styles could be seriously improved. I appreciate the support introduced by Scrivener 3 very much but I hope the next version will enhance them. For example, I would like to be able to rename them or to directly edit the style, instead of updating it from existing format.
Both of these things are already possible:
Format ▸ Style ▸ Styles Panel.If you didn’t need the sample text formatted that way, if you set a paragraph specifically for this purpose, then just reset it with the No Style setting. No harm no foul, it’s like closing a dialogue box in terms of how much “weight” the action has on you.
Or if you’re like me, you have a dedicated text item in the binder that is a full design sheet, where all of the styles can be tweaked in context with normal text and other styles, since trying to design in isolation or dialogue boxes is awkward and prone to endless cycles of going in and out of settings. Here is an example of what one of mine looks like:
Obviously, this stylesheet is aimed squarely at pure writing, but even for something that isn’t a design design, it can be nice to see how the styles are all meant to fit together visually.
And since this is a document in the project itself, if I want to tweak the way something looks, I do it right there in a designed environment, redefine the style, and the whole project updates behind the scenes.
…I would like to be able to rename them or to directly edit the style, instead of updating it from existing format.
So by the above definition, to my mind anyway, this is very much an approach of designing directly, and the notion of whether you are using an “existing format” or not to do so is somewhat artificial at that point.
Hopefully this won’t derail this thread, but… is there any way to make those styles “survive” a plain text sync (and edit somewhere else)? I suspect: No. But I had to ask!
I think this thread is well and truly derailed at this point anyway, seeing as how it started in 2013 about four years before Scrivener had styles on the Mac, and eight years for Windows. 
But no, they are purely aesthetic for my purposes, most of them don’t even have a function through the compiler. For styles to survive some kind of a plain-text sync or round-trip you’d need a whole markup system built for it.
Thank you very much for your message. I completely agree: Scrivener is for writing taks, not for design. I have an acceptable workflow to transfer the projects to desktop publishing software for the design. Anyhow, in my opinión Styles could be improved. For example, live autonumbering (I use <$n>, of course) or language definition to have a more flexible spelling.
