The HTML export/import filters need a refresh to implement better mapping to HTML-5 and inline CSS-3 style to allow better fidelity in ODF renderings. Writer Web as an HTML editor was broken at 4.2 with bug 48887 and bug 63211 So we are overdue for adding additional tests--is output an email mail merge? otherwise retain links. That would revert issues of lost image linkage to embedded images and return HTML edit capability. But to regain relevancy as a simple and convenient HTML editor, we need a rework of the filters to implement HTML5 markup and inline CSS3 styles.
Should libreoffice even aspire to be an HTML editor?
@David T., * >Should libreoffice even aspire to be an HTML editor? It is not an aspiration, rather seeking to restore that capability. The HTML Web component remains implemented--and its "source view" mode was a pretty convenient WYSIWYG editor for HTML 4 and inline style I believe back to StarOffice era. Are you suggesting we strip it all out and concentrate on XLST export only? While that is probably valid, I'd like to think there is still a need for visual HTML 5 markup with inline CSS3 and presenting that markup as WYSIWYG.
(In reply to V Stuart Foote from comment #2) > @David T., * > > >Should libreoffice even aspire to be an HTML editor? > > It is not an aspiration, rather seeking to restore that capability. But do we want to restore that capability? Does libreoffice need an internal HTML editor? (Note I am not talking about HTML import/export.) > The HTML Web component remains implemented--and its "source view" mode was a > pretty convenient WYSIWYG editor for HTML 4 and inline style I believe back > to StarOffice era. > > Are you suggesting we strip it all out and concentrate on XLST export only? I suggest we strip the whole Web module out. The HTML import/export should stay. (As C++ code--XSLT is IMHO completely unsuitable for the heavy processing that is needed to convert ODF to HTML.) > > While that is probably valid, I'd like to think there is still a need for > visual HTML 5 markup with inline CSS3 and presenting that markup as WYSIWYG. I don't disagree with that. What I disagree with is the need to have that HTML 5 WYSIWYG editor inside LibreOffice.
> I suggest we strip the whole Web module out. I agree wholeheartedly. > The HTML import/export should > stay. I would kill even that. Or at least keep it just one way, so people don't try to be clever and roundtrip a document (export, then later import, edit, repeat). Or would that work so incredibly badly anyway that nobody would be crazy enough to do it?
I agree with keeping HTML Im- and Export since it is a format that allows to structure texts well and can be read almost everywhere. I also think we should not aim for WYSIWYG editing. From a usability point of view, it would be great to have some usecases for Im- Export as well as the WYSIWYG in order to clarify our assumptions about the (un) usefulnesses of the features.
Hmm, David and Tor have a lot more weight than I, if you can get the ESC to agree--then *please* strip out the Writer/Web mode! The now broken support for HTML 4 leads only to frustration with trying to maintain style based markup using LibreOffice. On the other hand, isn't there current relevancy to CSS3, and a need to support emerging W3C "standards" for layout? In parallel to OASIS and ODF 1.2/ODF-Next? ODF(s) and XHTML 2.0/XHTML5 are not mutually exclusive. It is hard, but why would that GUI support not belong for users in LibreOffice?
(In reply to David Tardon from comment #3) > (In reply to V Stuart Foote from comment #2) > I suggest we strip the whole Web module out. I have just seen this proposal here to remove Writer/Web (web view and HTML source view) https://wiki.documentfoundation.org/Proposals_for_removing_features#Writer.2FWeb I oppose the removal of the web view and HTML source view/editing. It is a quite handy feature, which I frequently use and really like. I am quite sure that other people are using it, too.
(In reply to Gerry from comment #7) > I oppose the removal of the web view and HTML source view/editing. It is a > quite handy feature, which I frequently use and really like. I am quite sure > that other people are using it, too. What do you use it for?
(In reply to Tomaz Vajngerl from comment #8) > (In reply to Gerry from comment #7) > > I oppose the removal of the web view and HTML source view/editing. It is a > > quite handy feature, which I frequently use and really like. I am quite sure > > that other people are using it, too. > > What do you use it for? Gerry posted his use case here: https://wiki.documentfoundation.org/Talk:Proposals_for_removing_features "I have all documents in Libreoffice (including all their layout and formatting, of course). It is very handy to move (parts of) documents over to Writer/Web, switch to HTML source code, edit/refine the source code, switch back to Writer/Web view to see how it looks, switch back to source code and copy the relevant part of the source code to use it further for websites or CMS. In my opinion, only the tight integration with the office suite allows to not lose formatting in this kind of workflow." Usually CMSes include embedded WYSIWYG rich text editors like CKEditor or TinyMCE. If there are problems with the CMS editors accepting pasted formatted content from LibreOffice, bugs can be filed against them. Writer/Web cannot be used as a reliable preview of how something looks like in a browser and to bring it to such a state would require a huge investment of developer resources. We cannot compete with the developer tools in browsers. Honing them has taken dozens, probably hundreds of man years. Interaction with JavaScript, responsive design etc. - there is no way we could implement this. We should not try to compete with desktop WYSIWYG editors as they are very niche and ill-suited for web design and development. If they wish, developers can shed light on the technical challenges regarding a decision to amp up our HTML WYSIWYG capabilities.
This functionaly would be helpful for some other functionality such as EPUB and SVG. EPUB is surely using HTML based structure and CSS styling, SVG 2 is including integrations CSS, HTML5, and WOFF, our improves on HTML filters would be better for these formats, especially we integrated this filter for those filters. Additionaly, I suggest we can try to rework of the filter to rebased on a maturing backend such as WebKit.
This functionaly would be helpful for some other functionality such as EPUB and SVG. EPUB is surely using HTML based structure and CSS styling, SVG 2 is including integrations CSS, HTML5, and WOFF, our improves on HTML filters would be better for these formats, especially we integrated this filter for those filters. Additionaly, I suggest we can try to rework the filter to rebased on a maturing backend such as WebKit.
*** Bug 119482 has been marked as a duplicate of this bug. ***
*** Bug 122613 has been marked as a duplicate of this bug. ***
Since my Bug 122613 has been closed as a duplicate of this one (uh, well, really?) I am curious about the status here. Anybody out to address at least some of the aspects of this bug?
(In reply to Jens Troeger from comment #14) > Since my Bug 122613 has been closed as a duplicate of this one (uh, well, > really?) I am curious about the status here. Anybody out to address at least > some of the aspects of this bug? You have a lot of experience in C++ and this renovation work is in your business interest, so I think you are the perfect person to address it. Please join the developer chat https://irc.documentfoundation.org/?settings=#libreoffice-dev (or in your favourite IRC client) and you will receive all the guidance you need.
(In reply to Buovjaga from comment #15) > You have a lot of experience in C++ and this renovation work is in your > business interest, so I think you are the perfect person to address it. Not sure what makes you think that I have a “business interest” here; at most I have a hobby interest. I also already have a more-than-fulltime job doing other stuff, and I find it very difficult at the moment to take on more work…
Any update on this issue?
Well there has not been an aggressive move to strip out the Writer Web mode, but that probably should proceed. Filter import/export of HTML5/css3, and style sheet support in general--have not seen activity there either.
*** Bug 130720 has been marked as a duplicate of this bug. ***
Please add keyword needsUXEval and CC libreoffice-ux-advise@lists.freedesktop.org if input from UX is needed.
*** Bug 135282 has been marked as a duplicate of this bug. ***
> Gerry posted his use case here: https://wiki.documentfoundation.org/Talk:Proposals_for_removing_features [...] Also, professors who teach LibreOffice Writer in high schools have an obvious choice when using a program for teaching HTML. Writer is a WYSIWYG tool that their students already know.
*** Bug 70273 has been marked as a duplicate of this bug. ***
*** Bug 36977 has been marked as a duplicate of this bug. ***