Toggle bold format in heading H1..6

[Franz de Copenhague]

Hi Peter,

I am going to add a simple toggle button in app demo like Ctrl+B does, and I have found an issue toggling bold in headings. formatting API is wrapping inline text with <b> tags to apply bold and it is not enough to toggle bold in headings because of heading CSS styles.

The only way that I have found toggling bold is using font-weight "bold" and "normal" and skipping the extractSpecial call at formatting.ts. See attached patch. I won't push any change on formatting.ts without discussing it. 

This is a basic dilema between using <B><I><U> and inline styles, like DOCX run text vs ODT styles. 

Personally, I prefer inline styles. Actually the app demo is using inline styles with applyFormattingChanges API  and the app does not care how formatting API is implementing the underneath HTML. In conclusion, this is required to fix inside formatting API to allow applying "normal" font-weight to text in a heading, and inline style could be a easy way to fix it.

Franz    

[Franz de Copenhague]

Hi Ian,

I am intending the opposite,  consider that you have a heading stylename (Heading_20_1) that defines bold and underline formats and the user want a normal style for the the chapter title prefix. For example, "Chapter 1 Introduction" 

The initial state is:

h1.Heading_20_1 { font-size: 155%; font-weight: bold; text-decoration: underline;}
<h1 class="Heading_20_1" id="BDE23568-26">Chapter 1 Introduction</h1>

The user with the app selects "Chapter 1" and edits the heading, toggling bold and underline formats and the result could be

h1.Heading_20_1 { font-size: 155%; font-weight: bold; text-decoration: underline;}
<h1 class="Heading_20_1" id="BDE23568-26">

<span style="font-weight: normal; text-decoration: none;">Chapter 1</span> Introduction</h1>

You can see with this example that using <B> and <U> is an impediment for the toggle mechanism.

-Franz

---

Date: Sat, 2 Apr 2016 12:48:19 +0800
Subject: Re: Toggle bold format in heading H1..6
From: i...@amham.net
To: franzdec...@outlook.com

Hi Franz,

one of the next items I was going to look as part of the ODF processing is that of the round trip of editing headers. Initially I was just considering add/edit/delete cases. Not changing the formatting.

Currently when we write the html for a header we generate a header element with a class attribute to define its appearance.

And ensure that the style is defined.

If a user edits a header and changes the style I think the traditional ODF way would be to create an automatic style to wrap the header.

Consider one of my test cases.
A header 1 has a style h1.Heading_20_1 { font-size: 155%; font-weight: bold; }
<h1 class="Heading_20_1" id="BDE23568-26">Headline </h1>

It he wanted to make it underlined we can change it to

<h1 class="Heading_20_1" id="BDE23568-26"><u>Headline </u></h1>

Add the inline <u>. Not sure I know how to manage that on the put part of the process. But sure we can figure out something.

Is that what you were intending?

If a user wants to change the bold to normal how do we manage that?

Cheers,

Ian

--
You received this message because you are subscribed to the Google Groups "CorinthiaTeam" group.
To unsubscribe from this group and stop receiving emails from it, send an email to corinthiatea...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

--

Cheers,

Ian C

[Peter Kelly]

Hi Franz,

This is indeed a complex issue. It stems from the fact that in HTML/CSS, style properties are additive, rather than toggled - that is, if you have bold set on a style, then you set bold on an inline element inside a paragraph with that style, it will remain bold. This isn’t the only approach; as far as I’m aware OOXML actually does the reverse, where by two bolds cancel each other out.

Regarding styles, the design of the editor (and UX Write in general) was based around a very strong emphasis on the use of styles, explicitly discouraging manual, inline formatting. This philosophy came from the “what you see is what you mean” idea followed by LyX (see http://www.lyx.org/WhatIsLyX). That’s reflective of my attitude towards document authoring, but as   I learnt the hard way from many UX Write users, there are many people who prefer manual (inline) formatting instead. As controversial as the issue of styles vs. direct formatting is, I don’t see a reason why we can’t support both camps, in terms of the capabilities we provide.

A complication with the notion of bold, and other attributes, being in an “on” or “off” state is complicated by the inheritance of those attributes from styles. Actually, there’s three states - “on”, “off”, or “inherited” (this is codified in the CSS specification, albeit in a slightly different form - <b> is actually short-hand for font-weight: bold, and “not bold” is font-weight: normal; inherited is also a valid (and the default) property value).

I think the best solution for when the user toggles bold on or off is to have the editor check what the computed style of the selected text actually is. I think there are some DOM APIs which make it possible to access the computed style; otherwise we may need to implement the algorithm ourselves. If the selected text has a style where bold is on, then pressing bold should turn it off explicitly - that is, adding a <span style=“font-weight: normal”> around the selected text.

I’ve just had a look at your patch and I can see this is basically what you’ve done. One problem I can see however is that if there is text with a normal (non-bold paragraph style), and someone toggles bold on and then off again, they will be left with an extraneous <span style=“font-weight: normal”> in the DOM tree (and resulting HTML file) where it does not serve any function. So I think it would be better to only do this if we know the style is one that has bold set.

--
Dr. Peter M. Kelly
kell...@gmail.com

https://www.pmkelly.net/

PGP key: https://www.pmkelly.net/pgp-key

(fingerprint 5435 6718 59F0 DD1F BFA0 5E46 2523 BAA1 44AE 2966)