In any CMS based site after my work in future client or any client's staff (non-technical) will update website through WYSIWYG editor and it's surely possible they could use deprecated tag or any non-semantic and non validated code. so in this condition would it be better to use transtional doctype over strict for CMS based site?
Asked
Active
Viewed 326 times
4 Answers
1
Depending on the text editor engine used in your CMS, it may generate both invalid transitional markup as valid strict markup. For instance, if you use TinyMCE for text editing, it generates quite good HTML. If you use plain iframe with designMode enabled, it generates a real HTML mess out of it in Internet Explorer. So I'd say, WYSIWIG controls is not a good criteria for deciding if to use transitional or strict markup.
naivists
- 32,681
- 5
- 61
- 85
-
main problem is when client want to give any presentation to any text then WYSIWYG give inline style with – Jitendra Vyas Jan 01 '10 at 16:41
1
We use a strict doctype for our Sitecore 6 site. By default, Sitecore won't publish items that contain invalid html (rich text) fields, and you can limit the buttons/options available in the WYSIWYG mode.
Adam Hopkinson
- 28,281
- 7
- 65
- 99
-
Sitecore won't stop publishing , juss would give red error but we can publish. http://alexeyrusakov.com/sitecoreblog/2008/07/03/Sitecore+6+Validation+Part+2.aspx – Jitendra Vyas Jan 04 '10 at 04:09
-
It can be configured to still publish, but the out-of-the-box behaviour is to disallow publishing of items with invalid xhtml – Adam Hopkinson Jan 04 '10 at 09:51
0
Use HTML5 doctype. Just
<!DOCTYPE html>
WYSIWYG editors must not make errors, but HTML5 will perform normally and validate when XHTML Strict will fail.
myfreeweb
- 971
- 1
- 13
- 19
0
I'm sure the will find a way to break the validation of any doctype. so you shouldn't care about this. Here is a good explanation:
If you want a "safe" markup. enrich your backend form. dont just give them a plain textarea. provide image upload functionality. distinct input fields for heading, subheading, dates ect. Maybe even do a switch to markdown (if the user dont know html anyway)? that will lower the risk of a broken markup much more rather then choosing the most forbearing doctype.
