Bug Hunting Session
Bug 95861 - Writer Web -- rework HTML export and import filters to use HTML 5 and inline CSS3 styles
Summary: Writer Web -- rework HTML export and import filters to use HTML 5 and inline ...
Status: NEW
Alias: None
Product: LibreOffice
Classification: Unclassified
Component: LibreOffice (show other bugs)
Version:
(earliest affected)
4.2.0.4 release
Hardware: All All
: medium enhancement
Assignee: Not Assigned
URL:
Whiteboard:
Keywords:
: 119482 122613 (view as bug list)
Depends on:
Blocks: HTML-Export
  Show dependency treegraph
 
Reported: 2015-11-16 19:51 UTC by V Stuart Foote
Modified: 2019-11-05 17:38 UTC (History)
11 users (show)

See Also:
Crash report or crash signature:


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description V Stuart Foote 2015-11-16 19:51:57 UTC
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.
Comment 1 David Tardon 2015-11-20 20:24:29 UTC
Should libreoffice even aspire to be an HTML editor?
Comment 2 V Stuart Foote 2015-11-20 21:44:42 UTC
@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.
Comment 3 David Tardon 2016-01-01 15:16:49 UTC
(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.
Comment 4 Tor Lillqvist 2017-03-30 07:20:10 UTC
> 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?
Comment 5 jan d 2017-03-30 07:45:04 UTC
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.
Comment 6 V Stuart Foote 2017-03-30 12:47:23 UTC
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?
Comment 7 Gerry 2017-03-30 19:10:25 UTC
(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.
Comment 8 Tomaz Vajngerl 2017-03-30 20:30:47 UTC
(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?
Comment 9 Buovjaga 2017-03-31 08:07:11 UTC
(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.
Comment 10 Volga 2017-12-17 17:59:22 UTC Comment hidden (obsolete)
Comment 11 Volga 2017-12-17 18:00:28 UTC
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.
Comment 12 V Stuart Foote 2018-08-24 21:58:52 UTC
*** Bug 119482 has been marked as a duplicate of this bug. ***
Comment 13 Xisco Faulí 2019-01-10 12:19:45 UTC
*** Bug 122613 has been marked as a duplicate of this bug. ***
Comment 14 Jens Troeger 2019-01-10 12:38:25 UTC
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?
Comment 15 Buovjaga 2019-01-10 13:28:23 UTC
(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.
Comment 16 Jens Troeger 2019-01-11 15:27:31 UTC
(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…
Comment 17 Jens Troeger 2019-11-05 17:10:41 UTC
Any update on this issue?
Comment 18 V Stuart Foote 2019-11-05 17:38:38 UTC
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.