Upcoming changes to CSS code usage: Allowable and unallowable inline code

  • Author
  • #457449

    Original poster

    As you might have heard, a week ago, Matt announced that WordPress.com would soon be stripping out embedded CSS code for users who have not purchased the CSS upgrade. The example that he specifically identified would be verboten was written by panaghiotisadam and is as follows:

    <div style="position:fixed;top:0;left:0;background:#HEX_HERE;width:100%;height:100%;z-index:-11;"></div>

    Now, given that Adam’s code is actually an example of inline CSS, not embedded CSS, and that embedded CSS appears in the header of a document, which WP.com users have no access to, I’m guessing that Matt actually meant that inline CSS code would soon be stripped out.

    I’m okay with this and understand the need for such a change, but I am now wondering exactly what style attributes would henceforth be stripped out. All of them? Only a few select attributes?

    I’m asking because I do not have the CSS upgrade and I use a few attributes on my WP.com blog and would like to prepare for the upcoming change by removing the offending code in advance. Obviously, I would not like my layout and formatting to one day turn suddenly into mush, so I am interested in taking a proactive approach in editing my posts and pages.

    Thank you for your time.


    Original poster

    I should probably be more specific about the types of style attributes that I am wondering about by giving some examples, both to illustrate what I often use, and provide samples for users who might not be as familiar with the type of code being discussed here.

    • To center some of my post and page titles, I use style='text-align:center;'.
    • I will sometimes use code such as style='margin:2px; padding:1px; border:1px;' when positioning my pictures.
    • Occasionally, I use style='color:#ffffff;' and style='font:12px sans-serif;' to change the appearance of my text.

    A [comprehensive?] list of attributes can be found here: http://www.w3schools.com/CSS/CSS_reference.asp. All of them can be used as inline code except for the CSS Pseudo-classes/elements at the bottom of that page.

    So, which of the listed attributes will be stripped out, and which will be allowed to stay?

    Thanks again.



    Posting in the forum’s not likely to get you an informed answer. Contact staff directly and ask; they mostly leave the forums to the volunteers.

    And, in my experience, this is absolutely typical of the kinds of questions they refuse to answer anyway. But good luck!


    Original poster

    I think it’s okay to ask this question in the forum. After all, the Support staff does make important announcements here all the time. For example, when Platial went down late last month, andreitr chose to post the announcement here in the forum to let everybody know that WP.com would be removing that widget. And don’t forget that Matt himself made the announcement about the upcoming CSS changes here in the forum as well.

    Plus, your response has slightly deterred me from writing to Support directly, since you think that they won’t respond to me directly about this particular inquiry anyway. ;)

    So for now, I’m okay with leaving this question here so that both members and staff can talk about it as they come and go. I’m sure there are other users who are interested in making edits to their blogs in preparation for the upcoming changes, so they’ll find this information useful too!



    If they are going to strip out inline CSS, they’re probably just use a filter to strip out the style property of all html tags instead of just a selected few. This is just what I would do to save time but who knows what the staff is really planning to do.

    Just a random thought, the pseudo names at the bottom of w3schools’ list should be called selectors instead of classes/elements.


    Original poster

    That’s an interesting thought, and while I agree that that would be the simplest solution, I don’t think it will happen. WordPress.com regularly suggests the use of several style attributes, to change the look of text for example. If they were to completely strip out all instances of inline CSS, they would need to develop alternative ways for people to make such edits. They could create their own WP.com shortcode for such purposes, but that seems like an extremely tedious solution that would require lots of testing and bug fixes for what is otherwise a very simple task when using inline CSS.

    I think they are more likely to strip out only certain attributes. For example, the use of
    in text widgets can be used to emulate styles that would otherwise be possible only if a user purchased the CSS upgrade. I can see them eliminating all instances of that code in text widgets. That would stop those users from applying that sort of styling to their blog while being minimally disruptive to the rest of the bloggers.

    The question now, of course, is what other attributes will be stripped out?

    Oh, and I do not know why Pseudo-classes/elements are named as such on that website. I’m not involved with that site, so you’ll have to ask the webmaster.



    Feeling very agreeable today:
    @enilamalenj, agree with you that it’s a reasonable question to ask here
    @rain, agree with you that it might not be answered here, at least not officially and in detail
    @enilamalenj, agree again that some, rather than all, attributes, are likely to be stripped out.

    Also finding it fun to speculate about how this is going to go:


    Original poster

    That post is a great summary of the issues at hand, andrew.

    Currently, I believe that the Support staff will announce the changes here in the forum. If you think about it, there are essentially only two far-reaching ways that they can use to make an announcement to the entire WordPress.com community: their frontpage blog, or these forums.

    I’ve yet to see them write a negative post about WP.com on their blog (not that they would, since doing so would really take away from the posts about WP.com’s great services), and as such, they certainly won’t be using that valuable space to announce the removal of features from their blogging service.

    That leaves the forums. And as I have already pointed out when I mentioned the death of Platial above, it’s not unusual for them to use the forums as a medium to disclose any unfortunate news and changes to the WP.com service. Aside from that, when these changes finally do go into effect, where do you think concerned bloggers will race to for answers about the sudden changes to the styling of their blogs? They’ll come here to the forums of course, and we and the staff will be ready to help point out the new code restrictions.

    The obvious question, besides that of what CSS attributes will be allowed and disallowed, is when this announcement will be made. I previously mentioned that I’d be interested in checking my blog for any offending code right now so that when the restrictions do roll out, the styling of my blog doesn’t suddenly degrade into something unwanted. I’m sure that I’m not the only person who has thought about doing this. And the staff must have already considered the benefits of being proactive about the upkeep of our blogs, or rather, the disbenefits of not informing bloggers until after the fact. In light of wanting to avoid mass hysterical cries of “OMG, what happened to my blog!?” I think they will be addressing this issue sooner rather than later.

    And yes, I’m aware that there are bloggers who don’t pay attention and who will be flipping out when the changes go into effect regardless. That’s just too bad for them. ;D


    Currently, I believe that the Support staff will announce the changes here in the forum.

    Uummm… history would say you are being way too optimistic. Matt’s drive-by, referenced in the first post in this thread, will likely be the only warning you get. One minute your inline CSS will work and the next minute it will not.


    But I think we deserve an anwer, so I’ll repeat my questions: Why is it a “loophole”? Why must it “go away”? And what exactly will go away?



    Why is it a "loophole"? Why must it "go away"?

    Because bad guys use it to do bad things.


    Moderator Emeritus

    Yes, we can all hope for a definitive answer to what is this “loophole” and why and what must “go away” because of it.

    Without that though, what can anyone do? Besides make provisions to: leave, stay and pay, will stay and pay still work, will basic ‘normal’ formating still work,

    A separate set of issues:
    What about the strange ways the visual editor now works…
    will those quirks be fixed in this “closing loopholes?’

    —the visual editor automaticallyadds paragraph text styling to centered images
    —the html editor no longer accepts & frac12 ; sans spaces to make 1/2 (or similarily for the fraction 1/4) unless one switches to the visual editor before updating…
    —both the visual and html editor are adding curly quotes to code even when using the codes: & quot ; or & #34 ; (sans spaces) which used to work?
    —There are differences between both the visual editor and the html editor and
    how the editor for text widgets work: specifically with alignment of text and images.




    Because bad guys use it to do bad things.

    I’m not buying that unless you become more specific. What exactly is going away?

    Surely to God it can’t be a little code here and there to enhance my blog’s appearance by injecting some color. :(

    I’d like to know exactly what bad things can be done by adding a nice background color like I did to to my About page? What security threat could that possibly present?


    @ tellyworth: In my previous post above I was almost ready to add the question “why is tellyworth silent on this?”, so thanks for dropping by!

    But, to tell the truth, your reply isn’t convincing at all. I could be wrong, of course, but I don’t see how code such as the one I suggested can be used maliciously. The impression we’re getting is that you just want to kill code that allows us to do something for free instead of having to buy the CSS upgrade.

    Anyway, what you decide to allow or not allow is your business, not mine; but as a forum volunteer –especially as one who gives many replies on html and inline CSS– I’d really like to know what exactly is going to go away. (So far my impression is that WP doesn’t know either.)



    I’d rather not provide the details, but it has been used maliciously. We need to prevent that.

    I don’t know exactly what will be filtered, but things like absolute positioning will certainly be blocked from within style attributes (not from custom css). I don’t believe the intention is to stop simple styles like colour and font settings from style attributes.



    @ tellyworth: I too thank you for telling us what you are able, while being mystified as to how the code posted here presents a security loophole.
    I think it is a loophole in a different sense: it is an “artificial” way to style the whole blog – a task that belongs to CSS – from within a sidebar widget. From one perspective, such code can be seen as breaking the WordPress.com deal: this much for free, here’s the price list for these other things.


    Thanks again! If it has been used maliciously, then of course you mustn’t provide the details. (Although I’m dying to know… Any chance you’d indulge me after it’s taken care of?)



    The only “malicious” thing I can think of right now is using inline CSS to redirect visitors to other sites (linked from the header image).


    (“it’s taken care of” above should read “it’s been taken care of”, of course.)

    @devblog: Thanks too! That by itself isn’t malicious: depends on the kind of site you redirect. If you’re redirecting to the wrong kind of site, then you’re violating the TOS. In that case it’s the blog that should be killed, not the code!



    f you’re redirecting to the wrong kind of site, then you’re violating the TOS. In that case it’s the blog that should be killed, not the code!

    I agree 100%.

    Also, Matt said that only those who have the CSS upgrade would still be able to use _that_ kind of code… Now, I wonder, if the bad guys have “maliciously” use inline CSS to do their bad deeds, how’s wp gonna stop them if they decide to fork the $15.00 upgrade and keep doing it? WP would have to archive their blogs, of course…

The topic ‘Upcoming changes to CSS code usage: Allowable and unallowable inline code’ is closed to new replies.