It seems sometime to work fine and sometimes not, so in should I use divs inside form or not?
and in general is there a guide for what HTML tags will not work inside other tags?
Divs do not cause any intrinsic problems inside forms. Any CSS rules or JS that might get applied to them may cause problems, but the same is true of any element.
The HTML 4.01 specification includes a guide on how to read DTDs. This is applicable for HTML 3.2 and 4.x as well as XHTML 1.x. HTML 5 does not have an official DTD, so you have to pay attention to the "Content model" for each element in the spec.
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
I'm trying to extract just the html, without the encapsulating <!doctype>, <html> and <body> tags.
I've seen this question asked before many times, and the answer is always to exclude the "fullpage" plugin.
However, that plugin is no longer used in tinymce 6.
It seems that the classic editor version of tinymce now always uses an <iframe>, and those unfortunate encapsulating tags are passed along as a consequence.
For the sake of robustness I don't want to have to strip them out in the back end if I can help it; is there a way to extract just the html content in tinymce 6?
You would need to provide more details on what you are doing when you extract the content from TinyMCE.
In my quick testing simply using getContent() to extract the data from TinyMCE does not include any of those tags:
https://fiddle.tiny.cloud/MChaab/3
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.
I am trying to create a Editor component that will take inline javascript.
I understand that I can use clientlibs folder for loading JS, but some of the video CDN folks require you to put embed tags with JavaScript in the editor, and I think some of that is also used for rapid development. Currently with the state of RTE, I cannot put a script <script/> tag even after extending it, as it strips it out and only takes the html tags.
Could you please provide any insight if this could be doable in AEM 6.1
Here's what I have tried:
I looked at several post didn't got a clue
extended RTE using Adobe's documentation, but see a script button, that only takes html tags.
looked for hacks that could tell me what part of the code is tripping out </script> tags or could not execute js.
looked for some components out there that does that, found nothing
so far.
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?