Ok first version is done ( this one will do the link replacement so you still need to do the other modifications but at least you dont ahve to do a recompile

add following to webconfig

<httpModules>

<add type="SchwingSemanticFilter.SemanticDNN,SchwingSemanticFilter" name="SemanticDNNHttpModule" />

</httpModules>

extract and put the dll file in your bin directory

http://www.schwingnuke.com/schwingsemanticfilter.zip

 

This is the first version so you can all play with semantic dnn ( I am working on making a new version so that all the changes outlined int he document to the original dnn forntedn code also wont be neccesary but for now here you hve it, Semantic validating dnn sites

nbc wrote:

So it would be great to get a little group of like minded DNNers together so we can produce real world solutions for the core.

Yes, I agree.  What do you think of my provider model idea?  Can you see any problems with it?  Does anyone want to work on a document that can be presented to the Core outlining the provider model? 
Does anyone have any better ideas?!

well the provider model seems ok to me, Right now you only have one doctype and for specific skins I might need a differnet doctype. You can do neat tricks in quiksmode for fixed postion and things.

I fixed this myself by making a usercontrol with a nr of panels each with one of the doctypes I use and then I doa simple select case on my portalids to determine which doctype i wanted to use in this. But for a new version of dnn dynamic doctypes would be great

Well since I started this all let me start with what I would like to ahve included in the new skinning engine

 

examples i propose here are based on an html skin

define the doctype

- I would like to be able to set which doctype I want use use for a skin  so in my html skin i would have something like

<doctype>my doctype here</doctype> - thsi would then be parsed somehow that I know that for this skin the header should have this doctype

<headertag>scritps and stuff</headertag> - This would be the same as what we have now as headertag section per page, but it would be much better to have in a skin since with all the new libraries coming out, moofx, jquery, scriptaculous, prototype etc) I use more and more of these effect to enrichen my skins but now I need to put in these headertags for each tab I use the skin on, or I would have to chenge the default.aspx. It would be much better if this is on skin level

this is just an idea, but for the future of skinning we need better options, just look at the wordpress themes, they ahve plugins scripts and other option that you can pack all kinds of extra functionality with your skin

 

isomies wrote:

I am working a new CSS based layout here: http://www.obrienit.se/cityost - would anyone be interested in a copy of the final skin (plus a psd file for updating the picture of the cheese to something else!)  when it is finished?

 

Sure thing isomies. Let me know where I can download it when you are doen. Looks good by the way.

nokiko wrote:

examples i propose here are based on an html skin

define the doctype

- I would like to be able to set which doctype I want use use for a skin  so in my html skin i would have something like

<doctype>my doctype here</doctype> - thsi would then be parsed somehow that I know that for this skin the header should have this doctype

<headertag>scritps and stuff</headertag> - This would be the same as what we have now as headertag section per page, but it would be much better to have in a skin since with all the new libraries coming out, moofx, jquery, scriptaculous, prototype etc) I use more and more of these effect to enrichen my skins but now I need to put in these headertags for each tab I use the skin on, or I would have to chenge the default.aspx. It would be much better if this is on skin level

I would also like the option to have total control over what external stylesheets are included.  i.e. I don't want default.css, portal.css, or container.css to be included.  I also want a stylesheet for printing purposes to be included.  I'd also like the option to remove all the comments that are inserted in the markup before and after every module.

That's a good idea to have the DOCTYPE and header information in the skinning engine, as different skins would use different doctypes.  However, I think a provider model would be a quick solution to get support in there straight away, and then develop the skinning engine afterwards.  With the provider model, the DOCTYPE would be set in Web.config, and would apply to all skins.

Hi

Is anyone using the httpmodule in a website yet, so far I jut have used it n test sites and so far no issues with performance but would love to hear other peoples experience.

And who wants to help with making css skins and release them to community, or recode some excisting core mods

For my next css and xhtml skin, I will try to use multi level light weight css vertical menu. The menu uses pure css, is light and with no java or other strange files for server.

It is a vertical menu with 2 level submenu. (actually n level)

Menu1
Menu1
Menu1
Menu1         Sub Menu1
                   Sub Menu1
                   Sub Menu1        Sub Menu2
                                            Sub Menu2
                                            Sub Menu2
                                                      


It does validate at xhtm 1.0 trasitional,  and works great in static pages. I wonder how I could embed the menu right into the skin rather then having it as a module?

Is it even possible to have the menu right in the skin? Or does the menu need to be packed as a module?

I will try out your httpmodule nokiko, and will post here when I have had the time to test it properly.            

hi

youcan do this using a skinobjct, i have acss menu on css.schwingnuke.com that you can downlaod after registration

 

well i just converted over a table based skin with lot of nested tables into a css based skin

3 floated columns with a lot of subcolumns all using floated divs and the pseed increase was enormous about 2 seconds loading speed per page.

even tho dnn has some issues with negative margins floated divs can be used even if there are validation errors or other doctypes

 

 

Good news Nokiko,

The method I used was also using floats which worked well in the Simple Red Leaf skin. - One thing that everyone should be aware of though is a particular bug that occurs in IE6, to quote my blog,

"I'm particulalrly developing skins that are using float properties rather than fixed absolute positioning to create as fluid and flexible skin as possible.

Unfortunately quite a few browser errors can occur when using floats.

One particular error that I am discovering more and more is the Peekaboobug. - This shows up in the IE6 browser. You will find that your images will randomly disappear. - As well as images, within DNN, this also includes your Token links such as your breadcrumbs, search register etc.

There is a discussion here which discusses a hack and an explanation of the Peekaboo bug along with other IE bugs."

You may find this article useful if you are coming across the bug. - But, make sure you test their hacks against IE7 - the hacks are now out of date for IE7 - you can't use the *html hack for instance, you need to use the box model hack to ensure compatibility with IE7 and to just apply the hack to IE6 and below.

Thanks,

Hello everyone,

Well, I've finally had a bit of spare time to go through Tims tutorial on getting DNN to validate and I've now got the Simple Red CSS skin working and validated to XHTML Transitional 1.0

You can check both 3 and 5 pane versions.
http://skins.dnncreative.com/Home/tabid/53/Default.aspx

http://skins.dnncreative.com/RedLeaf5Panes/tabid/65/Default.aspx

The skins still include the Javascript that Nik provided and I found the extra bit of code that I needed to get it to validate with the Javascript. - I will upload the updated skins in a while, want to do a bit more testing on the CSS containers.

- A tip: I realised once I had got the skin to validate that I had set up the containers in the wrong way. The layout of the containers was originally setup using the same method as the skin. - ie a div tag with a unique id - if you use this method for the containers, validation errors occur because you can only have one unique id per page, with several containers added to the page, I had several ids of the same name - not good! - So all I had to do was change the divs ids to classes and styled the containers using classes. - It now validates with several containers added to the page.

(The pages with any other modules on (eg. announcements module) apart from the Text/HTML module are not compliant yet, but it's a big step forward!)

Will check out your module Nokiko as it looks like a much simpler method to implement for everyone.

I've also added some links to CSS based articles / layouts etc. on http://css.dnncreative.com I will keep adding bits as I come across them on my travels, if you have any good links, feel free to add them to the site.

If your interested in Tims design on http://www.obrienit.se/ we did an interview which you can read here covering DotNetNuke CSS skins and validation

Thanks,

That's great news - Can you clarify this comment -

>>
The skins still include the Javascript that Nik provided and I found the extra bit of code that I needed to get it to validate with the Javascript. - I will upload the updated skins in a while, want to do a bit more testing on the CSS containers.
>>

Does it require JS to be fully complian?? Or is this pure CSS with no JS assistance to make the skins fully compliant and browser compatible?

Looks like a good move forward.

Nina Meiers

Hi Nina,

Sure, the Javascript is not required for compliance, but it is an interesting solution to a problem I had.

Consider this: You create a pure CSS skin and you want to have several style sheets for the skin, for instance a print.css and a iehacks.css stylesheet as well as your skin.css file.

If this was a skin for a client where I had full control over the portal I would probably reference the different stylesheets by changing the default.aspx file.

The problem is that I wanted to distribute the CSS skin to the community and you can not ask everyone to edit their default.aspx files!

So, the Javascript is a solution provided kindly by Nik which allows you to call into your skin the various stylesheets dependant on browser or if you are printing etc.

- The comment refers to the code that you surround the Javascript with to enable your skin to be valid. If you don't use the code, it will create an invalid skin. Nik provided the code earlier in this forum, but it didn't quite work right, think there was something missing from it. - Anyway after a bit of hunting around I found the section of code. - I will be uploading the new version soon so you can check it out.

There could be a potential flaw in this method - what happens if the user has Javascript disabled? - In my skin it won't affect it. - It will print, but it wont have any special print layout and IE5 will just have text one size to large and some spaces where it shouldn't - nothing too drastic. - All other browsers will display without any changes.

Regarding validation, all I did was tweak DotNetNuke to produce valid code and then made sure that my skin produced valid code.

The skin.css file produces valid CSS, but the default css files that come with DNN all create invalid CSS, so I need to edit the default.css files for the CSS to be totally compliant.

In fact while your here, perhaps the core team could look at the default CSS, having a glance through it there are quite a few places where you can reduce the amount of code used by using CSS shorthand and perhaps you could also look at changing the code to be compliant?

Thanks,

Hello all,

Just to let you know, you can now download the updated skin with the validation fixes from here:
http://www.dnncreative.com/FreeRedLeafCSSSkin/tabid/238/Default.aspx

Thanks,

Lee