i find that there are often misunderstandings when people communicate. even via email. asking questions has frequently proved to be a successful strategy for me. it may work for others.
On Jan 29, 2010, at 1:07 PM, Lachlan Hunt wrote: > John C. Welch wrote: >> On 1/29/10 11:47 AM, "Lachlan Hunt"<[email protected]> wrote: >>> No, font selection certainly does not need to be present in the composer >>> to handle that, and many other use cases. >>> >>> The following markup illustrates precisely how you can achieve the >>> effect you want, without having to have any font selection for the user. >> >> <Stuff that so misunderstands how non programmers work that it makes my head >> hurt to look at it snipped.> >> >> So your solution to html editing is to require people to CODE RAW HTML IN A >> TEXT EDITOR? > > I'm not exactly sure what it is about my e-mail was so unclear, that it led > you to that conclusion. Obviously, I'm not suggesting for users of this > application to hand code HTML to do e-mails. Rather, I was illustrating what > the HTML composer could output independent of how the user entered it into > the composition window. > > So, let's take a look at this *output* one more time, and I shall explain it > to you more clearly: > > --- > <!DOCTYPE html> > <title>Message Subject</title> > <style> > /* Default stylesheet provided by the mail client. */ > body { font: medium Arial, Helvetica, sans-serif; color: black; background: > white; } > </style> > <p>Hi there,<br> > Here's a code sample that I thought you should take a look at.</p> > > <pre>#include <stdio.h> > int main(void) { > printf("Hello World!"); > return 0; > }</pre> > > <p>It really is <em>that simple!</em></p> > --- > > To produce this output from a WYSIWYG editor, the user would type in their > text. The composer would insert that boilerplate markup at the top including > the DOCTYPE, <style> element with default styles and title, and default to > marking up the user's text in <p> elements. When the user wants to enter > code, the user should be able to select an option for preformatted text. > This could be a toolbar button, keyboard shortcut, menu item, or whatever. > When the user performs this action, the browser would use the <pre> element. > The user would then see in their WYSIWYG editor that they are entering text > in a monospace font, since that is the default style for <pre> > > Similarly, when they type the last paragraph after the <pre>, the user would > turn off preformatted mode and the editor would switch back to a <p> element. > This could also work for other things like headings, lists, bold, italic, > etc. > >>> If you load that up into a web browser, you'll see that the paragraphs >>> are rendered in a sans-serif font and the code is rendered in monospace, >>> and it was all achieved *without* any user editable font families or sizes. >> >> You don't deal much with non-geeks, do you. > > Seriously, I think you need to watch your tone on mailing lists. > >>> If a user wants that to be presented in a bigger font in the compose, >>> all they have to do is zoom, just like you can do in your browser. >>> Zooming does not change the font size specified in the stylesheet, just >>> the size that it's rendered at. >> >> So you don't like allowing wysiwyg editors, but you want people to use STYLE >> SHEETS FOR EMAIL. > > Yes, using a stylesheet in HTML is the correct way to apply styles. Using > other alternatives like <font> elements is not. I'm not suggesting that the > user has to type the stylesheet themselves, that can be done by the composer. > > -- > Lachlan Hunt - Opera Software > http://lachy.id.au/ > http://www.opera.com/ > _______________________________________________ > [email protected] mailing list > List help: http://lists.ranchero.com/listinfo.cgi/email-init-ranchero.com _______________________________________________ [email protected] mailing list List help: http://lists.ranchero.com/listinfo.cgi/email-init-ranchero.com
