I am using UI for ASP.NET for AJAX Q2 2014 in a web project.
We are using RadEditor for creating content items for HTML email newsletters.
I am using the code below to set the set the editor filters on the Page_Load event but the editor is still rendering and saving styles instead of attributes.
??
We are using RadEditor for creating content items for HTML email newsletters.
I am using the code below to set the set the editor filters on the Page_Load event but the editor is still rendering and saving styles instead of attributes.
??
protected void SetEditorFilters(){ // DISABLE DEFAULT FILTERS txtContentHTML.ContentFilters = Telerik.Web.UI.EditorFilters.None; // SET DESIRED FILTERS txtContentHTML.EnableFilter(Telerik.Web.UI.EditorFilters.ConvertInlineStylesToAttributes); txtContentHTML.EnableFilter(Telerik.Web.UI.EditorFilters.FixEnclosingP); txtContentHTML.EnableFilter(Telerik.Web.UI.EditorFilters.FixUlBoldItalic); txtContentHTML.EnableFilter(Telerik.Web.UI.EditorFilters.IndentHTMLContent); txtContentHTML.EnableFilter(Telerik.Web.UI.EditorFilters.MakeUrlsAbsolute); txtContentHTML.EnableFilter(Telerik.Web.UI.EditorFilters.OptimizeSpans); txtContentHTML.EnableFilter(Telerik.Web.UI.EditorFilters.RemoveScripts); }6 Answers, 1 is accepted
0
Randy
Top achievements
Rank 1
Rank 1
answered on 07 Aug 2014, 04:30 PM
Clarification: I am specifically having an issue with spacing around an image. The image properties dialog sets CSS margins for the image, but the ConvertInlineStylesToAttribute ignores those and does not convert them to hspace and vspace attributes.
When the content is viewed in Outlook, the text crammed up against the image.
This has been the greatest frustration with the RadEditor to date!
I need to get this resolved ASAP for my customers.
When the content is viewed in Outlook, the text crammed up against the image.
This has been the greatest frustration with the RadEditor to date!
I need to get this resolved ASAP for my customers.
0
Hi Randy,
The hspace and vspace attributes are not respected by the editor filters because they are not supported in HTML5. More about the unsupported attributes is available in this forum discussion.
If these attributes are needed and Outlook cannot handle proper CSS margin stylization, I can suggest implementing a custom content filter that transforms the margins to the desired attributes.
Regards,
Ianko
Telerik
The hspace and vspace attributes are not respected by the editor filters because they are not supported in HTML5. More about the unsupported attributes is available in this forum discussion.
If these attributes are needed and Outlook cannot handle proper CSS margin stylization, I can suggest implementing a custom content filter that transforms the margins to the desired attributes.
Regards,
Ianko
Telerik
Check out the Telerik Platform - the only platform that combines a rich set of UI tools with powerful cloud services to develop web, hybrid and native mobile apps.
0
Randy
Top achievements
Rank 1
Rank 1
answered on 11 Aug 2014, 02:02 PM
I can certainly look into creating a custom filter.
In researching this issue, I discovered a number of forum threads from developers using the editor for email-based marketing and running into email clients that don't support CSS - especially Outlook. I was under the impression that ConvertInlineStylesToAttributes was - in part - a response to those issues.
It's also well established that Outlook does not support CSS in the content of email messages in any predictable manner. So it seems to me that not addressing Outlook image alignment issues for email marketers - which was specifically requested in the forum posts I read - was a bit short-sighted. This means that an identified portion of your customers are forced to each create a solution for a problem they all face.
At a minimum, it would be nice to have a downloadable custom filter for, what I see as an already identified issue, so your customers don't have to keep re-creating the wheel.
With that rant, I am off to create a wheel...
In researching this issue, I discovered a number of forum threads from developers using the editor for email-based marketing and running into email clients that don't support CSS - especially Outlook. I was under the impression that ConvertInlineStylesToAttributes was - in part - a response to those issues.
It's also well established that Outlook does not support CSS in the content of email messages in any predictable manner. So it seems to me that not addressing Outlook image alignment issues for email marketers - which was specifically requested in the forum posts I read - was a bit short-sighted. This means that an identified portion of your customers are forced to each create a solution for a problem they all face.
At a minimum, it would be nice to have a downloadable custom filter for, what I see as an already identified issue, so your customers don't have to keep re-creating the wheel.
With that rant, I am off to create a wheel...
0
Hello Randy,
I can understand your concerns, although you should note that the RadEditor control is used in more complex situations. Providing a valid and proper XHTML content is vital for the Editor users.
Such cases, like the hspace and vspace attributes are the perfect example for the inconsistent behavior of different browser engines. In Outlook they might be preferred, but when it comes to commonly used browsers, they may cause more harms and undesired side effects than the margins in Outlook.
Also, note that the RadEditor is used in a browser and this is why all tools, filters and modules of the control should use and generate valid HTML and CSS.
Indeed, there is the ConvertInlineStylesToAttributes filter, that is designed to serve the desired functionality, although for the sake of the proper Editor behavior we cannot provide a built-in functionality that does not respect the good practices for Web/HTML development.
Let me provide a simple example. Let say we have a filter that converts the margins to the mentioned hspace and vspace attributes. Currently we already know that they are not preferred in HTML5 and may lead to inconsistent behavior, but still we need them in Outlook. That is fine by know, because browsers still render correctly the DOM elements with these attributes. But in future, these attributes might be obsolete and the browser will be not able to render them correctly, setting them to some value will not make changes to the content and the images inside will act as nothing is changed in the DOM. Such behavior would be more harmful and frustrating to the end users.
Indeed, Outlook might not be able to render margins, but it is more likely the rendering engine of Outlook to be updated, so that it could render correctly margins in future.
Such inconsistent issues are best to be handled per case, according the specific scenario. If such scenarios were handled internally, every possible change and update of not so commonly used browser engines would force us to make changes according new specifications and introduce much more breaking changes of the control behavior. This would lead to a product that will force the web developers to change the configuration of the controls e.g., after every major upgrade of the Telerik controls.
This is why it is best such scenarios to be targeted as custom solutions. This way they can be supported easily and every minor change will be handled faster and more properly.
On a side note, for this case it would be better to have a custom server-side logic that ensures the correct HTML to be sent to Outlook mail. This way you will be sure that the content will be correctly rendered in the browser and after server-side logic all possible glitches to be properly translated for the Outlook render engine.
Regards,
Ianko
Telerik
I can understand your concerns, although you should note that the RadEditor control is used in more complex situations. Providing a valid and proper XHTML content is vital for the Editor users.
Such cases, like the hspace and vspace attributes are the perfect example for the inconsistent behavior of different browser engines. In Outlook they might be preferred, but when it comes to commonly used browsers, they may cause more harms and undesired side effects than the margins in Outlook.
Also, note that the RadEditor is used in a browser and this is why all tools, filters and modules of the control should use and generate valid HTML and CSS.
Indeed, there is the ConvertInlineStylesToAttributes filter, that is designed to serve the desired functionality, although for the sake of the proper Editor behavior we cannot provide a built-in functionality that does not respect the good practices for Web/HTML development.
Let me provide a simple example. Let say we have a filter that converts the margins to the mentioned hspace and vspace attributes. Currently we already know that they are not preferred in HTML5 and may lead to inconsistent behavior, but still we need them in Outlook. That is fine by know, because browsers still render correctly the DOM elements with these attributes. But in future, these attributes might be obsolete and the browser will be not able to render them correctly, setting them to some value will not make changes to the content and the images inside will act as nothing is changed in the DOM. Such behavior would be more harmful and frustrating to the end users.
Indeed, Outlook might not be able to render margins, but it is more likely the rendering engine of Outlook to be updated, so that it could render correctly margins in future.
Such inconsistent issues are best to be handled per case, according the specific scenario. If such scenarios were handled internally, every possible change and update of not so commonly used browser engines would force us to make changes according new specifications and introduce much more breaking changes of the control behavior. This would lead to a product that will force the web developers to change the configuration of the controls e.g., after every major upgrade of the Telerik controls.
This is why it is best such scenarios to be targeted as custom solutions. This way they can be supported easily and every minor change will be handled faster and more properly.
On a side note, for this case it would be better to have a custom server-side logic that ensures the correct HTML to be sent to Outlook mail. This way you will be sure that the content will be correctly rendered in the browser and after server-side logic all possible glitches to be properly translated for the Outlook render engine.
Regards,
Ianko
Telerik
Check out the Telerik Platform - the only platform that combines a rich set of UI tools with powerful cloud services to develop web, hybrid and native mobile apps.
0
Randy
Top achievements
Rank 1
Rank 1
answered on 20 Aug 2014, 02:36 PM
I understand your point. However, there have been a number threads by developers tasked with problem of creating email-compliant HTML output. In these cases, browser-compliant HTML5/XHTML output is irrelevant because is almost all cases CSS is stripped and/or replaced by the email client or the service provider's system and the most commonly used email clients are not HTML-5 compliant. The only current path to any consistency in HTML email output is "old school" HTML and its archaic attributes.
Perhaps an "Email-Compliant HTML" filter or a "fall back to 1995" editor mode to accommodate that scenario would be nice. :-)
Perhaps an "Email-Compliant HTML" filter or a "fall back to 1995" editor mode to accommodate that scenario would be nice. :-)
0
Hello Randy,
While this sounds like it could help a lot of people, there is also another problem with that - which mail clients should such a filter target? For example, Outlook 2013 would accept and render one set of attributes/CSS properly, but Outlook 2007 would work in a different way. This does not even begin to cover the multitude of email clients with their own ways of showing messages that are out there. So, such a filter would not be able to work for all (or even many) scenarios. If you, however, create a filter that satisfies at least one (or a number) of mail clients, I would encourage you to post it in our code library and we will gladly award your efforts and contribution to the community with Telerik points: http://www.telerik.com/support/code-library/aspnet-ajax/editor.
Regards,
Telerik
Check out the Telerik Platform - the only platform that combines a rich set of UI tools with powerful cloud services to develop web, hybrid and native mobile apps.