CSS class names in Chrome

6 posts, 0 answers
  1. Brian Ho
    Brian Ho avatar
    12 posts
    Member since:
    Mar 2010

    Posted 27 Feb 2011 Link to this post

    Hi there, 

    I recently upgraded my RadControls to (Q1 2011 I believe?)  I noticed a problem with the RadEditor while working in Chrome where all my class names got changed to lower-case and thus when I tried to apply a style the style wouldn't work.   I first noticed this error when I try to apply a class to a order list item and it worked fine in IE but not in Chrome.  The class names I'm using in my CSS have mix-casing (e.g.  lowerAlpha) and in Chrome the RadEditor was inserting (loweralpha).  Please help.

    Thanks
  2. Rumen
    Admin
    Rumen avatar
    14098 posts

    Posted 01 Mar 2011 Link to this post

    Hello Brian,

    This appears to be a browser behavior. When populating the ApplyClass dropdown and setting the classname to the element we do not modify the selectors. The values that appear in the dropdown is returned by cssRules property of the document.styleSheets object.

    It appears that when the document element is an <iframe> document all the CSS Rules are modified to lowercase by Google Chrome engine. You can verify this using a standard editable <iframe>. For your convenience I have attached a simple HTML page demonstrating this problem.

    A possible solution to this issue is to configure RadEditor to use editable <div> for its content area by setting its ContentAreaMode property to Div, e.g.:
    <telerik:RadEditor ID="RadEditor1" runat="server" ContentAreaMode="Div">
    </telerik:RadEditor>

    We have reported this issue to the developers of Google Chrome. Here is the link to the issue:
    http://code.google.com/p/chromium/issues/detail?id=67782


    Best regards,
    Rumen
    the Telerik team
    Registration for Q1 2011 What’s New Webinar Week is now open. Mark your calendar for the week starting March 21st and book your seat for a walk through all the exciting stuff we ship with the new release!
  3. Kristian
    Kristian avatar
    1 posts
    Member since:
    Mar 2012

    Posted 26 Mar 2012 Link to this post

    Hi Rumen,

    I am having troubles with this error as well. Which file do you implement your quickfix to?

    Best regards,
    Kristian Thrane
  4. Rumen
    Admin
    Rumen avatar
    14098 posts

    Posted 29 Mar 2012 Link to this post

    Hi Kristian,

    I missed the file attachment in my earlier post but it is available for download in the bug report page http://code.google.com/p/chromium/issues/detail?id=67782. The EditableIFrame.html file does not offer a fix, but shows that this is Chrome related issue.

    The only solution that we could offer, until the WebKit developers fix the problem, is to render the content area of RadEditor as an editable <div> by setting the ContentAreaMode property to "Div".

    Best regards,
    Rumen
    the Telerik team
    If you want to get updates on new releases, tips and tricks and sneak peeks at our product labs directly from the developers working on the RadControls for ASP.NET AJAX, subscribe to their blog feed now.
  5. Karthikbabu
    Karthikbabu avatar
    1 posts
    Member since:
    Nov 2012

    Posted 29 Nov 2012 Link to this post

    We are using telerik controls (RAD) in Sitecore and facing the same problem, also in Safari browser. The CSS class names from Apply CSS dropdown showing in lower-case instead of actual one. (e.g. .footNote --> .footnote).
  6. Ivan
    Ivan avatar
    6 posts
    Member since:
    Sep 2007

    Posted 04 Dec 2012 Link to this post

    Could it be that HTML markup created by RADEditor control is missing DOCTYPE directive in it? Please take a look at the response in the ticket for Chrome.
    This seem to work fine in the attached /editableiframe.html file if you make "iframe" body as this:
    var sMarkup =  "<!DOCTYPE html>" + 
             "<html><head><title>New Document</title></head>" +
                      "<body contenteditable=true style='overflow:scroll;margin:0px;padding:0px;height:100%'>" +
                      "&nbsp;</body></html>";



    Could you confirm whether you get the same behavior on your side.
Back to Top