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.
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.
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.
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).
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.
}
also important to note: each stylesheet cannot have more than 4095 CSS rules, in IE. experiencing this limit makes for some mighty interesting debugging.
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.
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.
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.
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).
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?
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 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.
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.
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.
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+.
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.
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.
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 :)
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...
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 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.
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. :)
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.
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.
