Bug 61735 - FILESAVE as HTML looses "Label Field" form control with error message
Summary: FILESAVE as HTML looses "Label Field" form control with error message
Status: NEW
Alias: None
Product: LibreOffice
Classification: Unclassified
Component: Writer (show other bugs)
(earliest affected)
Inherited From OOo
Hardware: All All
: low enhancement
Assignee: Not Assigned
: 76806 (view as bug list)
Depends on:
Blocks: HTML-Export
  Show dependency treegraph
Reported: 2013-03-03 13:26 UTC by Norbert X
Modified: 2021-08-16 13:01 UTC (History)
5 users (show)

See Also:
Crash report or crash signature:
Regression By:

Test file with form controls (14.19 KB, application/vnd.oasis.opendocument.text)
2013-03-03 13:26 UTC, Norbert X
HTML Output (5.61 KB, text/html)
2013-03-03 13:27 UTC, Norbert X
Sample document in correct HTML 4.01 Transitional (691 bytes, text/html)
2013-03-07 13:40 UTC, Rainer Bielefeld Retired
Sample document in correct HTML 4.01 Transitional (added <label...> without "for=" attribute) (849 bytes, text/html)
2013-03-07 16:30 UTC, Norbert X

Note You need to log in before you can comment on or make changes to this bug.
Description Norbert X 2013-03-03 13:26:07 UTC
Created attachment 75830 [details]
Test file with form controls


I was going to create a simple web-form, which contain some Labels, Text boxes, Checkboxes etc.
I created new ODT document, opened "Form Controls" Toolbar, and found needed form elements here.

I discovered that if I save a document with "Label Field" it will not exported to HTML file (if I select File-Save As). I get a warning message with text "Warning saving the document test_from_odt:
Write Error.
Document could not be completely saved."

Why I get this warning message? As far I know in HTML there is an equivalent representations of form controls - <label>...</label> for "Label Field".
So I hope you can add <label> representation for "Label Field".

This bug exists in (Ubuntu 12.04 LTS) and (Gentoo 13 amd64).
Comment 1 Norbert X 2013-03-03 13:27:03 UTC
Created attachment 75831 [details]
HTML Output
Comment 2 crazyskeggy 2013-03-03 17:49:13 UTC
Comment on attachment 75830 [details]
Test file with form controls

Edit odt file's mimetype so that it is downloadable (previously was plaintext)
Comment 3 crazyskeggy 2013-03-03 18:05:20 UTC
I can confirm this with LibO 4.0.0 and Chrome 25.0.1364.97 on Windows XP. The field titled "Label Field" shows an unclickable piece of text saying "Label Field" in LibO, and a blank section in Chrome.
After inspecting the page's source, Chrome tells me there is just a blank <p> (paragraph) item there. Exportign also results in the same error.
Comment 4 Rainer Bielefeld Retired 2013-03-07 13:39:08 UTC
Effect is reproducible with any Version (on WIN) I tested back until OOo 2.0.3

But is it a Bug? I do not think that <label> can be used as an independent thing, and so  LibO might proceed correcting that? Please see 

I will attach A Valid Html Document to demonstrate how <Label> is to be used.
For A use on HTML like ODF allows we would need a HTML definition link to proove that. 

Can you provide any html standard, a Valid page or similar underpinning your bug-suspect?
Comment 5 Rainer Bielefeld Retired 2013-03-07 13:40:15 UTC
Created attachment 76118 [details]
Sample document in correct  HTML 4.01 Transitional

See comment before how to use
Comment 6 Norbert X 2013-03-07 16:30:09 UTC
Created attachment 76123 [details]
Sample document in correct HTML 4.01 Transitional (added <label...> without "for=" attribute)

Hello, Rainer!

If you talk about validity  - you can test the document with the following link 

If I modify your example (add one more label without for= and without <input>) the document is still valid.

So you can convert LO "Label Fields" to HTML <label>s safely.
Comment 7 Rainer Bielefeld Retired 2013-03-07 17:05:21 UTC
(In reply to comment #6)
Good point!

Although I doubt that that is a common and intended use of the <label> tag, it might save some trouble for some of our users to export a <label> tag the way you suggested.

Unfortunately because of limited manpower HTML Export related bugs have very low priority.
Comment 8 Timur 2017-12-18 14:09:55 UTC
repro in 6.1+
Comment 9 stragu 2021-06-23 12:30:57 UTC
Reproduced in:

Version: / LibreOffice Community
Build ID: e3086b58eb5427d520b86c185f9d911bb6f7a3a0
CPU threads: 8; OS: Linux 4.15; UI render: default; VCL: gtk3
Locale: en-AU (en_AU.UTF-8); UI: en-US
TinderBox: Linux-rpm_deb-x86_64@86-TDF, Branch:master, Time: 2021-06-21_15:37:11
Calc: threaded
Comment 10 stragu 2021-06-29 13:25:04 UTC
*** Bug 76806 has been marked as a duplicate of this bug. ***
Comment 11 Christophe Strobbe 2021-08-16 13:01:23 UTC
(In reply to Rainer Bielefeld Retired from comment #4)

Even though Rainer Bielfeld's comment is now eight years old, I think it is still worth replying to.

> But is it a Bug? (...)

The <label> is intended to be explicitly associated with the form field it describes. This is explicity mentioned in section 4.3, "Maintaining the accessibility of Form Elements" of the "Open Document Format v1.1 Accessibility Guidelines Version 1.0": http://docs.oasis-open.org/office/office-accessibility/v1.0/cs01/ODF_Accessibility_Guidelines-v1.0.html#4.3.Maintaining%20the%20accessibility%20of%20Form%20Elements|outline

The code in the Accessibility Guidelines is not up to date, but the logic is still the same in current versions of ODF:

- You have a <form:fixed-text> element with the attribute form:for that points to the ID of the field it describes.
- The <form:fixed-text> element also has a form:label attribute with the label's actual text.
- The associated form field, e.g. a <form:text> element, has the attributes xml:id and form:id that match the value of the form:for attribute on the <form:fixed-text> element.

This mechanism is explicitly inspired by a similar mechanism (using for and id attributes in HTML.

This is unfortunately not so obvious from the wording in the OpenDocument Format specification. I can cite two sections from ODF 1.3 part 3 (released earlier this year):

[begin quote]
13.5.10 <form:fixed-text>
The <form:fixed-text> element defines a control which attaches additional information to controls, or displays information. Only one label may be associated with a control.

19.282 form:label
The form:label attribute specifies the text for a control.
[end quote]

> Can you provide any html standard, a Valid page or similar underpinning your bug-suspect?

If this refers to standards related to accessibility:

- HTML Technique H44 for the W3C's Web Content Accessibility Guidelines (WCAG): Using label elements to associate text labels with form controls: https://www.w3.org/WAI/WCAG21/Techniques/html/H44.html
  This is a technique for meeting Success Criterion 1.3.1 in WCAG 2.1 https://www.w3.org/TR/WCAG21/#info-and-relationships (and WCAG 2.0).
- This techniques goes back to the Web Content Accessibility Guidelines (WCAG) 1.0 from 1999: https://www.w3.org/TR/WCAG10-TECHS/#tech-associate-labels 

Without the for and id attributes, HTML's <label> element is useless from an accessibility point of view (unless the label element is wrapped around the input field, but it is probably easier to make Writer's exported HTML code use the for and id attributes than the label-around-form-field approach).