30 style tags per page limitation

[Rob Nicholson]

We're using a well known presentation layer library to implement complex
controls on an intranet site. IE has the following limitation which
effectively means that you can only have 30 <STYLE> tags per page. That's in
effect 30 style sheets per page, not classes - each sheet can have as many
style classes as you want.

http://support.microsoft.com/default.aspx?scid=kb;en-us;262161

Unfortunately, this presentation library generates individual <style> tags
*per* control which in effect limits you to 30 controls per page.

Anyone else thing it's a little bit off for the vendor to suggest that this
is a problem with IE and not their presentation layer?

The fix would be to group all the classes under one <STYLE> tag but as these
are ASP.NET server controls, we can't do that.

Cheers, Rob.

 

[Craig Deelsnyder]

We're using a well known presentation layer library to implement complex
controls on an intranet site. IE has the following limitation which
effectively means that you can only have 30 <STYLE> tags per page.
That's in
effect 30 style sheets per page, not classes - each sheet can have as
many
style classes as you want.

http://support.microsoft.com/default.aspx?scid=kb;en-us;262161

Unfortunately, this presentation library generates individual <style>
tags
*per* control which in effect limits you to 30 controls per page.

Anyone else thing it's a little bit off for the vendor to suggest that
this
is a problem with IE and not their presentation layer?

The fix would be to group all the classes under one <STYLE> tag but as
these
are ASP.NET server controls, we can't do that.

Cheers, Rob.

Rob, think I commented on your question in a previous post; doesn't look
like they budged much. Obviously they didn't think 30+ of their controls
would be used (or 29 if they'd at least let you use one in your page as
well); whether that's reasonable or not, you'd have to say. I think it's
somewhat dumb of them to push it back at you; if you're reasonably using
their controls (30 of them on a page is reasonable application of their
product), then they should work with you on this. I know who you're
dealing with, and have hit the same thing service-wise. My recommendation
is to find another product, verify they don't have the problem, and move
to them.

Also, is it reasonable for them to have to style at each control? I mean,
how many controls do you actually instantiate? Do you instantiate 30+, or
do you instantiate 1 that is then made up of 30+ controls internally, who
then spit out separate style tags? If the latter case, they shouldn't
style that way, they should rollup stylesheets to the highest level
possible. Especially now they know this limiation....

 

[Rob Nicholson]

Rob, think I commented on your question in a previous post; doesn't look

Yes, you did thanks - at that point I was just verifying the KB article
which describes the limitation.

like they budged much. Obviously they didn't think 30+ of their controls
would be used (or 29 if they'd at least let you use one in your page as
well); whether that's reasonable or not, you'd have to say. I think it's

Well as their control set includes things like buttons, tabs, toolbars as
well as a grid, they obviously are suggesting that you can built a rich
interface with their product. Especially the tab control which sort of
encourages you to create complex pages.

somewhat dumb of them to push it back at you; if you're reasonably using
their controls (30 of them on a page is reasonable application of their
product), then they should work with you on this.

"Disappointed" was the word I used in my email

I know who you're dealing with, and have hit the same thing service-wise. My recommendation
is to find another product, verify they don't have the problem, and move
to them.

We are actively looking but we can also replace some of their controls with
plain vanilla ones like the ASP.NET drop down list or command buttons.
Annoying, but it'll bring us below the 30 controls.

Also, is it reasonable for them to have to style at each control? I mean,
how many controls do you actually instantiate? Do you instantiate 30+, or

The main form in question has got 30+ individual controls when you add up
all the controls around the form like the toolbar, command and navigation
buttons. Of course, if we'd known about the limit before we started, we'd
have used them more sparingly. The product will still function with
non-interface/plain buttons equally as well as it does with a nicely
rendering, hover button.

style that way, they should rollup stylesheets to the highest level
possible. Especially now they know this limiation....

I agree but what do I know I must admit I don't know about how server
controls are rendered/painted by ASP.NET and whether is possible to buffer
the class definitions as the individual controls are processed and then
output one big <STYLE> tag at the end. One problem I can foresee is do
styles have to be defined before they are used? I'd suspect yes so this
wouldn't work as the definition would appear afterwards.

But then again, I'm not being paid to solve their problems - that's why we
bought a 3rd party control in the first place <grin> Then again, I can't
think of *any* project where we rely on 3rd party controls heavily where we
haven't had headaches... Please don't mention Crystal DLL hell ;-)

Cheers, Rob.

 

[Craig Deelsnyder]

Yes, you did thanks - at that point I was just verifying the KB article
which describes the limitation.




Well as their control set includes things like buttons, tabs, toolbars as
well as a grid, they obviously are suggesting that you can built a rich
interface with their product. Especially the tab control which sort of
encourages you to create complex pages.




"Disappointed" was the word I used in my email



My recommendation



We are actively looking but we can also replace some of their controls with
plain vanilla ones like the ASP.NET drop down list or command buttons.
Annoying, but it'll bring us below the 30 controls.




The main form in question has got 30+ individual controls when you add up
all the controls around the form like the toolbar, command and navigation
buttons. Of course, if we'd known about the limit before we started, we'd
have used them more sparingly. The product will still function with
non-interface/plain buttons equally as well as it does with a nicely
rendering, hover button.




I agree but what do I know I must admit I don't know about how server
controls are rendered/painted by ASP.NET and whether is possible to buffer
the class definitions as the individual controls are processed and then
output one big <STYLE> tag at the end. One problem I can foresee is do
styles have to be defined before they are used? I'd suspect yes so this
wouldn't work as the definition would appear afterwards.

But then again, I'm not being paid to solve their problems - that's why we
bought a 3rd party control in the first place <grin> Then again, I can't
think of *any* project where we rely on 3rd party controls heavily where we
haven't had headaches... Please don't mention Crystal DLL hell ;-)

Cheers, Rob.

I'm glad to hear you're trying to move on when you have the chance. I
mean when a company makes you pay for a product, you use it in 'normal
usage' and they just say 'it's a bug' and throw their hands up, that's
just ridiculous, especially as there are at least a couple good 3rd
party control vendors out there.

I'm by no means an 'internals design' expert on .NET, but what usually
happens, you'll notice, is that there is a CssClass property on a
control, that the control will then use/set internally and spit out in
its HTML. Then the person using the control has the responsibility for
defining the CSS class. If a control is so complex that it need its own
stylesheet, I could see that. But at the same time, define more than
one CssClass property for the consumer to define if needed for some
reason.

The only other option you'd really have (similar to what you've noted)
is to filter the Response (see Response.Filter) as it went out, which is
really hokey IMHO, I've only done it when I wanted to strip out
characters, etc. for a special case. You could inspect the stream of
HTML as it is being written and alter, but you can already see the work
to be done in figuring out that logic for your case.

I'm not sure that you have to define a CSS class before you use it (I
mean spatially in the page), I think browsers apply CSS after the whole
page is loaded, to have proper reference for doing so. So the classes
would be defined before application.

 

[Rob Nicholson]

I'm glad to hear you're trying to move on when you have the chance. I

mean when a company makes you pay for a product, you use it in 'normal
usage' and they just say 'it's a bug' and throw their hands up, that's
just ridiculous, especially as there are at least a couple good 3rd
party control vendors out there.

True I'm just very annoyed about spending a lot of money and then having to
spend a lot of time and hassle working around and finding bugs.

defining the CSS class. If a control is so complex that it need its own
stylesheet, I could see that. But at the same time, define more than
one CssClass property for the consumer to define if needed for some
reason.

The control is pretty complex, with the requirements probably beyond style
tags/sheets. I think a better solution would have been to implement their
own style structure, based around CSS and define it either via XML and/or
objects. Something like:

<GridStyle name="MyStyle">
<Font name="Tahoma" size="10pt"></Font>
</GridStyle>

This would have centralised the complex style structures centrally allowing
them to be shared quickly across all pages. Not sure what it would look like
in the design but I'm used now to lots of "UserControl" blanks anyway.

The only other option you'd really have (similar to what you've noted)
is to filter the Response (see Response.Filter) as it went out, which is
really hokey IMHO, I've only done it when I wanted to strip out
characters, etc. for a special case. You could inspect the stream of
HTML as it is being written and alter, but you can already see the work
to be done in figuring out that logic for your case.

They suggested something similar and I shuddered

Rob.

 

[Jeremy S]

Hi Rob,

Would you mind sharing with the rest of us who this 3rd party is? I'm not
into smearing... I just don't want to avoid a bad situation if it can be
known in advance. My company is looking to evaluate several 3rd party
control suites to be used in our own in-house applications - so your "in the
trenches" experience would be valuable to us.

Thanks!

 

[Rob Nicholson]

We are actively looking but we can also replace some of their controls
with

plain vanilla ones like the ASP.NET drop down list or command buttons.
Annoying, but it'll bring us below the 30 controls.

AARRRRGGGGGG!!! Now I'm going to have a go at Microsoft... We can't use the
Infragistics NetAdvantage WebCombo on our page as it uses a STYLE tag per
control and this creates the >30 style tags issue. So we've replaced all the
drop down lists with plain vanilla ASP.NET asp.dropdownlist control. Except
this has a problem as well:

http://support.microsoft.com/default.aspx?scid=kb;EN-US;q177378

This basically means that SELECT controls in IE *ignore* the Z-INDEX value
and *always* appear on top of other controls on the web page. We use a very
nice popup message implemented via a normally hidden DIV tag and the darn
drop down lists *always* appear on top of the popup message.

Nice one Microsoft! Why has this never been fixed as it's been around since
IE5...

So we now either have to loose the popup message mechanism (which works
really really well) or find another drop down list control that doesn't use
SELECT statements, maybe like the NetAdvantage WebCombo that doesn't also
generate lots of style tags...

Why is this so hard sometimes!!

Cheers, Rob.

 

[Rob Nicholson]

Would you mind sharing with the rest of us who this 3rd party is? I'm not

Don't see why not as it's a real problem IMHO, not just us being awkward.
It's the Infragistic NetAdvantage presentation layer toolset:

http://www.infragistics.com/products/NetAdvantage/default.aspx

into smearing... I just don't want to avoid a bad situation if it can be
known in advance. My company is looking to evaluate several 3rd party
control suites to be used in our own in-house applications - so your "in the
trenches" experience would be valuable to us.

The controls are very powerful but the learning curve is steep. Worth
climbing though even through trying to get your head around the zillions of
multilevel properties could drive you to drink.

Unfortunately, you can't >30 of their controls on a page which is a real
limitation (well it is for us) in the current system we are designing.

There are a number of bugs in there which means we're finding random crashes
which always worries us. It's quite feasible that the amount of HTML and
complexity of HTML being generated by the server controls along with the
reams of JavaScript is just too much for poor old IE. Considering IE has
been around so long, it's surprisingly unstable in some areas. And of
course, debugging HTML & JavaScript is painful at the best of times.

What irks me is that we're really just trying to write a database app which
would be a piece of cake as a standard Windows app Web apps are a real
step backwards in one way.

I can chat more by email if you want.

Regards, Rob.