I was looking over the .skin file, specifically the GridView part and was curious about the use of colors in the skin.

I've just started to get into testing CssAdaptor and without reading much of the whitepaper or playing with the sample, had a problem getting the colors to work.

In the end, I never had the CssSelectorClass added, however the colors of the skin were never applied either.

I understand the use of SkinId, but was curious as to why in the themes supplied with CssAdaptor, why the colors would be set for the GridView skin.

Nathan

*On a side note which I just now noticed, the pagination part doesn't render correctly if the GridView is wider than the page (need for scrolling).

vindicator:

I was looking over the .skin file, specifically the GridView part and was curious about the use of colors in the skin.

I've just started to get into testing CssAdaptor and without reading much of the whitepaper or playing with the sample, had a problem getting the colors to work.

In the end, I never had the CssSelectorClass added, however the colors of the skin were never applied either.

I understand the use of SkinId, but was curious as to why in the themes supplied with CssAdaptor, why the colors would be set for the GridView skin.

Nathan

*On a side note which I just now noticed, the pagination part doesn't render correctly if the GridView is wider than the page (need for scrolling).

Which one does it use?  I took everything and put back the skinid and that was the only thing affecting the look.  How can I make the CSS affect it?

When you go to the sample pages in the kit you'll notice that they include a radio button group in the upper left allowing you to experiment with turning off the adapters.  That way you can visually inspect the control when it uses the traditional markup and when it uses the new markup.

The new markup is styled using style sheets found in the theme folder(s).

The traditional markup is mostly styled using font, color, etc., attributes set in the skin files.  Those colors, fonts, etc. are ignored by the adapters.  After all, the whole point of the adapters is to produce extremely lean markup that can be styled using linked style sheets.  Without the adapters, the skin's fonts, colors, etc. are turned into embedded or inline styles.  The adapters depend, instead, on your having defined appropriate rules in your style sheets for the markup that the adapters produce... so they don't need to insert inline styles, etc... so they ignore the fonts, colors, etc. that they see on the tags in the page or in the skin file.

If you are building a site where you intend to use the adapters all the time (never disable them) then you can generally skip making the skin files.  You'll be putting all your stylistic info in the rules you create for your style sheets.

Make sense?

Regarding CssSelectorClass... this is explained in the white paper at this spot, http://www.asp.net/CSSAdapters/WhitePaper.aspx#SamplesCssSelectorClass.

Ahhh Russ, that is exactly what I was looking for in an explanation.

But at the same time, I think the skin files can still be useful when you are repeating control settings such as the PagerSettings.

Regarding the pager conversion to div, would you say that when the table is wider than the page but the div doesn't extend longer than the width of the window is simply a CSS limitation or would there be a way to workaround that problem?

<table style="width: 1800px;">
   <tr>
      <th>...
      </th>
   </tr>
   <tr>
      <td>...
      </td>
   </tr>
</table>
<div class="pager">...
</div>

In this example, the table takes up more space than the window causing a horizontal scroll. But the div will only fill the width of the window.

Nathan

I hear ya.  The kit's GridView sample page, http://www.asp.net/cssadapters/gridview.aspx, exhibits the behavior that you are describing if you make the browser window narrow enough.  You'll find that the table has a "natural" minimum width that is wider than the min width of the <div> tags that are used for pagination.  As you described, those pagination <div> tags typically live above or below (or both) the <table> that is the grid of data being shown.

So you need to figure out a way, in CSS, to "tell" the page not to let the pagination regions become narrower than the sibling table.  With me so far?

One solution is to try to set a minimum width for the parent element of both the pagination and the table regions.  With the adapters in play, you get a div that looks like this:

<div class="AspNet-GridView">

It's the parent of both the table and the pagination div.  So you want to effectively want:

div.AspNet-GridView
{
  min-width: 30em;
}

Obviously the 30em width value is a placeholder.  You would set it correctly for your situation.

Of course, it's not that simple because IE6 doesn't recognize min-width (I'm not sure whether or not IE6 does).  So you have to tell IE what to do.  It turns out that "width" in IE6 (not sure about IE7) is actually treated like min-width so you can do things like this:

div.AspNet-GridView
{
  min-width: 30em;
  _width: 30em;
}

Then what happens is that IE6 picks up the _width (because IE6 ignores the leading underscore) but the _width is ignored by other browsers (Gecko, etc.) which do recognize the min-width (which IE ignores).  Still with me?  Ha ha.

OK, the problem with _width is that it's pretty hacky.  I don't like it, frankly, though I admit I've used it in the past.  I guess I'm a reformed sinner.

Now, I tend to use conditional comments to add <link> tags where I add IE6-only or IE7-only rules.  So I would have a general rule like this:

div.AspNet-GridView
{
  min-width: 30em;
}

And I would have the exact same selector in IE6-only and/or IE7-only style sheet that looks like this:

div.AspNet-GridView
{
  width: 30em;
}

Note that I'm not using the underscore here because I don't need the hack. The IE6 or IE7 style sheet will only get used when the browser is actually IE6 or IE7 so I don't need to mess around with the name of the property in the CSS rule.  Nice.

Thoughts?

Related to this, I found that the Pager section width was independent of the GridView table width but it looks OK in the demo since they default both to 100% width.  You can see in the HTML above in this thread that the table tag is closed before the pager section opens and I believe this is the cause.

I reviewed the GridViewAdapter.cs file from the sourcecode. It appears that a simple change may fix this:

Lines 124..126 from the original:

     writer.WriteEndTag("table");
     WritePagerSection(writer, PagerPosition.Bottom);

Lines 124..126 could be changed to:

     WritePagerSection(writer, PagerPosition.Bottom);
     writer.WriteEndTag("table");

I did not test this but it seems that it would take care of including the Pager section within the table tag.
Any comments? I'd be interested in submitting this as a change if it does not break anything else. How could I proceed?