https://bugs.documentfoundation.org/show_bug.cgi?id=166835
--- Comment #8 from Heiko Tietze <[email protected]> --- (In reply to Eyal Rozenberg from comment #3) > It's the fact, for at least one change - the first format-breaking change, > the user will be _fully_ aware of what they're doing... Another example: You can direct format text as bold or via character style, both are saved as <b> to HTML (and I would argue this is always DF). IOW, you have a technical perspective on data and a user POV, depending on expertise and workflow. If you warn the first time about "styles are not stored with HTML" users might not care but if it comes to another incompatibility they will for sure. So you have to do it for every single attribute. Same argument in comment 5. I doubt the use case of Benjamin loading an "extra format", something that is not primarily suited for text processors or spreadsheet apps like html, rtf, csv etc., expecting a different function set works the same way. Expert users probably not invest "hours of working" ending up in being surprised on save. When it comes to "similar formats" like odf - docx, we should rather aim for 100% compatibility - and still get into situations where the proprietary format has its limitation. More generally: Why do we always care about other applications? We should proudly present our work and only secondarily consider other tools. User running LibreOffice are supposed to work with ODF - period. -- You are receiving this mail because: You are the assignee for the bug.
