Closed. This question needs to be more focused. It is not currently accepting answers.
Want to improve this question? Update the question so it focuses on one problem only by editing this post.
Closed 6 years ago.
Improve this question
It's 2017 and we are still stuck with HTML tables to create rich emails. Why? It seems reasonable to leverage the hard work behind the modern browser engines (ie. blink), when all you want is to render an HTML document properly.
Update: Since this question was closed and my answer resembles a blog post, I published an updated version on Medium.
Email clients use rendering engines appropriate for displaying emails. This is not always in step with displaying web pages.
Only a small % of email users care about HTML/CSS support. Think email marketers and developers. The vast majority of email users simply want a simple, secure way of sending and receiving rich text messages with other people. That’s what email clients are designed for.
Even more advanced users don’t often cite good HTML/CSS support as a top concern. Recent innovations give us a little insight as to what folks are frustrated with regarding email clients: help managing incoming messages, more security, less SPAM, and overall ease of use.
No one cares if it takes developers a long time to use <tables> and inline CSS to create an email. When it comes to changing how emails are rendered… “If it’s not broke, why fix it?” When email clients actually do update rendering, it’s rarely news outside of the tech community. Few people care.
Consider Desktop Outlook, which typically comes bundled with programs like Word and Powerpoint. All these programs have a similar interface and display output. If you can author a Word document, there’s almost no learning curve in writing an email in Outlook. That’s huge for a lot of people. In all likelihood, Outlook’s rendering engine wasn’t chosen based on it’s ability to render an HTML document properly, yet the product is still considered a success. Because desktop Outlook and doesn’t get automatic updates, old versions (that we have to code for) tend to hang around.
Fun fact: Outlook 2000-2003 rendered email using whatever version of Internet Explorer was installed locally the computer to render email (usually Internet Explorer 6).
Gmail is another example. While Gmail has pretty good HTML/CSS support, it didn’t support external CSS files until late 2016. Gmail (unofficially) cited security as one of the reasons. I don’t know what keeps the Gmail team up at night, but I bet it’s not how email developers can’t optimize their email layouts. I bet it’s security. And so that’s where the gmail dev work gets focused.
Overall email clients do their job relatively well. Since HTML/CSS support matters to so few people, changing it is likely not often a priority for product teams that make email clients.
However, things are trending in the right direction. Gmail and Yahoo! app began supporting media queries in most of their products. Outlook on iOS got a huge facelift including good markup support. New email clients that crop up (Mailbox, Nylus. Polymail) generally have good HTML/CSS support compared to the web. Rarely does support go backwards. The majority of clients based on market share use “modern rendering engines”.
Additionally we can always reference our own email analytics. Don’t have many Outlook subscribers? Then code an email using <div>s. Don’t need to support every mobile client? Then use media-queries.
Related
Closed. This question is opinion-based. It is not currently accepting answers.
Want to improve this question? Update the question so it can be answered with facts and citations by editing this post.
Closed 2 years ago.
The community reviewed whether to reopen this question 1 year ago and left it closed:
Original close reason(s) were not resolved
Improve this question
Which syntax and features should I use if I wanted to write a webpage that could be correctly parsed by any device realistically still in use?
By currently in use I mean also devices whose usage is not statistically meaningful to be included on browser usage statistics, but still reasonable enough to be used in the real world without being too much of a stretch: e.g. A screen reader, a Point-Of-Sale/Kiosk Device, an Internet appliance like a smart TV or a console.
I've recently been assigned to develop an HTML landing page requiring support for - hear me out - the ancient Microsoft Internet Explorer 6. Yes, you read that right.
Long story short, it was in the requirements for a public administration project that was in a legal limbo for a long time, and reworking these requirements would be more problematic than developing it and be done with it. At least according to my boss. Besides, it shouldn't be that much different than writing a current-day HTML newsletter.
But it got me thinking - what's the oldest browser (as in, the one with the oldest HTML standard support available) that I could realistically find in the wild?
I'm not talking about relevance or caniuse-level-of-support numbers, just something that for some more-or-less realistic reasons (excluding "here's a Windows 3.1 VM getting to the internet" retro challenges) people would still be using to get online. Also some security requirements (mostly updated SSL/TLS) cut off quite a bit of older devices, mostly games consoles like the Dreamcast, PS2 w/Network Access Disk and the PSP, or the original Nintendo DS, so those are also excluded.
Other than the aforementioned IE6.0, I can think of Opera Mini browser (which version?) for some legacy mobile phones, or maybe some kind of internet appliance still using the Netfront runtime (IIRC The Playstation 3 still uses a pre-webkit version of it).
Any suggestion?
preword - apologies this became a bit of a rant, I will try and tidy it up later and focus it more. I also understand you may have to listen to your boss so this has become me ranting on your behalf to your boss. I hope you can use some of it to construct a strong argument with your boss to get the spec changed. It also doesn't answer the question as it is titled. Probably worth a few down votes but I enjoyed having a rant!
Given the comment the OP asked this answer is applicable to that.
What are the oldest browser standards I need to support for accessibility?
The WebAIM annual survey is a great place to get this information.
Under the section 'Browsers' we can see that 2.1% of respondents still use IE 6,7 or 8.
Unfortunately they do not indicate what split of those who use IE6 but I would imagine it would be less than 0.1% overall as very few sites still operate on IE6 correctly.
I personally develop to IE9 standards, so use ES5 for JavaScript (or compile to ES5), HTML 5.0 features and CSS3 non-experimental features.
The reason for this is that those who do use IE8 and below tend to be screen reader users due to compatibility with the software they own. They also tend to use a very specific set of websites due to the fact that most websites just will not work for them.
Many people would argue that you must include everyone, and in an ideal world you should. However you also have to consider that your goal in accessibility is to provide the best experience possible for the widest number of people. This is not possible using IE8 and below as you lose a lot of the HTML5 standards that are useful for accessibility (particular form related attributes, navigating by regions such as <main>, <nav> etc.).
So what about the people stuck on IE6-8 then?
As stated they tend to be screen reader users. The beauty of this is that as long as you develop valid HTML, user correct WAI-ARIA attributes etc. (basically go for AAA WCAG 2.1 rating or as close as possible, at least AA rating) then in IE6-8 the site will still function reasonably well and be usable, even if not perfect.
CSS is where your main struggle will be, making a site work in IE6 is just horrible if you still want to follow best practices (try styling a button for example to make the font size large enough and colour contrast AAA rated). Also how do you then make it responsive for mobile users without hundreds of hacks?
So what if you have to support older browsers.
You can provide a separate version of the site (shock, horror, gasp).
Use user agent sniffing to redirect people to a separate, stripped back, text only with minimal styling version of the site. Be sure to include a link to the main site and indicate that this is a version of the site designed for older browsers.
This requires careful planning as you have to ensure that the same information is maintained on both sites and that features introduced are replicated across both sites.
This is why nobody does this and isn't something I would recommend at all. The amount of things to consider, the limitations on features you can introduce and the chance of updating one version and not the other (even with a Content Management System) is very high. Making just one of those mistakes is likely to cause you more problems than not implementing this at all.
Conclusion
HTML5 introduces many great features for accessibility.
Regions for navigation are one of the biggest wins.
By designing to older standards you will likely end up with a site that is less accessible.
For example, a lot of WAI-ARIA attributes don't work in modern browsers, never mind in older browsers. Trying to fall back to using WAI-ARIA attributes is not going to work.
What about an accessible and easy to use layout? IE6 was the days of tables for layouts because CSS was so limited with positioning. (want a sticky navigation bar? Good luck implementing that!)
To provide 'best effort' I would use a HTML5 shim to at least fix the layout for things like IE7 and IE8, IE6 just isn't feasible.
Another argument is security. How on earth are you meant to write secure JavaScript that is IE6 compatible. Heck try finding a single piece of information alive on the internet today on 'how do i fix this problem in IE6'. Perhaps your solution here is to just not use JavaScript at all. (and yes someone will argue progressive enhancement allows you to use JavaScript, but then you have JavaScript errors which would then mean you fail WCAG under 'Robust').
Oh and did you know that you can't even use <style>*{position:relative}</style><table><input></table> as that will crash the browser?
As a final thought on this rant part, Windows 98 will run IE9 and NVDA. So we cannot make the argument that people may not have the financial resources to upgrade as NVDA is free. We could argue they do not have the technical knowledge on how to upgrade, at which point all I could say is write an article on the site on how to upgrade and redirect people there maybe? It gets a bit silly at that point as to where you draw the line.
How to win the argument with your boss / help them get the spec changed
Your boss is in a bad position but probably doesn't have the 'firepower' they need to persuade the spec to be changed easily.
Here is a simple way for them to win the argument:
WCAG 2.1 AA is the minimum legal standard that we can build this site to without risking getting sued.
This is impossible while maintaining compatibility with IE6 and without compromising on accessibility features.
The cost of getting accessibility wrong, coupled with the additional development cost associated with trying to develop to such an old standard makes this infeasible.
Couple that with the likelihood of developing a application with massive security flaws that could make the site vulnerable I would highly recommend we change the minimum requirements to IE8.
tl;dr
The oldest browser you realistically need to worry about is Internet Explorer 9. Even then you are being generous with your compatibility requirements. Do not try and develop a site that works in every browser ever encountered since 2001 (yes IE6 was 2001), you will break things for more people trying to accommodate people who do not want to upgrade (Windows 98 will run IE9 and NVDA).
Do not attempt to support IE8 and below as you will actually end up making decisions that will negatively impact accessibility.
If you can create a HTML5 valid and CSS3 valid website that is WCAG 2.1 AA standards compliant then you are already more accessible than 99% of websites in the world.
You're not asking the right question.
Users of what I build may be different than the users of what you build. To one audience, it may not matter if the site only loads on current browsers. To another audience, it may be the only thing that matters.
Additionally, some sites outright require newer browser features to function... no web-based fallbacks are available. Also, there are current browsers that don't support much of anything (i.e. Safari, Lynx, etc.) so it's not necessarily a matter of age... but capability.
The question you should be asking is, how do you make the decision of what to support and what not to support. Short of pointing you at your analytics and logs, this isn't a technical question, but a business question.
Closed. This question is not about programming or software development. It is not currently accepting answers.
This question does not appear to be about a specific programming problem, a software algorithm, or software tools primarily used by programmers. If you believe the question would be on-topic on another Stack Exchange site, you can leave a comment to explain where the question may be able to be answered.
Closed 6 months ago.
Improve this question
Yahoo web mail (mail.yahoo.com) is stripping out these inline styles, but keeping things like color and padding.
text-decoration
font-size
border-radius
text-align
font-family
Any idea why these are purposely being removed?
Example:
<span style="font-size:30px;">Hello</span>
becomes:
<span style>Hello</span>
What can be done?
This is the difficult part because options are few. Even with free market choices well established corporate entities have little to no business reasons to improve their products unless competition comes along. You could always attempt to file a bug report (like, where if even any where though...) and as usual wait decades for a(n intelligent) response (*cough* Mozilla *cough*). You could attempt to work around the issue (replace width with min-width in example). I've noticed that font-size: 120%; works just fine so consider what unit values you're using for testing.
You can make a different though, even if it's relatively small. I was wronged by a motherboard manufacturer in the mid-2000s and since then they've lost tens of thousands of dollars of sales because of me directly and who knows how much more based on the video I posted back then and that is just in the past ten years. The issue with Yahoo is different, at best all you can do is write a blog entry and link to other people talking about the issue to raise awareness. You could go so far as to disallow registrations from users with Yahoo accounts or greatly discourage users from using Yahoo accounts though that could lead to a loss of members so I wouldn't do something like that unless you've got something people really want. The state of HTML email in general is exceptionally sad at this point though most (at least technical users) typically have multiple email addresses.
You could always use <style type="text/css"></style> even though scoped CSS is not widely supported in 2017 except for Gecko/Firefox though it did seem to fix some of the issues for me that you mentioned you were having.
Lastly you can always provide a "view this email on our website" option; I see it all the time because HTML email is still a disaster (2017). I've even seen nonsense with developers sending email with html element (uh, it's not an entire page, it will be embedded, but you know, whatever...).
So try utilizing different unit values and even the contexts themselves. Inline-styling is the way to go and if that fails provide a website version of the email (with security considerations for email with sensitive data).
Closed. This question is opinion-based. It is not currently accepting answers.
Want to improve this question? Update the question so it can be answered with facts and citations by editing this post.
Closed 9 years ago.
Improve this question
Having ranged through a number of support indices and point - trouble - shooting, templates and tutorials, I felt like I was struck by a thunderbolt when it occurred to me that I should be making all my emails to work in Gmail first, because I don't recall at least ever seeing that as a specific recommendation.
This is assuming I have elements I may want to be visible depending on the user's device/screen, and as such, out of all the email clients I've been hassled by, Gmail is the least flexible since it doesn't support any embedded styles. So, to me, it would make the most sense to layout the email for how it should work in Gmail, then add on to it from there primarily with embedded styles.
As per the question guidelines, I'm not looking for opinions about this, but technical limitations that you all could foresee arising as a result of this workflow. That being said, what would they be, if any?
I've been slicing emails for a very long time and have watched the changes (or lack thereof) over the years. I don't think in terms of "GMail" or "Outlook" first but rather what I consider the three basic categories of HTML emails: fixed, fluid or responsive (or a combo of one of the first two and responsive, too).
A properly done fixed email looks the same everywhere and is supported by every major email client. A fluid email will change on every email client but the changes will be relative to neighboring changes and can for the most part be predicted. A responsive email, although similar to a fluid email, has much more granular control over rendering and can actually set the "fluid rules" based on screen size.
Depending on your target audience, my recommendation to you would be to build a fixed email that looks awesome (you're worst case scenario) and then add styles to the <body> tag to handle responsive to make it even more awesome. Once you get the knack for building fixed emails it goes pretty fast so you'll spend most of your time in the responsive side of things.
View Campaign Monitor's Guide to CSS for the most comprehensive guide of supported CSS in email clients. In general, before you use a certain type of css you should see what email clients are supported. Gmail would be a good reference point to start, but you will want to be aware that there are some elements that will not work in some other clients.
Closed. This question is off-topic. It is not currently accepting answers.
Want to improve this question? Update the question so it's on-topic for Stack Overflow.
Closed 11 years ago.
Improve this question
Has anyone, with a large sampling, done research on how many users actually print webpages? I'm looking for some percentage values. .01%, 1%, etc actually print webpages.
It seems like a waste of time, to create design oriented print pages, if the stats extremely low.
It is very easy to create some print styles for your stylesheet to make printing easier on people.
As an example: http://www.alistapart.com/articles/goingtoprint/
In the same way that not everyone who visits your site will be disabled, the best practice is still to create sites that work for people with accessibility problems.
I don't have a link to a study for you but I'm very confident that it depends heavily on the type of content. I.e. the percentage of people who print a youtube video page is for sure much lower than those who print a recipe from a online cookbook.
So it's probably best to run your own study on the particular website where you need it. You can either make a little poll for the users of your site or track how often pages actually get printed.
This is not a metric that is usually tracked.
Since one needs to differentiate the regular page from the printable page, this requires a custom implementation on the printable version page that sends a particular tracking code/cookie.
It is not that hard to implement, one can even have printable pages tracked in google analytics or any analytic engine, but as I said it does require preparation and most people don't track this metric in particular.
It is possible through JavaScript to track the actual printing event with IE browsers. Considering users most likely won't switch to IE just to do the printing, it would give some sort of accurate indication of what % of the IE users, print the page.
For more information about the onbeforeprint and onafterprint events have a look at:
http://msdn.microsoft.com/en-us/library/ms536672(v=vs.85).aspx
Btw, I am not saying that collecting this data solely from IE users would give an accurate indication of the overall % of printed pages across all browsers, because IE is far more commonly used in office environments rather than home environments.
Closed. This question is opinion-based. It is not currently accepting answers.
Want to improve this question? Update the question so it can be answered with facts and citations by editing this post.
Closed 4 years ago.
Improve this question
HTML 5 has interesting features for developer and user, but if customers are still demanding to have support for old browsers should designer/developer go for HTML 5 ? Or should stick to good old ways using JavaScript libraries, flex and flash to do the heavy lifting.
If accepting HTML 5 is too early, how long you think it will take to use HTML 5 features for big web application? (hear by big i mean application still reaching huge number of users with different OS and browsers combination)
Do you think HTML5 will carry all the issues(cross browser stuff) that web developers have faced over decade, or it will make life easier?
In a word: Yes.
People are STILL using IE6, and will be using IE7 for many years to come. If you're creating a public-facing application then you have to take into account browsers that may be being used by millions of potential visitors.
There are features that will degrade gracefully, and those are great.
If you're building a web based app that's not public, then you can go ahead an use whatever you like. I do a lot of development work where the final project is limited to a specific browser but in those cases the application is never available to the public.
Sitepoint has some very nice articles about this very subject:
http://articles.sitepoint.com/article/html-5-snapshot-2009
http://www.sitepoint.com/blogs/2009/05/26/html-5-now-or-never/
Also, check out the following to see what browsers support what new up-and-coming (or been here a while) features:
http://a.deveria.com/caniuse/
No, I think it isn't early.
Start now and slowly start adopting new elements (except video/audio as they are the least supported). For IE, you have JS solution that adds new elements and adds ability to style them.
Try, really. You'll see how much it's easier to tag your document :)
When people talk about "cross browser issues" they almost always mean "IE issues". Modern browsers, that is, anything but IE, pretty much work well with modern standards and practices and dumbing down the web just for IE is just sad.
There are a number of javascript workarounds to make older, non-standard browsers like IE work with HTML5 though I don't recall them off the top of my head but parts of HTML5 can be made to work easily in IE; such as the new elements aside, section, etc.
In my situation, we just completed an ecommerce solution using HTML5 elements with no problems but had to include the workarounds and hacks for IE.
Naturally, you need to take your audience into account. Check your analytics. But there are some great tools if you want to take advantage without leaving everyone behind:
<!--[if IE]>
<script src="http://html5shiv.googlecode.com/svn/trunk/html5.js"></script>
<![endif]-->
I'd also recommend you take some time at html5doctor.com where they discuss what can and can't be used now. A really cool resource they are working on is the html5 reset: html5doctor.com/html-5-reset-stylesheet/
Oh, and use ogg ;)
I recommend you take in use any new feature you think is interesting but make them degrade gracefully. It can be a bit of work, but that's the life you choose if you go outside the life of using libraries. However you will probably learn some very valuable skills.
Using HTML 5 isn't an all-or-nothing solution, much like CSS3 there are specific features you can start using today that will enhance your sites for browsers capable of using them.
It's up to you to make a decision on what those features are and how far you can take them. If IE6 and no-Javascript are big factors in your audience, then this will likely be limited. However, if you are happy for those users to get a not-so-pretty but still-usable experience then go ahead!