On 1/29/10 2:51 PM, "Lachlan Hunt" <[email protected]> wrote:
>> actually, if i understand correctly, he's suggesting that the >> composer has a pre-determined stylesheet, not that users create or >> user stylesheets. whether it's such a terrible suggestion or not will >> be easier to talk about if it's first understood. then we can talk >> about the same thing. > > Yes! Thank you for understanding. > > John, the whole point is to keep the HTML composition features to a > minimum. Provide enough for users to convey the semantics of their > content, but not so much that they can go crazy with wild fonts, > colours, transitions, borders, and other unnecessary bells and whistles. And CSS wil PREVENT THIS? > > Think about the market for just a moment, and think about what such > users really need for composing mail. These are power users who read > and write significant amounts of e-mail. Such users want the ability to > quickly and easily communicate their message, without getting bogged > down in pixel perfect design issues. This is not an app for e-mail > marketers, who want the e-mail themed to match their corporate image and > style guides; or for kids who want to send colourful e-mails to their > friends. > So now you're defining power users to mean "people like you"? Because that's what I'm seeing. You've just said: Designers can't be power users Email marketers can't be power users People under <age> can't be power users. And people say I'M arrogant. Ye Gods. Why not be honest and say if you can't use Emacs for email, you don't count as a power user. > For a power user, the kind of content that they are likely to be > interested in writing is: > > * Quotes (including both for replies, and copied and pasted from other > sources) > * Bold and Italic for emphasis > * Links and e-mail addresses > * Bulleted and Numbered lists > * Preformatted text (e.g. code fragments) > * Headings > * Tables Um, no. Tables are overkill. And then some. > * Emoticons The interpretation of emoticons to images should be up to the recipient. What, you want to send emoticon images or links to them in the email > * Images (e.g. photos) It's funny how your definition is FAR more complicated than mine. Tables never, ever, ever occurred to me. > > These features are easy to do in plain text, and many users including > myself, find that a whole lot quicker and easier than messing around > with HTML. The aim is to get the message across, not make things look > pretty. Wait, you say this and TABLES? TABLES????? > > However, I will admit that there are power users who prefer the look and > feel of HTML over the monotony of plain text. But these users are still > more interested in communicating their message than making things look > pretty. The features listed above can be provided with a few very > simple commands. These are the toolbar buttons that I think would be > appropriate for e-mail composition. Formatting is about enhancing clarity and readability too. It is not some goofy toy. But CSS??? TABLES? How can you advocate CSS and TABLES in the same email and not have your computer burst into flame. One of CSS's prime purposes is to make tables uncessary. > > --- > * Paragraph (default selection, <p>) > * Headings (3 heading levels should be sufficient, <h1> to <h3>) > * Preformatted text (<pre>) Yeah. Because just letting people pick a monospace font is so evil. > * Block Quotation (<blockquote>) > > * Ordered List (<ol> and <li>) > * Unordered List (<ul> and <li>) > > * Table > - When editing a tables, the user should be able to specify > header cells and data cells > - Insert/delete rows and columns > - Merge cells This makes my head explode. So let me get this straight. Choosing a font: EVIL Choosing a font size: EVIL TABLES IN EMAIL: ROCK ON BRAH!!!!! I'm having GoLive flashbacks here. > > * Bold (<b>) > * Italic (<i>) > * Link (<a>) > > * Emoticons Again, how do you propose to do this without sending image or links. You can send emoticons in plain text, there's no reason why you need a friggin' emoticon button. > * Images > --- > > These commands should be suffient for the vast majority of communication > needs. To get your message across, there is very little reason for > specifying anything else beyond that. It's also very easy to provide a > nice clean and simple default, non-user-configurable [1], stylesheet for > those elements. How do you propose it not be user configurable? This is after all, open source code. Undoing that crap will be trivial (PLUGINS!). Want neon pink backgrouns and flourescent green text? Just use the "blind gramma" plugin. Plus, I can think of no better practical joke than this. For the record, your concept here is INFINITELY more complicated and abusable than anything I have suggested > > Most of those can also be easily translated into a plain text > alternative. I realise tables present a little bit of a challenge, > however. (It would be useful to investigate how other mail clients > handle that issue later) THEY DON'T USE TABLES. Not Entourage Not Mail Thunderbird does, and that's crazy too. Ye Gods. > > [1] Note: If we provide a way for users to edit the email source > directly while composing, then users could mess with the stylesheet if > they really want to. But this is completely unnecessary for most users > using a WYSIWIG composer. Yeah. Infinitely nested tables will ROCK as a plain text conversion. TABLES! I need more vodka -- John C. Welch Writer/Analyst Bynkii.com Mac and other opinions [email protected] _______________________________________________ [email protected] mailing list List help: http://lists.ranchero.com/listinfo.cgi/email-init-ranchero.com
