Addition of previous and next classes, and more flexibility for advanced theming

Does it? Only if someone alter's $data through a preprocess function, and doesn't properly sanitize it. But that would surely be the job of the altering module/theme, no?

EDIT: Maybe you are right Perhaps we should call filter_xss() on it here just to be on the safe side?

Well the point of enabling html in the titles was to allow for more advanced theming. For example, if you want to pass in an icon for each stage. So yes, I think it's important to al least allow those that want to do more advanced theming to do so.

What about for designs that need the content of the li element to be more than a simple string - perhaps part of that string needs to be wrapped in a span so that it can be shown in a different color? Or perhaps we need to be able to pull out images from the database and apply imagecache styles to them in order to allow administrators to associate icons with each step, or maybe the icons are contextrual and change depending on the content of the cart. Orr maybe we need to embed the output of a view within each list item? None of these things are unreasonable, and none of them are possible without allowing html into the li element.

In our case, we need to be able to wrap part of the title text in a span tag to allow it to be displayed in a different color and style. I would say that is not exactly an out of this world use case.

I'd love to know how you could wrap part of a string in a span tag using css alone!!? Or is there some magic css trick that I 'm not aware of that lets you target specific parts of a string in order to apply different styles to them?

How does allowing html into the li tag allow for an XSS attack? I don't think there is anywhere in the CMS that lets you enter html text that will be used for the progress step titles. They are derived directly from the code definitions of the individual checkout pages. The only way someone could alter them is through a custom module or theme, and if someone has the ability to upload custom code then this would be the least of our worries. It is generally assumed that if if someone has the ability to upload custom code then they have the ability to do anything.

> You need JS/CSS to style just a part of a LI tag.

Dont really see that as a very good solution, though doable of course.

> There are contrib modules that allow you to rearrange/retitle checkout pages (who add more checkout pages also)

If there are contrib modules that are allowing people to retitle checkout pages, they should probably be sanitizing data, no?

> Generally you don't want format different part of a title. Even you want, example that you give, like embed a view output, won't work by default, as filter_xss().

The views example was something I just dreamt up, although I can think of some cool things you could do using views here, or imagecache/styles. Yeah, filter_xss() wouldn't event allow my simple span tag actually anyway.

> So I think: 1/ it is a really edge to use HTML in the checkout page title

I think you need to think outside the box a little. It's really not that edge case. It's just not your run of the mill standard out of the box use case.

> 2/ it'd better to hook_block_view_alter() to modify the renderable array (if any) returned by this module.

Yeah, in an ideal world. However, I've been there before and unfortunately drupal's theme_list() doesn't actually use render arrays. Not without the core patch at #891112: Replace theme_item_list()'s 'data' items with render elements. I've used that patch on several sites, along with patches for og, omega, and various other modules and themes to make them take advantage of it. However, it's looking increasingly unlikely that that patch will make it into D7, which means no render arrays in theme_list output, which means hook_block_view_alter isn't going to be much help.

Ok, better than nout I guess. Thanks.