Asking for ux-advise for what default should be. This is pretty much two bugs in one:

1. Apparently insert as link is disabled;

2. Default behavior has changed.

Just for clarification, the insert as link has been disabled from 3.3.0, so that is not a regression.

Jay. you haven’t provided a rationale on why we should again default to linking instead of embedding.

The default in html is to link to images and not embed them, but if an author wish it to be embedded, he has the choice of doing it that way.

Bug 48887 discusses a similar situation gone wrong with images always being embedded.

I try to stay out of the ux discussion as I think it typically just is 50% of people saying "I prefer X" and the other 50% saying "I prefer Y"

but here...I prefer the current default. I think it's reasonable that a normal every day user is not going to know what "link" even means, so if this is the default, then they save and take the document with them to a system without the net...they will be quite surprised (and angry) to not see their image shown.

That being said, the link being grayed out seems problematic.

Just to clarify, I am not saying this is what i prefer, this is the norm with html editors. When you open an html editor (dreamweaver, frontpage, etc) and insert an image, it will not embed the images into the html document, as that is not how websites are created.

Lets rest the Summary "WRITER WEB: handling of inserted images -- data URI embedding as base64 for email support, broke LO as HTML editor"

That is the issue--so now what to do from Design / UX perspective.

Is LO functional for an intended use?  For emailing a document as HTML, embedded is much more functional, convenient, and *is* the norm. So a yes there.

But, it looks like we went too far in "correcting" bug 63211 -- MAILMERGE: looses embedded image when e-mailing as html. See the commit and its help:

fdo#63211 - embed images in HTML export
http://cgit.freedesktop.org/libreoffice/core/commit/?id=﷒0﷓

http://cgit.freedesktop.org/libreoffice/help/commit/?id=59090e419fef3a6ec7a5270585d72312dafb78d2

Michael Stahl called it in https://bugs.freedesktop.org/show_bug.cgi?id=79730#c6

"it looks like this commit will unconditionally(!) write the
images as embedded base64-encoded, regardless of whether
it is set as an embedded or linked image, and thus introduced
this regression"

As a result we have bug 48887 and dup bug 79370

So, while the default of always embedding images (as data URL -- RFC 2397) is not technically incorrect (I actually prefer to embed) unfortunately it has broken the use of Writer Web's "HTML source" editor mode as it does not present the data URI of the image, nor show its insertion point.

I've no problem with the default handling of images in ODF documents converted to HTML being to embed them. But there should be working options for the insertion of graphics into HTML documents by relative links or internet URI (RFC 1808). 

Perhaps even give a user a configuration option to make inserting links their preferred handling in all ODF converted to HTML. The HTML view editor formatting, of linked images rather than embedded, has been lost since early in the 4.2 cycle with HTML refactoring for fdo#63211.

And that absolutely needs to be corrected--in some fashion.

Most would agree that Writer's Web HTML editor is long overdue for rework--to again make LibreOffice's HTML markup editing mode fully functional and regain relevance as an HTML/XHTML editor. 

Design and UX functional goal should be to edit HTML 4 & 5 of various structure, and support in-line CSS, and of course should expose any embedded data URI.

(In reply to V Stuart Foote from comment #7)
Going to need new eyes (or stronger glasses I guess) that is bug 79730 not 79370
s/79370/79730/
s/rest/reset/

The main problem is that it should be honoring the link option of images. If a user inserts the image in a word document in Writer and purposefully sets it as a linked image, it should not be embedded into the exported html. In the same way, if an html document with linked images is loaded, it shouldnt embed them on saving (bug 79730).

I absolutely agree with Jay, the data URI shouldn't be used per default.

- It's definitely not the standard in the web.
- Supporting it is not mandatory as per the HTML standards. Many browsers don't support it.
- It's really a crude hack anyway, as it blows up the data size extremely.

I would just like to add that this bug is very annoying for me. I use LibreOffice to write scientific publications in and I want to export them to a website. Due to the embedding, this is not currently feasible in an easy way, either "save as HTML" or "export to HTML".

My work around involves pasting into Wordpress which will then convert it.

If possible, I would like to know when a fix can be implemented?

Related problems:
Bug 87485 - Writer: embedded PNG results in slow scrolling 
https://bugs.documentfoundation.org//show_bug.cgi?id=87485

Bug 48887 - FILESAVE: Save as HTML in Writer should not embed images 
https://bugs.documentfoundation.org//show_bug.cgi?id=48887

I think the embedding is causing the extreme slowdown of scrolling. It is so bad that I cannot edit my 60 page paper on my weak laptop (Linux Mint 17.1, 64bit) but only on my desktop (Win 8.1, 64bit).

We never give ETA's - this is a volunteer project, your options:

1) Fix it yourself;
2) Pay for a fix;
3) Find a friend/family member to fix it;
4) Wait...and it could be a long time (we have thousands of bug reports open and in the grand scheme this one isn't that serious)

Writer Web as a functional HTML editor has been missed!

@Vasily, if as Luke suggests in bug 48887 you are revisiting generation of HTML-- rather than a simple revert of Ciorba's work to embed all images into HTML as base64--could we test for mail merge and only embed in that case? Then retain linked images within a Writer editable HTML.

@Ciorba Edmond you still with us?

@Jay - when changing a bug to highest please leave a comment explaining why you believe it deserves that. In particular when you change your own bug to it....it seems like you're pushing your pet bug. There are a total of 2 non QA members commenting on this bug over nearly a year - hardly seems to be something that will impact the wider community enough to constitute highest. Nor is the QA work done on it (no bibisect for instance). Again, removing myself from cc to avoid getting irritated.

@Joel, *

If you look at the history. Jay has pushed this out from ux-advise back as a specific Writer regression.

Specifically, we have lost ability to edit concise HTML, as the Writer Web HTML source edit mode was broken by and remains broken with changes made for supporting mail merge sending as HTML.  Embedded images bloat size of the HTML source, and obscure the document content and structure.

Yes, this can be resolved by partial reversion of
http://cgit.freedesktop.org/libreoffice/core/commit/?id=5dd1b3da57862a6577717544dde56482add89170

with addition of testing for output to LO's mail merge and only embedding in that instance.

But it would not have moved while remaining a ux-advise issue. So, I'm OK with this going to Highest/MAB as the issue remains a regression in function that breaks a major legacy feature of OpenOffice.

The XLST based export to XHTML is a poor substitute for the convenience of concise HTML editing of Writer Web in HTML source mode.

This needs to be corrected. Ideally our HTML support should be brought current with changes suggested in bug 95861 of adjusting filters to use HTML5 and CSS3--but I won't push that too hard. Returning the HTML edit capability is a good start.

That's all fine - I wasn't necessarily saying this isn't a highest bug (MAB or w/e other name) I just was saying that it's important that QA contributors at least put in minimal effort to follow agreed upon procedures. This is particularly true when a QA contributor is bumping their own bug to highest. This is mainly to avoid the impression that we're pushing pet bugs. I didn't really doubt that this was a highest - just like to see the justification when someone pushes it there :)

(In reply to Joel Madero from comment #14)
> @Jay - when changing a bug to highest please leave a comment explaining why
> you believe it deserves that.

Will remember to do that next time and did so due to stuart's comment 13 to bring more attention to this issue as the component is completely unusable as an html editor.

> In particular when you change your own bug to
> it....it seems like you're pushing your pet bug. There are a total of 2 non
> QA members commenting on this bug over nearly a year - hardly seems to be
> something that will impact the wider community enough to constitute highest.
> Nor is the QA work done on it (no bibisect for instance).

Bibisecting was done by stuart in comment 7.

As an HTML instructor, I want to confirm that linking to images is now and has always been the default for HTML documents and HTML websites. It was also the default for Libre Writer up to version 4.2. I recently migrated from LO 4.1 to LO 5.0.3 and now Save As HTML no longer creates separate image links. Please restore the proper HTML image linking as soon as possible. This is a disaster!

Armin's work on bug 94088 has restored some function in handling inline graphics in HTML round trip. LO now handles the import of the base64 encoded images.

He notes that the HTML import and export filter needs to be redone--absolutely! But perhaps see bug 95861 for that.

Unfortunately, using a data URI (RFC 2397) for images was hard-coded for bug 63211. So relative links and URLs are lost--regardless of LO user settings--so this remains a regression in LibreOffice for folks needing a convenient WYSIWYG HTML/XHTML editor.

With Armin's tweaks to handle reimport of HTML to LO correctly, at this point I think the most glaring problem is the edit canvas for Writer/Web where if toggling to "HTML source" mode--the <img src="data:image ..." /> tag for the embedded images is not being displayed.

Meaning that when in "HTML source" mode while working with an HTML/XHTML document you can not directly style the image element, nor reposition its anchor.

We have some movement on this, yea!

Oliver S. is reworking code for the bug 63211 patch, to restore support for linked images in the HTML as user prefers, while keeping base-64 encoding for mail merge support.

Thanks Oliver!

=-ref-=
https://gerrit.libreoffice.org/#/c/23359/

Oliver Specht committed a patch related to this issue.
It has been pushed to "master":

http://cgit.freedesktop.org/libreoffice/core/commit/?id=46fa816aa0a713c54836b9689fa7a1c9ff55ef5a

tdf#63211: saving embedded images to HTML optional

It will be available in 5.2.0.

The patch should be included in the daily builds available at
http://dev-builds.libreoffice.org/daily/ in the next 24-48 hours. More
information about daily builds can be found at:
http://wiki.documentfoundation.org/Testing_Daily_Builds

Affected users are encouraged to test the fix and report feedback.

Adding keyword 'bibisectRequest'.

Calling this Resolved Fixed -- Oliver S.'s commit for bug 63211 (comment 21) restores functional linked images for WRITER WEB hmtl documents. Although now means to actually embed into the HTML seems a bit off--but that is another issue. This restored needed WYSIWYG function.