Bug 101179 - Writer/Web: View > HTML Source mode toggles are awkward
Summary: Writer/Web: View > HTML Source mode toggles are awkward
Status: NEW
Alias: None
Product: LibreOffice
Classification: Unclassified
Component: Writer (show other bugs)
Version:
(earliest affected)
5.1.4.2 release
Hardware: All All
: medium normal
Assignee: Not Assigned
URL:
Whiteboard:
Keywords: needsUXEval
: 133204 145264 (view as bug list)
Depends on: 95861
Blocks: Writer-Web-Layout 101772
  Show dependency treegraph
 
Reported: 2016-07-28 19:07 UTC by Stefan Knorr (astron)
Modified: 2021-11-08 08:20 UTC (History)
6 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 Stefan Knorr (astron) 2016-07-28 19:07:45 UTC
To reproduce:

1. Open Writer/Web (e.g. via File > New > HTML Document)
2. Save the document (this is necessary because otherwise Writer/Web will not
   show you a source view of your file): File > Save As (etc.)
3. Switch to the source view: View > HTML Source

Now, open the View menu again. Observe that "Print Layout" and "Web Layout" are grayed out i.e. unavailable. This is, despite the fact that the three items Print Layout/Web Layout/HTML Source should act as alternatives. (Which is implied by the UI, given the radio-button like circle in front of the item. And that they act as alternatives is also logical.)

Now, to switch out of HTML Source view, you have to click View > HTML Source again. You are not able to use either of the logical items Print Layout or Web Layout.

(I hope that makes a bit of sense.)
Comment 1 V Stuart Foote 2016-07-28 22:37:34 UTC
Confirmed on Windows 10 Pro 64-bit with
Version: 5.2.0.3 (x64)
Build ID: 7dbd85f5a18cfeaf6801c594fc43a5edadc2df0c
CPU Threads: 8; OS Version: Windows 6.19; UI Render: GL; 
Locale: en-US (en_US)

The mode toggles seem a little muddled. Unable to move back to Normal or Web layout without first toggling out of HTML Source view.

So, it can be in HTML View--or not. And only if not, then either Normal (i.e. print preview) or Web view.

Beleive intent is when toggled into the HTML view--the Normal and Web view widgets were not visible--instead of just greyed out.

Not sure if that can be improved.

@UX-Advise?
Comment 2 Heiko Tietze 2016-07-28 22:51:10 UTC
I would also expect that HTML Source is an option when I load such a document. But it is there only with Stefan's test sequence.

Is this really an UX thing? It smells like a bug, or an inconsistency at the code.
Comment 3 QA Administrators 2018-06-19 02:45:33 UTC Comment hidden (obsolete)
Comment 4 Heiko Tietze 2018-06-20 08:11:49 UTC
Definitely a bug since the "HTML source" toggle button on the toolbar does the trick.

Version: 6.0.4.2
Build ID: 6.0.4-2
CPU threads: 8; OS: Linux 4.17; UI render: default; VCL: gtk3; 
Locale: en-US (en_US.UTF-8); Calc: group
Comment 5 QA Administrators 2021-06-13 03:47:45 UTC Comment hidden (obsolete)
Comment 6 Heiko Tietze 2021-10-22 06:51:29 UTC
*** Bug 133204 has been marked as a duplicate of this bug. ***
Comment 7 Heiko Tietze 2021-10-22 06:52:48 UTC
*** Bug 145264 has been marked as a duplicate of this bug. ***
Comment 8 skyhook 2021-10-22 14:44:13 UTC
Will move my thoughts to the duplicate if oldest is best; I did search first but that's 2016. The longevity of this issue is noted.
Comment 9 skyhook 2021-10-22 15:30:17 UTC
(In reply to skyhook from comment #8)
> Will move my thoughts to the duplicate if oldest is best; I did search first
> but that's 2016. The longevity of this issue is noted.

That was confusing. Requests are so similar I thought I was looking at my 2021 report. <a href="https://bugs.documentfoundation.org/show_bug.cgi?id=145264">145264</a> has been marked resolved. 

Back to the issue, I'll summarize by voting that this HTML format feature shouldn't exist, duplicating menu and tool bar or not: 

Pro:
- once inside an HTML text file, togging text to WYSIWYG is handy

Cons:
- badly implemented menu control was my main reason for stepping in here
- little gain from ten lines of boilerplate
- forcing user new file awkward
- little gain from HTML file extension if not editable by Writer
- help file literally incorrect on re-open detail
- long history of users confusing this issue

Anybody editing HTML would save a text version of their source as their platform would likely have a different application associated with an HTML extension, also, a browser open to view and refresh edits as the proof in the pudding. I might still like the idea of toggling views, but its utility is so minimal I don't feel it justifies the confusion. If doubling down, the goal should be to have any existing HTML file toggle to text on demand, for editing.
Comment 10 V Stuart Foote 2021-10-22 16:26:12 UTC
(In reply to skyhook from comment #9)
> ...
> Anybody editing HTML would save a text version of their source as their
> platform would likely have a different application associated with an HTML
> extension, also, a browser open to view and refresh edits as the proof in
> the pudding. I might still like the idea of toggling views, but its utility
> is so minimal I don't feel it justifies the confusion. If doubling down, the
> goal should be to have any existing HTML file toggle to text on demand, for
> editing.

Well in reality, the entire Writer/Web module is broken. It was implemented for HTML 4.0 transitional and provides no support for external CSS2 or CSS3.

The developer consensus for bug 95861 is to strip out the entire Writer/Web module; and this issue with the HTML view "modes" just goes away. 

Essentially we don't want to work in HTML/XHTML directly--just on VCL canvas as needed by filter import to ODF.

Another facet of that is though the XSLT based import and export filters do a reasonable job with ODF formatting they are non-performant, so a major C++ based refactoring of HTML/XHTML/XML import and export filters has been suggested.

For myself, I've moved to the dump Writer/Web module as unsupported with no chance for dev maintenance or needed feature implementation. It just needs to be dropped.
Comment 11 skyhook 2021-10-22 23:33:24 UTC
(In reply to V Stuart Foote from comment #10)
> (In reply to skyhook from comment #9)
> > ...It just needs to be dropped.

Thanks for reaching out. My final word on this, then, as a user: 

"What do you use it for?" was asked in 2017. I fell into this because I wanted to proof formatting in my Thunderbird sig's. 

That was a bit of a surprise in itself, that I had to work with tags. I could trial-and-error with test messages, and didn't require Writer. After I stripped increasing amounts of cruft, I learned all I needed was simple inline formatting like their grey placeholder. I wish detailed formatting was easier in TB but if TB interprets HTML anyway, doesn't it follow to use that functionality for other elements like signatures? I tried but no joy, it's all or nothing WYSIWYG, which is why I'm relating TB to Writer. 

With Writer, I can save formatting as HTML and monitor it in a browser; faster, easier, and up to date, and I can copy the code something else like a sig. I'm ignorant of the machinations behind save-as formatting, but I'm guessing losing HTML/Web would have some connection to losing the entire format option. 

At the current level of complexity, I can see why people might hesitate to lose a nice shortcut. Writer might have a place but not as a step towards a full-blown HTML5 editor, that the majority concede is off target and not trivial. I would call the current state somewhere in the middle and failing there, and it could be simplified. 

After reading the 2015 and the deprecation link, HTML/Web just feels like a pit trap that nobody is willing to fill in even though the war is over. I didn't see any significant pressure not to. 

Good luck.
Comment 12 Heiko Tietze 2021-11-08 08:20:42 UTC
(In reply to V Stuart Foote from comment #10)
> Well in reality, the entire Writer/Web module is broken...
> The developer consensus for bug 95861 is to strip out the entire Writer/Web
> module; and this issue with the HTML view "modes" just goes away. 

So resolve this one as WF? Or ideally block loading/saving HTML documents (I disagree with bug 95861 and would just remove all of this).