Hi guys,
With the new Prometheus, I'm hoping that when customers edit their pages, the editor doesn't produce a lot of suporfulous <span> tags. It'd be great to keep the output as clean as possible.
In your demo section, I double clicked on 1 word so it highlighted. I then added a foreground and background color to that word in one go. This is the HTML that was produced:
<span style="COLOR: #663333; BACKGROUND-COLOR: #ff6666">successor</span>
I then double clicked a 2nd word and added underline and foreground color to the word, again at the same time. This is the HTML that was produced:
<span style="COLOR: #ff6666"><span style="TEXT-DECORATION: underline">tight</span></span>
In the latter case, I'm wondering why there are 2 span elements produced? Can it not behave like the first case where style attributes are added together to a single <span> element?
Look forward to your reply.
With the new Prometheus, I'm hoping that when customers edit their pages, the editor doesn't produce a lot of suporfulous <span> tags. It'd be great to keep the output as clean as possible.
In your demo section, I double clicked on 1 word so it highlighted. I then added a foreground and background color to that word in one go. This is the HTML that was produced:
<span style="COLOR: #663333; BACKGROUND-COLOR: #ff6666">successor</span>
I then double clicked a 2nd word and added underline and foreground color to the word, again at the same time. This is the HTML that was produced:
<span style="COLOR: #ff6666"><span style="TEXT-DECORATION: underline">tight</span></span>
In the latter case, I'm wondering why there are 2 span elements produced? Can it not behave like the first case where style attributes are added together to a single <span> element?
Look forward to your reply.
1 Answer, 1 is accepted
0
Hello Bardia,
There is a difference in the two scenarios - which involve different interaction between the editor's script and the browser's rich edit engine.
At the low level the browser engine uses FONTs rather than SPANs for font formatting, and <U> tags, rather than CSS to perform the Underline command.
Then the editor steps in with is ContentFilters to transform the content from (non-XHTML, tag names in upper case, missing quotes around many tag attributes, obsolete non-XHTML tag attributes instead of css styles) content into XHTML compliant content.
In the first scenario, the browser performed internally the two operations using a single FONT tag - e.g.
<FONT color="#663333" style="BACKGROUND-COLOR: #ff6666">successor</FONT>
The editor then is able to convert this to a single SPAN.
In the second scenario, however the browser produces two tags
<FONT color="#ff6666"><U>tight</U></FONT>
To ensure correct functioning the Underline filter provides direct mapping between U elements and SPAN elements.
It works both ways - when content is loaded in the editor it is converted into tags that the browser's edit engine is able to work with, and then when the editor content is submitted [or editor is set in HTML mode], the filters perform the XHTML conversion.
The bottom line is that it is possible to improve on the Underline filter to use parent SPAN tags if available, and this is on our TODO list. For the time being, however, this is how the filter functions. You should not worry so much on having too many SPAN tags because while the content is in the editor there are in fact only U tags that get converted to SPANs in the last possible moment and thus creating a mess of too many SPAN tags is highly unlikely.
Best regards,
Tervel
the Telerik team
Instantly find answers to your questions at the new Telerik Support Center
There is a difference in the two scenarios - which involve different interaction between the editor's script and the browser's rich edit engine.
At the low level the browser engine uses FONTs rather than SPANs for font formatting, and <U> tags, rather than CSS to perform the Underline command.
Then the editor steps in with is ContentFilters to transform the content from (non-XHTML, tag names in upper case, missing quotes around many tag attributes, obsolete non-XHTML tag attributes instead of css styles) content into XHTML compliant content.
In the first scenario, the browser performed internally the two operations using a single FONT tag - e.g.
<FONT color="#663333" style="BACKGROUND-COLOR: #ff6666">successor</FONT>
The editor then is able to convert this to a single SPAN.
In the second scenario, however the browser produces two tags
<FONT color="#ff6666"><U>tight</U></FONT>
To ensure correct functioning the Underline filter provides direct mapping between U elements and SPAN elements.
It works both ways - when content is loaded in the editor it is converted into tags that the browser's edit engine is able to work with, and then when the editor content is submitted [or editor is set in HTML mode], the filters perform the XHTML conversion.
The bottom line is that it is possible to improve on the Underline filter to use parent SPAN tags if available, and this is on our TODO list. For the time being, however, this is how the filter functions. You should not worry so much on having too many SPAN tags because while the content is in the editor there are in fact only U tags that get converted to SPANs in the last possible moment and thus creating a mess of too many SPAN tags is highly unlikely.
Best regards,
Tervel
the Telerik team
Instantly find answers to your questions at the new Telerik Support Center