All style tags after the first 30 style tags are not applied in IE (4-8) | Hacker News Reader

All style tags after the first 30 style tags are not applied in IE (4-8)

support.microsoft.com

114 pointstimdorr58 comments

The fact that 30 is suspiciously close to 32 makes the impression that there's some unholy C black magic in the background of the bug. I wish programmers stopped doing stuff like that unless they really have to.

Huh. A five bit range would give a max of 31, and if we assume that the default/built-in stylesheet knocks another off, that's 30.

I agree with you, though I think I'd prefer this to hint at the reason over it being an entirely arbitrary descision. Making such a choice for a bad reason is still preferable to making it for no reason.

Yeah, I'm hoping it's that. Purely arbitrary would just be... stupid.

    struct Element {
        // Update: apparently 16 wasn't enough.  Raised to 30 to pass test #452
        StyleData styles[30]; // No one uses more than 16 style parameters anyway.
    }

It may be a sanity check; often when writing parsers for "in the wild" data you have to pick a cutoff for where "doesn't make sense" is so that you can tell if you're looking at junk data and stop trying to make sense of it (and the RAM / CPU entailed in such).

This is what happens when you work at a company which doesn't have the sense and engineering leadership to arrive at a single core set of collections and such ala CoreFoundation: http://developer.apple.com/mac/library/documentation/CoreFou...

Microsoft has a hodge podge of several attempts at the same, and because none is truly core and universally available, it's quite easy to be ignorant of what's available and roll your own crappy, limited data structures.

also important to note: each stylesheet cannot have more than 4095 CSS rules, in IE. experiencing this limit makes for some mighty interesting debugging.

If you've got a stylesheet with more than 4095 rules, I bet you have some interesting debugging anyway.

It's not that unreasonable. Scenario: You download the Fugue icon set (http://www.pinvoke.com/). You're working on a template, and want to be able to quickly try out different icons in different places. If you generate two rules for each of the 2500 icons, you're over the limit.

Ouch, I always try to make limits be 0, 1 or many - where 'many' is the limit of physical resources.

A motivated, well documented, and standardized limit is sometimes appropriate. This is not one of those times.

This problem can be avoided by using @import statements within each style tag to import more than 30 stylesheets. Some discussion here: http://drupal.org/node/228818

Of course, you should avoid doing this in production anyway, and just asset package your stylesheets into very few stylesheets. I've made a fork of the asset_packager project to support this behavior after 31 stylesheets: http://github.com/jamesyu/asset_packager_ie_css_limit

There's a limit to the number of @import's you can have per style tag too, but the imported stylesheets can also include @import's, from what I remember.

And I love the link at the top (when not viewing the page in IE): Upgrade your Internet Experience. Which links to IE, of course.

I laughed hysterically when I saw that at the top after reading the first few lines of the kb article.

I've hit this problem before - I use a separate stylesheet for each logical (in my mind) group of styles - header, footer, main content, blog, and so on. This way, I only have a few styles in each file, and it's easier for me to manage (YMMV). I only combine them into a single stylesheet on production and staging.

It's annoying to have to run the stylesheet combine when testing as when I find problems, I have to sort through a mass of css and rerun the combiner in order to test fixes.

http://www.i-marco.nl/weblog/archive/2006/06/24/time_breakdo...

(But without the red section).

I'm assuming this doesn't include the inline style="" params and only includes <style> tags. At first, I thought it did and didn't believe such a limitation went unnoticed by many for so long.

The inline style params are called attributes. Anything within the tag itself -- of form token="value" -- is called an attribute (unless there is some arcane SGML or HTML structure that I'm missing).

Hmm, odd limit. I've never had more than 5 style tags on a page, though, and fewer since I got into using yuicompressor.

Has anyone here actually run into this in practice? If so, how? Just curious.

Create a modular UI framework that allows modules to import their own stylesheets. You hit this problem really quickly.

Perhaps, but if you're including 30+ stylesheets in a given page you're doing it wrong.

Every stylesheet is an extra (blocking) HTTP request. 5 is already too many, but 30 is seriously impacting your user's experience.

This bug can be triggered by inline stylesheets as well which do not create additional HTTP requests.

Fair point, but in what case does including 30 inline stylesheets make sense?

I'm hesitant to call this a bug.

Well, with MS, its a feature.

At MS, it might be dictated by a coding standard.

More seriously, I was once treated VERY skeptically by an old-school programmer (not at MS, never worked there) when I replaced some of his fixed-sized buffers with resizeable ones. "If our customers are running workloads that create more than 256 frooble node objects, I want to hear about it." Via a bug report? Really? And then get a new bug report next year when the new limit is reached? But he was adamant, and if it was up to him we wouldn't have made the change at all. The way he worked, you knew how many frooble node objects the customer needed, and if you were wrong then you fixed the code.

If it was meant to be a feature, it should have at least been documented. How is it good to have undocumented, arbitrary limitations on a platform that you are using?

The one time I've run into this 'bug' in the past was on a site that used lots of javascript plugins, more and more of which are coming with their own CSS files nowadays.

Of course you can concat them together, but that adds a maintenance burden in the future whose size can vary wildly.

At the very least, there is a documentation bug here. The reason for this seemingly arbitrary limit should be documented by MS.

It makes perfect sense if you're generating your HTML and CSS from some kind of code-generator. Limiting it to only 30 style tags is really arbitrary and small.

using inline style tags directly after elements can have a noticeable speedup on a pages rendering, dynamically generated pages could quite easily have well over 30 with the only downside being this silly limit.

and that isnt mentioning the boundary situations for things like web page builders with the ability to user define styles in which having a "lot" of style tags is architecturally a good idea.

I am quite tired of this "your doing it wrong" meme when its used instead of "you arent doing the same thing I am doing"

It's not unheard-of for components on a page to be separately generated, and for each to emit its own HTML and style info.

Two words:

development mode

I'd hope there would be server side combining of stylesheets. I have seen performance suffer from including about 10 stylesheets; don't want to imagine 30+.

In the reddit thread this seemed to crop up a lot in Drupal where each module installed can use its own CSS sheet.

There's apparently a setting to merge them but at least in that case something like this issue cropping up makes sense.

OK, I suspected that. I think that's a code smell, though; I have trouble seeing why you wouldn't want to get such styles into the main stylesheet.

My first web app (no longer active) allowed dynamic styles to be applied to different elements on a page. I used dynamically generated <style> tags to do this, and yes I did hit this limit on IE.

These days, I might dynamically generate a CSS file in that situation.

When using Drupal it can be pretty easy to run into this (and I have). Modules are allowed to add default stylesheets for their forms/controls/etc. so in a website with a large number of modules this sometimes happens. First time I ran into this it took quite a bit of time to figure out.

Drupal has a performance feature, which will take these CSS files and automatically aggregate them together. This can make for difficult debugging because problems will disappear when you move from a development to a production environment.

Yes. Sometimes while testing I'll put style=".." references in my tags just to get a feel for how things will look, then I'll commit to something and put it in the CSS files.

Fortunately, I do all my testing in Firefox so I've never even noticed this limitation :)

style=".." on an element is an attribute, not a style tag (<style>), and so is unaffected by this limitation.

Developers on the Facebook Platform ran into this problem a few years ago. Facebook had a bunch of style tags in their source already -- it seems like they put them in different pieces all over the place.

When you would write an application (your FBML is put into their layout) and use even more, you'd eventually run into this limit.

I think they fixed it by combining all style tags in applications into one, since they had to parse them for security reasons anyway.

Anyone want to guess why the number is 30?

Somewhere in Redmond, WA

PageStyleTagsW tags[

Thinks for 5 seconds

PageStyleTagsW tags[30]; /* should be enough for any page /

Goes and gets a free soda*

Sometimes imposing arbitrary limits in C is a lot easier than manually managing dynamic memory in the heap..

I've seen this where I work all the time. I've also seen code where the developer created 25 different structures named structure_type_X where X is 1-25, the size of the structure's internal buffer.

How do you deal with 25 different structure types with nothing different but the name and buffer size? Why, a switch statement of course...

It's pretty common for Verilog developers to think they're writing C code, but that's the first time I've heard the converse.

The guy does some pretty interesting stuff - writes scripts to automatically generate structures so class variables are byte aligned and within cache lines and all that.

But he has made some of the dumbest use of C++ I have ever seen. Verbs as classes, sometimes making it obvious that inheritance escapes him, and an entire cpp file over 10k lines long that does nothing but assert the mass amount of assumptions his code makes. The one method is literally called 'check_assumptions.'

I'm not bitter though.

Sounds like a problem for C++ templates.

Now you have two problems.

Sounds like Pascal...

I'm pretty certain this is the case too, just an arbitrary limit due to coding laziness. I'm sure people argued about it and decided that 30 external style sheets was way more than enough since using that many would be crazy and cause plenty of problems on its own. Then, of course, later on the team decides how they want to handle inline styles and someone suggests they've already got all this infrastructure for handling external styles, why not just use that? Nobody reevaluates the style limit and then hijinx ensue down the road.

I have to admit, there have been a few times I've written comments like the following:

    /* Just a quick static array to get it
     * working.  Should be enough for all the
     * usual tests so we can work on core
     * functionality.
     * 
     * TODO: change it to a linked list or
     * something to dynamically track style
     * tags.
     * 
     * Update: Changed from 16 to 30 because Alex
     * tossed in a new test that breaks this
     * build.  This really ought to be updated
     * next major release, but for now we just
     * need to get it working.
     */

Avoiding these sorts of pitfalls is one of the greatest benefits to using a modern language with good generics support. In C#, for example, it's actually easier to code with lists than with arrays, so you can skip the "fix it so it doesn't have an arbitrary range limit" coding step (which often never gets done anyway).

The not-so-modern language that IE is written in (C++) has a similar construct (std::vector) in its standard library. It is possible that code was originally written prior to the widespread adoption of the STL and was never updated to use it.

Drupal's discussion of this (and with a workaround, I vaguely remember) ... http://drupal.org/node/256802

"Resolution: To work around this limitation, combine multiple classes into a single style tag."

Um... don't they mean multiple styles into a single class tag?

No. What they mean is combining

  <style>
    .class1 { .. }
  </style>
  <style>
    .class2 { .. }
  </style>

into

  <style>
    .class1 { .. }
    .class2 { .. }
  </style>

I would never defend Internet Explorer, but I don't think this is really a big deal. If you have more than 30 style tags on any page, something is very wrong. IE has plenty of bugs and limitations that are much worse than this. :)

Yeah, I agree with you. But think about it, if we have so many style tags in a single page, we did it bad. If IE has this stupid limitation, they did it bad.

Someone brought this point up on proggit, and it was debunked by someone else who pointed out that many developers break their stylesheets up into multiple components for development purposes and then compile and compress them for production. This bug prevents them from testing on IE effectively.

Genghis Khan might have had far worse faults than picking his nose at the dinner table, but that still doesn't excuse the behavior.

It's true that more than 30 style tags on a production application is a big problem; however, in development mode it can be useful for debugging and maintainability to break out your stylesheets into granular modules that get concatenated at deploy time.

I've personally bumped into this limit in IE in development mode. My solution was to build a dynamic method that concatenated all the stylesheets on the fly if the IE user agent was detected.

Reply on news.ycombinator.com