https://bugs.documentfoundation.org/show_bug.cgi?id=166835
--- Comment #11 from Eyal Rozenberg <[email protected]> --- (In reply to Heiko Tietze from comment #8) > 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 believe this is a similar concern as the one jan d raised: What constitutes an "incompatible change"? Please see my reply to that in comment #10. > 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. I did not quite understand the end of this sentence. I will say that a 'Benjamin' user will likely not open plain text documents in LO Writer. But it's not inconceivable Benjamin would open a CSV for editing in Calc; or Markdown in Writer. And he may well do some formatting not supported by the file format. > Expert users probably not invest "hours of working" ending up in being > surprised on save. That is partially true. If we don't think of Expert as a binary - it is quite possible for a user to work on commented tracked change to a DOCX he got from a collaborator, and only save his work after, say, an hour or two. > 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. First, this feature is not about _applications_, it is about file formats. It's true that some formats are associated with applications, like DOCX, PPTX etc. But: CSV, TSV, plain text, Markdown, HTML - those are not app-associated. Regardless - your point is a Red Herring. You see, this feature is only about the case of editing non-ODF formats. When a user is editing an ODF file, or creating a new file - this whole issue is irrelevant. This feature does not in any way encourage _more_ work with non-ODF formats (nor less) - it's just about what happens when users choose to edit them. (In reply to Telesto from comment #9) > I fully support this in principle. Would give more freedom, instead of > constant compromising functions and such on foreign formats. And well file > formats become probably less of an issue with cloud solutions. Same point as I was making to Heiko. ODFs are great - but this bug is about when you're editing other things. And some formats are just not that rich - nor should they be. Would you suggest people use ODS instead of CSV or TSV for unformatted tabular data? Or that Markdown is a useless format? Surely not. -- You are receiving this mail because: You are the assignee for the bug.
