Styling XML with CSS

by JamesDiacono 23. April 2010 05:26

I’m sure you’ve heard of XSLT (DON'T GO AWAY I'M NOT SUPPORTING XSLT!). XSLT is used to transform XML into different XML – for example, rendering XML as HTML.  An example:

The XSLT method

<album>
	<title>Funkentelechy Vs. The Placebo Syndrome</title>
	<artist>Parliament</artist> 
	<year>1976</year> 
	<funkativity>10</funkativity> 
</album>

can be transformed (using XSLT) to this:

<div class="album">
	<h1>Funkentelechy Vs. The Placebo Syndrome</h1>
	<p class="artist">Parliament</p>
	<p class="year">1976</p>
	<p class="funkativity">This album has a funkativity rating of 10/10</p>
</div>

Now the question is, "is h1 a better tagname for the artist of the album than artist?". I'm pretty sure the answer is no. However, the HTML engine has no idea how to display an artist tag - it treats every unknown tag like a span tag.

The pure CSS method

So display information has to come from somewhere else. Some people may find the idea of markup depending entirely on CSS for display abhorrent. I do not. I maintain that reading the source of the album XML block makes just as much sense as reading the rendered HTML version. And screenreaders...if I was a screenreader I'd want concise and descriptive XML, rather than having to wade through a bunch of HTML crap. And let's be real: everyone's web client supports CSS.

Styling XML with CSS is actually very simple and very robust. The first thing to understand is that HTML is just a custom namespace of XML. The second thing to understand is you can have multiple namespaces present in any XML document. That means you can use both HTML and, say, a custom namespace...which you can define and set styling rules.

I won't blather much more. I'll just fill you in on how CSS targets namespaces.

The CSS @namespace declaration

In short, I can write up a stylesheet which targets a specific namespace and only a specific namespace. My XML file would look like this:

<?xml version="1.0" encoding="UTF-8" ?>
<albums xmlns="http://jdiacono.org/music">
	<album>
		<title>Funkentelechy Vs. The Placebo Syndrome</title>
		<artist>Parliament</artist> 
		<year>1976</year> 
		<funkativity>10</funkativity> 
	</album>
<albums>

Here I declare that the XML inside and including the albums block is of the namespace http://jdiacono.org/music. Don't be misled by the namespace looking like a URL...I haven't even registered jdiacono.org and this is still valid. This is because namespaces are actually just unique, case-sensitive strings, and URLs tend to be unique and full of information. Let it be known that this block is all there is. It is a completely self descriptive block of pure data, which references nothing external.

Now to style this...here is my CSS:

@namespace url("http://jdiacono.org/music");

albums {
	display:block;
	}
	
album {
	display:list-item;
	list-style-type:decimal;
	margin-bottom:0.5em;
	padding:0.5em;
	border:1px solid;
	}
	
album title {
	display:block;
	font-size:2em;
	font-weight:bold;
	border-bottom:1px dashed;
	}
	
album artist {
	display:block;
	font-size:0.9em;
	}
	
album year {
	display:block;
	font-weight:bold;
	letter-spacing:0.4em;
	color:Green;
	}
	
album funkativity {
	display:block;
	font-style:italic;
	}
	
album funkativity:before {
	content: "This album has a funkativity rating of ";
	}
	
album funkativity:after {
	content: "/10";
	}

Now I have another example that is much more nourishing, which uses HTML and a custom XML namespace in the same page. You will need a browser other than IE to view this.

farmcode.org/sourcecode/cssNamespaces/cssNamespaces.xml

UPDATE: Looks like IE9 is supporting this!

Categories: CSS

Umbraco 4.1 Benchmarks Part 1

by Shannon Deminick 15. April 2010 18:42

This is the first installment of what will hopefully be many Umbraco benchmark reports created by various members of the core team in the lead up to the launch of Umbraco 4.1. This benchmark report is about the request/response performance of the Umbraco back-office. This compares 4 different configurations: 4.0.3 with browser cache disabled (first run), 4.0.3 with browser cached files, 4.1 with browser cache disabled and 4.1 with browser cached files. These comparisons have been done by using newly installed Umbraco instances with ONLY the CWS package installed. The benchmark results were prepared by using Charles Proxy.

Test Stats 4.0.3 4.0.3
client cached
4.1 4.1
client cached
Content app Completed Requests 68 7 46 6
Response (KB) 687.05 72.48 431.41 32.54
Edit content
home page
Completed Requests 50 2 34 1
Response (KB) 385.10 47.28 343.36 12.07
Expand all
content nodes
Completed Requests 17 17 16 16
Response (KB) 18.47 18.47 13.96 10.85
TOTALS Completed Requests 135 26 96 23
Response (KB) 1063.62 138.23 788.73 55.46

Note: the above is based on <compilation debug=”false”> being set in the web.config. If it is set to true, the compression, combination and minification for both the ClientDependency framework and ScriptManager is not enabled. Also, this is not based on having IIS 7’s dynamic/static compression turned on, these benchmarks are based on Umbraco performing ‘as is ‘ out of the box which will be the same for IIS 6.

Though there’s only 3 tests listed above, these results will be consistent throughout all applications in the Umbraco back office in version 4.1.

The 4.1 difference:

  • In 4.0.3, all ScriptResource calls generated by ScriptManager were not being compressed or minified. This was due to a browser compatibility flag that was set in the base page (this was probably very old code from pre v3!).
  • Script managers in the back-office have the ScriptMode=”release” explicitly set (for minification of ScriptResource.axd)
  • The ClientDependency framework is shipped with 4.1 and all of the back office registers it’s JavaScript and CSS files with this framework. This allows for:
    • Combination, compression, minification of dependencies
    • Rogue script/style detection (for those scripts/styles that weren’t registered with the framework will still get compressed/minified)
    • Compression/minification of specified Mime types, in this case all JSON requests in the back office (namely the tree)
    • Compression/minification of all JavaScript web service proxy classes (‘asmx/js’ requests that are made by registering web services with the ScriptManager
  • Much of the back office client scripting in 4.1 has been completely refactored. Most of the JavaScript has been rewritten and a ton of file cleanup has been done.

Compared to 4.0.3, this is a HUGE difference with some serious performance benefits!

Categories: .Net | Umbraco | ClientDependency

ClientDependency now supporting MVC

by Shannon Deminick 6. April 2010 18:38

I’m please to announce that the ClientDependency framework now supports MVC! It’s very easy to implement using HtmlHelper extension methods. Here’s some quick examples:

Make a view dependent on a CSS file based on a path defined as “Styles”

<% Html.RequiresCss("Content.css", "Styles"); %>

Make a view dependent on jQuery using a full path declaration:

<% Html.RequiresJs("/Js/jquery-1.3.2.min.js"); %>

Rendering the Style blocks and defining a global style path:

<%= Html.RenderCssHere(new BasicPath("Styles", "/Css")) %>

Rendering the Script block (no global script path defined):

<%= Html.RenderJsHere() %>

There’s still a provider model for MVC but it uses a slightly different implementation from Web Forms. The same compositeFiles provider model is used but instead of the fileRegistration provider model that is used in Web Forms, a new mvc renderers provider model is used. A renderer provider is similar to the Web Forms fileRegistration providers but instead of registering the markup in the page using the page life cycle, a renderer provider is used to render out the html block necessary to embed in the page.

All of the functionality that existed in Web Forms exists in MVC. You can make as many views that you want dependent on as many of the same or different client files that you want and the system will still sort by position and priority and remove all duplicate registrations. Rogue scripts & styles still get processed by the composite file provider in MVC. Currently however, if you place user or composite controls on your views that have Client Dependencies tagged with either the control or attribute method used in Web Forms, these will not be registered with the view and output with the renderer. 

MVC pages have been added to the demo project as examples so have a look! You can download the source HERE

For full details and documentation go HERE

ASP.Net Client Dependency Framework RC1 Released!

by Shannon Deminick 18. March 2010 17:13

With the community feedback, bug reports, patches, etc… I’ve managed to find time to upgrade this library to a release candidate status. We do use this framework in many production websites but it was great to hear from other in regards to specific bugs that were found relating to particular environments. These bugs have all been fixed up and this library is looking very stable.

You can download the binaries here.

Better yet, I’ve put together a near complete documentation library on CodePlex here !!

I still think the best way to learn about this project is to download the source code from CodePlex here and have a look at the demo web application included.

Moving forward, the next phase for this library is to add MVC support and another file registration provider called PlaceholderProvider which will give you even more granular control over where dependencies can be rendered in your markup. MVC support should be fairly straight forward and we’ll include a demo project for this as well.

Well definitely be releasing a final version soon after the next Umbraco 4.1 release candidate is released (which will hopefully be fairly soon!)

Happy day! Any and all feedback, bug reports and patches are definitely appreciated!

Client Dependency Framework Beta Released

by Shannon Deminick 29. September 2009 07:06

I’ve posted a new Beta release on CodePlex, you can get it here: http://clientdependency.codeplex.com/Release/ProjectReleases.aspx. On the releases tab includes a sample web site that has most of the functionality that you can do so please download it for a documentation reference.

Newest changes & additions

  • Namespace and codebase changes/steamlining
  • Proper versioning added
    • Versioning is done on a global basis in the config
    • Old versions are retained and can still be accessed from the Client Dependency URL that was previously used (if necessary)
    • Versioned composite files names are prefixed with the version number (i.e. version 2 files will be prefixed with '2_') so it's easy to figure out which files are old
    • The composite file map also reflects which composite file sets are under a specific version
  • Provider model extended to support 2 types of providers:
    • File Registration Providers
      • Still comes with 2 providers: page header provider and a lazy loading JavaScript client based provider
    • Composite File Providers:
      • Comes with the standard provider: CompositeFileProcessor
      • You can implement your own provider to customize the way that files are combined, compressed, minified, etc... if the standard provider isn't exactly what you are after
  • Forced providers! You can now force a dependency to use a particular provider. This can be useful if you want to ensure that a particular script or stylesheet is rendered on to the page differently. For example, you may want to ensure that a script is lazy loaded (using the lazy load provider) but the rest are rendered in the page header.
  • Utility methods added to the ClientDependencyLoader for more dynamic implementations
  • A test website is included in the release which doubles as documentation, it includes:
    • Standard page header provider example
    • Forced providers example
    • Lazy load provider example
    • Dynamically registering dependencies in your code behind
    • Registering dependencies with attributes and via aspx controls

Things //TODO:

I’ve finished off versioning so at least i can cross that off from the previous list. But there’s still more to do:

  • Implement functionality for jQuery CDN
    • This will be a new control/attribute to easily include jQuery in your project
    • You will have the option to select which CDN you want to use (Microsoft or Google), or you can supply an address (like your own CDN/web server)
    • Though this framework will be included in Umbraco 4.1, we’ll be leaving this functionality out of the Umbraco build as we realize that there are quite a few installs that operate behind a firewall that won’t have access to the CDN.
  • Implement skeleton for Microsoft AJAX 4 CDN
    • Again, this will be another new control/attribute to easily include Microsoft’s new brand of AJAX with their CDN solution
  • Add support for MVC
  • Support for JS/CSS Minification with options to disable per dependency
    • The reason this hasn’t been implemented yet is that I’ve found a lot of scripts/stylesheets break with minification so we need to be able to turn this on/off on a per file basis
  • Some more documentation/examples in the example web application

ASP.Net Client Dependency Framework Released

by Shannon Deminick 15. September 2009 12:35

Repository/Download

  • CodePlex Home: http://clientdependency.codeplex.com
  • The repository has the latest new version, the alpha release version is OLD so best to get the latest codebase from the Source Control tab!

History

I’ve been busy in the Umbraco core putting in place a new Client Dependency framework for version 4.1. I thought since this could benefit many other people/projects that I’d take it out of the Umbraco core and make it its own standalone project. Currently in Umbraco v4, there’s already a Client Dependency framework that you may have come across if you’ve decided to go deep within the core code. It was developed for Umbraco Canvas (live editing) by Ruben (and Niels I think) to be able to tag controls as being dependent on CSS/JavaScript files to be lazy loaded into the client’s browser to enable live editing of the page. I thought the idea was great and wanted to combine it with a bunch of work that we had done in the office already to make a library that everyone can use. So what does it do???

Features

Most of the features can be enabled/disabled in the configuration section. By default, they’re all enabled.

  • Make your controls dependent on client files by:
    • Attributing your controls
    • Using the JSInclude or CSSInclude web controls
    • Dynamically registering them in code
  • Provider Model so you can choose how you would like your JS and CSS files rendered
    • Comes with 2 providers: page header provider and a lazy loading JavaScript client based provider (the original lazy loader by Ruben… nice work!… slightly modified though)
    • You can explicitly tell the engine which provider you would like a particular script/stylesheet to be rendered out by if you require this. An example could be that you want one script in particular to be rendered in the page header, but another script to be lazy loaded.
  • Combining and compressing JavaScript and CSS files
  • Resolving the correct URL paths in CSS files while they are being combined so you don't have to worry about this
  • Combining external JS and CSS files
  • OutputCaching of the combined/compressed composite files
  • Saving of the combined/compressed composite files for increased performance when applications restart or when the Cache expires (persistent compression/combination)
  • Creation of an XML file map to tell you which saved composite files are for which real files
  • Easily clearing the cache
  • Tagging client files with priorites
  • Tagging client files with path names so you don't have to worry about moving files around in your project, worrying about absolute vs. relative paths, or running your application in a virtual folder

This library isn’t the answer to all of your compression needs, but it is a good start or addition to something your already using. Most other compression libraries out there are module based which can do page compression, script/css compression/combination, etc… and are all a really good idea. The compression/combination part of this library is just a really good bonus on top of what it is actually made for which is making your controls dependent on client files without worrying about duplication and having full control over how you want them rendered in your page (i.e. Provider model)

Umbraco Usage

Because there are so many controls in Umbraco and so many client files, its very difficult to keep track of what has already been included in pages, other controls, etc… This library is now part of Umbraco 4.1 codebase and all controls are now using it. There was a lot of hard coding paths to either /umbraco_client or /umbraco folders which is one of the reasons Umbraco won’t run in a virtual folder in IIS. This library solves the hard coded path issue.

What this means for package developers is that they don’t have to worry about whether or not jquery, or other JS/CSS files have been included in the page, they can simply add a client dependency to their controls.

Easier Team Development

If you’re working in a team locally in your office or one that spans between different office, this implementation makes things a whole lot easier for developing controls.

Things //TODO:

  • Need to add versioning
    • This will remove old versioned persistent files saved under any older version
    • Easier to deploy since right now you would need to remove the persisted files to remove the cache
  • Add support for MVC
    • This should be pretty darn easy i think
  • Adding some more providers (i.e. ScriptManager provider, etc…)
  • Documentation

Config

<clientDependency isDebugMode="false">
  <fileRegistration defaultProvider="PageHeaderProvider"
    fileDependencyExtensions="js,css"
    enableCompositeFiles="true">
        <providers>
            <add name="PageHeaderProvider" 
                type="ClientDependency.Core.FileRegistration.Providers.PageHeaderProvider, ClientDependency.Core" />
            <add name="LazyLoadProvider" 
                type="ClientDependency.Core.FileRegistration.Providers.LazyLoadProvider, ClientDependency.Core" />
        </providers>
    </fileRegistration>
    <compositeFiles defaultProvider="CompositeFileProcessor" 										
        compositeFilePath="~/App_Data/ClientDependency"
        compositeFileHandlerPath="DependencyHandler.axd">
          <providers>
            <add name="CompositeFileProcessor" 
                type="ClientDependency.Core.CompositeFiles.Providers.CompositeFileProcessingProvider, ClientDependency.Core" />
          </providers>
    </compositeFiles>
</clientDependency>

Includes/Usage

Implementation is pretty simple…

  • You need a ClientDependencyLoader to do the loading, only one of these can exist on the request (just like the ScriptManager in ASP.Net)
  • You can use CssInclude and JsInclude controls in your User Controls/Pages, etc… to declare that a CSS or JS file is required OR
  • You can use the ClientDependencyAttribute to attribute your composite control classes OR
  • You can programmatically add a dependency by using the ClientDependencyLoader’s methods (there’s a few of these overloaded methods):
    • ClientDependencyLoader.Instance.RegisterDependency("Content.css", 
                     "Styles", 
                     ClientDependencyType.Css);

The FARM adds a nail to the coffin of IE 6

by Shannon Deminick 20. July 2009 10:19

Days until TheFARM drops support for IE6



We are happy to announce that we will cease to support IE 6 development from Oct 31 2009. We will continue to support our clients’ existing websites but any new development will target Firefox 2+, IE 7+, and Web kit browsers (e.g. Safari, Chrome).

IE 6 was released in Aug 2001, it is 8 years old and 2 more browsers have since been released from Microsoft… it’s about time people stop using this horrible, horrible browser. Other larger players including YouTube have also stated that support for IE 6 will stop. We’re hoping that more agencies will adopt this idea and push for clients to finally make the upgrade or switch to a new browser… it’s 8 years old!

Comments are always welcome!

Tags: , , ,