We all know how various CSS implementations are bogus in browsers. If you think only iE has quirks, then here you can find some others. Of course, IE is the most broken, far, far more than anything else. But, this is not to topic for today.

What I want to rant about how the very design of CSS were broken. Why there should even be an article about how to make three columns? And calling this holy grail? Now come on. This should be easy to achieve and not be so hard that it's a myth to be found. It was easy with frames, it was easy with tables, now I pray, why it's not equally easy with CSS? I do know about CSS3 columns but come on, this is not even yet a standard, when there will be widespread browser support for it?

Now, a taste of things to come in Drupal six. I plan to introduce a hook registry. The most direct gain I plan to get is that module_invoke_all won't blindly merge array returns, that's not always desired. Per hook weights are often asked for -- the current weight system is a bit blunt. We might want add short descriptions for our hooks to self-document. Also, there are way too many invokes (user, node) and module_implements iterations, I hope to be able to provide one API for all them.

A very simple, but powerful change will be changing the hook called at the end of _drupal_bootstrap_full from init to start. This way we can differentiate between the init called by bootstrap and the start. This hook will replace hook_menu !$may_cache because the new mneu system won't have that.

Adding these two together, I will ditch menu.inc completely and move the menu system into a new, required menu.module (and moving the admin stuff into another menu.inc but in the modules/menu dir) and use menu_start instead of a special menu_execute_active_handler. Of course, a return path will be needed from _drupal_bootstrap_full back to index.php but that's a piece of cake. Using menu.module will let me move the navigation block from user.module to where it belongs: menu_block.

On devel list I already announced going to MySQL 4.1 so -- finally! -- we can use subqueries. Already there is a patch which intends to speed up a query in comment.module which would need these.

Once upon a time I wanted to introduce a system for blocks which would have used callbacks and some caching. It was deemed a monster, but I will take a stab and see how can we tame it.

I would like to see some form of materialized path in core to support complex taxonomies and books (and maybe menus too?). nested trees are a well-known choice, but if you insert just one element then you need to recalculate lots. I exchanged a series of emails with Vadim Tropashko on the subject and them it became clear the real problem is that whatever tricky encoding method we choose, weighted elements will always be a problem. His suggestion is that the tree viewer shall order by weight on display time -- as most tree viewers only display a fraction of the tree at any given time (think Explorer and files). Not so in Drupal -- book and taxonomy displays the whole tree. This will need some discussion. kkaefer had some excellent JS tree tricks but what how will we degrade? hmmmm....

Commenting on this Story is closed.