Gmail will now support CSS media queries(googleappsdeveloper.blogspot.com) |
Gmail will now support CSS media queries(googleappsdeveloper.blogspot.com) |
If only because it's simpler, so it might have been more fully and consistently supported (and it's not a security nightmare).
If everyone could just agree on a safe subset of HTML for email then that's all we would need.
text/enriched was basically proposed as an interim result for richer text than plain text back when HTML email was controversial.
There is a more-or-less defunct community group at the W3C about building an HTML email specification. In practice, the elephant in the room remains Outlook, which uses the same HTML engine built into MS Word, which, IIRC, is built on IE 5.5.
In lacking most of HTML's complexity and features, it lacks its security issues, too. And in being very small, you can reasonably expect the whole spec to be implemented.
But yes, with a very strictly validated, very small HTML subset you could get a similar effect. At that point, though, why use HTML?
Color
causes the affected text to be displayed in a specified
color. The "color" command requires a parameter that is
specified by using the "param" command. The parameter
data can be one of the following:
red
blue
green
yellow
cyan
magenta
black
white
or an RGB color value in the form:
####,####,####
where '#' is a hexadecimal digit '0' through '9', 'A'
through 'F', or 'a' through 'f'. The three 4-digit
hexadecimal values are the RGB values for red, green, and
blue respectively, where each component is expressed as
an unsigned value between 0 (0000) and 65535 (FFFF). The
default color for the message is unspecified, though
black is a common choice in many environments. When
nested, the inner "color" command takes precedence.
Odd that it's 96bpp colour, of all things.
1) RGB: #rrggbb (rgb hex) / rgb(r,g,b) (rgb int 0-255) / rgba(r,g,b,a) (as before, plus alpha). In addition, rgb/rgba support percentage values instead of 0-255.
2) red (color names)
3) hsl(h,s,l)
4) cmyk(c,m,y,k)
For compatibility with anything except Thunderbird (which supports all four formats IIRC), stick with #rrggbb or plaintext names. Webmailers are especially prone to filtering by regex (ugh), and stripping out everything they don't know.
I feel like I'm reading Hacker Rehashed News
I'm really pleased that email cannot set a style header and has limited ability to have the email deviate greatly in presentation from other email I receive.
Just playing devil's advocate here.
If you want to show your styles to Gmail users and you have to inline your CSS in every HTML tags you want to alter, which is very ugly and made the email size unneeded large.
That said, we still need to get this sort of thing in Microsoft Outlook, and both that and Gmail really need to support CSS to something of a normal standard, like with say Apple Mail or what not. There's no real reason email standards should be different to browser ones, except with the former not having Javascript included.
There are plenty of reputable email clients that add extra styling to make email look better that are not necessarily spam.
https://www.gaertner.de/~neitzel/mail-policy.html
https://www-user.tu-chemnitz.de/~heha/email.var
The prevailing attitude seems to be "If you can't configure your email client to send plaintext or follow the other rules I've listed on my site, I'm not interested in communicating with you."
Yeah, thanks. I'm doubly ecstatic when the unsubscribe link is in the HTML version and not the text version.
The example they give with a YouTube email. I wonder if they decided to make the change because of internal pressure from those sending out marketing emails.
This way, content using position:absolute can't escape the iframe borders, and the mail gets to enjoy full responsiveness.
Even without media queries, enabling <style> blocks in html emails is huge (google was the last holdout). For anyone developing html emails, this is a nice set of changes.
I don't need any of this fancy.
I'm looking for something that resembles GMail's actual functionality that is currently supported by Outlook and a variety of other email clients. I would just prefer a Gmail-native app because the Gmail app works more smoothly with Gmail than Outlook or any other provider does - particularly around search.
There is a request to HTML to let iframes take the height of their contents (the main thing anyone wanted from <iframe seamless>, which is now removed from HTML), but it's gone nowhere as of yet.
I've gone back to using standard Gmail but added the Inbox Categories, which I find to be very useful on top of the labels & filters I have in place.
Never, ever, EVER embed an iframe thinking it will make your life better.
I dont think email sender cares about how iframe is rendered. They currently render in a rectangle, and they will keep render in a rectangle.
I think it's to do with perceived ownership of the environment in which the information is consumed.
Your website... feel free to style, brand, make pretty or ugly. You can make the experience consistent within your realm.
My inbox... I get to control my workflows, how I consume things, in which order, etc. I choose to make the experience consistent within my realm.
That holds fairly well as a definition for why I prefer chat clients that grant me the ability to make all messages consistent, and that do not allow the sender to dictate terms. It also holds up with things like Netflix, it's their realm they can knock themselves out on their design.
It does seem to be whether the environment it is presented is "yours" or "mine".
You are free to set your client to ignore styling on the content, but the content should be stylable for everyone else that wants it to look good.
Also, I think many people do that with AdBlock, so it's not unheard of to block styling on webpages of dubious origin.
In that, yes, I agree. Bonus points for being able to inline respond to messages again. (I hate Outlook's forcing top posting.)
One thing that seems to have helped me (but is very much YMMV), is when I reply, it keeps the html code all messed up. Then when the person I'm discussing with sees that, they'll occasionally ask me why their email is messed up. That gives me an opportunity to explain html vs text, and they usually would rather their email "work everywhere".
For input, you need to be able to reliably close and open a switch. This may be difficult for people with tremors, but many accessibility systems are built around single bit inputs, so it's a start. If you can manage another input method, it can be translated to Morse as well.
Internationalization is harder, it's not a good fit for non-alphabetic languages.
Morse code is highly translatable to other senses assuming that the audience had a reason to learn it. I can't think of a single disability with lack of temporal awareness, and only a few with impediments to temporal perception (as you noted).
That said, I don't know ANY blind sea captains. This will be a problem for adoption.