Hi, I'm sure that this part of the development is even more complex than other aspects... But sooner or later we'll get to using style sheets anyway... So, why not make steps in that direction... or even leaps... The Master Document already implies that style sheets as such do exist :) Only we call them templates, still. I guess, based on just a superficial glance, that there are styles that are mandatory for any Writer document. This is what makes it (at the moment, still) hard to make a step toward bare documents with default style sheets... (instead of templates) Templates and style sheets (or styles) are totally different things per def. A template has content elements. It's a page with some elements already in it. A style or a bunch of them is something that you apply afterwards, when some content is there. Totally different functionalities. Therefore, one day or another, it will be necessary to dump template culture and start the new style sheet culture, which will be cleaner and simpler, like HMTL5 compared to html4... This evolution could begin with style sheets... meaning: • being able to export them • being able to import them • being able to edit them, including copying and pasting sections fro one to another... THIS would, I guess, need • the phenomenon of the bare document • the set of basic styles that are mandatory to have for any document • establishing two views for styles: |-> an advanced view with all the style details, without the editing option |-> the "simplified" (valid / practical) view... with editable aattributes ------ RIGHT now, as I see, the style sheet as such already exists, as styles.xml However, it's pretty messy as it is, especially with all the Asian stuff... see: <style:text-properties style:use-window-font-color="true" loext:opacity="0%" style:font-name="Liberation Serif" fo:font-size="12pt" fo:language="hu" fo:country="HU" style:letter-kerning="true" style:font-name-asian="SimSun" style:font-size-asian="10.5pt" style:language-asian="zh" style:country-asian="CN" style:font-name-complex="Mangal1" style:font-size-complex="12pt" style:language-complex="hi" style:country-complex="IN" fo:hyphenate="false" fo:hyphenation-remain-char-count="2" fo:hyphenation-push-char-count="2" loext:hyphenation-no-caps="false" loext:hyphenation-no-last-word="false" loext:hyphenation-word-char-count="no-limit" loext:hyphenation-zone="no-limit"/> What I see as a layman is that opacity, for example shouldn't be defined within a style. Not to mention the Chinese and INdian references... and Hyphenation methods... which also should be defined per section, whatever... "font language" also seems made up... etc, etc... I mean, there's a lot to do to get to using styles... as style sheets... I wonder if it will ever happen? (When I started this post, I thought if was about 1000x simpler to achieve the goal, exporting and importing style sheets. Now even I can answer: yes, it's a very long way to go.) - - - thank you for developing libreoffice and writer - - -
We are bound by what ODF framework supports, all other styling schemas need filter based translation--import and export (and why our CSS is not native and integration of HTML5/CSS3 is missing, see also bug 95861). Template ODF documents (nothing to do with the Master document .ODM) is much more efficient to store and exchange style details. Trivial to describe minimalistic ODF archives (especially with ODF Flat XML) as containers of styled paragraphs, tables, page layouts that can be applied to new documents or pasted as new elements on an existing document (opened in any of the LibreOffice moduels, not just Writer). So, beside improving the import/export *filters* for HTML5 and CSS (2.1 or 3) and a browser like "Web" viewing of that rendering, how much advantage is there really to implementing something more than current ODF template documents to hold applicable ODF styling? Not seeing a need to split out handling of our ODF 1.3 compliant styling--too much dev work for something that would be alien to all external "style" implementations, W3C CSS or other. Template archives are enough.
(In reply to V Stuart Foote from comment #1) > Not seeing a need to split out handling of our ODF 1.3 compliant styling... Nor a good use case that makes it necessary. Thanks for your input anyway, Peter!