I have seen bunch of HTML email templates example and all of them use <table> element for layout. Is there any specific reason for using <table>? I tried making one without it and it works for me. Should I be worried that it might break for someone else with different browser?
The main reason tables are still used nowadays is to support Outlook 2007/2010/2013. Those versions use Microsoft Word engine to render HTML, and it's quite a mess. It has a limited support for CSS (no float or position for example), and some CSS properties are only supported on some specific HTML elements. For example, padding is supported on a , but not on a . And even when you could theorically use padding on more semantical elements (like tags), or use margin on elements instead, Word's rendering engine is still massively bugged and can have unpredictable behavior with such HTML and CSS code. Thus, developers find it easier to just use instead.
But here's the thing : if you don't feel like you need to support Outlook 2007/2010/2013, then you can absolutely ditch tables and use better code instead. And even if you need to support it, simple one-column layouts can be done without tables. The reason your template works in Outlook 2011 is that this version (for Mac only) uses WebKit rendering engine (just like in Safari or Apple Mail).
Referring to this old post(why-is-it-still-recommended-to-use-tables-for-email-structure) and some of my own experiments:
We can definitely use HTML tags and not just <table> tag. It gets rendered well in modern browsers. I have personally experimented with Chrome ( which most probably means it works on all chromium based browsers ) and Safari.
Another thing I noticed is, the email clients stripped the template and removed all tags except the main content. In other words, it only rendered what's inside the <body> tag and removed other tags like <html>, <head> including the <body> tag itself. So I don't use those tags in my template at all.
Related
This question already has answers here:
Closed 11 years ago.
Possible Duplicate:
HTML: What is the functionality of !DOCTYPE
I recently asked a question here and the solution was a simple:
You need to add a doctype to the page. This should fix the issue for you.
Now, my pages work fine in every browser without the doctype (except IE). Does IE need a doctype (is this an IE only thing) and do other browsers just assume it OR or is it doing something I'm not seeing.
What are its functions and how does it work?
All browsers need the doctype. Without the DOCTYPE you are forcing the browsers to render in Quirks Mode.
However, DOCTYPE was only partially used by the browsers in determining dialect and parsing, even though that was the purpose. This is why HTML5 has reduced the DOCTYPE to simply:
<!DOCTYPE html>
2.2. The DOCTYPE
The HTML syntax of HTML5 requires a DOCTYPE to be specified to ensure that the browser renders the page in standards mode. The DOCTYPE has no other purpose and is therefore optional for XML. Documents with an XML media type are always handled in standards mode. [DOCTYPE]
The DOCTYPE declaration is <!DOCTYPE html> and is case-insensitive in the HTML syntax. DOCTYPEs from earlier versions of HTML were longer because the HTML language was SGML-based and therefore required a reference to a DTD. With HTML5 this is no longer the case and the DOCTYPE is only needed to enable standards mode for documents written using the HTML syntax. Browsers already do this for <!DOCTYPE html>.
Source: HTML5 differences from HTML4: DOCTYPE
The Doctype does two things.
It identifies which dialect of HTML you're using.
It controls whether the browsers uses "standards" or "quirks" mode to render the document.
If there is no doctype, or there's an unrecognized one, then it uses "quirks" mode and interprets the document as best it can. If there IS a doctype, and it recognizes it, then it follows the standards. The results of the rendering can vary depending on how it interprets the document.
Why?
Why specify a doctype? Because it
defines which version of (X)HTML your
document is actually using, and this
is a critical piece of information
needed by some tools processing the
document.
For example, specifying the doctype of
your document allows you to use tools
such as the Markup Validator to check
the syntax of your (X)HTML. Such tools
won't be able to work if they do not
know what kind of document you are
using.
But the most important thing is that
with most families of browsers, a
doctype declaration will make a lot of
guessing unnecessary, and will thus
trigger a "standard" rendering mode.
Source: http://www.w3.org/QA/Tips/Doctype
You should have a DOCTYPE for ANY browser. It tells the browser how to interpret the html and css. This is why html4 and html5 have different definitions (as does xhtml). All very important for validation.
What IE will do is put the document into what it calls 'quirks mode' which basically ignores a whole heap of rules for how CSS should (by modern definitions) behave. Here is a good summary of the issue. It harks back to the bad old days of non-standardised CSS support
Browsers need at the least to render in what is known as standards mode. See John Resig's article on the html 5 doctype: http://ejohn.org/blog/html5-doctype/. Now if you want your browser to not use standards and render like its 1990 go ahead and not add anything and you will see floats and other now standard items not work correctly. If you want to have your page render/validate in accordance to a particular standard then you would want to add more to the doc type but it is not necessary.
From W3Schools, a doctype is "an instruction to the web browser about what version of the markup language the page is written in." (http://www.w3schools.com/tags/tag_doctype.asp)
If you do not include the doctype, the browser may assume you are using a different language than you really are, causing it to be rendered incorrectly.
From W3Schools.com:
The doctype declaration is not an HTML
tag; it is an instruction to the web
browser about what version of the
markup language the page is written
in.
There are a handful of different doctypes, and changing them can drastically change how your page renders.
The doctype declaration should be the
very first thing in an HTML document,
before the tag.
The doctype declaration is not an HTML
tag; it is an instruction to the web
browser about what version of the
markup language the page is written
in.
The doctype declaration refers to a
Document Type Definition (DTD). The
DTD specifies the rules for the markup
language, so that the browsers render
the content correctly.
Reference
Upon migrating my old web interface with extensive use of jQuery Tmpl, some of my templates have ceased to work. Further investigation shows that the templates not working are the ones starting and ending with TR tags (i.e. table rows getting appended to an existing table). The source text just gets removed by the jQuery Tmpl script! If I use the TR tags in a broader context like wrapped in a table etc everything works just fine, but as soon as they are used in an isolated template, they get wiped out.
working example:
<script id="workingTemplate" type="text/x-jQuery-tmpl" >
<table>
<tr><td>this works</td></tr>
</table>
</script>
not working example:
<script id="notWorkingTemplate" type="text/x-jQuery-tmpl" >
<tr><td>this does not work</td></tr>
</script>
The first example renders the full HTML code when checking with Firebug, the latter renders an empty SCRIPT tag.
The difference between the old and the new web interface that could in any way be related to the templating is a change from jQuery 1.5.2 to 1.8.2. I haven't tried running anything below 1.7.2 since this is where the .on() function got added, and the new framework has an extensive use of this method.
Are there any workarounds for this problems except the most obvious (= changing templating framework to something still maintained)?
EDIT:
When loading the template from a string, the content stays intact,
$.template( "tableRowTemplate",'<tr><td>this works</td></tr>');
$.tmpl("tableRowTemplate", data).appendTo('TABLE#mytable TBODY');
but is unfortunately no good for me since my templates are a tad more complicated than the examples (server side dynamics etc...). It does give some hints though. Obviously, it is the initialization of jQuery Tmpl that removes the content if it does not comply with something to me unknown. Maybe jQuery.fn.domManip?
Hi I am building a small web based email client. I am facing problems in displaying HTML mails. What are the best practices involved in displaying an HTML mail? Some things I found
Css Reset
Strip body tag in the mail
First of all, it's important to not allow all the CSS and HTML tags. I would look for the file and allow a defined set of HTML tags and CSS attributes.
For example, if you reset the CSS, you can still send stuff like <iframe>, <form> and all other possible malicious tags.
So I would start of thinking what kind of HTML tags would you like to support, and strip all other ones out of it. And then the same for the CSS.
This is by no means easy. I mean you also would have to take in account things like people trying to break your interpreter...
You could look into this Sitepoint Blogpost, it describes how people should code HTML-emails. So it might be a good idea to start there and see what's usually supported.
The one sentence answer would be "1. Use table-based layouts, 2. only inline CSS, and 3. test in every email client possible."
The client testing is probably the most important because every email client (and client + browser combination) may have its own quirks and many are just learned along the way; such as using HTML attributes width & height because Outlook won't always follow the inline styles for width & height, or that Gmail tends to add margins around images unless you explicitly set margin:0 for the HTML elements, etc. etc.
When fixing the look of an HTML email in one client ends up breaking it in another client, don't keep adding more and more styling: try to simplify the HTML/CSS, even if it means writing more markup. For example, if padding and margins don't look right, the same look could be achieved by adding more rows or columns to the table and fixing their heights/widths. More tags is simpler than worrying about how all the email clients will render the CSS box model.
There's a lot of articles and blog posts on HTML-for-email such as http://articles.sitepoint.com/article/code-html-email-newsletters that are helpful -- though a lot are out of date with newer versions of clients.
How does the Reader function of Mobile Safari in iOS 5 work? How do I enable it on my site. How do I tell it what content on my page is an article to trigger this function?
A lot of the answers posted here contain false information. Here are some corrections/clarifications:
The <article> element works fine as a wrapper; Safari Reader recognizes it. My site is an example. It doesn’t matter which wrapper element you choose, as long as there is one, other than <body> or <p>. You can use <article>, <div>, <section>; or elements that are semantically incorrect for this purpose, like <nav>, <aside>, <footer>, <header>; or even inline elements like <span> (!).
No headings are required for Reader to work. Here’s an example of a document without any <h*> elements on which Reader works fine: http://mathiasbynens.be/demo/safari-reader-test-3
I posted some more details regarding my findings here: http://mathiasbynens.be/notes/safari-reader
I've tested 100 or so variations of this on my iPhone in order to figure out what triggers this elusive Reader state. My conclusions are as follows:
Here is what I found had an impact:
Having around 200 or more words (or 1000 characters including whitespace) in the article you want to trigger the "Reader" seems necessary
The reader was NEVER triggered when I had less than 170 words; although it was sometimes triggered when I had 180 or 190 words.
Text inside certain elements such as <ol> or <ul> (that are not typically used to contain a story) will not count towards the 200 words (they will however be displayed in the reader if the reader is triggered for other reasons)
Wrapping the 200 words in a block element such as a <div> or <article> seems necessary (that said, I'd be surprised if there were any websites where that was not already the case)
For full disclosure, here is what I found did NOT have an impact:
Whether using a header or not
Whether wrapping the text in a <p> or letting it flow freely
Punctuations (ie removing all periods, commas, etc, did not have an impact)
It seems the algorithm it is based on is looking for p-Tags and it counts delimiters like "." in the innerText. The section (div) with the most points gets the focus.
see:
http://lab.arc90.com/experiments/readability/
Seems to be the base for the Reader-mode, at least Safari attributes it in the Acknowledgements, see:
file:///C:/Program%20Files/Safari/Safari.resources/Help/Acknowledgments.html
Arc90 ( Readability )
Copyright © Arc90 Inc.
Readability is licensed under the Apache License, Version 2.0.
This question (How to disable Safari Reader in a web page) has more details. Copied here:
I'm curious to know more about what triggers the Reader option in Safari and what does not. I wouldn't plan to implement anything that would disable it, but curious as a technical exercise.
Here is what I've learned so far with some basic playing around:
You need at least one H tag
It does not go by character count alone but by the number of P tags and length
Probably looks for sentence breaks '.' and other criteria
Safari will provide the 'Reader' if, with a H tag, and the following:
1 P tag, 2417 chars
4 P tags, 1527 chars
5 P tags, 1150 chars
6 P tags, 862 chars
If you subtract 1 character from any of the above, the 'Reader' option is not available.
I should note that the character count of the H tag plays a part but sadly did not realize this when I determined the results above. Assume 20+ characters for H tag and fixed throughout the results above.
Some other interesting things:
Setting for P tags removes them from the count
Setting display to none, and then showing them 230ms later with Javascript avoided the Reader option too
I'd be interested if anyone can determine this in full.
Both Firefox and Chrome have the similar plugin named iReader. Here is its project with source code.
http://code.google.com/p/ireader-extension/
Read the code to get more.
I was struggling with this. I finally took out the <ul> markings in my story, and viola! it started working.
I didn't put any wrapper around the body, but may have done it by accident.
HTML5 article tag doesn't trigger it on my tests. It also doesn't seem to work on offline content (i.e. pages saved on your local machine).
What does seem to trigger it is a div block with a lot of p's with a lot of text.
The p tag theory sounds good. I think it also detects other elements as well. One of our pages with 6 paragraphs didn't trigger the Reader, but one with 4 paragraphs and an img tag did.
It's also smart enough to detect multi-page articles. Try it out on a multi-page article on nytimes.com or nymag.com. Would be interested to know how it detects that as well.
Surprising though it may be, it indeed does not pay any attention to the HTML5 article tag, particularly disappointing given that Safari 5 has complete support for article, section, nav, etc in CSS--they can be styled just like a div now, and behave the same as any block level element.
I had specifically set up a site with an article tag and several inner section tags, in prep for semantic HTML5 labeling for exactly such a purpose, so I was really hoping that Safari 5 would use that for Reader. No such luck--probably should file a bug on this, as it would make a great deal of sense. It in fact completely ignores most of the h2 level subheads on the page, each marked as a section, only displaying the single div that adheres to the criteria mentioned previously.
Ironically, the old version of the same site, which has neither article, section, nor separating div tags, recognizes the whole body for display in Reader.
See Article Publishing Guidelines.
Here are APIs about how to read and parse: Readability Developer APIs. There's already a project you can refer: ruby-readability.
A brief history:
The Safari Reader feature since Apple's Safari 5 browser embeded a codebase named Readability, and Readability started off as a simple, Javascript-based reading tool that turned any web page into a customizable reading view. It was released by Arc90 (as an Arc90 Lab experiment), a New York City-based design and technology shop, back in early 2009. It's also embeded in Amazon Kindle and popular iPad applications like Flipboard and Reeder.
I am working on algorithms for cleaning web-sites from information "waste" similar to Safari Reader feature. It's not so good as readability but has some cool stuff.
You can learn more at smartbrowser.codeplex.com project page.
Update: Please disregard, my problem was caused by an advertisement bar being inserted by the vendor who provides my workplace wireless service.
I was building a mobile friendly website and wanted to use HTML 5. However when I specify the doctype as <!DOCTYPE HTML> , I get a gap at the top of the page on safari on the iphone.
I notice that other sites have the same problem such as nextstop.com and nike.com
I guess safari does not fully support HTML 5 yet. Anybody know of a workaround?
HTML 5 is still in a very unstable state. Don't use it in a production environment.
Edit Just so you guys know what it's about, HTML 5 is currently an Editor's Draft, and the document clearly states (in the Status of This Document section) that this specification is not stable, and that a consensus may not have been reached on any of the proposed sections. I think it should be clear enough that it means it's a bit early to start using it.
All browsers correctly interpret the HTML doctype. Putting it in sets your browser into Standards Compliant mode, that is the only difference with or without the doctype.
You can use a CSS reset tool like http://meyerweb.com/eric/tools/css/reset/ to get rid of default margins and padding on all elements.