<html>
<head>
<meta http-equiv="content-type" content="text/html; charset=ISO-8859-1">
</head>
<body bgcolor="#FFFFFF" text="#000000">
Hi Joe thanks for the first feedback!<br>
<div id="smartTemplate4-template">
<hr>
<style type="text/css">#newHeader { font-size: x-small; }#newHeader b { font-weight:bold; color: #990033; }</style>
<div id="newHeader"> <b>From: </b>"JoeS"<a class="moz-txt-link-rfc2396E" href="mailto:joesab2005@gmail.com"><joesab2005@gmail.com></a><br>
<b>Sent: </b>Tuesday, 17/07/12 20:06:28 20:06 GMT Daylight Time
+0100 <br>
<br>
</div>
</div>
<blockquote class=" cite" id="mid_5005B7B4_2050808_gmail_com"
cite="mid:5005B7B4.2050808@gmail.com" type="cite">
<div class="moz-cite-prefix">On 7/17/2012 7:22 AM, Axel Grude
wrote:<br>
</div>
<blockquote class=" cite" id="mid_50054AE6_7050203_gmail_com"
cite="mid:50054AE6.7050203@gmail.com" type="cite">
<meta http-equiv="content-type" content="text/html;
charset=ISO-8859-1">
<div id="smartTemplate4-template"><i>Following up: </i>What's
the status of papercuts?<br>
<i><br>
</i></div>
<br>
<div id="smartTemplate4-template">Since replacing the complete
composer is probably to big a task for the scope of papercuts
I would like to discuss a number of enhancements to enhance
the current (html) composer functionality:<br>
<br>
<h3>Color Selection</h3>
<a moz-do-not-send="true"
href="https://bugzilla.mozilla.org/show_bug.cgi?id=453853"><b>Bug 453853</b></a>
-<span id="summary_alias_container"> <span
id="short_desc_nonedit_display">Unable to set hex value
for background color in the color picker</span> </span><br>
<br>
I would like to rename this to (upgrade color picker to allow
more color selections). Unfortunately I do not have
Thunderbird bugzilla admin rights, and maybe there is another
bug on this elsewhere [I searched for Tb/Compose + {color
picker} and for Tb/Compose + {colors} ]?<br>
<br>
A quick way would probably be if we could include
rainbowpicker into the core code (obviously after asking its
author)?<br>
<br>
</div>
</blockquote>
Well, you can edit the hex after you pick a basic color, but a
better direct selection would be nice. </blockquote>
Ah yes - wouldn't that effectively close <a moz-do-not-send="true"
href="https://bugzilla.mozilla.org/show_bug.cgi?id=453853"><b>Bug 453853</b></a>
? That widget is actually new to me! What I would actually really
prefer would be a HSE color selection with a hue ribbon and a square
of just one hue with variations on S and B (like photoshop) as this
is a lot more exact:<br>
<br>
along these lines:<br>
<img src="cid:part3.00000205.04050902@gmail.com" alt=""><br>
<br>
this would still be useful after dropping CMYK and L,a,b support
(and add alpha instead). Still my ideal for a color selection - this
one makes it way easier to arrive at the correct color quickly.<br>
<br>
<blockquote class=" cite" id="mid_5005B7B4_2050808_gmail_com"
cite="mid:5005B7B4.2050808@gmail.com" type="cite">
<blockquote class=" cite" id="mid_50054AE6_7050203_gmail_com"
cite="mid:50054AE6.7050203@gmail.com" type="cite">
<div id="smartTemplate4-template">
<h3>Format Painter</h3>
"A copy format" function is badly needed. One problem
currently is that a lot of the built in formatting tools
actually insert tags (such as <big> <b> <i>)
rather than styles, so a more fundamental problem must be
addressed first:<br>
<br>
</div>
</blockquote>
A little background here;<br>
Back when the editor was modified for CSS (Daniel Glazman) it was
decided that CSS should not be used in mail<br>
due to interoperability problems with Yahoo,Gmail and others.<br>
In fact, I think there is just an editor flag that keeps html
instead of css </blockquote>
I think this needs to be re-evaluated. It is true that there is
still a problem with webmail and outlook, but the mail clients keep
catching up. One thing I did experience though is that inline styles
are more reliable than <style> rules as they are often dropped
because of scoping issues. I would be brave and walk forward (with
the 20 million users) and rather risk loss of fidelity for standards
compliance. If you were going for major compatibility you (e.g.
outlook fidelity) you would have to back pedal so far... I
personally for HTML email CSS is the future (as it is for HTML5). <br>
<br>
<b>If Thunderbird can lead by example, then this is the one area
where I would like it to be brave: <u><br>
</u></b>
<ul>
<li><b><u>be CSS3 compliant</u>; </b></li>
<li><b><u>encourage use of CSS</u></b>; <br>
</li>
</ul>
<p>it is not that hard. Just use a proper browser engine, there are
plenty choices out there. Of course, composing is an entirely
different kettle of fish (that's the hard bit). :)</p>
<blockquote class=" cite" id="mid_5005B7B4_2050808_gmail_com"
cite="mid:5005B7B4.2050808@gmail.com" type="cite">
<blockquote class=" cite" id="mid_50054AE6_7050203_gmail_com"
cite="mid:50054AE6.7050203@gmail.com" type="cite">
<div id="smartTemplate4-template">
<h3> CSS Property Editor</h3>
Image > Advanced property editor Enhancements<br>
<br>
I wonder if this could be generalized to apply CSS properties
to all sorts of tags (not just img). Ideally I would like the
possiblity to select a paragraph (which we should be able to
turn from a <br>....section...<br> into a
<p>..</p> pair, and then select something like a
"layout" option.<br>
<br>
As a starting point we could use the "Inline Style" tab of the
"Advanced Property Editor" and add a dropdown to the Attribute
field. The tricky bit is to select the correct tag (probably
the nearest enclosing tag) and to visually represent this in
the Editor window.<br>
<br>
<screen snipped> <br>
For this particular purpose (increasing style expressiveness
in the WYSIWIG editor, via inline styles) I would chose to
remove the tabs "HTML attributes" and "Javascript Events" and
focus on css styles alone. ONe thing that Thunderbird does
very badly at the moment is to expose the current expressive
power it has via CSS3 to the ordinary user. Most other rich
editors have some sort of a "x-ray" mode where special
(meta-)characters such as tabs, line feeds, section breaks
etc. are displayed; what I would like to have is something
generic that shows enclosing tag pairs (or an outline around
html constructs) so that they can easily be spotted and
manipulated. This is actually the hard part of this
enhancement, but I think discussion of this would be fruitful.<br>
<br>
Rationale:<br>
<br>
Currently, the only way to create an email with "clean
markup" is by using extensions that expose HTML source, which
works for me, but not most ordinary users. As <i>first step</i>
we could make it easier to add inline styling via the method
above; this will make it easier for users to discover layout
features of Composer. As a <i>second</i> <i>step</i> we
might then later encapsulate the interface so it can be used
by users who do not know CSS.<br>
<br>
I would love to be involved in such composer improvements, but
I would also like to assess as to what other ideas or maybe
code fragments are already out there. Therefore I am currently
holding off on filing new (or re-appropriating existing) bugs
on this and adding them to the papercuts list, until I have a
feel for what the opinions on the list on this are.<br>
<br>
</div>
</blockquote>
I have been looking for better css composition for years.<br>
I think the dropdown idea is great. (auto-complete would be even
better)<br>
</blockquote>
Yes I thought of adding some template strings for the value textbox,
like <br>
box-shadow - [h-shadow] [v-shadow] [blur] [spread] [color] [inset]<br>
but that could all as well be added in version2. <br>
<br>
A "default values memory effect" would be good though. There is
always the issue (pain) with copying / pasting styles when you are
dealing with inline styling. Of course, using CSS classes would be
the real way forward here, but they are even less supported by other
mail clients than CSS.<br>
<br>
I think we will also need some sort of level inspection UI (ala FX
inspector; showing a breadcrumb trail of enclosing HTML tags) in
order for this to be efficient and easily understandable to the
average user. I was even thinking maybe a HTML tree in a Composer
sidebar might be a nice short-term fix.<br>
<br>
Somehow the paradigm has to shift away from "text-selection" to "tag
pairs". Do you think there is a way to take the ordinary users (who
don't speak HTML) there?<br>
<br>
<blockquote class=" cite" id="mid_5005B7B4_2050808_gmail_com"
cite="mid:5005B7B4.2050808@gmail.com" type="cite"> BTW, I think
the advanced editor still drops margin-left/margin-right, if you
make any other changes there. </blockquote>
eeek. What is quite amazing to me in current Composer (read:
Netscape 4.0 - yes it didn't really change very much since then, I
have been watching!) is that there is so much functionality built
around formatting images, and so little around the lowly <p>
tag. Is using <p> instead of <br> a [un]surmountable
challenge?<br>
<br>
</body>
</html>